PAC takes along time to learn.....

I am finding that I program and debug using PICED. THis all works OK.

I then down load to PAC and think it should work the same.....

Wierd things would happen. I have worked out it is that the PAC after downloading thinks all group addresses are OFF (0). As network messages are send around CBUS is learns the actual state and changes them. THe problem is that some logic may depend on group addresses it has not learned the state about yet.

Ie a program does some thig if "YYYYY" = OFF

"YYYY" is actually ON but the PAC has not learnt this yet so executes the YYYYY = OFF code.

if you quickly toggle all the group addresses (via Tool Kit) that the logic program uses it learns all the correct states and all is OK. And then logic works fine.

It would be nice if there was a way that when you download the new program it also downloaded the states that CGATE currenty knows (when you were debugging). That way it would be off to a running start.


The same issue is true with PICED. If you start it from scratch and then load logic and run logic it also takes time to learn the group addresses states.


I have notices that after about 1 minute Cgate will learn the correct state of the group address even if there is NO change to the state of the group address if the group address is attached to a relay unit or a switch. (I assume this is the CBUS checker checking for inconsistencys). I have noticed that group addresses connected to SENPIRSS do not update automaticly. I have some on the SS and DA and unless their group address changes state CGATE never learns the correct state.


To get around this I was thinking of putting in the initilisation section some code that changes the group addresses so that they get learnt Quickly.
or
Is there some cbus message to read the Actual State. and corresponding PAC command ??


Charles

 

The PAC establishes the correct state (not level) of all group addresses within two MMI frames. By default the MMI interval is set to 3 seconds, so the correct state should be known within 6 seconds. The correct level will not be known until the next time it sees a C-Bus message for that Group Address.

All levels are stored internally so that after a power failure, all levels are known instantly. Therefore this issue only exists briefly when the device first has power applied.

In the future the PAC will be changed to make it more like C-Gate, where it goes out and scans the network to find the levels. This still takes some time to do though.

 

Please excuse my ignorance. I assume you mean by MMI this the process that output units keep in sync the input units status. if there was a break in comms.

(I tried to do a search in the Forum for MMI incase there was other doco that explained this but it say {"MMI" search term TOO small } )

But does this apply to input units that have group addresses that are not attached to any output unit. (ONLY the PAC).

The current project had 10 SENPIRSS. I am using the sunset function to determine wether the area is light or dark. It has a group address and the only other place this is used is on the PAC. The areas are dark so the Group address is ON. The PAC thinks the group address is OFF. It does not learn the state until the room goes light and then dark (takes 24 hrs !!) NOT 6 seconds......

Charles


Cgate has the same issue.

 

You are quite right. I didn't want to go into a long winded explanation of the subtleties of the MMI mechanism. The MMI only synchronises inputs and outputs. If a Group Address is not used by an output unit (dimmer or relay), then it does not get reported in the MMIs. Therefore, the state of these Groups will not be known until they change.

C-Gate does things differently. It sends out messages to read the Group Address values from each unit. Colour C-Touch does the same thing. Eventually, PAC will do this too. This is very complicated and time consuming, which is why it hasn't been done in the PAC yet.

 

So would a way around this be to set these group addresses in the initialisation part of the PAC. I assume if the PAC sets the state it learn it !

 

That is one way of doing it

Note that this is only a problem the FIRST time you power it up after downloading the project. After that it will be fine following a power failure, since it recalls the levels from EEPROM.

 

Point of Clarification

Correct me if I am wrong. Initialising group addresses in the initialisation section of the PAC would set the associated GA's to levels as far as the PAC was concerned. These levels may not represent the actual levels of the groups in C-bus land.

Where initialisation is helpful is to ensure the GA's are defaulted (for want of a better description) so logic programs (code) are not inadvertently actioned.

 

The PAC would sent the initialised values onto the C-Bus so the other units would change to match the initialised values.

 

When you do a PAC reset is this the same and a power on off ?? (IE does it keep the memory of levels ?? )

Is there a way to know in a program the reason for the last restart?
1) PAC Reset
2) Power Failure
3) Program Download


Even if levels are stored in eeprom they may be wrong after a power outage especially if group addresses are only applied to input units. Output units may have default values after a power failure but MMI would pick this up after 6 second. Trouble is logic may run wrong for that first 6 seconds especaily if PAC used to control pumps and read levels. I think it is still safer to sent any critial group addresses in the INIT section.

Charles

 

The levels get erased in both cases.

No