(Curt and Ken, pls read this) If Time results in Unknown state after clock set

[d0ughb0y]

I have a previous discussion with Ken regarding this.

Ken says with

If Time>11:00 Then LT1 On
If Time>21:00 Then LT1 Off

that it is impossible to end up with unknown state.

Today, I had to set my clock again (AC can't seem to keep accurate time, 1 or 2 second correction is fine, but I am up to 45 leap seconds already), and my LT1 ended up in unknown state. I set the clock before the LT1 comes on. (e.g. in the above example, if I set the clock before 11AM).

I think this is a bug in AC firmware. As I agree with what Ken says that according to the manual, If Time statements "roll over" or "wraps around" and hence if Time>0:00 is not necessary. But as I have shown here, that is not the case in reality. I have the latest firmware. Can other AC users please test this to see if this happens on their controller also, just to confirm this is a bug? (just set the clock time and leap seconds before the first if time statement time)

Here are pics as proof it can happen
pic showing LT1 in U state (first device, pic is blurry since I took it handheld with no flash). My LT2 was already On when I set the clock, and as you can see, it is not affected by the clock set, because it already satisfied the first If Time statement for LT2.

Ken, if the U state only lasts for less than a second, then I would not be able to take this picture.
http://reefcentral.com/gallery/data/500/186039LT1U.jpg


pic showing LT1 in off state after I added If Time>0 Then LT1 off

http://reefcentral.com/gallery/data/500/186039LT1off.jpg

I have other statements that depend on state of LT1 that gets messed up if LT1 is in U state (because that will evaluate to false with either LT1=on or LT1=off). So as a workaround, I had to add the If Time>0:00 Then LT1 off statement which I don't like considering AC jr capacity is only 40 statements and I have to take up an additional line for each device that I do not want to end up in U state.

I think adding an "Init" statement to initialize a device state can go a long way. Other statements like OSC and RND already have an initial state that goes with the command, it would be nice to have that feature for all commands. This is not necessary if this bug (if confirmed) is fixed, at least for If Time commands).

thank you.

[kenargo]

This is what I tried but I couldn't reproduce what you are seeing:
have a 2 line program:

If Time > 12:00 Then LT1 ON
If Time > 21:00 Then LT1 OFF

The controller time is set to 11:35, I changed leap seconds from 000.0 (I didn't realize you can do tenths:), exit and run; the light was correctly off. I did the same again but this time went back to leap seconds == 0; again exit and run and the light was still off.

In both tests the light did not change state; it was off before the test and remained off. Is it possible to post your complete program and I will try exactly what you have?

When I execute a reset command of the AC I see a "U" on the light which lasts about 5 seconds, then it turns off.

I can't explain what you are seeing; of corse I am testing on an AC3 (I don't have a Jr to test with).

[d0ughb0y]

The light stayed off for me, but the state shows U.

To be exact, I advanced the time, and added a few seconds to leap seconds.

perhaps it is a problem with ac jr. only.

[kenargo]

It sounds like I did the same thing but for me the light indicated off (no 'u') and was off.

Out of curiosity; have you tried copying your program and re-initializing the unit to factory settings and then reload the program? If you have Aquanotes (Lite or full) and the serial Jr you could try this.

[d0ughb0y]

Out of curiosity; have you tried copying your program and re-initializing the unit to factory settings and then reload the program? If you have Aquanotes (Lite or full) and the serial Jr you could try this.


I think that will require me to recalibrate the ph probe, and I don't have calibration fluid at hand. Even if it did work, it still is a bug in AC jr firmware. I can try it when I have the ph calibration fluids.

I know deleting program lines leaves the garbage in memory and reinitializing will clear it and "compact" the program lines. The program lines will get compacted also if I simply download the program to aquanotes and update it back to the controller, which I did a few days ago.

[kenargo]

If you use Aquanotes there is a screen that contains the slope and reference values for the PH probe; you can save and replace the value after the reset but in general, yes you would need to recalibrate.

I suggested trying this because there have been instances where brown-outs have caused systems to act strage and an re-init has cleared the problem; it was just an idea. You might want to call Neptune directly.

[d0ughb0y]

I am hoping other ac jr users can do the test to see if the device goes into inknown state or not.

I'm sure someone from nepune who has access to the ac jr. firmware source code can determine exactly what caused the device to go into unknown state.

[clp]

I've tested this on both the current (3.3) and previous version of firmware, and I can't replicate the problem. Please email support@neptunesys.com your complete program and timer names, and I can try that.

Curt

[d0ughb0y]

thanks for looking into this Curt. I will email you my program when I get home tonight.
Can you tell from the firmware source code that it is impossible for devices using If time to end up in unknown state? or are there instances when it can end up unknown? I have seen it occur twice on my controller already.

If based on the description that If time statements are evaluated first, then that should guarantee the device never ends up in unknown state right? regardless of what other statements that device is used in.

BTW, I changed the clock and leap seconds (adjusted forward) directly on the controller, not in aquanotes.

thanks

[clp]

With only 'if time' statements on a timer, then yes I would say that the unknown state is impossible. If there are other statements besides 'if time', then it is possible to introduce the unknown state.

Curt

[d0ughb0y]

out of curiosity, can you elaborate with an example? (This is for my better understanding on how exactly the program logic works, and I am sure this info will benefit others as well)

If the "if time" puts the device in a known on or off state, I can't think of any other way to put it in unknown state with other commands.

The only way I can think of why it ended up in unknown state on my controller is because the logic did not "roll over" because I changed the clock before either of the two If time statements time. because as soon as I added the if time>0 then LT1 off, the device went to the off state. And I think I actually removed the if time>0 then LT1 off (actually I simply changed it to the same values as the first if time>11:00 then lt1 on), and Lt1 ended up in unknown state again!

from what I recall, all I had in addition to the if time are
if temp>83 then LT1 off
and a max change 015m then LT1 off.
but I'll know for sure when I look at it again later when I get home.

[d0ughb0y]

As it turns out, the memory on my controller may actually be corrupted. I went ahead and did an init all memory reset as Ken suggested, and took out the if time>0 statements. I'll observe it for a few weeks and hopefully this the problem do not occur again.

thanks

[d0ughb0y]

Ken,

As it turns out, though my controller's memory was corrupted and I did the initialize, I still saw the U issue.

Curt determined that my placement of MAX CHANGE made the device stuck in the U state. I'm not sure if this was expected or not, and if it will be fixed in the next firmware release. But I think given that If Time statements are evaluated first, then the device will never be in a U state does not hold here, because it seems MAX Change was executed first before the If Time, or The If Time evaluation did not roll over, causing the MAX CHANGE to hold the U state.

These program lines caused the problem. LT1 will end up in U state if you do something in the controller before 10:59 that will restart the program (such as setting the clock or leap seconds, or modifying a program line)

If Time>10:59 Then LT1 ON
If Time>20:59 Then LT1 OFF
MAX CHANGE 010 M Then LT1 OFF
If Temp > 83 Then LT1 OFF

It should be

If Time>10:59 Then LT1 ON
If Time>20:59 Then LT1 OFF
If Temp > 83 Then LT1 OFF
MAX CHANGE 010 M Then LT1 OFF

I have not seen the U state for a couple days now.
You should try it so you can see that the U state can occur with If Time statements.

cheers

[kenargo]

Intersting; well, in any case I am glad you have been able to find your issue and get something that works for you!

Question; did the "U" go away after 10 minutes (aka, after the Max Change expired); do you remember? Just curious...

Thanks for the update.

Wow, I must be good; even the simulator holds the LT1 in a "U" state:)

[d0ughb0y]

I don't think it cleared out, since U is nieither an On or Off state so MAX CHANGE would not be able to keep track of the on or off time.

In your program, how did it end up in U state if the if Time statements roll over? I just want to better understand the logic of the statement evaluation.

thanks

[kenargo]

In the sim it doesn't roll out either. What happens is that the time says to turn the LT1 on, but them Max Change is evaluated which says don't let it turn on. I must have created simular logic as the real controller.