Once Condition activated by Key Only

I have a number of GA that I am trying to control with one key on a NEO and other conditions that the PAC monitors.

I have setup a Scene (PAC) with the above GAs ( I decided to use a scene, because I can get the GAs to switch on in stages).

On the Neo I have a virtual GA that toggles ON/OFF and on the PAC; I have a module that uses ONCE to activate/deactivate the above scene based on the virtual GA.

Code:

once (GetLightingState("All Wall Outside Lights")=ON) then
begin
       SetSceneLevel("Wall Outside Scene",91%,"0s");
end;

once not (GetLightingState("All Wall Outside Lights")=ON) then
begin
          {Swtich All Outside Wall lights OFF}
          SetScene("Wall Outside Scene");
end;

This works fine, when I press the key on the NEO the GAs turn on and off via the scene.

Now I added code in other modules that monitors other conditions to turn the virtual GA ("All Wall Outside Lights") on and off based on some other conditions, which in turn should activate/de-active the scene. However this does not happen.

I know the PAC conditions handle the virtual GA properly because the status LED on the NEO changes as it should, but the GA in the scene do not. If I press the key on the NEO, all works.

What is interesting is, if I connect my laptop to try and debug, everything works fine, I disconnect my laptop and the logic code stops activating/deactivating the scene.

Any ideas???

 

Can you send in your project archive to Tech Support and ask them to pass it onto me ?

 

Hi Darren,

I have sent the archive to [email protected].

 

I believe that the most likely cause of problems is due to the amount of code being executed. Can you check whether the PAC is resetting itself when this problem occurs ?

If the status indicator stops flashing for a few seconds, this means that the PAC has reset itself due to a problem (in this case, too much code).

 

Will check.

Will this be too much code in one particular module, or too many modules executed at once, or too much code in total, that is all modules?

 

The PAC logic engine will reset if you try to run too much code in one loop. If some modules are disabled, or paused, then their code doesn't count. See the logic help file "FAQ" section, "How much logic is possible ?" topic.

 

Hi Darren,

I had a look at the FAQ and at the Operation Section of the Logic Help File which defines a loop.

What I do not understand in this case is ... If I add an additional lines of code in the logic (Logic Line 56 and Logic line 90) to change the scene as well as the GA, it "seems to work okay", if I remove the the above lines and just change the GA, the GA changes, but the once conditions does not seem to take effect.

If you look at the archive, you will see that most of my code consists of once conditions (90% of the modules). This modules are are not disabled or paused, will their code count as well?

 

I have disabled the lines which you say are necessary for it to work, and it seems to work correctly.

You use a series of variables (such as DarkOutSide) which have not been initialised. They get set in Once statements, but these don't get executed until something changes state. This means that these variables are undefined until that time. These need to be set to an initial state in the initialisation section of the code.

It may also be of help to put some debugging information in the code (LogMessage only works for colour C-Touch projects, but you could convert it for now to get it working in PICED).

If this doesn't help, you will need to provide additional information to Tech Support with exact details of how to make the fault occur and details of what you expect to happen and what does happen. They should be able to resolve it for you.

 

Testing with a PC or PC connected to the PAC always worked, how did you guys do the testing?

After looking at the ?How Much Logic Is Possible? section of the help file and your comments, I decided to re-look at debugging the logic again.

As I said earlier, I could not debug, because when I connected my PC to the network, all worked and I could not cause the condition to occur. Even testing on the PC alone could not produce the condition.

I added logic in the initialize section to pulse specific GA when the PAC resets. Disconnected and waited for the condition to occur. Once the condition occurred, I commented one line (at a time) of logic and transferred the project to the PAC, disconnected my PC and waited to see if the PAC resets. After a few tries, I found the course, which was surprisingly

Code:

 SetScene("All Downstairs Lighting Scene"); 

in the procedure ?AlarmInNightMode?

I deleted about 3 GA in the scene and tested again and everything worked as it should.

Does this mean GA in scenes would be counted as part of logic lines?
Or would it be that one of the GA was the cause?

 

Sorry, I had forgotten that it worked on the PC, but not in the PAC. I tested on a PC.

OK. Executing this scene is obviously "the straw that broke the camel's back". You must be right on the borderline of what the PAC can process and these extra couple of Group Addresses in the scene is making it take just that little bit longer (too long) and causing the PAC to re-start the logic.

You will need to either :
1. Remove some logic (presumably undesirable);
2. Improve the efficiency of the logic code; or
3. Change the code so that not all of it runs each loop.

For option 2, see logic help file, "FAQ" section, "Efficient Code" topic. The code is generally quite good, but specific minor suggestions include :

Replace (DarkInSideHouse=true) with just DarkInSideHouse (the "= true" is redundant)

Replace GetLightingState("All Entertainment Lights")=ON with GetLightingState("All Entertainment Lights") for the same reason.

Reducing the number of modules will help a little.

Where possible, when you set a mode, apply any other changes at the same time, rather than checking the mode later and applying the changes.

Scenes can be triggered directly, rather than using logic.


For option 3, see logic help file, "FAQ" section, "How much code is possible" topic.

 

I am busy trying out option 2.

Thanks Darren.

NB: What are the chances of PICED (in future) telling you when you are at the borderline?

 

This has been discussed in other posts. Basically, it is very, very hard to do. I agree that it would be invaluable, but it would be months of work to do it accurately.

 

Hi Darren
Is there a smll bit of code I can add to the PAC that would signal on a Ctouch Screen that the PAC was crashing?
PAC is hidden away so watching the LED is not easy
thanks
Mike

 

You could add some code in the Initialisation section of the PAC to set a group address for example. On the colour C-Touch you would then be able to see that the PAC has started up.

 

I'm obviously not understanding the problem/symptoms
if there is too much code does the PAC fail to initalise and then just sit there doing nothing?
I assumed it started and then at some point hung
Mike

 

As far as I saw, when there is too much code, the PAC would restart. When PAC starts or restarts the "Initialisation" part of logic is executed.

What I did to identify that PAC restarted, was to pulse a GA (that is not set anywhere else in the logic) ON. Choosing a GA that is not used elsewhere makes it easy to identify and simplifies what could be complicated if other parts of the logic starts fiddling with the GA and gives you the impression that the unit was reset//restarted.

I placed the above mentioned piece of code in the "Initialisation".

After loading the changes into PAC, the unit is restarted; the GA switches on for predefined time and then switches on. I would then monitor the GA, and at any time (except power failures of course) the lights (which are controlled by the GA) are on, I would know that PAC crashed/restarted.

 

As far as I saw, when there is too much code, the PAC would restart. When PAC starts or restarts the "Initialisation" part of logic is executed.

What I did to identify that PAC restarted, was to pulse a GA (that is not set anywhere else in the logic ) ON. Choosing a GA that is not used elsewhere makes it easy to identify and simplifies what could be complicated if other parts of the logic starts fiddling with the GA and gives you the impression that the unit was reset/restarted.

I placed the above mentioned piece of code in the "Initialisation".

After loading the changes into PAC, the unit is restarted; the GA switches on for predefined time and then switches on. I would then monitor the GA, and at any time (except power failures of course) the lights (which are controlled by the GA) are on, I would know that PAC crashed/restarted.

 

I have upgraded to PICED 3.4.1 (after installing Toolkit 1.3.0 and finding out the hard way that PICED needs to be upgraded as well).

For some reason the borderline has shifted. The logic code was not changed, the only newbie is the version of PICED. Most of the logic that was fine, started crashing as well. I am busy trying to isolate the crash-causing line number, but I thought I should ask if there is anything in the new version that would cause this?

 

There were no changes at all to the logic engine between V3.4 and V3.4.1