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

[2twisty]

Classic 150, solar setup. Firmware 1849.

I've got a WBjr on Aux2 to measure amps and report SOC

I've got AUX1 wired to start my generator on SOC low, set at 60%SOC for the low limit and 92% for the high.

Most of the time it's worked beautifully.  However, since I got it set up and working about a week ago, I've had two incidents where the the classic reset on its own (not at midnight) and the controller energized AUX1 even though the reported SOC was in the 70s.  This, of course, ran the generator until it reached 92.

It's behaving like during the reset, the SOC value momentarily goes below 60 (or undefined, perhaps?) which triggers aux1 when it shouldn't be.

There are 2 issues here:  1) why is my Classic resetting in the middle of the day for no apparent reason and 2) why does AUX1 turn on when SOC is not at 60% during that reset?

[Resthome]

Resetting in the middle of the day has been seen by s few. If you catch it before sunset or the ARST at 1159 (if you have that set) you should record the RFR number as that might tell you why it reset. 

To get Reason For Resting (RFR), go to the main number one status screen and
then hold down the Left-Arrow key and then tap the ENTER key. You will see
a bunch of numbers. On the top line, right in the middle, if the classic has
gone to Resting from some awake state, it will show a number which is the RFR.

Sometimes that RFR won't show you why it is not waking up but will show you
something to do with why it went to sleep the last time.

Here is a list of RFR's... RFR = 5 is the most common.

ReasonForResting = 1 Not enough power to wake up (Doesn't apply to wind mode)
ReasonForResting = 2 Insane Ibatt reference. Try again
ReasonForResting = 3 Negative current on WakeUp, try again
ReasonForResting = 4 Input V is lower than Vbatt while running
ReasonForResting = 5 Power is too low for 90 seconds (Solar 20W, Wind 50W)
ReasonForResting = 6 FETs are too darn hot (>98 C)
ReasonForResting = 7 Ground Fault
ReasonForResting = 8 Arc Fault
ReasonForResting = 9 Battery current is negative (possible load on input terminals)
ReasonForResting = 10 Battery is less than 8 Volts
ReasonForResting = 11 Low Light #1
ReasonForResting = 12 Low Light #2
ReasonForResting = 13 Recheck Voc. V pv went higher than previous Voc too much
ReasonForResting = 14 Low Light #3
ReasonForResting = 15 Low Light #4
ReasonForResting = 16 Normally because user turned MODE OFF... Disabled
ReasonForResting = 17 Vpv > 150V (Classic 150)
ReasonForResting = 18 Vpv > 200V (Classic 200)
ReasonForResting = 19 Vpv > 250V (Classic 250)
ReasonForResting = 22 Average Battery Voltage is too high above set point (overshoot)

ReasonForResting = 25 Battery breaker tripped (Similar to RFR 22)

ReasonForResting = 26 Mode changed while running OR Vabsorb raised more than
10.0 Volts OR Nominal Vbatt changed by modbus command
while Classic was running

ReasonForResting = 27 bridge center == 1023 (R132 might have been stuffed)

ReasonForResting = 28 NOT Resting but RELAY is not engaged for some reason
(this may be a bogus RFR in recent 2013 firmware)

ReasonForResting = 29 ON/OFF stays off because WIND GRAPH is insane (Amps > 100A)

ReasonForResting = 30 (not used anymore after 6-25-2012) Was too high of peak Ibatt
New Reasons for Resting â€" 2/05/14 Builds 1758-1759
ReasonForResting = 1    Wake state, (Vpv < PreVoc AntiClickSenstvty  (MB Addr. 4236)
ReasonForResting = 2    Insane Ibatt on WakeUp state (offset changed from off state)
ReasonForResting = 3    Negative current on WakeUp state
ReasonForResting = 4    dispavgVpv < (dispavgVbatt - 10) Now -25 (RestartTimerms = 1500) ReasonForResting = 5    Too low power and Vbatt below set point for 90 seconds
ReasonForResting = 6    FETtemperature >= 100C Hot
ReasonForResting = 7    Ground Fault
ReasonForResting = 8    Arc Fault
ReasonForResting = 9    (IbattDisplaySi < -15) (negative current) (MB 4200)
ReasonForResting = 10   (dispavgVbatt < LBDlowV)  Battery less than 8 Volts
ReasonForResting = 11   Vpv >= 90% of Voc but slow. Low Light #1
ReasonForResting = 12   Vpv < 90% of Voc   Low Light #2
ReasonForResting = 13   Vpv > (Voc + 10V) in    PV_Uset || Solar1_OandP
ReasonForResting = 14   Vpv >= 90% of Voc  but slow.  Low Light #3
ReasonForResting = 15   Vpv < 90% of Voc and taking too long.  Low Light #4
ReasonForResting = 16   Normally because user turned MODE OFF...  Disabled
ReasonForResting = 17   Vpv > 150V  (classic 150)
ReasonForResting = 18   Vpv > 200V  (classic 200)
ReasonForResting = 19   Vpv > 250V  (classic 250)
ReasonForResting = 22   Average Battery Voltage is too high above set point (RestartTimerms = 2 sec)
ReasonForResting = 25   Battery breaker tripped  (Vbatt shot up high)
                            (If RFR = 25 on Wakeup, check modbus register 4200)
ReasonForResting = 26   Mode changed while running, Vabsorb raised more than
                             10.0 Volts or Nominal Vbatt changed by modbus command
                             AND MpptMode was ON when changed...
ReasonForResting = 27   bridge center == 1023  (R132 might have been stuffed old units)
ReasonForResting = 28   NOT Resting but RELAY is not engaged for some reason
ReasonForResting = 29   ON/OFF stays off because WIND GRAPH is insane
ReasonForResting = 30   PkAmpsOverLimit (will change somewhat 1-23-2013)
ReasonForResting = 31   AD1CH.IbattMinus > 900   (peak negative battery current)
ReasonForResting = 32   Aux 2 Logic input is high.  Aux2Function 15 (external disable/enable)
ReasonForResting = 33   OCP in a mode other than Solar or PV-Uset (1-10-2013)
ReasonForResting = 34   AD1CH.IbattMinus > 900 Classic 150,200 newer than 1-23-2013
ReasonForResting = 35   Vbatt < 8.6 V  (LOW LOW battery)
ReasonForResting = 36   Battery temperature is Greater than reg address 4161 specified
ReasonForResting = 136  Battery temperature fell below MB reg. 4161 - 10 C (Classic turned back on)
ReasonForResting greater than 100...  100 + PowerOnReset, WDT, etc...
ReasonForResting = 104  Watchdog WDT reset (only at boot until first RFR)
ReasonForResting = 111  Normal Power up boot (only at boot until first RFR)
                 [ 100 +   1 = POR,  2 = Ext. Reset  4 = WDT  8 = Brown Out ]

[2twisty]

I'll look into the RFR.  The mid-day resets are rare for me.. 

But there is a new data point.  I happened to be awake at midnight for the daily reset, and it set off the generator again when SOC was only 70%. My SOC should trigger AUX1 when SOC falls below 60.

So...  It appears that the logic that triggers SOC Low on AUX1 is being evaluated before the SOC has been determined.  If this is a correct assessment, a small change to the code should fix it:  You could either put a small delay in the code that evaluates the conditions for the AUX channels so that things like SOC can be calculated first, or if it's what I suspect that the register for SOC is undefined and that the SOC Low condition is simply

Code Select Expand

While SOC < SOCLowSetPoint
{
  AUX1=TRUE;
};

Then I'd suggest doing this:

Code Select Expand

While ((SOC < SOCLowSetPoint) AND (SOC >= 0))
{
  AUX1=TRUE;
};

I've not seen the code, and I'm not sure how an undefined variable will evaluate in that code, so perhaps setting a flag in the initialization routine like IsSOCReady=FALSE, and then in the routine that calculates SOC to update that flag to IsSOCReady=TRUE

Then you can use

Code Select Expand

While ((SOC < SOCLowSetPoint) AND (IsSOCReady==TRUE))
{
  AUX1=TRUE;
};

Sorry if this doesn't make sense.  I'm thinking like a programmer this evening.

I think I'm going to turn off the midnight reset for now, but I was using that because I was noticing some strange behavior after a few days with no reset.  I like the idea of a midnight reboot just to clear out any cobwebs in the running program, though.  So getting this fixed is something I'd like to see.

[boB]

I'll look into the RFR.  The mid-day resets are rare for me.. 

But there is a new data point.  I happened to be awake at midnight for the daily reset, and it set off the generator again when SOC was only 70%. My SOC should trigger AUX1 when SOC falls below 60.

Maybe what happened was that when the Classic reset, the Aux output went inactive (as it would as the processor resets) until  it
put the Aux output into a known condition ?

For instance, if the processor is IN reset, the Aux output should be in the OFF state (no voltage being output to the terminal)
and if you are looking for an active LOW, you will have that during the reset.

boB

[2twisty]

I've got the relays set to 12V output on AUX1.  My stuff all looks for active HIGH, so that if power is lost to the Classic, it fails safe and turns the generator OFF.

The Classic is actively turning AUX1 on during reset.  It shows on the MNGP as being active and the blue LED in the case is on.  It stays on until the SOC comes up to 90% which is the cutoff setpoint.

This is clearly a logic problem in the Classic.  When it resets, the SOC Low condition is evaluated at a time that the Classic thinks that the SOC is either undefined (and evaluating to less that 60, my setpoint) or is at some initial value less than 60 and the code that updates the SOC variable in the Classic has not run to say "I'm at 75%" and prevent the SOC Low trigger from enabling.

What data can I provide from my Classic to prove this?

[zoneblue]

The random reboots, and on reboot SOC reseting to last nights midniight value , are both known bugs of the current firmware. Because of these two bugs i would not be using aux /soc just yet. Most of the time it will work right, but when it goes pear shaped it can do so in a nasty way. False positive is only going to waste fuel, but the reverse will take the bank right down to your inverter LVD, not something you want.

I can certainly imagine that it is in midnites plan to fix this, but im not sure when. 

[2twisty]

Agreed. However, the reboots during the day aren't the problem. When my classic reboots at midnight, the fact that it remembers the SOC from midnight is immaterial. What is a problem is that my SOC is 70 and the gen gets started needlessly. It seems that fixing that bug would be relatively simple.

I have turned off the midnight reboot for now. Hopefully the classic will be stable without the reboot until this can be resolved.

[zoneblue]

I have detailed logs from my system, and the reality is that sometimes the SOC will reset low, but other times it will reset high. If its the latter, which will occur in bad weather, and heavy day loads, then your gen wont start until its too late.

Just to be clear, regardless of whether you have daily reset turned on , upon a spontaneous reboot, SOC will always reset to the value that was saved to eprom the previous midnight.

[dgd]

Just to be clear, regardless of whether you have daily reset turned on , upon a spontaneous reboot, SOC will always reset to the value that was saved to eprom the previous midnight.

If this is the only time the soc is written to eeprom then is the solution to just update the eeprom each time the soc value changes?

dgd

[boB]

I'm still not ~quite~ understanding this I think.


(EDIT:  I Re-read it.   I understand the question and/or problem.  I just don't see why it would
   go HIGH when not going down to 60% SOC...   Did you say that the Aux 1 goes HIGH right when it
   did that un-wanted OR wanted reset ?  Did it take a reboot to make Aux 1 go HIGH prematurely ?
       IF the Aux 1 output goes HIGH immediately after the reboot and the SOC% seen is above your low
     setting, then MAYBE simply waiting a certain minimum amount of time will fix it ?  i.e. Maybe the problem
      is that the SOC % value right after reboot in the Aux 1 code is not quite fully calculated yet ?)

The Classic will (should) save the present SOC values (the proper values ?) to EE prom just before a midnight reboot (if enabled)

So, when it reboots at that scheduled time, the SOC % should come back up as being the same value.

1)  I would rather not be writing to EEprom every time the SOC changes by 1 percent.  It will wear out eventually, although, maybe not for many years.

2)  Maybe you could take a video of the MNGP and values you are talking about that cause the Aux output to change to a high state and start the generator.  That might help explain it ?

I will go back and read the statement again to see if I was just tired or something when I first read it.
Then, I will probably have to go to a Classic and set the bit that allows the SOC % to change about 200X more rapidly than
normal to be able to repeat the scenario quicker.

boB

[Halfcrazy]

Well if we are worried about wearing out the Eprom how about writing the SOC every hour? Or every 30 minutes. Can we write the KWH as well so they are not lost when the classic reboots randomly?

[dgd]

So with soc varying daily from 100% down to maybe 50% then back up to 100% as a worst case guess and probably significantly less for many RE systems, that would be 100 writes per day.
Maybe that would be a wear out figure over 5 years of 180,000 writes.
Or maybe not.
Depending on what space is available in Eeprom there are ways to use a small array to reduce single location writes.
This increases the programming complexity to deal with eeprom - to mitigate possible eeprom failure so that unexpected system resets don't cause bigger problems.

Or just take the risk of writing the eeprom more often and revisit the change when the real issue of random resets issue is resolved

Dgd

[zoneblue]

Well as a stop gap every three hours would be a compromise.

Id like to also make a case for the classic amps anomoly bug.  Once everyone realises how useful the WBJr data is when combined with classic output amps, this would be really really cool to get right.

I know few others currently use this data, but if you think about it , when you subtract WBJR amps from Classic amps, you get your total load amps. This datapoint is right there waiting to be used. People pay good money adding check meters, kWh meters, inverter remotes etc to their system to track usage, but the fact is that the classic is now capable of generating this information in real time. Adding it to MNGP/mymidnite/local app is the obvious thing.

However, it does suffer from two small, i think easily resolved, issues:

1. classic amps rounding/averaging uses different algorithym to WBJr amps.
2. Very occasionly there is some kind of issue where the classic amps get muddled during bulk. Ive reported this in detail elsewhere.

But if noone else sees this as a big deal, thats fine too. It still works pretty well as is.

[2twisty]

OK, let me try to explain:

I have AUX1 configured to SOC Low.  The low trigger is 60 and the upper is 84.

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.


I realize that any mid-day reset may cause the generator to start, if at midnight the SOC was below 60.  However, my SOC is almost never at 60 at midnight.  It's usually around 1-2am when it falls that low.  So, generally, it's somewhere in the upper 60s around midnight.  That means that a mid-day reset should NOT activate AUX1, but it always does.  This further supports my assertion about the order in which the code is executing. 

It should be easy enough to test; set up AUX1 like I have and wait until midnight reset.  Not sure if a bully menu reset would cause it or not.  But every scheduled reset or mid-day goofball reset causes AUX1 to turn on when I have it set to monitor SOC Low.

[2twisty]

Oh, and last night, I turned off the auto-reboot.  The generator (and AUX1) worked perfectly.