8ch dimmer head scratcher

Have an 8ch dimmer that has head scratcher of a problem.

One load stopped working so I identified which one of the 4 dimmers it was and then which channel. I then switched the local dimmer pack channel to check the channel load and all was well. So then I checked that the dimmer was getting the C-Bus command, ran C-Bus diagnostic an can see the GA go on and off to a given command.

I have one unused/spare channel on the dimmer pack and another 6 channels connected to loads (plus dead one) so I checked the remaing 6 loads and no problems all worked fine.

The unit LED on the dimmer pack continuing flashes all other 3 are solid. The only other anomally is the Tag Name seems to have changed on the dimmer pack tp "REP 16708" I never punched that in and I am the only person to have accessed the system. Probably red herring stuff.

Anyway thought it must be a faulty channel so I swapped the load to the spare channel then reassigned the groups on the dimmer. Changed one of the keypads to reflect the change and then made a switch. Bugger me it doesn't work.

Switched the local load switch on the reassigned spare channel ....yep it worked OK......checked the command was being recieved to the reassigned group ......yep it worked OK.

What are the chances two identical channels that don't work via C-Bus but do at a local level?

I have powered down the C-Bus system including the CNI and rebooted....same situation.

I can see the GA switch via C-Bus diagnostics on the original channel and now the spare channel.

I can get both channels to switch the load at the local level but not the C-Bus.

FYI the load is 4 X 35 Decostar IRC halogens using Atco 60VA Possums on each lamp.

Can't help but think there is some sucker bait here.

Any thoughts or suggestions????

Thanks and regards,

Fleetz

 

Just swap the load the no longer workers on the two channels to a known to be working channel and that doesn't work other than at the local switch level!

I suspect there must be something with the load even thou all 4 halogens come up OK when it is switched to local.

I can only concluse that one or more Possums have failed some how. Has anyone else experienced any issue like this with the Atco Possum transformer???

Maybe the capacitance value has increased on one or more of the 4 transformers? Can this cause failure of a dimmer channel?

Methinks the dimmer pack is karput....well 3 channels/

Appreciate any feedback.

Thanks and regards,

Fleetz

 

A few things to try.

The most likely cause of your problem is that the Enable C-Bus Priority option has been turned off in the dimmer. It's on the Global tab in Toolkit.

When this option is turned off, you need to manually cancel local override mode on the dimmer, by holding down a channel button for a second or so, before the channel will start responding to C-Bus commands again. If the Unit LED is blinking then one or more channels are in local (or remote) override mode. The Unit LED stops blinking when all channels are back to C-Bus mode. By default, the C-Bus Priority option means that in-coming C-Bus messages will have higher priority than the local toggle buttons, and this is the default configuration. It sounds like this has changed on your unit.

If this doesn't solve the problem then take a look at the Logic tab. Make sure there isn't a group there that's keeping the channel off.

If the part name of the unit has changed (for whatever reason) then it's probably checking the other unit parameters. The most fool-proof thing to do might be to reset the unit back to defaults in Toolkit and then re-assign the groups to the channels.

If the channel will turn on and off from the local override buttons but not from C-Bus then it's likely that the load is OK, but it's still worth checking. Put an incandescent lamp on the channel and then try to control it from both C-Bus and the local toggle buttons on the dimmer. If it works fine from both then you know the problem is the load. If neither works then the problem is the dimmer hardware.

Plenty of electronic transformers don't like being under-loaded. With 35W on a 60W transformer it's running at under 60% load. Try replacing the 35W IRC's with 50W ones.

 

Hello Newman,

Thank you for your prompt and bang on the money fix. I can stop scratching my head.

Indeed it was the "Enable C-Bus Priority" not checked in the dimmer unit. I can not explain how it got unchecked nor can I explain the Tag Name changing to "REP 16708" all a mystery. If anyone else had access to my system then I could understand but no one has....... a mystery! But hey it is electronics and after 38 years in the electronic game nothing surprises me.

I now better understand the local and C-Bus Priority control functions on the output units, something I have not had to delve into before. It has been a set and forget function. You never stop learning!

Newman please take a bow and thank you for taking the time to help. It is appreciated!

Regards,

Fleetz

 

The thing that made diagnosing the problem easy was that you provided relevant information about what was going on, so thanks heaps for being clear and factual. You described the symptoms accurately, rather than trying to guess at what was going on, and didn't bias the information based on your suspicion of what the problem might be. You separated your suspicions from the facts clearly.

The key pieces of information in diagnosing the Enable C-Bus Priority option as the problem were:
- Unit indicator flashing. Excluding Learn, this only flashes in local or remote override modes.
- Part name changing. This suggested that the unit configuration may have unintentionally changed somehow.
- Moving the load to another channel replicated the issue, whereas other channels worked fine. This clued me in to the local override buttons being pressed changing something.
- Using the Diagnostic Utility to see the group going on and off. This ruled out another unit interfering with the expected behaviour.
- Stating that local toggle buttons worked but C-Bus messages didn't, which really clued me in on the Enable C-Bus Priority parameter.

Clear and complete facts are gold when diagnosing problems.

 

I agree with Newman here 100%

now.. making use of another interesting tid-bit you have reported:

If the unit were experiencing some memory corruption due to cosmic rays or similar, I would expect one or two bits of EEPROM to change state. This would likely just change one or two characters in an otherwise normal unit name. Is the name "REP 16708" one or two characters from what you expect the unit name should have been?

If it was really sick, and the firmware was corrupted to the point of running off through uncharted ROM*, then I would expect complete gibberish in the name field.

Changing to "REP 16708" from a completely different name seems to me to be highly unlikely, and therefore, methinks; likely to be an important clue to some subtle problem in either C-Gate, or Toolkit. Is "REP 16708" anything that you might have keyed into the PC at any time, and perhaps could have been accepted as a string input to Toolkit?

 

Hi Don,

No I can confidently say I have not typed "REP 16708" but off course can say 100% I have not. When the name changed is anybody's guess. I suppose I only noticed it when I went looking for anomalies.

Strange that it is only this dimmer pack (4 in the installation + 3 relay units) had the two anomalies. The Enable C-Bus Priority was previously checked.

Why all of a sudden it went of with the pixies is as I said a head scratcher......it probably will remain that way. The only concern is that something might not be stable be it C-Gate , Toolkit or a dimmer pack.

All I can do is keep an eye on it, hopefully it has been resolved but I will be looking at the system sideways for the moment.

Will report any further issues if they surface.

Thanks for the input.

Regards,,

Ian

 

Hi Nick,

Unit address is 003.

The only other device that is connected to the C-Bus system is a Ness C-Bus interface V3.

Regards,

Fleetz