PAC store phantom groups?

Hi, I'm fairly new at working with the PAC so please forgive me if im missing something trivial. What I am working with is a 3rd party automation system that interfaces with the CNI to communicate with C-BUS. Basically all I get are the ability to control any group within the lighting address 56. These jobs have only dimmers/relay boards and no input devices to control the dimmers, this is all done by the automation controller. Everything works perfectly if i'm controlling a group address that is assigned to one of the dimmer output channels. I can turn on/off any of these groups and the state of these groups is always correctly reported back to the automation system. If i try to create a group in toolkit that is not assigned to an output channel (this would be called a phantom group if im not mistaken) I can turn that group on via the automation controller but in about 30 seconds or so the cbus network reports back that the state is off. If i assign that group to one of the logic groups on a dimmer and uncheck all the channels assigned to that group then the state is preserved as it normally would be. So is there a way to have the PAC store these phantom groups somehow and keep there state correct on the network? I wouldnt have a problem using the logic groups method however, im limited to only 4 groups per dimming module then and that isn't enough on some projects.

I have been using the PAC to store scenes on these projects and triggering them with these phantom lighting group addresses. It works perfectly but I lose the state of these groups within 30 seconds unless i assign them to logic groups then the state is preserved as one would normally expect.

 

When you say that the "cbus network reports back that the state is off" what do you mean exactly? Is there a lighting "off" message? Or is the MMI mechanism reporting the state is off?

To me this sounds like some sort of MMI correction happening.

There is no need for the state to be "preserved" while the system is operating. It seems more likely that the dimmer is contributing to the MMI messages once the group is being used by the dimmer.

The PAC does not contribute to MMIs, so this will not help.

I would suggest running the C-Bus Diagnostic Software connected to another PCI or CNI to observe and record the C-Bus messages. Set the "monitor" option in the mode settings and make the problem occur. There should be clues in the log which indicate what is happening. If you are unsure, post and extract from the showing the 30 second period from setting the group to it being changed back again.

 

Thanks for the help Darren. Much appreciated. Would i be able to log these events through the PAC or would I have to put a 2nd CNI on the network?

I guess what I really am wondering about is what is the best option for creating phantom groups in a system with no input units, just dimmers, a CNI, and a PAC?

 

You can use a PAC as a USB PCI. It will not execute its logic, scenes and schedules while you are doing this.

Only output units (such as dimmers and relays) contribute to the MMIs (assuming that is what made the difference).

Is is best that we understand the cause of this problem and fix it, rather than masking it with a solution which works, but we do not understand. What you are observing is not normal behaviour, and it is important to work out what is going on.

 

C-Bus Ethernet xAP Gateway.

I'm guessing that's Scott from Toronto.. using one of our C-Bus Ethernet xAP gateways for the automation ?

If so you're using old firmware where the MMI's were resetting the gateway state table. Just upgrade the firmware in the Ethernet Gateway to latest and it will then track 'phantom' groups correctly on the lighting application (56). It doesn't matter whether they are initiated from your automation system or from C-Bus. Unfortunately there is no ability using a C-Bus SIM module to participate in the MMI mechanism and hence maintain a persistent state.

Also you can now send commands to all lighting compatible applications on C-Bus, although it still only maintains an internal state model for application 56.

K

 

The fix for phantom loads not being able to keep their status is...
Populate the logic section in the output units with the Phantom group addresses and then remove the tick so it will not control any channels