controlled status UKN

[jdeveaux]

Currently this is what I have set for my OZN timer..

If ORP < 385 Then OZN ON
If ORP > 425 Then OZN OFF

Why, when my orp is between 385 and 425 does the status screen display UKN when the controlled port is ON?

Am I missing something or do I have it setup wrong?

Thank You,

[kenargo]

Nothing wrong; the AC hasn't caught up yet. When you update the program or reset the controller the program starts out with all devices set to 'unknown'. If the ORP reading does not allow either statement to evaluate true the screen will read 'U" because the program doesn't know what to do. At some time in the future the ORP will either climb/lower and one of the conditions will evaluate to true and then the screen will read correctly; nothing to worry about.

[d0ughb0y]

The state of a device will end up on or off only if one of the if condition is true. If no statement for a device is true, then it will end up in Unknown state.

If you do not want to end up with UKN state, you must make sure at least one if condition will result to true.

For instance, in your example, if QRP value is 400 at startup. none of your two if statements will be true, therefore, OZN will be in UKN state.

You have to watch out for this condition if you have "If Timer" statements that depend on the state of another device. You DO NOT want the device to ever have an Unknown state. So this is definitely something to worry about.

A typical example is

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

When you look at the program statements in AC at time 07:00 and restart the program run, LT1 will end up in unknown state!!! Personally, I think this is a bug in AC firmware. AC docs says time are treated as "wrap around" value. Therefore, at time 07:00, it should treat that as if Time > 21:00 Then LT1 Off condition as true and put LT1 in off state, rather than in Unknown state.

So what I end up doing is use up another statement to add
If Time>0:00 Then LT1 Off
in order to ensure LT1 is never in an unknown state, because I have IF Timer LT1 statements that get messed up if LT1 is in an unknown state.

[kenargo]

When you look at the program statements in AC at time 07:00 and restart the program run, LT1 will end up in unknown state

This is an not completely correct; the AC treats time as a value that rolls over; in the above example, if you reset at 7:00 then LT1 will be off because 21:00 roils over until the next time (which would be 08:00.

With "if Time' it is not possible to have 'unknown' state. You might see a "u" for a few seconds until the program is evaluated but it quickly goes away. In my test it remains "U" for < 1 second.

BTW:

If you have 2 conditions, an on and off NEVER include the following:

If Time>0:00 Then AAA Off

to initialize your timer; it will cause your program to act strange.

[d0ughb0y]

I know what you are saying, and I agree that because it wraps around (roll over), it MUST NOT end up in Unknown state, but I know for a fact it can and it did happen, hence I said it is a bug in AC firmware.

It happened to me one morning before lights on. My alarm is dependent on LT1, and is forced off on lights out. But that morning,when I looked at my program before lights on, and LT1 ended up in Unknown state (because both If Time statements are false), and triggered my alarm!!! Needless to say, everyone in the house woke up. It remained U until I added If Time>0:00 Then LT1 Off.

I do not see how this
If Time>0:00 Then LT1 Off
If Time>08:00 Then LT1 On
If Time>21:00 Then LT1 Off
is a problem as long as they are in order shown.
Can you elaborate beyond just saying "it will cause your program to act strange"?

It is a good idea to make sure a device If Timer statement is dependent on never ends up in Unknown state. Lesson learned for me, and just passing on the info, since the subject of this thread is about unknown state.


<a href=showthread.php?s=&postid=13698026#post13698026 target=_blank>Originally posted</a> by kenargo
This is an not completely correct; the AC treats time as a value that rolls over; in the above example, if you reset at 7:00 then LT1 will be off because 21:00 roils over until the next time (which would be 08:00.

With "if Time' it is not possible to have 'unknown' state. You might see a "u" for a few seconds until the program is evaluated but it quickly goes away. In my test it remains "U" for < 1 second.

BTW:

If you have 2 conditions, an on and off NEVER include the following:

If Time>0:00 Then AAA Off

to initialize your timer; it will cause your program to act strange.

[kenargo]

Can you elaborate beyond just saying "it will cause your program to act strange"?

Clarification; I should have further said the program as the original poster listed, using 'if' value commands would not work as expected if they used the if time > 00:00', it is explained in the sticky "Best Practices" thread.

I assume you are using the latest version of firmware? Perhaps the bug was in the past but when I test I have not been able to reproduce your error. As you say; it doesn't harm anything but when you are close on lines (e.g., Jr, has like 40 lines max) then 1-2 extra lines could make a difference.

[jdeveaux]

Thank You for the input... so let me see if my interpretation is correct...

I should put at the beginning a line that states

If Time > 00:00 Then OZN ON
If ORP < 385 Then OZN ON
If ORP > 425 Then OZN OFF


This will turn the Ozone on every time the program cycles but turn it back off if the ORP climbs over 425.

The only problem then is that when I get over 425 the outlet would start cycling on and off every time the program cycles.

I believe I've read about a line I can add that would control how often it can cycle an outlet so I'll go take a look at the best practices and the manual again.

Thank You,

[d0ughb0y]

Ken,

The example in the sticky makes sense, only because the two conditions use > and < (there is a hole where state can be either off or on depending if value is going up or down). If both conditions use > as in "If Time", it will not be an issue ( Time only goes one way :)). Unless you can describe in a similar way how it can be an issue. And yes, it is annoying that it will use up one extra line, but it is a good safety to make sure "If Timer" statements can only be compared to an On or Off state, as Unk state will always evaluate to false.

I have to recall what I did, I may have changed the clock or the leap seconds and that triggered the LT1 to end up in Unknown state. What matters here is it can happen, so I would not make a general statement that it cannot happen.

I think it is incorrect to generalize the statement to not use If Time>0:00 statement if there are on/off statement pair, as it is appropriate to use in most cases.


John,

Your statements will work, if that is your desired result. In fact, second line is redundant and can be removed. You may want to add a Max Change line.

What is different is, without the If Time statemetn, If ORP is going up, OZN will be off in the "inner" rnage. IF ORP is going down, OZN will be on in the "inner" range.
If you add the If Time>0:00 statement, then you will not have the "inner" range,
It is by no means bad or incorrect to do so.

So In your case, it is probably best to remove the If Time, as Ken recommends.

Regarding cycling, it does not work the way you think. AC will not turn on or off the device as it evaluate each statement. It will evaluate all statements first, then the last condition state is when it will switch the device.

so if you have
If Time>0:00 then OZN On
If Time>0:00 then OZN Off
If Time>0:00 then OZN On
If Time>0:00 then OZN Off
If Time>0:00 then OZN On
If Time>0:00 then OZN Off

it does not turn OZN on/off 3 tmes, it will just turn it off if it is not already off, because that is the final state after evaluating all conditions.

[jdeveaux]

That makes sense Thank You. I will remove the redundant statement.

[kenargo]

The correct program is:

If ORP < 385 Then OZN ON
If ORP > 425 Then OZN OFF

I am not sure how well you followed d0ughb0y's comments but if you leave the "if Time' then the OZN will turn on when ORP < 385 and turn off as soon as it rises to 385 or greater. That is the example we are trying to explain, perhaps not that well.

d0ughb0y, yes, that was what I was trying to say; to use the initializer when using 'if time', but if you have a < and > conditions then you should not because it causes the timer to act only to the condition that is opposite the initializer.

[jdeveaux]

I changed it to...

If Time > 00:00 Then OZN ON
If ORP > 425 Then OZN OFF

That got rid of the UKN state and I verified the ozone is on, current reading is 398. I changed the variable to 390 and the OZN timer turned off.

[kenargo]

With this program the OZN will turn on at any setting <425 and below and off at 425 and above. In other words it will turn on/off when the reading changes by 1. That is what we ment about loosing 'range' when you use 'if time'

[jdeveaux]

Ok back to the original settings for now.

I just don't like logging in while out of town and seeing a status of UKN but I can see the ORP and set it to manual.

Thank You,

[kenargo]

You will only see "U" until the ORP hits one of the test conditions. There is another option (but I don't like using it); that would be to use the following:

If Time > 00:00 Then OZN ON
If ORP > 425 Then OZN OFF
Max Change OZN 005 M Then OZN Off

This will keep OZN off for 5 minutes (or what ever value you choose). What I don't like about this patters is you are really guessing how long to keep the timer off. It does get rid of the "U" but it still means that OZN could come on every 5 minutes because it will still be a change of 1 that is the difference between on and off.

[jdeveaux]

I will go ahead and live with the UKN for now. I don't want to wear out the ozone generator cycling it on and off. On another note it was driving me crazy that even with a 200mg generator I could not get my orp over 400 but I broke out the fluke today and as it turns out I had some stray voltage coming from one of my MAG pumps. Dumped the pump and the orp jumped to a reading of 455 :eek2:

I've corrected my grounding probe that obviously wasn't working and recalibrated the orp probe.

Thank You again for the help and advice.

[kenargo]

Glad everything is working for you.

I've corrected my grounding probe that obviously wasn't working

I don't believe in them; if you have a GFI they are not needed and can do more harm than good; that and most people don't use them correctly anyway.

[jdeveaux]

I have GFI's on every outlet. I don't know that they do any harm if they are grounded correctly. I just forgot to attach the ground the last time I was working on the electrical.

[kenargo]

Grounding plugs is one of those great debates in the fish world; being an electrical engineer I do not believe they offer any benefits if you have GFI outlets. A while back I asked an engineer friend of mine who worked at Square-D and he indicated that you should NOT ground the water for various reasons.

A few comments I have captured below:

* a GFI trips when > 5mA of current; if you have a leaking device you could come home to find that your GFI has tripped and all your equipment has been off for a long time and your tank might not be (healthy).

* Fish can touch them; even if something is leaking all things in the water are at the same potential and thus are not affected; it is only through the creation of an electrical circuit that you come in contact (of feel) the current. If the probe where in the water and there was a leak of any significants and a fish picked on the probe; the fish could be fried.

* The above always gets the response about "me"; so the fish are happy but then I stick my hands in the water. This is what the GFI is for.

* There has also been some studies on the affects of fish and such with ground probes; since the probe creates a circuit between the leaking device and the ground probe it is possible that tank inhabitance are affected by being part of the circuit. It's theoretical but I haven't found anything totally conclusive.