C-Gate <-> PICED loses status after reconnect after 2hr timeout

As my wife can not make up her mind about how she wants things to work until she has seen it work and always wants small changes.

I have been debuging PAC code in PICED. The trouble is I would love to be able to just let the PICED code run on the PC for a week till all the bugs and modifications are done and then program to PAC. (So I don't use too may of the 100 program cycles)

1st problem is the 2 hr time out. I know it is there so you cannot get a free Home Gate type system. Can clipsal have a version you can "BUY" that has this limitation removed ??

The 2nd problem I have noticed is that if PICED disconnects after the 2hrs and a group address then changes (that is not associated to an output) and then you reconnect C-BUS(via menu), PICED does not see this change. I thaught even though PICED disconnects from C-BUS C-Gate is still running and C-Gate holds an array of all the current group address status. It would have seen this group address change. Why when you "reconnect" does PICED not refresh its knowledge of the status of group addresses from the the C-Gate Knowledge. At the moment I have to toggle the group address for PICED to get its current status. Am I just wrong and C-Gate does not hold this information.

Charles

 

Hey CC

You should be careful using your pc to test code that is going to run on a PAC. I have found that even if the code works ok in ur PC it doesn't work on the PAC ( i think it has to do with the processor speed).
To answer your other questions, they do make have a version to buy it's call homegate or shcedule plus.
I'm not sure about cgate but i think once you have disconnected (or been disconnected) cgate stops polling the network, until you reconnect to it and because the address isn't in any units it can't find the start of that address... ( maybe one of the cis guys would have a better answer)

 

The following is my understanding of what occurs :

1. Cgate doesn't actually "store" anything at all... it's just a server that make a connection between Comp and C-Bus.

2. I believe that PICED only sees the on/off/ramp events, it doesn't actually check whether the load is on or off. In other words, it changes it's status based on seeing a command going out onto the network, but it doesn't actually "poll" the output devices to see what they are doing.

I think that the switches can re-synch themselves (LED status) after a while, but dunno if PICED ever does so. But even if it did, if you had a Group Address that is not associated with an Output, then I doubt there is no way that PICED could know what level it was at...

The honourable C-Bus techie ppl will probably give the correct info...

John

 

PAC limit is 1000 cycles. See http://www.cbusforums.com/forums/showthread.php?t=2525.

I will have a talk with Marketing about this.

I have just tested this and it works perfectly. Can you provide details of what is happening to our tech support people so they can look into it ?

Correct. C-Gate monitors and maintains the state of all Groups, once it has opened the networks. If you disconnect from C-Gate, but leave it running, it maintains the correct state of all groups.

 

C-Gate stores the state of all group addresses and units. This enables it to respond instantly when you ask C-Gate for a group address level.

This is correct. However, when PICED connects to C-Gate, it send a command to ask C-Gate for the level of ALL groups known to C-Gate so that PICED can get the initial levels right. From that point on, it monitors the on/off/ramp events for any changes.

There is a patented mechanism called MMI which enables the switches to re-synchronise themselves. PICED also uses this system indirectly via C-Gate.

Correct. If a group does not exist in a unit and has never been transmitted onto C-Bus, then C-Gate (and hence PICED) will not know about it or its level.

 

I just sat down (now the end of the FIN year has passed) to document this issue for sending to Support.

I created a seperate test network PCI, RELAY,SWITCH. so it could be independent of my installtion and so support could recreate.
Well everything works as expected !!!

So I then test my install again. (mine uses a CNI) (freshly rebooted machine) and again all works as expected !!!

I have seen this issue many many times (so I know it is not a once off) it might me time related so I will let some time pass and see what happens.


Charles

 

C-Gate, PICED and PACS

Darren,
Can you confirm???
It is my uderstanding that a PAC controller rebooted or restarted only looks for the status of output devices NOT input devices.
We have completed several projects where, for many reasons, there is no direct programming from the input devices to the outputs.
When modifying these projects we have had to manually go around and retrigger all inputs to "synchronise" comms and ensure all statuses are updated within the PAC.
AND

Is there a way of polling all groups for status on start up of the PAC or Colour C-Touch??

 

I fixed this issue by using the initilisation feature of the pac. write some code so all the group addresses not on outputs are set to known values.

Charles

 

The PAC uses the MMI mechanism to determine the state of groups after first power-up. This has a couple of limitations :
1. Only output units provide data in the MMIs
2. It only provides state (on/off), not level
Once PAC has been running and has seen a level set, it will remember that level, even after a power failure.

Not at the moment.

 

Noticed in release notes
8910 Allow longer connection time to C-Bus for testing.

Thanks Darren.

What is the new time out ?? 24 hrs

Charles

 

The new time-out is a random time between 2 and 3 days.

 

This is great thanks darren.

CHarles

 

So what is the new time OUT?

 

Interesting cause, when I posted, the two items (Darren's and Charlie Crakle's) above where not even there ....