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?
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 ]
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
While SOC < SOCLowSetPoint
{
AUX1=TRUE;
};
Then I'd suggest doing this:
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
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.
Quote from: 2twisty on November 29, 2014, 02:27:40 AM
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
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?
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.
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.
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.
Quote from: zoneblue on November 29, 2014, 08:58:28 PM
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
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
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?
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
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.
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.
Oh, and last night, I turned off the auto-reboot. The generator (and AUX1) worked perfectly.
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
Quote from: 2twisty on November 30, 2014, 06:38:12 PM
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.
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.
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
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?
Quote from: 2twisty on December 04, 2014, 12:06:04 AM
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
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?
Im curious why you say that the classic seems to benfit from daily reboots?
Quote from: zoneblue on December 06, 2014, 09:40:54 PM
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
Quote from: 2twisty on December 06, 2014, 06:36:13 PM
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.
Quote from: boB on December 07, 2014, 03:35:03 AM
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
Quote from: boB on December 07, 2014, 03:21:42 AM
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.
Quote from: 2twisty on December 08, 2014, 08:32:05 PM
Quote from: boB on December 07, 2014, 03:21:42 AM
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 ?
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.
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.
I always see the LA drop its connection, but it is almost 100% that it reconnects on the LA own retry. I can't remember when it fail to connect and required a reboot. I have seen it once or twice but it's been a while.
In my case I am only monitoring it for a week or so at a time during spring, summer and fall. Winter it's on it's own and other that the Classic logging itself I don't know what is happening because there is no internet connection.
Well, at least it is good that the Classic does not appear to need to
be reset anymore to get the internet connection back. THAT was a bad deal !
That being said, it SURE would be nice if TCP/IP connections were always reliable.
Electronics stuff is just never 100% reliable. Computers crash, cell phones
drop calls, records and CDs skip, silicon integrated circuits go bad for no
apparent reason... I have seen two large semiconductor companies
have BATCHES of defective microprocessors that were supposedly reliable that gave me
nightmares in the past 15 years.
So, with that in mind, are we REALLY expecting cars to drive themselves reliably
with all that electronics in them ????? I just don't see how it can work but
I guess we will see !
boB
Quote from: boB on December 10, 2014, 03:16:40 AM
Well, at least it is good that the Classic does not appear to need to
be reset anymore to get the internet connection back. THAT was a bad deal !
I'm not sure that's an accurate statement. There seems to be times where the only thing that will restore the Classic's network IS to reboot it.
WHen I have trouble connecting, I will often ping the Classic's IP. Most of the time I get a reply. That doesn't mean I don't have to reboot the classic..It usually means that I have to reboot the PC I'm using to clear the junk out of Adobe Air. When it does NOT reply, the ONLY cure is a reboot of the Classic.
I can start a log of when it misbehaves and what is required to fix it, if you like. Is there any other data that you need? I need to add another cutoff switch between my distribution block and the Classic so that I can kill the power to the classic without killing power to the inverter. Shutting down my entire system for a hard reboot is a real PITA, since I have computer equipment that has to be shut down cleanly.
.It usually means that I have to reboot the PC I'm using to clear the junk out of Adobe Air.
Is there not another way to clean out Adobe Air?
Quote from: Westbranch on December 10, 2014, 12:01:03 PM
.It usually means that I have to reboot the PC I'm using to clear the junk out of Adobe Air.
Is there not another way to clean out Adobe Air?
I have not heard of a problem with Adobe Air itself. I will point Andrew to this discussion.
2twisty, have you also tried rebooting your router instead lf the Classic ?
What kind of router are you using and in what mode is it in ?
boB
When we discussed this a while back a lot of us were using Linksys routers, but I don't think there was any conclusion made. I looked at it with Wireshark back then it was with the old firmware before boB made changes to the Classic Network code. At that time it was the Classic that did not respond. Be interesting if someone could run a Wireshark trace until they get a disconect to see who is dropping the ball. I guess it could still be a quirk in the router losing the response. I'm no longer using a Linksys router and I still get the disconnects just not ones where I have to reboot. This is also with a more recent Classic. At least one after the case mod for the fans was made. I see this mostly when trying to extract data from the Classic with the LA.
Wireshark discussion from before.
http://midniteforum.com/index.php?topic=1054.msg8230#msg8230 (http://midniteforum.com/index.php?topic=1054.msg8230#msg8230)
Yeah, this problem is evidently still on certain systems and has mainly to do with networks ungracefully disconnecting
at ~just~ the right time. Or, wrong time. We're working on it still of course.
The Classic is plugged into a regular 5-port gigabit switch. It's not a router.
I don't buy any argument that my network hardware is the problem, since I have several items on my network and none of them have any problems making and maintaining a connection to or from any other piece of hardware except the Classic.
This tells me that the problem is in the Classic, not the network.
As for Adobe Air: in another thread somewhere here, there was discussion that Adobe Air can sometimes get a little wonky and a reboot can sometimes fix it. I've also had to reinstall Adobe Air on my laptop as well as on my mobile devices. The LocalApp is completely useless on iOS, and is marginally useful on Android.
I'd love to see an OS-native app for this; trying to make a one-size fits all application totally cross-platform is problematic at best.
I agree that the Classic should not have to be reset to regain communications.
Are you running the Classic in DHCP or STATIC IP mode ?
If DHCP, what gives it and the other devices on your network their IP addresses ?
I've used both static and DHCP. I prefer static, because the classic kept getting different IPs and the Local App would remember the old one and I'd have to remove it from the list.
It's currently set to static.
To answer your question, the internet router is an Apple Time Capsule. I've even tried statically setting the IP on my laptop, and it doesn't seem to affect the problem. It does it regardless of the DHCP/Static settings.
The laptop is connected to the network via WiFi. I suppose I could run cat5 across the floor, but I'll need a note from you explaining why that's needed to my wife, lol.
testing with a Cat5 will tell , over time, if that wifi is part of or the issue... is the Classic attached to a router or a bridge?
BTW, I have Aux 1 remembering the state of the output over an auto-restart.
Now, it doesn't set it until a couple seconds after the reboot though.. I will try and tighten
it up some but chances are that it may glitch high or low for a moment until it sets it
right.
Quote from: Westbranch on December 13, 2014, 01:38:08 AM
testing with a Cat5 will tell , over time, if that wifi is part of or the issue... is the Classic attached to a router or a bridge?
It is not directly connected to a router or bridge.
The Classic connects to a 8-port gigabit switch, to which all my ethernet-enabled devices connect.
I have a wireless range extender that is also plugged into that same switch. My laptop accesses the network over wifi via that range extender.
The range extender connects to the router wirelessly (about 1/4 mile away!) which serves the DHCP and provides access to the Internet.
Quote from: boB on December 13, 2014, 08:21:32 PM
BTW, I have Aux 1 remembering the state of the output over an auto-restart.
Now, it doesn't set it until a couple seconds after the reboot though.. I will try and tighten
it up some but chances are that it may glitch high or low for a moment until it sets it
right.
Great!
How about adding a delay in the AUX1 code so that it waits after a reboot for a moment to give it time to set the level?
For example, add some boolean variable called InitDone, and have the code that decides whether Aux1 should be turned on check that the value of InitDone is TRUE. Then in the code that runs immediately on reboot, set InitDone to FALSE until the init procedures are completed. That should prevent the accidental trigger of AUX1 until you've had a chance to write the values of SOC from EEPROM to the registers.
Again, I've not seen the code, so I don't know how easy it would be to add something like this -- just a suggestion.
Interesting data point:
When I cold-boot the CC by removing the power, it does NOT automatically energize AUX1. So, there is some difference in how the CC behaves between a reboot and a power-cycle.
Scratch that data point. I cold booted the controller again later today and it started the generator.
So, it seems that if the SOC falls between the low and high setpoints, it will start the generator. Not sure how to address that programmatically, unless there is some way to store the state of Aux1 over a reboot so that it knows that AUX1 was OFF while the SOC was 70ish. That should indicate that it was still falling and not rising.
And I DO need a daily reboot. If I don't reboot the CC daily, I will usually lose the ability to connect via the Local App. Interestingly, I can usually ping the IP of the Classic... Every now and again, I can't even do that. But most of the time I can ping it but not connect. I either get "retying" forever, or "not found."
Rebooting the Classic (and sometimes the host PC) restores access via the Local App
2twisty, try this
http://fusion.midnitesolar.com/MidNiteSolarUpdate_1923_12-18-2014_v4.60.exe
BTW, Merry Christmas too !
boB
OK. I'll download it and do the update tomorrow.
What changed?
Found the Changelog:
12-18-2014
Classic build 1923
Lifetime kW-Hours and Lifetime Amp-Hours will now accumulate and
not be limited to just 16 bits worth. (long time bug) 65535
Aux 1 SOC% output will now remember On/Off state through an auto-restart cycle
Whizbang Junior accumulations will save periodically throughout the day to non-volatile memory every 90 minutes
Classic will go to Resting for 8 seconds when MPPT mode and power output stays below 50 watts for 15 minutes in Legacy, Hydro or Dynamic tracking mode if Insomnia is On. (night charging sanity check)
Removed VariMax Absorb mode
MNGP build 1922
Added menu LIMITS---MORE--- High battery temperature charger shut off
Fixed Daily Hi-Power graphs log numerical readout. Was only
showing 3 digits
Increased time required to show "Got Comm ?" message by 2 seconds
Well poo. This is the first firmware update I've attempted since I got my Classic. All my windows Machines use 64-bit, so apparently, the USB driver won't install.
I also have a Mac. Could you produce this firmware in the Mac/Linux flavor for me? Or, is there a 64-bit windows driver available yet?
Also, Will I have to do a factory reset after uploading this? I'm assuming so. Is there any way to back up the Classic's settings?
Quote from: 2twisty on December 25, 2014, 11:34:35 PM
Well poo. This is the first firmware update I've attempted since I got my Classic. All my windows Machines use 64-bit, so apparently, the USB driver won't install.
I also have a Mac. Could you produce this firmware in the Mac/Linux flavor for me? Or, is there a 64-bit windows driver available yet?
Also, Will I have to do a factory reset after uploading this? I'm assuming so. Is there any way to back up the Classic's settings?
Are your Windows machines running win7 or win8.1 ?? The USB to Serial driver installs a little different between this two OS's. The Midnight instructions are pretty good but they have to be followed in the exact sequence or you can have trouble installing the driver the first time.
Yeah, you need to do a factory reset Vulcan Mind Melt and No there is no way to backup the Classic setting. Best you can do is jot them down. After a while they become second nature.
Uh, there is a really good point just raised. Does Midnight have 64 bit drivers for the windows machines with win8+ ?
I just had to install 64 bit drivers on my wife's pc, for sync with a Palm OS PDA, the 2003 install disk only has drivers that support the 32 bit machines. Some kind souls continued work after palm sold to HP, and HP abandoned the palm platform. Having the right drivers made all the difference
Could this be the factor why some win 8 machines work, and some don't ? 32 bit vs 64 ? (and why I drag out an old laptop for the firmware update)
QuoteClassic will go to Resting for 8 seconds when MPPT mode and power output stays below 50 watts for 15 minutes in Legacy, Hydro or Dynamic tracking mode if Insomnia is On. (night charging sanity check)
Does this solve the generator charging voltage confusing the Classic and getting the batteries running the PV and consuming watts ? If Insomnia is OFF ??
The drivers seem to work ok on 32 or 64 bit windoze 7 and win 8... windows 8.1 made it VERY hard to install non-signed drivers though.
It can be done, just takes an act of congress on windoze 8.1
Yes, there IS a mac and Linux version but you must be computer literate to use the Mac and Linux version since it is command line driven at the moment. Still the old yechhy USB virtual comm method. Will make up this version tomorrow and post that link.
Mike, I think this covers the problem where in the evening if there was somehow some watts showing up that the Classic will shut itself down if less than 50 watts of offset is showing.
boB
My windows machines are Win7x64SP1
I am quite proficient with command line in OSX/Linux.
I didn't see any "step by step" instructions for installing the USB drivers. Can you point me to them?
EDIT: Found it here. Instructions are at the bottom for various OS's...
http://www.midnitesolar.com/firmwareReport.php?firmware_ID=9&firmwareProduct_ID=1&act=edit
boB
This is the normal page for downloading firmware and there are some instructions here...
http://www.midnitesolar.com/firmwareReport.php?firmware_ID=10&firmwareProduct_ID=1&act=edit
There is this older document...
http://www.midnitesolar.com/pdfs/Classic_firmware_update_doc.pdf
Now, there IS another PDF or two that is newer and more in depth. BUT I'll be darned if I can find it !
There is also a video or two showing this. I know that Ryan knows where it is.
We'll get a link for it tomorrow if not sooner I hope.
OK, found it thanks to Google. There SHOULD be a link to it on our firmware page though...
http://www.midnitesolar.com/firmware/Firmware_install_Windows7.pdf
And windoze 8 ...
http://www.midnitesolar.com/firmware/Win8_firmware_update.pdf
boB
OK. I've got the firmware updated and my settings restored. I'm running my generator manually right now since we have had 2 days overcast and little solar input.
If I'm awake at midnight (2 hrs from how) I will note AUX1 behavior. However, it won't be a fair test until I can get back to float on solar, since the Classic is really confused about SOC right now, with the alternate charging and the multiple reboots for firmware updates, it thinks I'm at 90-something right now, when, in reality, I should be in the upper 70s.
I'll report back after I've gotten back to float.
I would like to add my voice to the request for ethernet firmware updates, as well as a way to back up the settings on the classic and easily restore them so firmware updates can be painless.
Glad you got it updated.
The Local App will soon (if not released already ?) be able to import and export all modbus registers. That is one way
to back up the settings.
Updating firmware is always a PITA. In the case of the Classic, The USB method happened first and the way it is now
was pretty much the only way that was going to work then. Then, the Classic was updateable by Ethernet but
not the MNGP. It could be finished to update the MNGP and that may (or may not) happen. Now, the way to go is
most likely how the Kid is updated, by a drag-and-drop file transfer. It would be even harder to make
all the older Classics compatible with a newer update method. If we had unlimited resources, we'd be working
harder on this but it is going to take a longer unfortunately. This comes up a lot around here though as you might
imagine.
It would be nice if the processor used in these products had more memory like a PC or Linux computer but it is
very limited.
boB, is this new firmware update going to take care of the issue of the Equalize function somehow getting into the Start Equalize function rather than defaulting back to the Stop Equalized. I just saw this again when I made a trip to the lake to check on things. I was changing the Rebulk value and when I hit enter to save the setting the controller jumped to Equalized when I when to the Equalize menu sure enough the Equalize Start option was showing. This has been brought up in the forums before and I believe you were aware of it but don’t see anything in the Readme file about it being fixed. Hopefully it can be included as with everything else Midnite has going on the firmware updates are getting few and far between.
Sorry to hijack the thread but since the subject of new firmware came up I thought I would ask.
OK. Got to float today. We shall see if it works properly on the reboot tonight.
Believe me, I'm quite aware of the small amounts of memory that these processors have. I used to have an aftermarket ECU in my car to control a turbocharger. The SOC in that thing had so little room left that the developer had to optimize the code every time to make the tiny changes fit. I've never understood why they don't put more RAM on these SOCs.
I'd love to see a RasPi with a couple gigs of RAM. It would make many things so much easier!
Fell alseep before midnight last night. However, the starting of the generator usually wakes me briefly, and from the SOC I saw by morning, it looks like the generator did NOT start prematurely last night.
I guess I now need to wait for a time to see if it turns on properly, lol.
I'll update this thread as soon as I have any useful data to report. But from the looks of it, it seems to be working!
Well..... The exact feature I asked for bit me in the @^#..
When I did the FW update, I missed one of my settings when I was putting them back in...the size of the battery bank. The Classic thought it was a 400Ah bank when it is a 208Ah bank.
So, my SOC readings were way off, and my generator was not starting. Found it this AM when I noticed that my voltage didn't jive with the SOC that the Classic reported. Thankfully, it was only a couple days, and both days I got back to float by early afternoon.
Generator is running now; it kicked on immediately after I updated the bank size to the correct value.
Please get that backup/restore function working soon!
Quote from: 2twisty on December 30, 2014, 09:43:32 AM
Please get that backup/restore function working soon!
This exact feature is in the latest Local App...
Andrew is the keeper of this. Ryan or Andrew should release this if it is ready.
boB
Yeah! Let's start the new year with an update to the Local App!
Woohoo! Is it ready, Andrew? Are we there yet?
:)