Classic Firmware 1795: 03/17/2014

[Resthome]

With the following steps I am able to get the Classic with firmware 1795: 03/17/2014 to reset (reboot) itself.     I believe it was also happening as far back as firmware 1759: 02/05/2014 and possible farther.

• Go to the MNGP Log menu and select Daily
  
• Go to the Local App 0.3.51 and select DATA then Offline
• The Classic resets with a RFR code of 104
• Power off the Classic and back on to reset the RFR code to 111
• Then repeating steps 1 & 2 the Classic reset with a RFR code of 104

Can anyone else duplicate these resets with these steps?

[boB]

John,  I have ~some~ success here...  First, a question...

>>>3. The Classic resets with a RFR code of 104<<<

Is your Classic Resting when you see it reset ?  Remember that this RFR code will stay
as 104 forever if the Classic's mode is off or it is night time (dark.)

  OK, having said that, back to what I just found.

I am able to repeat something with your recipe but not exactly a reboot of the Classic itself...

What happens here is that the Local App, through TCP/IP of course, will have its connection close
in the middle of trying to read the offline data.

Now, I think this is happening when the Classic itself is saving the minutely logs and I had my
interval set for every 60 seconds (the minimum you can set through register-address 4135)
so trying to read the daily logs from the Local App, taking its sweet time, would always coincide
with that minutely data logs write to EEprom and would close the TCP/IP Ethernet connection
almost every single time...   But the Classic was not resetting when the connection was lost.
This is still great information !

This behavior happens even if I am NOT in either of the Daily or Minutely logs graph screens and
the connection to the Classic does return without having to reset the Classic.

It has to be related to the Classic writing minutely/recent data logs to EEprom while the
Local App is reading the Daily logs from EEprom inside the Classic.

Aside from the Local App, this newer revision, 1795, does stop the Classic from resetting while
the MNGP is sitting in the logs graph screen when the Classic saves minutely data to the EEprom.
The MNGP graph screen is unaffected though, as it is just reading the same data over and over
through the RS232 modbus line to the Classic.

When I changed register address 4135 to a very large time value, this Local App behavior stops happening and
the local app's offline data read will complete with the EXPORT button ready to save to disk several times
in a row.   At one minute saving intervals, it would lose the connection every single time, except maybe
one time.  I can only assume my start of reading the offline data came RIGHT after the Classic saved
its minutely/recent data logs to EEprom and was just enough time to read that data that one time.

Your minutely logs interval is most likely 5 minutes or 10 minutes and I think that it may do a save
soon after it resets itself, so if it is resetting, that may be what makes it very repeatable
for you.  I will have to look closely at that again now.

If your Classic is really resetting and not just dropping the Local App connection, then I am not
sure what might be happening there.  BUT, there is still something rotten in Denmark !

Thanks for this valuable input !
boB

[Resthome]

boB.. 

It is definitely a restart of the Classic and this is happening on two different Classics. One which is brand new and sitting on the bench. The fans rev up and the LEDs flash and if you are in the middle of absorb the max absorb timers reset to the max absorb time.

After each one of these resets with the RFR showing 104 I power the Classic off so the RFR would reset to 111.  On the older Classic that is in production I have some exported log files showing the resets that I have attached. I had to snip out some of the data between these resets to get it to fit on the forum. Please note these resets where random and before I could pin down the cause but it may be helpful. The resets are highlighted in yellow. On this older Classic Ryan had me replace the Control Board for a different issue, but the resets were happening with both the old and new control board.

On the newest Classic I have it setting on the bench and only have it connected to a 12v battery bank with no PVC connected. So it is resting all the time. The newest one is running the firmware you posted a link to at http://fusion.midnitesolar.com/MidNiteSolarUpdate_1795_3-17-2014_v4.29.exe

I am not even going to the Graph screen on the MNGP. I am letting it set on the Daily Log screen (my guess is it is reading from the EEPROM on this screen) and almost immediately within 10-20 seconds after I start the Local App and put it in the Offline data mode the Classic restarts. My second guess is when the Local App first starts the Offline data mode (I believe Andrew has said he is using the File Transfer mode here) there is some kind of writing to the EEPROM that is causing the resets to happen. Just guessing as I am no expert.

By the way register-address 4135 is a decimal 1on this bench Classic.

Disconnects from the Local App happens here but it's because the Classic reset. 

I'll be glad to try any testing you require on this to help you resolve it. I think if we can resolve it on the Classic on the bench that it may also solve the resets on the production unit.

Thanks again boB for looking into this issue. Midnite has the best support of any company!

[Halfcrazy]

You are correct I can recreate that as many times as I want here. It is a full reboot. Fans rev up and everything. Interesting? I mean I "assume" that is a rarity but it sure does point to a problem

[Resthome]

Thanks Ryan,

I just had a though of why boB isn't seeing the resets. Since he is loosing the connection to the Local App for some reason. I doubt that what ever takes place in the Local App Offline data transfer on our systems is taking place because of the lost connection. Maybe, who knows. I think the real issue is are there other times that as boB suspects that the read and writes cross paths that would cause the Classics to reset. You would think there would be some kind of busy flag that would be set when the EEPROM was preforming a transaction so they couldn't cross paths.

The question of the day is if we make sure to leave the Classic MNGP in the Status display would we be safe from resets? Don't know as I would think that the Classic would be reading and writing to the EEPROM a lot of different time but maybe it's only doing it one at a time and its the outside monitoring communications(like the local app) that can cause a read and write to conflict. Lots to think about but I will leave it to the experts to come up with a solution.

What is really strange is I had never seen any of these resets before we started to add the WBjr features. And that would have been since the fall of 2011 when I installed the Classic. But since my actual presence is weekend or a weeks vacation on the boat I may never have seen it until now. And I did always have the A-RST set so it would have negated any RFR codes I think or at least until the next regular resting at night. And I just started to look at the MNGP more with the Net Amp and other WBjr features. An that is when I could not understand the SOC going back to 100% in the middle of the night because I still had not seen the resets until the next trip.

Okay enough said for now. We just need to get boB's Classic to reset ! Maybe he needs to go steal one off the production line.   

[Halfcrazy]

Well worse comes to worse we will make boB come to Maine and play in the snow and watch mine!

One thing that's different about the Logs menu is that it uses a file transfer protocol (I think?) vs modbus

[Resthome]

I did reread boB post and I think I can say that I do not see the resets in the Graph screens on the MNGP panel. I have in the past but not currently. But leaving the Classic MNGP sit in the Daily or the Hourly Log screen (non Graph) and then starting the Local App and going to DATA OFFLINE that causes the resets within 10-20 sec of going to Data Offline in the Local App.

Ryan I believe you are correct about the Offline data retrieval in the Local App using the Modbus file transfer method. boB asked that of Andrew in another thread and Andrew's reply was Offline data was using File Transfer. Of course it's over TCP/IP. I tried the varies USB/Com8 data dumps to Putty on my laptop and none of them triggered a reset but I don't think any of them are using the Modbus File Transfer method.

Okay all of this is above my pay scale. Just trying to pin down some more info.

[boB]

I am not even going to the Graph screen on the MNGP. I am letting it set on the Daily Log screen (my guess is it is reading from the EEPROM on this screen) and almost immediately within 10-20 seconds after I start the Local App and put it in the Offline data mode the Classic restarts. My second guess is when the Local App first starts the Offline data mode (I believe Andrew has said he is using the File Transfer mode here) there is some kind of writing to the EEPROM that is causing the resets to happen. Just guessing as I am no expert.

OK, trying this now...  I was NOT in this same screen as you were.  I was in the graph screen.  I read your
recipe wrong.  Thank you for correcting me here.

BTW, this "text" logs screen does not use the file transfer method.  It reads using regular old modbus
registers.  Both log reading methods read the data from the EEProm on the Classic.

By the way register-address 4135 is a decimal 1on this bench Classic.

This register "address" should not be capable of going to the value of "one"  (1)....  Minimum of 60 seconds
and maximum of 20,000 seconds is what the Classic limits that value to.  Maybe you were reading "register" 4135
which would be register "address"  4134.

OK, checking your original method.  I bet it resets as well since Ryan's did.
I don't think that WB Jr. has anything to do with this but you know how things
can go.

Also, you are correct...  I did add a busy flag to stop the weird cross-access.

boB

PS.   YES !!!   It RESETS !!!  COOL !!!

Thanks  RestJohn !!!

OK, NOW, the question is...   If you have two (2) MNGPs on one Classic, one of those sitting in the LOGS text
screen and the OTHER MNGP sitting on a graph screen, does it reset the same way this does using an MNGP
and the Local App ?  It should, but I would be happy if it did not reset using that method...  I would hope that
it only resets now using the Local App.

BTW, also, it appears that, and makes sense, that register address 4135 does NOT have to be set for
a frequent log saving interval to make this happen.

boB

[atop8918]

Wow!
Excellent, excellent find, RestHome! Repeatability is the first (and usually biggest) job in fixing bugs. Thank you for digging into this one.

[Resthome]

By the way register-address 4135 is a decimal 1on this bench Classic.

This register "address" should not be capable of going to the value of "one"  (1)....  Minimum of 60 seconds
and maximum of 20,000 seconds is what the Classic limits that value to.  Maybe you were reading "register" 4135
which would be register "address"  4134.

Yeah got the wrong one.  Register "address" 4135  is  300  which would be the 5 minutes.

Glad you were able to reproduce it.

[boB]

OK...   I just verified that the Classic will reboot/reset if you have two MNGPs and set one
to read a graph and the other to sit in that LOGS textual screen...  Over and over...

So, I don't think this has any bearing on TCP/IP connections but will definitely look to
see why this is happening.  I suspect this is an easy one to fix but I don't suspect (yet)
that is will fix much else.

Thanks for finding this !  I thought for sure I had already tried this and I think
I have...  It may very well be an artifact of the latest software and the latest fix
for that other resetting method, sort of related to this one.

boB

[boB]

OK, well I found the problem and it can be fixed but will take a bit of time and work.

I do not think this is related to rebooting of the Classic while nobody is interacting
with it though (unfortunately)..   Still pondering a fix but at the moment, this
particular reboot scenario is mostly (and luckily) an annoyance.

Thanks again and keep taking notes if you find anything further.

[Resthome]

OK, well I found the problem and it can be fixed but will take a bit of time and work.

I do not think this is related to rebooting of the Classic while nobody is interacting
with it though (unfortunately)..   Still pondering a fix but at the moment, this
particular reboot scenario is mostly (and luckily) an annoyance.

Thanks again and keep taking notes if you find anything further.

Thanks boB you guys are awesome with your support.

Yeah the annoyance to me was if the Classic was half way through or worse almost all the way through it's Absorb cycle. It would reset the timer on the Absorb timer and start another complete Absorb cycle.