Aux1 SOC Low to start generator: Classic resets and gen starts at wrong SOC

[dgd]

Maybe a double test so when soc% reaches low point there is  delay of a couple of minutes, then second test  to see if the soc% is still at/below the test value then the AUX is enabled.
If the soc% needs recalculating after a planned or random rest then this second test after delay may stop unplanned genny starts

dgd

[boB]

At just before midnight, the Classic will report that SOC is 70%.  The classic reboots.  AUX1 is turned on.  The classic still reports 70% SOC.  Generator runs until SOC reaches 84, then shuts off.

So, somewhere in the reboot, the value for SOC that is used to turn AUX1 on is evaluating to less than 60.  Sounds to me that the code that evaluates the SOC Low is executing before the value on the EEPROM is read into the register on the Classic.

Yes, I think you are correct.  This should be very easy to check.  Do you know how long the Aux 1 is staying active after that reboot ?
i.e. Did Aux 1 STAY active for a while or did it just "glitch" active, start the generator and then go inactive again quickly ?

boB

PS, there are wear leveling techniques to reduce wear on the EEprom.  Just takes time.

[2twisty]

It stays on until it reaches the high limit, and I'd expect it to do that.

Once the flag of "hey, I fell below 60%" is triggered, there's no logic to say "hey wait, I went from <60 to 72% in 3 seconds."  So, as far as the charge controller is concerned, the batteries just got a SUUUUUUPER fast charge. 

It's not a glitch in the AUX1 code; that part is working properly since the code is written as "if SOC falls below 60 for any amount of time, energize AUX1 until SOC goes above 84 for any amount of time."

Another way to fix this is to put a time constraint on it.  "If SOC falls below 60 for one minute, energize AUX1 until SOC rises above 84 for one minute."  You could even make this delay time configurable, but I think that we'd be OK with one minute. 

Other fixes include a flag in the AUX1 code to make sure that EEPROM data has been written to the registers before running the AUX1 code.  I think I like the time constraint idea better, since it would be harder to accidentally fake it out.

[boB]

OK, so just so I am documenting this, I adjusted my office classic to use Aux 1 as SOC% LOW and a low of 60%
and high of 84% with fairly short delay and hold times.  This MNGP is in LED mode 1 so it shows the AUX
states on the internal LEDs and the Aux 1 relay is jumpered to click.
Battery Amp-Hours is 100 so is kind of like the SOC % as well.

Luckily, I added an enable flag, bit  0x0800  in the EnableFlags3  register address 4181  so that when it is
high, the WB Jr. Amp-Hours count a couple hundred times faster just so I can more easily evaluate
things like this.  Very handy here !

So, Upping and Downing the SOC% does what it is supposed to so far.  Below 60% SOC Aux 1 turns ON and
above 84% SOC it turns OFF.

Now, when the Classic resets or is first powered up, all the bits and bytes get cleared to zero and of course
the Aux outputs are also told to be low (zero volts out)

So I ramped up and down the Amp-Hours and watch the Aux 1 do its thing as we expect and while I have it
at 70%, I change the time to nearly 23:59 so that it will re-boot soon.  There is also a force a "New Day"
button combination in the LOGS--DAILY menu (hold the left arrow key and then hold down the ENTER key)
which also works but I figured I better just let this Classic re-boot on its own.

So, while at 70% SOC the Aux 1 output was zero, off, low because it counted down from above 84% SOC.

When it rebooted, it came up OFF (zero volts, LED off) and at 70% SOC.  This is counter to what
you are seeing I think.  You would find Aux 1 ON.

And when I had it reboot at less than 60% SOC when the Aux 1 was HIGH (12+ volts, ON) before
the reboot, it wakes up as OFF, zero, low.

That is to be expected because the classic initializes to low or off and the SOC% has not gone above
the high set point (84%) or below the low set point (60%).

Now, the EEprom is read during initialization which comes before the main() code in the classic so
the remaining Amp-Hours have been read but I will have to look closer to make sure that the SOC %
itself which is calculated from all that information has been done first.  But I would think that this
classic here might have the same problem as yours....

Since all variables here are initialized to zero before any are filled from EEprom, I would think
it should all work the same.  I will have to look further of course.

One thing that could be done if necessary to fix this problem would be to store the state of
the Aux 1 output for reboot memory if the SOC% function is being used and just remember that
state.  If the battery SOC% was above 60% before the reboot, then there will be plenty
of time below or above the high/low set points.

I just wanted to let you know what I have found so far.  More work to do of course.

boB

[2twisty]

Hmm.  So, if your Classic is behaving during reboots, I wonder what's different about mine?

You are right that I am consistently seeing different results.  Basically, when SOC Low is set up on AUX1, if the Classic Reboots, the AUX1 is energized and the generator starts.

It's been working properly now that I've disabled the nightly reboot.  Of course, I'd rather have that option enabled, since the Classic seems to benefit from a nightly reboot.

What other information can I provide that might help?

[boB]

What other information can I provide that might help?

I'm not exactly sure BUT I am trying to make it remember what position it was in right after the reboot.

I can see why if it came ON after the reboot and was at, say 70% SOC, it would not know whether it
was going UP or DOWN until it reached the upper or lower setting.  Actually, it could know once
it changed by 1% but by then, the generator has been on for a while at least which you would rather
not happen.

boB

[2twisty]

OK.  Good.  It seems that you've seen the logic puzzle now and are working on it.  I've turned on the midnight reboot again because my Classic runs better with it turned on.

I guess I will just have to be OK with the generator coming on every night and charging to 84%.  Right now, I am guaranteed to drop low enough every night anyway, so if it comes on at midnight or at 2AM isn't a problem.

I am definitely interested in getting this fixed.  When/If you update the FW, where will it be announced?

[zoneblue]

Im curious why you say that the classic seems to benfit from daily reboots?

[boB]

Im curious why you say that the classic seems to benfit from daily reboots?

Well, it used to be anyway that the Classics' Ethernet connection would sometimes "stick" and
stop talking to a remote computer until the Classic was rebooted.  Rather than having to go
and reset the Classic by powering it off and back on again, this was an option to keep from
having  to do that if it was a remote site.

I am not aware of this happening with the last few revisions of code. (I lost track of how long ago
it was) We keep the Auto Restart in there anyway.....  Just in case.

boB

[boB]

I am definitely interested in getting this fixed.  When/If you update the FW, where will it be announced?

I would say that you could see this beta in just a few days...  Just as soon as it has been proven
to not have any glaring bugs that have to be worked out. That is, no new bugs have been made.

[dgd]

I would say that you could see this beta in just a few days...  Just as soon as it has been proven
to not have any glaring bugs that have to be worked out. That is, no new bugs have been made.

Just wondering if it includes the fix for solar mode dropping input voltage to near battery voltage issue 
Dgd

[2twisty]

Well, it used to be anyway that the Classics' Ethernet connection would sometimes "stick" and
stop talking to a remote computer until the Classic was rebooted. 

DINGDINGDING!  WE have a winner.  And yes, mine still does this. 

Just took this screen shot.

[boB]

Well, it used to be anyway that the Classics' Ethernet connection would sometimes "stick" and
stop talking to a remote computer until the Classic was rebooted. 

DINGDINGDING!  WE have a winner.  And yes, mine still does this. 

Just took this screen shot.

How long did you wait before rebooting the Classic to see if the network would
fix itself ?

Maybe you just have a bad Classic  processor  ?

I would really like to know what a mid-day reboot Reason For Reset comes up as.

We may just want to RMA you Classic eventually but I would love to know that info if you
notice it reboot during the day and can catch it.  The RFR I am interested in would be 104
or a Watch Dog Reset.  The reset at midnight will be a 104 for sure but shouldn't happen
during the day or non-midnight.

How about the year quarter the Classic was built or serial number  ?

[2twisty]

14655 is the serial number I use for the password. 

I can't RMA this unit without an advance replacement.  I can't be without my charge controller.

I rarely have ever had it reboot in the middle of the day. It HAS happened, but only a few times.

I've never rebooted the Classic just to get the LocalApp to connect.  Sometimes I have to reboot the machine that the Local App is installed on, but most of the time that doesn't work and I can't connect until after a reboot (which occurs at midnight, and I try to connect again the next morning....)

It's a royal PITA to play the reboot game to get the LocalApp to work.  So, when it's acting up, I just walk over to the classic and use the MNGP.  Then, later, I'll try again and sometimes it works.  Being able to connect with the LocalApp is not a requirement for me since I CAN just walk 5 feet over from my computer to the CC and use the MNGP to do what I wanted. 

However, I do have ideas of using a RasPi to integrate the Classic with my Outback, so getting the network working is an important thing for me -- but down the road.

The bigger issue is that a reboot ALWAYS causes my generator to start. 

[zoneblue]

Well i can easily set blackbox back to once a minute open and close mode. That will tell you in about 3 days whether the network stack is still the issue, or whether its actually local app. I hardly ever use the LA so couldnt comment on it.