Today was I watching the Local App dash panel and reveling in the fact that my small (1650 W) PV array was close to generating 8 kWh before 4:00PM. The celebration was cut short however, when the Local App kWh display was at 7.7 kWh and then suddenly was reset to 0.00 kWh. Now, one might argue that this may be disappointing, although not critical or of vital importance. More disturbing though, at the same time, my SOC (WB-Jr) also instantaneously jumped from 92% to 97% (in Absorb, ~8-9 charging amps, over 2 hours remaining; EA set at 3 amps). Minutes later, I walked out to the barn and checked the display on the Classic which confirmed these numbers. Checked the recent history in the LOG menu. Recent history confirmed that at 15:08 energy produced was 7.7 kWh, but the next consecutive record (15:11) showed 0.00 kWh. I do have the reset checkbox set in Local App, but this has behaved as expected (resets the Classic at midnight) and until now all data has been faithfully retained. This strange behavior doesn't exactly instill confidence in the recording accuracy and integrity of the data recorded/stored by the Classic. I am familiar with the "normal" logging behavior because I frequently review the LOG data, download and plot the offline data from Local App (the novelty of this marvelous toy wasn't yet worn off).
There are no other power sources feeding my Classic and the AC-IN breaker on the Magnum inverter was switched off. Battery connections and terminal screws on classic and PC connections in combiner box were tight (and no stray strands of wire). The system load was light and constant (~450-600 Watts); nothing else out of the ordinary other than cold temperatures (-12 C).
Any thoughts as to what may have caused this anomaly?
A Classic reset during the day will zero out the daily history data before they get saved. The local app has a set of debug numbers on the status page. You might want to post them in case this was a Watch Dog Timer Reset so the Midnite folks can look at them. Search the forum for Reason for Resting and retrieve the RFR number from you Classic before it resets tonight and post that number here also.
What version of firmware are you running and what is the version of the LA?
Just a heads up if the Classic MNGP is left viewing Logs and you attempt to fetch the Offline data in the LA you will almost surely see the Classic reset. This is a know bug.
This sounds like it did reset during the day. The time was correct so it wasn't a reset at midnight problem...
As RH asked, what is the version of firmware and what is the serial number ? Do you also have an
idea what the internal Classic temperature runs ? The FET and PCB temperature would be nice to know.
It may be that it had a defective processor that reset when it gets semi-hot. We have seen just a few
but those did not usually reset but would normally hang/freeze. We screen every single Classic for this.
The Serial number should give us an idea of when it went through production here.
Also, the jumping from 93% to 97% should not happen but if this is the newest firmware, it may be that if
the Classic did reset, it saves the State Of Charge every 90 minutes or so, so it may have brought
itself back to 93% or 97% or something while you weren't looking.
It's hard to say sometimes by looking at the Local App screen.
boB
I attached a screenshot of the Local App Info Page with the version and #DB codes (it is getting dark now, nearing rest mode).
Naturally, I have no record of the temperatures, however, after staring at it all day I can provide an accurate recollection of these values close to the time of the error:
FET: 46 C
PCB: 30 C
Bat: -12 C
If your classic (not local app) time is set right, then this is a classic sign of a watchdog timer reset. Here these occur every 3-14 days, and date back to firmware 1470ish.
Quote from: zoneblue on February 20, 2015, 06:00:32 PM
If your classic (not local app) time is set right, then this is a classic sign of a watchdog timer reset. Here these occur every 3-14 days, and date back to firmware 1470ish.
one thing that can cause that is when the local app and the remote or both displaying the log graphs at the same time can reset it. yeah check the temperature around 4 p.m. Classic temperature sensors
Reason for resting (depressed left arrow key from main status menu and tapped ENTER) top middle numeral: 4
Although this is probably of little value since the unit had already gone into RESTING.
boB:
Quotewhen the local app and the remote or both displaying the log graphs at the same time can reset it. yeah check the temperature around 4 p.m. Classic temperature sensors
I wasn't displaying anything out in the barn on the Classic (its single digit temps outside)
Don't know how to access logged temperature data except for the daily FET?
The values I already posted should be accurate for around the time of the alleged reset.
SN: CL16199
other info:
1821: 04/14/2014
1849: 04/21/2014
Restome:
I was not in the LOG menu and viewing data offline from Local App. I usually download these data first thing in the morning, as they only seem to update during the night. BTW, download takes about 2-3 minutes.
Zoneblue:
What is a "watchdog timer reset"
OK boB:
Just remembered that I had the chart active. Wasn't aware I could add data channels after the fact.
I attached the temp and kWh showing the glitch/reset around 15:00
2nd attachment {edit} shows where SOC jumps by 5% at the time of the reset.
I believe that DB5 is the one boB is looking for and in your case it is zero. So no info there. Also doesn't appear to be a temperature problem with those numbers. And as you said the unit already had gone to resting so the RFR doesn't provide anthing. Might look through some of your old data to see if this has occurred in the past.
Oh, those graphs in the Local App are fine and aren't the download of daily logs I was thinking about in combination
with the MNGP displaying logs graphs. So, that is not the reason that it reset, if that's what it was.
Remember that Resting is different than Reset.
And, Rest Home, you are correct, since DB5 is zero, that ~should~ mean that this Classic did not do a watch-dog
reset, at least not the last time it reset or was powered down and back up again.
Garret, A Watch Dog Timer (WDT) reset is when the code crashes and/or freezes and does not keep running, this
timer which is in hardware rather than software, will reset the Classic after 5 seconds of the start of
the freeze. Normally, a watchdog timer is reset when the code is running correctly and is not allowed
to count the 5 seconds necessary for it to do its thing and reset the Classic. When it does that, it
puts some information in that DB5 register spot to give us information on the WDT reset... But if
DB5 is 0000, then it most likely did not do this WDT reset so I think that information tells us that
something else happened.
boB
I really appreciate all the help. You folks are very responsive!
QuoteMight look through some of your old data to see if this has occurred in the past.
I reviewed all the the logged data and can't find another instance of an apparent reset.
The reset in of itself, whatever the reason like I had previously mentioned, is not a major concern. As long as the system continues to operate, especially whenever I am away from my home.
I am a little worried about the sudden increase (+=5%) in SOC. I want to make sure this CC is accurately monitoring the batteries before I purchase another 150 and expand my battery bank for the second 6-panel top-of-pole mount I just completed that is ready to put in the ground (soon as it thaws).
What causes the yellow background when the time offset error is not showing ?
I simply changed the color scheme to suit my tastes (not very fond of chartreuse green). During a partial shading event, the background does change to a much more vivid, and noticeable bright yellow
Garret, there is nothing in the algorithm or code that would make the SOC% "jump" like this as far
as it calculates SOC.
That being said, there are events that could cause it to jump to 100% but even that would be rare
as long as the Absorb time and/or the Ending Amps is low enough.
Transitioning from Absorb to Float naturally will make it go to 100%.
Pressing the right button combination in the WB Jr. MORE screen can cause the SOC to jump to 100%.
If the Classic somehow reset before the 90 minute automatic SOC save and the SOC was higher
than it was during the last 90 minute data save, then the SOC% would jump DOWN some, not up
in percentage because that last period of information was lost.
So, if your SOC% jumped up 5% but did not jump up to 100%, I am not sure what would
have happened. Sometimes things happen when we are not looking and we don't notice
things. That's the hard part to diagnosing a lot of these things. Drives me nuts !
boB
Just my opinion;
The WBjr is a terrific gift that comes along, FREE, with the standard Classics.
SOC readings include so very many variables that, personally pay no attention to what is displayed on any of battery monitors. Guess that if I was seeing 50% SOC, when 85% was expected, would look further ...
Have my Efficiency set to 70 %. And the proper efficiency setting really depends upon the DOD that the battery has experienced in the previous discharge cycle.
AND, of course, the Rate of Discharge and Charge affect the true SOC.
I use the WBjr's Net AH reading in early morning to see how many AH have been removed from the battery -- for me, all else flows from this important number.
Garret, since you have FLAs, you DO know the best measure of SOC -- your Hydrometer. The SOC reading from the WB is a good rough indication, as you also know.
FWIW, Vic
Doesn't matter what I did or did not see, or that I may not have been looking when what may not of happened happened. Look at my post that shows the recorded data. Even if I did not observe the event that caused the zeroing of the kWh meter and 5% increase in SOC instantaneously (but I did) on the Local Status App., the data record clearly shows this anomaly. Just want to get to the bottom of what may have happened.
WOW !! Garret,
Did not mean to Spool-Up anyone.
If you re-read my post, not even very carefully, it should be obvious that I was making no disbelieving comment. I DO believe that what you saw and recorded did happen. And posted nothing to the contrary.
In re-reading my post, you should find that what I was saying is that the accuracy/repeatability of SOC measurements is probably less than the SOC jump that you noted, especially on FLA batteries.
The Classic is a complex, advanced product, and like most things, it is not yet quite perfect.
FWIW, Have Fun with the new system. Your Friend, Vic
Quote from: Garret on February 21, 2015, 09:38:26 PM
Doesn't matter what I did or did not see, or that I may not have been looking when what may not of happened happened. Look at my post that shows the recorded data. Even if I did not observe the event that caused the zeroing of the kWh meter and 5% increase in SOC instantaneously (but I did) on the Local Status App., the data record clearly shows this anomaly. Just want to get to the bottom of what may have happened.
I magnified the charts so I could read the values better.
Could you please look at the SOC% for the previous hour and 1/2 ?
I am wondering if maybe your SOC% was sitting at the higher percentage somewhere up to
90 minutes before the apparent reset. If so, then that would explain the jump after reset.
Also, what is going on with the FET temperature being negative at the beginning of the chart ?
boB
Quote from: Vic on February 21, 2015, 06:20:54 PM
Have my Efficiency set to 70 %.
Vic, unless your batteries are almost toast, I don't understand why you have
your Amp-Hour efficiency so low ? That is, unless you REALLY want to make
sure that you have put more than enough A-H back in.
boB
Garret
it is pretty clear from those logs that the classic did reset, When it did it took a "Jump" in SOC % for some reason? I cant give you a reason why but I will play around here and try to recreate it. Ideally we would find the reason they reset and fix the root issue. Maybe it is the networking code and Andrews new release will fix it. This has always been a suspicion of mine that its some how connected to the Ethernet?
Ryan
I just forced mine to reboot by viewing the logs. The SOC stayed the same. I will try my other two when I get out shoveling snow. Luckily its real easy to crash the classic so I can play around and see if I can recreate this jump in SOC
QuoteAlso, what is going on with the FET temperature being negative at the beginning of the chart ?
It was perhaps the coldest morning (-24 F) I have witnessed in 50 years in our area. My System is installed in a completely weather tight, but unheated barn. I'm surprised the recorded temps weren't even lower. Must be that it is somewhat warmer inside the barn. At the time of the reset, temps were about single digits. Classic had no problems with these temps in the past. Not saying very low temperatures not a contributing factor, though. I am somewhat concerned about the in-elasticity of cabling in these temps, especially the Ethernet cable running to the WiFi bridge and the possible strain it could inflict on the PCB. Just throwing that out there.
Sorry Vic,
I tend to become defensive at times, because I am sensitized having to deal with some of the most skeptical and contrary people where I work. Not directed at anyone, especially you. You have been most helpful in resolving my other issues.
From what I've read in the posts, you guys are really gonna like me when I start running into problems using the diversion features.
Guys, i thought that the reason the SOC changes after a reset, is that the SOC reverts to the last value that was saved to eprom. EPROM writes occur at midnight each day (same for kWh/day etc). And since the last firmware, every 90 minutes for SOC at least. So the value that it resets to, may or may not be little or a lot different, that all depends on how active yor system is at that time. It can go up or it can go down depending on the time of day the reset occured.
I do not know what affects the frequency of resets, some report them regularly, others infrequently. However some probably watch there systems more than others so thats a factor.
Hi Garret,
Thanks, no problem ... sounds like work can be "fun"!
You are a real asset to the group, am sure that we all will benefit from your observations and analysis.
And boB, just a couple of things;
My Flooded batteries are not often deeply-cycled, so Absorb is a larger percentage of the recharge, and therefore these batteries appear to be less efficient than those under deeper discharge. 85% was too high a number, so just set it to 70%.
And, I need not tell you that constructing a fairly accurate model of the discharge/recharge behavior almost any battery is not a simple process ... seem to be many variables.
Am presently Skipping 3 recharge days on the bank that is most heavily used, but sometimes will Force Bulk on a Skip day, when needed. Furthermore, on occasion will goose up the Vabs to try to get a full charge when WX has been dim. Each of these things should impact what appears to be the efficiency.
The second item, is that Battery Monitor SOC is simply (in my mind) a very approximate guess of what the real SOC of a battery. And with FLAs, can get a fairly close read on what the actual SOC is in a minute or two, with the Hydrometer. Am delighted that am not using AGMs.
The WBjr is a very, very useful device, which I use a number of times per day -- checking Net AH early in the day, and then looking at the actual battery charge current, later in Absorb (always use Shunt EA to end Abs). A very slick addition to the Classic.
The two main battery banks here are each ten years old, but seem to be in generally good health, with a lot or remaining Capacity. Some carp about FLAs, but would still go Floodeds, if the decision needed to be made today.
Just my opinions, Thanks, Vic
Bob, im not convinced the local app reports DEBUG5 accurately. Mine has always said 0, even though the contents of those registers i send you from time to time says otherwise.
The classic just reset while i was typing this, and heres the registers:
peter@cubie:# ./newmodbus.1.0.18-ARM 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 13:00:59 02/01/2003
4380 10 (0xA)
4381 370 (0x172)
4382 76 (0x4C)
4383 0 (0x0)
4384 0 (0x0)
4385 599 (0x257)
4386 173 (0xAD)
4387 2996 (0xBB4)
4388 2 (0x2)
4389 0 (0x0)
4390 2007 (0x7D7)
Local app says:
Absorb Time:03:30:00
Equalize Time:01:00:00
Last Voc:87
DB1: 0x379cebac
DB2: 0x-40b5469b
DB3: 0x6a5b3422
DB4: 0x-53ace6b2
DB5: 0x0
firmware 1849
Application Version 0.3.65
Quote from: zoneblue on February 22, 2015, 06:01:18 PM
Bob, im not convinced the local app reports DEBUG5 accurately. Mine has always said 0, even though the contents of those registers i send you from time to time says otherwise.
Will have to have Andrew see this too.
Thanks for the info !
boB
Quote from: Vic on February 22, 2015, 05:26:15 PM
And boB, just a couple of things;
My Flooded batteries are not often deeply-cycled, so Absorb is a larger percentage of the recharge, and therefore these batteries appear to be less efficient than those under deeper discharge. 85% was too high a number, so just set it to 70%.
I think you are talking about energy charging inefficiency and not amp-hour efficiency.
As far as I know, amp-hour efficiency is every that low. Yes, it takes more watt-hours for the
Absorb area up when the SOC is in the 90% area. But watt-hours and amp-hours are different
things.
Either way, it does not hurt to have the efficiency set on the low side.
boB
Hi boB,
Yea, do know that the AH Efficiency is considerably higher than is energy.
Have never tried to set this Efficiency value correctly, as am always twisting the knobs, trying to avoid charging for as many days as is reasonable, and also that it is not a meaningful quantity to me. Have fairly large battery banks, that occasionally need to be deeply-cycled.
The other data from the WB IS useful, and that is what is used.
More later, Thanks again, Vic