waterlevel ato

[Smotz]

There was discussion on re-doing the water-level class. Any movement on that?

[Smotz]

guess not..
sorry to say but support has plummeted.

[binder]

I'm not sure what the discussion was about. What was going to be done with it? I'm asking out of curiosity.

[Smotz]

I'm not sure what the discussion was about. What was going to be done with it? I'm asking out of curiosity.

http://forum.reefangel.com/viewtopic.php?f=3&t=6043

http://forum.reefangel.com/viewtopic.ph ... 0&start=10

[binder]

gotcha. i haven't kept up on this. I don't use an ATO. I just have a gravity fed float valve feeding my sump.

Sent from my XT1585 using Tapatalk

[lnevo]

Sorry I havent been around as much as I should. Nothings happened. It might be better to do a straightforward if then else on the WL and add a separate time based flag for now. The WL ATO class does things with milliseconds and stuff that I think its where its failing.

The problem I have is not much way to test. I know its a lot but once I get my Star setup I may be in a better position to help write something different.

[lnevo]

I have a feeling I know whats' going on.

Millis does wrap occasionally.

I have a feeling that we are catching those moments. The if statement looks like this

WLATO.Timer = millis() // Iniitalizing the variable...

if ( (millis()-WLATO.Timer > TempTimeout)

If millis wraps when we subtract we get a negative number, granted these are unsigned longs, but not sure how well it takes it. In any case I have some debug code running on my Star and will see if I can recreate it. I think I can

[lnevo]

Whoa, I don't think it's the case... I think we're getting stuck in the starting section... I added a Serial.println in the section where we set WLATO.Timer = millis() expecting to get the starting value. and it printed non-stop. Which means I think that WLATO.IsTopping() is not getting set.

if ( WaterLevel.GetLevel(Channel) < LowLevel && ( !WLATO.IsTopping()) && bitRead(AlertFlags,ATOTimeOutFlag)==0)
{
WLATO.Timer = millis();
Serial.print("Starting: ");
Serial.println(WLATO.Timer);
WLATO.StartTopping();
Relay.On(ATORelay);
}

Serial output:

Starting: 309422
Starting: 309568
Starting: 309715
Starting: 309861
Starting: 310007
Starting: 310154

This should be relatively easy to fix I think... So right now it's just a matter of time from the starting millis() that you get a premature timeout.

[lnevo]

hmmm why does this always return false? For the low and high ato ports, it reads the pins, we could probably have this function return activestatus but I need to see where we set that to make sure it's implemented.

#if defined WATERLEVELEXPANSION || defined MULTIWATERLEVELEXPANSION
class RA_ATOWLClass : public RA_ATOClass
{
public:
unsigned long Timer;
inline bool IsActive() { return false; }
};
#endif // WATERLEVELEXPANSION || MULTIWATERLEVELEXPANSION

[rimai]

For ATO pins, it is active or not active.
On WL, there is no active state.

[lnevo]

Yeah but it's something other topping is not staying set, causing it to go into a constant restarting loop.

So I added a Serial.println(topping); whenever StartTopping or StopTopping are called.

inline void StartTopping() { topping = true; Serial.println(topping);}
inline void StopTopping() { topping = false; Serial.println(topping);}

Starting: 161841
0
0
0
1
Starting: 162052
0
0
0
1
Starting: 162264
0
0
0
1
Starting: 162413
0
0
0
1

The Starting statement is the millis right after we call StartTopping

if ( WaterLevel.GetLevel(Channel) < LowLevel && ( !WLATO.IsTopping()) && bitRead(AlertFlags,ATO
{
WLATO.Timer = millis();
WLATO.StartTopping();
Relay.On(ATORelay);
Serial.print("Starting: ");
Serial.println(WLATO.Timer);
}

[lnevo]

Ok, I'm the one clearing topping... ok digging deeper.

[lnevo]

Ok so there's definitely an opportunity for a wrap in the unsigned long that coudl cause the timeout to fire prematureley...

if ( (millis()-WLATO.Timer > TimeTimeout) && (WLATO.IsTopping() )

If millis does wrap (which to does, but supposedly every 50 days) then the current time will be less than the timer was set for and then when we subtract it will wrap and be greater than TimeTimeout. But it should be rare and it isn't, unless it's wrapping sooner then expected.