Logic on PAC causes unit reset (works fine in PICED)

Hi all.

I have a piece of logic that when its execution is triggered on a PAC it presumably causes the unit to restart/reset, but the same logic runs fine in PICED when connected to network with logic running for test purposes... I say 'presumably' because the network log shows the measurement app messages straight away when running in PICED, but on the PAC I see messages that could only be generated by the initialisation logic running so the unit must have restarted.

This is doing my head in. Any tips/clues as to what could be happening? Any tips/clues for me to investigate why the PAC hardware is objecting?

PAC firmware 3.80.0, Monitor Version 1.6, PICED 4.11.2.0

Cheers, and thanks in advance for input.

Code:

{ If Wiser requests irrigation values then send them on the measurement application }
once GetLightingState("Irrigation Values Request") = ON then
begin
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 0, tReal[0]);   Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 1, tInt[1]);  Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 2, tInt[2]);  Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 4, tReal[4]);   Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 6, tReal[6]);   Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 7, tReal[7]);   Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 20, 8, tInt[3]);  Delay(0.5);
  SetLightingState("Irrigation Values Request",OFF);
end;

 

Further information.

If all SetRealIBSystemIO statements are commented out then the PAC doesn't restart when the "Irrigation Values Request" group is set on. Also, if all but the first SetRealIBSystemIO statements are commented out it also resets.

If I create a Measurement App entry in manager that uses the device number 2 (same as unit PAC address) and change the code to reflect the new device number the same thing happens - resets - so following the recommendation to have device = unit makes no difference.

Other statements like 'GetRealIBSystemIO' don't seem to cause a restart.

All measurement app entries have the 'controllable' option set, too.

 

Variables?

Something weird is going on here...

Changing the first line to send a fixed value (not a variable)

Code:

  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 0, 0.0015);

and commenting out all the rest allows the PAC to set the measurement device value - message is logged as being sent. Hmmm. Something up with variables?

Re-wrote the code to not use array members, but instead just use simple variables. Saved to PAC, set the "Irrigation Values Request" group, and... the PAC restarted.

Resources report in PICED looks more than fine.

Changed the code to the fixed values below and it works perfectly:

Code:

once GetLightingState("Irrigation Values Request") = ON then
begin
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 0, 0.0015); Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 1, 0);  Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 2, 0);  Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 4, 1.1);   Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 6, 2.1);   Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 7, 3.1);   Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 20, 8, 1234567);  Delay(0.5);

  { *** Lines commented
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 0, r0); Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 1, i1);  Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 2, i2);  Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 4, r4);    Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 6, r6);    Delay(0.5);
  SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 7, r7);    Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 20, 8, i8);  Delay(0.5);
  }
  SetLightingState("Irrigation Values Request",OFF);
end;

 

Further information.

OK. Narrowed this down to the Real variables being used. Integer measurement app messages work fine.

All variables are set to zero in initialisation code, and in the code the variables are loaded thus (as an example):

Code:

if GetBoolIBSystemIO("Measurement App Valid Value", "Local Network", 19, 0) then
  r0 := GetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 0);

Recall that this works in PICED. Any clues?

Apologies for the multi-posts, by the way.

 

Found an acceptable work-around.

Tried various code combinations in an attempt to get past the PAC crash, like setting the IB system IO in a procedure using a temporary variable, using other variables, varying the code size/complexity/execution order, and all consistently achieved exactly the same crash. The only thing that works is to use constants for the value to set, which is obviously an unworkable work-around.

As a work-around that actually suits the logic, I am writing my values to the measurement application from the PAC exclusively using integer variables, as any use of real values for send seems to trigger a crash (I multiply the real value by 10000 then round & send). The purpose of writing these values is to load them into a Wiser on startup of that device's logic, as Wiser still can't save System IO values to survive a restart. After written to the measurement application by the PAC, the Wiser reads them and divides the value back to its correct order of magnitude. Unlike the PAC, the Wiser has no issues sending real values to the measurement application, so all is well with the world from that point on.

Code:

once GetLightingState("Irrigation Values Request") = ON then
begin
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 0, round(r0*10000));   Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 1, i1); Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 2, i2); Delay(0.5);
  SetIntIBSystemIO("Measurement App Integer Value", "Local Network", 19, 4, round(r4*10000));   Delay(0.5);
...

For now, my issue is avoided with this integer conversion kludge.

Happy to provide the code from the PAC and Wiser for folks at CIS to determine whether the way I write logic is the problem, or whether there's an issue with the PAC 3.80 firmware writing real values on the measurement application. I did note in the change log that PAC 3.51 firmware solved some SetIBSystemIO issue ("18634 Fixed SetIBSystemIO") a couple of years back, so possibly this code needs more attention on the PAC. After finding that, I had a half arsed attempt at back-porting the PAC project to a WISER version featuring 3.50 firmware, but it did not go well... My integer use work-around was definitely the path of least resistance, and also resulted in many less write cycles on the poor old PACs EEPROM, which must now be prematurely aged with all the test write cycles.

Again, apologies for the do-it-yourself forum thread full of self-replies. Had a good chat with myself, though.

Cheers,
Steve.

 

No need to apologise. It is extremely helpful that you went to the effort of narrowing down the cause of the problem. I am sorry that we were not able to provide any useful feedback in time.

In summary, you found that this causes the PAC to reset:

Code:

SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 0, r0);

but this does not:

Code:

SetRealIBSystemIO("Measurement App Real Value", "Local Network", 19, 0, 0.0015);

I am unable to verify this at the moment, so someone as Clipsal will need to look into it.

Does it matter what the value of r0 or the constant in the above code is?

I can imagine how a value of 0 could cause an error due to the use of logarithms to calculate the value of the exponent.

 

It does not seem to. One test I ran lets the logic load the value elsewhere (by periodically reading the same value from the measurement app). Another test I ran sets the real variables to arbitrary positive values using constants immediately before the SetRealIBSstemIO procedures are called. Both yield the same crashy result.

It would appear to me that the code is fine, and being compiled fine, as it executes fine in PICED. The only place it does not execute is when running on the PAC.

Mark responded today with a PM, Darren, by the way. His interpretation of an issue summary is this:

I've offered a copy of the project that causes the crash 100% of the time for me.

Cheers.

 

I believe Wiser automatically saves system IOs edited using the UI within 5 minutes from the time of the last edit. However, values edited using logic are not saved automatically. I'll let the powers that be know that this needs to be addressed soon.

 

That would be brilliant if the saving of System IO modified by logic were finally implemented. I've certainly gone through quite a bit of pain with a round-about way of saving these values that could have been totally avoided with an on-Wiser solution.

As a side question, does the PAC have the ability to save System IO, or is that only for touch screens (and hopefully Wiser in future)? Never gone looking to see, to be honest.

Cheers.

 

Already did, Nick.

I didn't save the exact code I used at the time, but if I recall correctly there were four real values I was trying to set (when triggered by a group address going non-zero), so I added four lines above the SetRealIBSystemIO lines that set each of the four variables to a non-zero value.

In another test, all code lines were commented out in the module to reduce confusion and replaced by a few lines that I modified slightly, compiled, sent to unit, checked result. First try was to use an arbitrary numeric value (something like 0.0015) as a parameter (worked). Second try was to use a global variable set to a non-zero value immediately before call (didn't work). Third try was to move the fragment of code into a procedure, declare a local variable, set to non-zero (didn't work).

In all cases where a failure was observed on the PAC the logic compiled and tested fine when running in PICED.

Hope that helps.

 

The touch screens and PAC do save User System IO values.