PC Interface control of lighting

Not sure if this is a hardware question or a software question, but I'm trying to control lighting groups via an external device, using the serial interface into the PC interface. I'm using the lighting protocol (limited release) and am seeing some funny behaviour which I'm wondering if others have seen. I'm activating lighting each time an event happens in the controller and have noticed that the last light which is activated in a sequence turns itself off after (what appears to be) a random time. Could be from a few seconds to minutes. I am breaking the protocol to the extent that I'm leaving the checksum off (it's a pain to calculate this dynamically). But the lights all turn on when they're asked to. But if I turn on, say, 5, then the last one activated will usually turn itself off before the controller does.

Anyone know what would cause this? As a test, I've just issued a control to turn on a non-existent group every minute, to see if that mostly eliminates the problem (the theory being that this non-existent group will become the last one activated and thus turn itself off - which is fine).

Thanks

Ben

 

Ben

It might be a PIR detector on that group address on the system somewhere. If you turn on a C-Bus Group Address and then trigger (walk in front of) a C-Bus PIR somewhere that uses the same Group Address then the PIR timer would run and turn the Group Address off at some time later. Worth checking this out.

Can you also say what version of PCI you are using and which C-Bus units you have on your network that have the group address that turns off in them.

 

Thanks for the replies.

The PC Interface firmware versions shows as 4.3.00. I don't have any PIRs on the circuit (at least not CBus PIRs - I use PIRs attached to the home controller to send a signal to the PC interface whenever PIRs are activated. I've isolated these though and still see the same effect.)

I am using Area addressing and it does span multiple outputs. I've seen some other problems with this so I know what you mean, but these units are turning off with no external input which I can see. I haven't put an analyser on the RS232 interface between controller and PC Interface, but can be pretty sure that there is no explicit message going on there, as the unit which turns off has changed as I've added more control. At the moment, this has happened on the 8-way DSI output and a normal 8-way dimmer. I can say that the only outputs which are turning off are ones which I've activated (using their group number) via the PC I/F. I send an Area address to turn all units on and then activate some of them (turning them on if they are already on) later. It is the last one of those that has been activated this way which is unstable.

 

Ashleigh,

Many thanks. I'll get rid of the Area addressing and hopefully see this disappear. I didn't need it particularly - just saved a bunch of individual lighting commands.

 

Do you have any key or sensor units with the same groups in them as the groups you are controlling from the PC Interface? If not, you can rule out area addressing as the problem. If you do, then be aware that the key unit must be included in the area addressing in order for the system to work correctly. refer to http://www.cbusforums.com/forums/showthread.php?t=879
for information on the use of area addresses


The PC interface version you have is just fine, no problems with that one that I am aware of.

What command are you using to turn on the load? You should be using a ramp-to-level-at-rate command with ramp rate = 0 and final level whatever yopu want (but not zero). he output (dimmer) units have no timing mechanisms that can turn off a load, but the load can respond to the logical combination of the group you intent to control and up to 4 other groups. Is there any chance that this logic is active and one of the other groups is turning off?

Don

 

Thanks Don,

I haven't got the database in front of me, so can't check, but I suspect you may be right - I doubt that I worried too much about input units, and the post you refer to does teach me a lot!

I use the Ramp to level command (over 4 seconds), but I've noticed that the lights turn off immediately (ie no ramp).

I'm away for a couple of days, but will reprogram the whole thing (without area codes) when i get back.

Many thanks again

Ben

 

I've now set all the area addresses to be the same, removed the area turn-on, and am turning on the lights individually (but still using the PC I/F rather than any switches. It still doesn't work. Lights still turn off after some time, sometimes after as little as a few seconds, but more often after a few minutes. The next thing I'm going to try is using the full command protocol (ie using the checksum) just to remove that as a source of error. One of the groups has address 0, and this doesn't turn on at all. Is there something special about Group 0?

Will report back when I've recoded to use the checksums.

Ben

 

I've now coded in all the checksums and the acknowledgement character. Can't be entirely sure that the checksums are correct as the controller I'm using is pretty basic. But the small checks I've done seem ok. I've also changed the system to disable MMI reporting. Things still aren't working correctly, but I've done a bunch of tests and have seen some changes.

I use Area addressing to turn the whole area off (All units have the same area number now), but turn on each using the Ramp to Level command. I try to turn on about 6 lights in a row using this technique, and haven't seen any lights turn off without my telling them to (although I can't be absolutely sure this isn't happening, as it takes a while to see that). They also seem to turn on when I just turn one or two on at once. However, when I do 6 at once (ie 6 ramp to level commands in a row), then only the first 3 or 4 turn on reliably. Sometimes 3, sometimes 4. Is there a buffer on the serial port to the PC I/F which can be filled? And what happens if it does? It looks like it may be dropping the last 2 or 3 commands. I've also tried adding small delays (1/10 sec) between commands, but this hasn't changed anything.

Any ideas?

Thanks

Ben

 

nothing special about address 0

If you are assembling commands with a header and more than one lighting command before issuing the frame with a carriage return, then there is a limit of 4 ramp-to-level commands before the bus buffers in the units get too full. This could explain some lost messages. I would recommend one ramp-to-level command per message until you get everything working perfectly, then add the optimisations.

From what you said, it sounds like the lights are staying on now. Is this true?

Don

 

Don,

Thanks for the reply.

As far as I can tell, the lights are staying on now, although I probably haven't watched them for long enough to be absolutely sure.

I send each control command as separate message (ending with <CR>). Each one is now prefaced by a 10msec delay. But only the first four in a sequence is acted upon, so it looks like it could be a buffering issue. I'm trying to do 6 circuits in a row, but they are all sent as separate commands. How long should I wait between commands (or at least a sequence of 4) before the buffer has been cleared (if it is a buffering issue)?

Ben

 

It really sounds like a buffer issue, as you suspect. The best solution is to wait for confirmation of each transmission, but that will make your side more complex, and it looks like this is undesirable. To determine a suitable delay, it is useful to consider how the PC interface and C-Bus communication works.

Whan a command is sent to the PC interface, it is sent to a FIFO buffer(22 characters), which is emptied into the C-Bus transmit buffer only when the PC interface C-Bus side is ready for more data. C-Bus transmission of a short lighting command takes about 24ms, assuming no re-transmissions required due to noise or bus activity. Note that it is likely that a network Status Report will be encountered on the network, as these are initiated regularly by units to check status of groups, A Status report takes 148ms of bus time.

As suitable delay between frames would be ~170ms, which will allow for a status report in progress on occaision.

If you want to speed up the response time of your commands, you can concatenate up to 4 ramp-to-level commands or 6 on/off commands within one frame.

Don

 

Thanks for this Don.

I've now added the delay between one set of 3 commands and the other, and it's working!

I like the idea of concatenating commands. This format isn't explained in the protocol. How many checksums, and ack characters do you use? I presume there's only one '\' too.

Thanks again for the support.

Ben

 

concatenated commands

If you can monitor network traffic coming over the network, you'll see what concatenated commands look like every time you press a key on a unit which has that key selected to control more than one group. All C-Bus units use concatenated commands to streamline their communications.

From a PC Interface, you need the same header information: backslash, message type, destination application and number of networks, then where you would insert a 2 or 3 byte command, you can insert more than one command, then finish with a cariage return(cr).

If you choose to send a number of commands always to the same application, the PC Interface remembers the backslash, message type, destination application and number of networks, so you can simply enter more commands followed by (cr) with NO backslash or other information, and each time, the PCI will add the missing stuff and send it on the C-Bus network.

(I'm not sure if the info you have told you that)

Don

 

Thanks - I think I'm set now

Ben