PAC logic problems - 'once'

Hi all,

I'm probably clutching at straws but my new logic isn't working as expected and I'm running out of idea's.

I'm really suspecting there is either an issue or a difference in 'once' logic with an 'and' condition when running on the PAC verses running in PICED. My logic below in PICED seems to work. It doesn't when downloaded onto the PAC
Is it possible I need an extra set of brackets to enclose all the conditions in the 'once' statement below?

I've copied the below logic out of two different modules:
This logic is in one module:

if (Time >= sunset) or (Time <= sunrise) then
begin
bDarkOutside := TRUE;
end
else
begin
bDarkOutside := FALSE;
end;

And this logic is in another module:

once (bDarkOutside = TRUE) and (DayOfWeek in ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]) then
begin
{ If they're already on, leave them on and don't schedule the auto off }
if (GetLightingState("Verandah and Garage") = OFF) then
begin
SetLightingState("Verandah and Garage", ON);
{ Flag the fact that they're on automatically so we can automatically turn them off }
bAutoFrontLightsOn := TRUE;
end;
end;

I should mention that bDarkOutside is initialised to FALSE within 'Initialisation' and I checked that the lights weren't on when I downloaded the new code.


Another piece of logic that seems to work from PICED but not on the PAC is:
once (TimerTime(ord(TMR_STARTUP_SEND_SMS)) >= STARTUP_SMS_DELAY) and (GeneralSendSMSString = '') then
begin
TimerStop(ord(TMR_STARTUP_SEND_SMS));
Format(GeneralSendSMSString, 'PAC 1 Startup. Ver = ', Version);
{Writeln('General: Sending Bootup SMS ', GeneralSendSMSString);}
end;

Again, GenerealSendSMSString is initialised in 'initialisation' to an empty string.
Again it has 'once' and an 'and' but I didn't put extra brackets around the whole thing.

I'm running PAC firmware 3.13.

And finally, is it OK to leave WriteLn's in the logic downloaded to the PAC? I always take them out. I haven't tried to leave them in. I imagine they wouldn't do anything and the only benefit to leaving them in is I can be lazy and not have to remove them

Thanks
Brad.

 

Just a few (hopefully) silly questions..

How much other logic have you got running?
When you run in Piced, what's the runtime percentage?
Is there any other logic that you've got running in the PAC but not in Piced?

 

Hi froop,

A fair bit of logic. Blind control, other lighting control served off PIR events, occupancy monitoring, SMS control of CBUS, etc.. All of which works fine. Its just these two little problems.

The first code fragments I posted really shouldn't be influenced by other PAC logic so I was hoping that was enough for someone to comment on. The second fragment could be other issues related to code I haven't posted that can't send this unsolicited SMS message.

Hmm, I do have some code that works and blows my theory about 'once' and 'and' away.

once (bDarkOutside = TRUE) and (GetCBusState("Local Network", "Trigger Control", "ctrlPorticoPIR PAC1") = ON) then

This is a 'once' with an 'and' it definately works.

I've profiled the project in PICED and had spent quite some time making sure the % is low. It peaks about 35%, so its pretty low.

There's no logic that is designed to run only in PICED as this is a PAC project, however there is conditional logic so that the project behaves OK for offline development and testing in PICED - e.g. simulation of the mobile phone, etc.

I'll be doing some debugging to narrow it down, which if it is only happening on the PAC does not excite me. I was hoping someone may have an 'aha' moment.

 

Hi froop,

A fair bit of logic. Blind control, other lighting control served off PIR events, occupancy monitoring, SMS control of CBUS, etc.. All of which works fine. Its just these two little problems.

The first code fragments I posted really shouldn't be influenced by other PAC logic so I was hoping that was enough for someone to comment on. The second fragment could be other issues related to code I haven't posted that can't send this unsolicited SMS message.

Hmm, I do have some code that works and blows my theory about 'once' and 'and' away.

once (bDarkOutside = TRUE) and (GetCBusState("Local Network", "Trigger Control", "ctrlPorticoPIR PAC1") = ON) then

This is a 'once' with an 'and' it definately works.

I've profiled the project in PICED and had spent quite some time making sure the % is low. It peaks about 35%, so its pretty low.

There's no logic that is designed to run only in PICED as this is a PAC project, however there is conditional logic so that the project behaves OK for offline development and testing in PICED - e.g. simulation of the mobile phone, etc.

I'll be doing some debugging to narrow it down, which if it is only happening on the PAC does not excite me. I was hoping someone may have an 'aha' moment.

 

Thats interesting. I logged on to the forum, created the reply, hit post, I was prompted to login again cos I took so long to create the reply and the post ended up being here twice!

 

Sorry, no "aha" moments, but maybe a couple of suggestions to break down your logic a bit more.

First off, this module:

Code:

if (Time >= sunset) or (Time <= sunrise) then
begin
  bDarkOutside := TRUE;
end
else
begin
  bDarkOutside := FALSE;
end;

could probably also be done with a once instead of an if.

Code:

once (Time >= sunset) then
begin
  bDarkOutside := TRUE;
end;

once (Time >= sunrise) then
being
  bDarkOutside := FALSE;
end;

You can then also change your problematic code:

Code:

once (bDarkOutside = TRUE) and (DayOfWeek in ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]) then

by extending the bDarkOutside logic:

Code:

once (Time >= sunset) then
begin
  bDarkOutside := TRUE;
  if (DayOfWeek in ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]) then
begin
  bTurnOnOutsideLights := TRUE;
  { Or call a function to turn on the outside lights }
end;

This may not suit the rest of your project, but its another way to do it if you can't figure out what your other issue is.

 

Thanks Froop,

Your first suggestion is exactly what I had initially and I changed it to see if it fixed the problem. Given that other events are happening, it would appear that bDarkOutside is in the correct state and is not the problem.

Time to add some debug...

 

If you think about the logic flow here as in number of seconds from midnight then this condition will not be true for a time value greater than sunrise - therefore you won't get your flag (bDarkOutside)to FALSE.

WriteLn is not supported in the PAC so you should delete, comment out or use the clever utility
if not ispac



As per Froop's suggestion better code is once however again thinking about how the seconds tick by and the logical flow changing the order of the code to this

Code:

once (Time >= sunrise) then
being
  bDarkOutside := FALSE;
end;

once (Time >= sunset) then
begin
  bDarkOutside := TRUE;
end;

is the way to go because the code is processed top down and if the PAC ever resets and its after sunset, the first section of code will be true immediately followed by the second section of the code being true and you are back in business.

 

Lucky,

With regard to my if statement, if the time is midday then

Time >= sunset is FALSE
Time <= sunrise is FALSE

(FALSE or FALSE) is FALSE so the 'else' is executed setting bDarkOutside to FALSE.

My problem doesn't appear to be that bDarkOutside is not set Properly as other logic works.
Its probably going to be some funky logic issue.

 

Your two conditions (or) are false so your code won't be executed for a time value of midday, therefore your 'else' action (after begin) may as well not be there.....
Am I missing something...

 

I think you're missing something

Brad's logic in that if..else statement is fine. It's just that its not as efficient as using two "once" statements. Although in this particular case the gain is minimal.

His logic says:
If the time is after sunset, or if the time is before sunrise, it is dark.
Otherwise it is not dark.

Nothing wrong with that.

 

I haven't debugged on the PAC yet, but I've 'turned up my debug' from within PICED and the logic executes correctly when running in PICED, admittedly with some 'offline test' code enabled.

I guess its either a timing issue when the logic runs on the PAC thats doing something I'm not expecting, or maybe something weird like I've used a String where I should have used a LongString and I'm overflowing a variable?

I'm going to focus on the simple case thats not working (Verandah Lights) because I know bDarkOutside is getting set correctly so its only the 'once' thats not working.

The only thing I did do with the PAC last night was to run the CBUS diagnostic utility (would love that thing to read a tag file), reboot the PAC and confirm that the verandah lights weren't being switched on and off again quickly.

 

I see the if..else sees the code processed every loop regardless of the condition being true. I usually try to stick to (and think in terms of) once or nested statements to keep the process load down.

 

Have you tried to disable all other modules and only run the bit of troublesome code on the PAC?

 

OK, I think I have it.

The once command that had DayOfWeek in etc doesn't work because sets aren't supported in the PAC.
PICED doesn't warn you about the use of this particular one. In my case it caused the PAC to reset some random time later.

My second once command I'm using to send an SMS when the system starts up wasn't working because the PAC was resetting before the 10 minute timeout for that SMS expired.

If there's a spotters fee for this (cos I think PICED should have picked up the problem) here is my wish list:

PICED editor should allow Shift + cursor keys to block select code. (I hate using the mouse to select multiple lines of code to copy).
PICED editor should navigate words with CTRL + left and right arrow (Like it does with Shift + CTRL + Left and right, but without selection).
The ability to pass tags as parameters to procedures (Yep, buckleys of this one I imagine).

Finally, I can sleep in peace....