:'(Hello
I am having a stranfe behaviour with my Classic 150
Twice now during the day the unit just reset anx shows 0 righf after
I loose all data of thd day
removed auto reset no change
any idea
Alain
Alain,
Did you see the Classic when it did this ?? Did you notice if the display (MNGP, Remote) reset like
you had turned the power off and back on again ?? You would see the Midnite Solar logo (moon)
appear on the screen when it did this.
Was it the kW-Hours that was zero ?? Or did you see the voltage display go to zero ?
Thank you !
boB
Mine did this the other day too but it's only happened once. I was pushing buttons around the time it happened but I wasn't in the logs where you can manually reset the daily data so I have no idea how it happened. Mine did not restart, it just cleared the kW-hrs for the day.
Quote from: Wxboy on February 27, 2013, 12:55:09 PM
Mine did this the other day too but it's only happened once. I was pushing buttons around the time it happened but I wasn't in the logs where you can manually reset the daily data so I have no idea how it happened. Mine did not restart, it just cleared the kW-hrs for the day.
There is a way, from the daily logs main menu, to reset the daily logs and this will also clear the kW-Hours on the
main status screen... Maybe you hit that button combination.
How you do this is to hold down the Left-arrow key and while holding it down, you press the ENTER key for
a moment until the display says "NEW DAY" I think it is... Now, you might do this and not see the New Day
message come up if you're not expecting it and it just happens to do this.
Maybe that's what happened ?? Maybe I need to make it a little bit harder to do this ?
boB
boB, I was trying to say that I was not in the logs menu when it happened. I do reset the daily data there on a regular basis before I shut the Classic off at night but in this case I was not in the logs menu so I couldn't figure out how the data was reset. Again it only happened once so I wasn't going to mention it but since someone else brought it up first I thought I would chime in.
I don't think anyone could accidentally do that so I wouldn't worry about changing the process of resetting the daily log.
My Classic just did the same thing reset just for heck of it. I am using the actual released code 1181 . But using the Beta version of the App/ Air 3.17/
When it reset all lights were blinking and having fun, It cleared all Kw and Ahrs for the day .
This has happened 3 times now. Different days. I just thought it was a fluke. But now who knows.
Quote from: SolarVet on March 01, 2013, 01:40:15 PM
My Classic just did the same thing reset just for heck of it. I am using the actual released code 1181 . But using the Beta version of the App/ Air 3.17/
When it reset all lights were blinking and having fun, It cleared all Kw and Ahrs for the day .
This has happened 3 times now. Different days. I just thought it was a fluke. But now who knows.
I wonder if you might have auto-reset turned on in this week's menu?
If that is turned on and your clock is wrong also, you would see it reset during the day. But the kilowatt hours would be added to the lifetime kilowatt hours even know they cleared on the main status screen.
It's worth checking out anyway.
boB
FWIW, I had the reset taking place at some ungodly hour of the morning. Went to let the cat out or stoke the fire somewhere around 4:30, 5:30 a.m., and the thing just about scared the life outta me.
I've since turned the reset off... Since the reason was to allow it to chat with the local app now and then, but changes to both have fixed the drop-out issue.
I have also had the kWh reset. The kWh readout on my Classic 150 (S/No. CL03940) reset itself about 2 or 3 hours into today's sunlight, after updating the firmware last night (MNGP 1042 12/1/2012; Classic 1181 12/1/2012). KWh had reach 0.3 when this occurred, and since then started increasing again, currently at 0.5 kWh.
Relevant points:
* I was not operating buttons on the MNGP at the time.
* This never happened on my old firmware (MNGP 1056 6/29/2012; Classic 1070 8/13/2012), over three months of trouble-free operation.
* The main reason for last night's update was to get the PC Solar Status Panel working (it could not connect previously).
* This morning prior to sun-up I enabled A-RST (Auto-Reset).
* The date and time in my MNGP is only 1 minute slow at 15:36 hours. The kWh glitch occurred at about 12:00 (noon), according to the log. This could indicate that some part of the A-RST is broken; perhaps it is applying a 12-hour offset?
I have disabled A-RST as a precaution...I'd rather have an accurate kWh log and sometimes have to restart the system, than to have this behavior.
I saw these issues and more with firmware 1181
Upgraded to beta 1341 and now all is good, so far :)
dgd
dgd wrote:
QuoteI saw these issues and more with firmware 1181
Upgraded to beta 1341 and now all is good, so far
A kWh reset just happened again to my recently updated Classic 150, at 17:52 hrs. :( Well, there goes the 12-hour offset theory out the window...
I observed the following:
1) PC Solar Status Panel disconnected and showed the Connection Closed dialog box (clicking OK brought the Panel back)
2) Prior to the 2nd kWh reset of the day, the reading was approx. 0.7 kWh
3) The Classic 150 fan did the startup burst, however I did not see the MNGP screen until after the fan (it was the fan burst that alerted me).
I think I'll move on to the 1341 beta.
Make sure that the Clock is set in the MNGP of course. Also, in the TWEAKS
menu, the 3rd or 4th screen up is one called "TimeSync" Make sure that is
set to ON. It should come up as ON after doing a Vulcan Mind Meld re-initialization.
The kW-Hours will automatically be added to the Lifetime kW-Hours and then reset
at 23:59 just before midnight. If it thinks it is 23:59, it will do this then.
If for some weird reason there is a time sync problem, you can read the
Classic's internal clock/calendar by going to the MNGP TIME set menu and
the holding down the LEFT arrow key and tapping the SOFT-right key.
The MNGP sends time and date to the Classic control board once per minute or so.
boB
OK, so there have been a few random-like resetting Classics.
I would like to find out of it is the entire Classic resetting ? Or, is it just the kW-hour
resetting like happens at 23:59 at midnight ?
What versions of Classic firmware are you guys seeing this on ? Are you seeing it just
on the latest beta software ? Or 12-1-2012 version also ?
This is evidently not an epidemic but more than 2 or 3 is enough to be somewhat worrisome.
Any information to help narrow things down would be most helpful !
Thanks everybody !
boB
Quote from: boB on April 18, 2013, 02:54:48 PM
OK, so there have been a few random-like resetting Classics.
I would like to find out of it is the entire Classic resetting ? Or, is it just the kW-hour
resetting like happens at 23:59 at midnight ?
What versions of Classic firmware are you guys seeing this on ? Are you seeing it just
on the latest beta software ? Or 12-1-2012 version also ?
This is evidently not an epidemic but more than 2 or 3 is enough to be somewhat worrisome.
Any information to help narrow things down would be most helpful !
Thanks everybody !
boB
Ok, boB, which firmware version would you like me to "downgrade" to? I currently have 1370 04-08-2012 on it and, as you know see these resets.
I have these on my hard drive:
Classic_ALL_Gen4-150V_12-1-2012.ctl
Classic_ALL_1370-150V_4-8-2013.ctl
Classic_ALL_Gen4-150V_11-28-2012.ctl
I can do it no problem. Not much power coming in lately anyway. (no sun).
Tom
Quote from: TomW on April 18, 2013, 03:42:59 PM
Quote from: boB on April 18, 2013, 02:54:48 PM
OK, so there have been a few random-like resetting Classics.
I would like to find out of it is the entire Classic resetting ? Or, is it just the kW-hour
resetting like happens at 23:59 at midnight ?
What versions of Classic firmware are you guys seeing this on ? Are you seeing it just
on the latest beta software ? Or 12-1-2012 version also ?
This is evidently not an epidemic but more than 2 or 3 is enough to be somewhat worrisome.
Any information to help narrow things down would be most helpful !
Thanks everybody !
boB
Ok, boB, which firmware version would you like me to "downgrade" to? I currently have 1370 04-08-2012 on it and, as you know see these resets.
I have these on my hard drive:
Classic_ALL_Gen4-150V_12-1-2012.ctl
Classic_ALL_1370-150V_4-8-2013.ctl
Classic_ALL_Gen4-150V_11-28-2012.ctl
I can do it no problem. Not much power coming in lately anyway. (no sun).
Tom
I looked at your "record" on my android while at lunch and it was behaving itself then.... It wasn't before though as Ryan
pointed out to me.
Have all of those revisions done this ? Or is that one 1370 (4-8-2013) the only one so far that you have seen do this ??
I know you don't have a lot of sun right now so maybe you should wait until you have some more sun ?
boB
boB;
Yes, I believe I was getting this from all of the revisions. I saw it on the LA combined with dropped connections. It seems it only became obvious in the mymidnite data. Seems the offline data self heals or something because the totals seem to get in there?
I don't report issues with my LA as its older AIR on Linux so may be that affecting the LA.
When it showed up on the mymidnite page I figured it was the Classic not the LA?
Sorry I cannot give better info.
Tom
Quote from: TomW on April 18, 2013, 07:19:05 PM
Seems the offline data self heals or something because the totals seem to get in there?
Do you mean that you think that the totals (lifetime kW-Hours) are being updated with
these zero'd out kW-Hour readings ? If so, that lifetime kW-Hours reading on the Local-
App should also be updated I would think.
Keep watching. That's all we can do at the moment. Maybe your hardware has a problem ?
Maybe there are a few Classics with some hardware abnormality ?? I don't know yet.
boB
boB;
What I meant is that WRT KWH that the offline data seems to get the correct data when it writes it out at 23:59? My offline data used to have multiple 0.00 KWH entries prior to this current beta firmware and before dates were included with just numbers of days prior. I probably have those files on HD someplace. But, then, I am really not sure as I was not watching it very closely.
Now that I am aware it may be an issue, I will pay closer attention.
Tom
Hi,
When I encountered this issue, the data reset affects the Classic and the Local App.
I have recorded these days datas, so i can answer the question, but only when I returned to home.
Yann
Thank you Yann and Tom !
And Tom, the new firmware you are running fixes the multiple day logging issue but
what I am wondering is, does the one daily entry in the offline data jive with the
data added to the lifetime kW-Hours ?? If your Classic would normally have
logged multiple non-zero kW-Hour values for a single day is one thing I would
like to find out.
I think that, unless your Classic actually "rebooted" itself during the day, that the
chopped up kW-Hours that you saw zeroed out should be accumulated in the LOGS
lifetime kW-Hour value at the end of the day. That's what I would really like to know
and by looking at the hourly/minutely/recent history logs (only viewable in the MNGP),
each group of kW-Hour data logged should show up there because that is logged every
5 or 10 minutes so you could add that up yourself.
In fact, you can actually download the EEprom in this latest firmware to a CSV file
and that might be what we may have you do at some time.
boB
Hi,
So, find enclosed screens captures of one of the 2013/03/28 resets.
My LocalApp logs are very heavy ( it seems to put two days in the day file, 50 000 records ).
My computer registers these datas beetween 06:45 to 19:45 and after goes in sleep mode.
Can I send these datas by mail (four files 2013/03/28, 2013/03/29 and 2013/04/08, 2013/04/09, 5.5 Mo each) ???
Edit : The firmware was this beta version "MidNiteSolarSetup_3-1-2013_v3.69.exe" because I goes up on 2013/04/12 to this Beta Version "MidNiteSolarSetup_4-8-2013_v3.70.exe".
Yann
Quote from: boB on April 19, 2013, 01:35:52 AM
In fact, you can actually download the EEprom in this latest firmware to a CSV file
and that might be what we may have you do at some time.
boB
boB;
Running Application Version 0.3.24 with the 1370 Classic Firmware and current MNGP firmware and I cannot see how to pull out that cvs file? Got any info on "how"?
Mine has not done the zeroing since I brought it up, either on the Local App or My Midnite page.
Figures. Ghost in the machine I guess.
Tom
To dump the EEprom, you have to get a terminal emulator like Putty or something like that
and connect to the Classic via USB. USB mode 3 (interactive). Make sure the Classic
and terminal emulator is talking (USB Mode 1 or 0 for instance will spit out data) and
in mode 3 and the terminal emulator set to log to a file, type in....
"download EEprom"
without the quotes and return (ENTER) and it should start sending out address and data, comma separated.
I can upload an excel file with some explanations of the addresses which is kind of handy for
plopping in the 2 columns of retrieved CSV data and it should line up with the template.
boB
Well, my Solar Classic reset 3X today. Was dragging in a lot of solar amps through it for my 1500 watt array with heavy loading on the inverter as well. No where near the capacity of the Classic on amps, tho.Better half is good at using it when it is coming in. Yay!
Batteries were generally in Absorb in between load dips. Local App showed the lost connection pop up and it reset my KWH reading in the Local App. This leads me to believe I am having this problem only under heavy charging and perhaps including heavy loading on the inverter.
I did have a day or 2 of no resets during low production level days.
Just what I am seeing here.
Tom
Tom
Dumb question, do you have anything running on the Aux outputs?
Ryan
Quote from: Halfcrazy on April 26, 2013, 04:35:52 PM
Tom
Dumb question, do you have anything running on the Aux outputs?
Ryan
Ryan;
Funny that you ask.
Yes, I run AUX1 to a 12 volt automotive pilot relay to activate a 24 volt coil HVAC relay to activate my 120 volt coil relay to my 120 volt water heater element. Actually a DPDT relay switching from grid to inverter so I can heat water regardless of the battery situation.
AUX1>Automotive relay>>HVAC relay>>DPDT relay>>water heater. More parts than ideal but works unless that is resetting the Classic?
Also funny, I was in the area just awhile ago and the relay switched off (audible) then back on a few seconds later and the Classic reset at about the same time. There was no way the voltage triggered the relay off at the low set point. Never caught it doing this before.
Something to do with power draw on the AUX1 circuit? I do have a spare SSR I could replace the pilot relay with for minimal draw on the Classic Aux1?
The plot thickens....
Tom
Ok so boB thinks you are getting a watchdog rest. So do you have Auto reset (A-RST) enabled?
If not then we need to check a couple things, if so we need to check another couple things.
If the A-RST is Not enabled try this for me:
Disable Web access and see if the resets go away or lesson.
If not then unplug the Ethernet cable and try it.
My other thought is that maybe the relays are over loading the power supply? So you could try turning the aux1 and 2 off for a day and see as well. I would try 1 thing at a time though if you can.
Ryan
Quote from: Halfcrazy on April 26, 2013, 05:41:51 PM
Ok so boB thinks you are getting a watchdog rest. So do you have Auto reset (A-RST) enabled?
If not then we need to check a couple things, if so we need to check another couple things.
If the A-RST is Not enabled try this for me:
Disable Web access and see if the resets go away or lesson.
If not then unplug the Ethernet cable and try it.
My other thought is that maybe the relays are over loading the power supply? So you could try turning the aux1 and 2 off for a day and see as well. I would try 1 thing at a time though if you can.
Ryan
Ryan;
A-RST is "OFF"
Yesterday, before I read your latest post, I swapped the relay driven from AUX1 to an SSR spare I had so the AUX1 loading should not be an issue.
Good sun today so similar conditions to yesterday when it reset later in the day with higher S.O.C. levels.
I will leave web access enabled and the ethernet connected to see if the SSR cured it.
Seems better than making multiple changes if we want to know "why". Shotgun approach is OK if you just want to fix things but I think we want to know "why"?
Thanks for the tips.
Tom
OK, just got 4 resets in as many minutes. Classic was in Bulk MPPT and about 28 volts with an 800 watt or so load.
Tells me it is NOT the AUX1 load causing it?
Next.. Disable Web Access. Turn AUX1 "OFF". AUX2 was always "OFF".
Let you know what, if anything, happens now.
Tom
Tom
Thank you for the troubleshooting on this. This will help everyone for sure.
Ryan
Ryan;
Nearing dark and Westering sun with clouds and behind the tree(s) and as near as I can tell no new resets. I was away but the KWH value looks right for the rest of the day since the earlier resets.
Just FYI.
Tom
The Classic CAN reset if too large of a load is put onto the Aux outputs BUT your Classic
has that 00000080 bit set in your "info_flags" which points to the watch dog reset.
A reset due to temporarily overloading of the power supply will not cause a watch-
dog reset (at least I don't think it will ?)
You can verify though if the aux output resets the Classic by going to the Aux menu
and manually turning the Aux output to ON from an OFF condition a few times.
boB
Hi,
@Bob,
the Eeprom dump must be done on the same day that the reset occurs, or we can access datas a lot of days after ?
@Tom,
Thinking of Web Access, does your Classic calls MyMidnite servers every 13 minutes but do?t push datas at each call like mine ( few Lines on qnode14) ?
Yann
Quote from: boB on April 27, 2013, 10:04:52 PM
The Classic CAN reset if too large of a load is put onto the Aux outputs BUT your Classic
has that 00000080 bit set in your "info_flags" which points to the watch dog reset.
A reset due to temporarily overloading of the power supply will not cause a watch-
dog reset (at least I don't think it will ?)
You can verify though if the aux output resets the Classic by going to the Aux menu
and manually turning the Aux output to ON from an OFF condition a few times.
boB
boB;
OK, I toggled the AUX1 on and off a dozen times with no resets. Battery volts were still low (24.5 V) from overnight loads and early AM testing.
As far as excess current through the Classic, with only 1500 watts nominal of solar into 24 volt nominal battery the absolute maximum power I have seen is 2KW and maybe 80 amps?
Still waiting and watching.
Any other stuff to check out?
Tom
Quote from: TomW on April 28, 2013, 11:15:29 AM
boB;
OK, I toggled the AUX1 on and off a dozen times with no resets. Battery volts were still low (24.5 V) from overnight loads and early AM testing.
As far as excess current through the Classic, with only 1500 watts nominal of solar into 24 volt nominal battery the absolute maximum power I have seen is 2KW and maybe 80 amps?
Still waiting and watching.
Any other stuff to check out?
Tom
Aux overloading is not the problem, obviously.
You may be happy to know though that I saw this same exact
reset last night here at home on a Classic I am working on.
It reset just about like yours did, like, a few times right in front
of me. I turned off Web Access and it has not done it since, which
has been overnight and then some.
<<<Any other stuff to check out? >>>
Please try turning off web access for a day and see if that stops the resetting.
I am debugging this now but it appears to take an hour or maybe two before
it will reset. At least that's what happened last night.
Also, you and I (and maybe another one ?) are about the only ones that I know of that have seen this happen.
Some people have Auto-Reset enabled which will cause this to happen if the Classic
thinks it is 23:59 or if you force a new day in the daily logs menu which will both show
up as Info_Flags showing 80 in the lower 2 digits.
boB
boB;
Web Access has been off for at least 24 hours and maybe 36 or 48. Yesterdays resets happened with Web Access disabled.
Just FYI.
Tom
Quote from: TomW on April 28, 2013, 04:24:40 PM
boB;
Web Access has been off for at least 24 hours and maybe 36 or 48. Yesterdays resets happened with Web Access disabled.
Just FYI.
Tom
Oh. darn ! I was hoping.
Still debugging
Thanks,
boB
Quote from: boB on April 28, 2013, 04:33:05 PM
Oh. darn ! I was hoping.
Still debugging
Thanks,
boB
Ha. If it was easy, anyone could do it.
Tom
Tom, have you had any resets today ?
boB
Quote from: boB on April 28, 2013, 05:06:56 PM
Tom, have you had any resets today ?
boB
boB;
None I am aware of. Been outside a lot away from the equipment but showing 8+ KWH in today so that is about what I expect.
Not sure how to tell if it reset other than seeing it do it?
Tom
So lets run another day or 2 with Web Access disabled. Maybe that's a clue.
Ryan
Quote from: Halfcrazy on April 28, 2013, 07:35:00 PM
So lets run another day or 2 with Web Access disabled. Maybe that's a clue.
Ryan
Ryan;
Ok, easy enough. As an aside I just put the turbine on this Classic for the night and it is working as expected so far so we probably can say that other one has issues with wind. See my recent email.
More as it happens.
Tom
Mine reset sometime late today.
FYI
Tom
Quote from: TomW on April 29, 2013, 07:21:27 PM
Mine reset sometime late today.
FYI
Tom
Was web access enabled or disabled ?
And are you using the local app ?
I am assuming that your clock is set and Time Synch is ON on the MNGP ?
boB
Sorry to get into this private exchange.
Mine Classic reboots yesterday, and resets the production total during the day.
I have the latest firmware installed but without VMM done.
WebAccess is enabled and LocalApp is running.
As said before, my first reset with Kwh reinit during the day was with the precedent firmware, the 28 march.
Yann
I see this random reset too sometimes more than once a day. It clears the daily kw/hr figure otherwise normal operation. Only started to see this when my classics connected to my midnite every 13 or so minutes. Disable web and no resets.
Dgd
Quote from: boB on April 30, 2013, 12:01:22 AM
Was web access enabled or disabled ?
And are you using the local app ?
I am assuming that your clock is set and Time Synch is ON on the MNGP ?
Be nice if the LA had a clock display in the corner or something
boB
Web Access Disabled.
The LA was running on the laptop.
Clock is correct. Not sure how to check the Time Synch? MNGP>>EXTRA asks for a password but I never set one. Is that where it is?
AUX1 is Manual Off.
Tom
Quote from: TomW on April 30, 2013, 10:10:04 AM
Clock is correct. Not sure how to check the Time Synch? MNGP>>EXTRA asks for a password but I never set one. Is that where it is?
Thanks Tom.
The Time Synch is a new TWEAK. It tells the MNGP to either send the time and date to the Classic control board
or not to. This is so if you have more than one MNGP and only one of their batteries are good or only one
of their time and date is set, you can have one of those MNGPs be ignored.
This tweak is also for when the Local App is able to set the time and date on the Classic, we can ignore the MNGP
altogether.
Still hot on the trail of yours and my reset.
boB
Quote from: boB on April 30, 2013, 03:01:52 PM
Still hot on the trail of yours and my reset.
boB
boB;
Just FYI,
I am under fairly heavy charge / load (2KW + in and 1.5 KW to 2KW loading) today much like when other resets have happened but so far no resets today.
I won't change the Time Synch which is "on" unless you want me to.
Ain't it fun chasing The Ghost in the Machine?
Tom
Tom, I am wondering if these resets are possibly related to the actions of certain routers and/or modems and/or ISPs.
I also think that the Classic may need to have had to have either web access enabled OR the Local App connecting
to the Classic in order for it so have this strange reset. Your Classic reset with Web Access disabled but I believe
you had your Local App talking to the Classic which would fit that description.
What kind of router are you using at home ? Do you have another router you can temporarily change it to ??
The Classic here in my office has been calling into my midnite for days now with the same firmware as ours
and has not hiccuped once. That is what makes me think that it might be some kind of interaction with
certain routers. It still shouldn't happen, but that's the theory that is going through my mind at the moment.
boB
Quote from: boB on April 30, 2013, 03:38:04 PM
The Classic here in my office has been calling into my midnite for days now with the same firmware as ours
and has not hiccuped once. That is what makes me think that it might be some kind of interaction with
certain routers. It still shouldn't happen, but that's the theory that is going through my mind at the moment.
boB
Linksys WRT54G or GL here with DDWRT Firmware: DD-WRT v24-sp2 (07/22/09) mini.
Sorry, without purchasing another router that is all I have. I have three of them one in the house one in the Power Room and a spare. The one in the Power Room is the router for the LAN. I may have a D-Link Access Point with a dead radio I could use on a wired subnet maybe. Main router still be the Linksys, tho.
Routers are cheap these days maybe I should grab one off Amazon to try? I always had good luck with Linksys so far so no idea what is good and what is China junk like that D-Link that lasted a couple months.
I read some posts saying the Linksys routers may be an issue but never heard any more.
Tom
Well, this Classic is also ~connected~ to a WRT54G or GL WiFi box BUT I don't think it is
the router in this case. I think it's just a bridge here.
boB
boB;
This Classic is connected directly to the WRT54G(L)
Tom
I to have been getting the Kwh reset every day now after upgrading to the latest firmware. It happens late afternoon or evening.
Kurt.
Quote from: offgridQLD on April 30, 2013, 05:58:35 PM
I to have been getting the Kwh reset every day now after upgrading to the latest firmware. It happens late afternoon or evening.
Kurt.
Kurt, I will ask some similar questions.
I your Web Access enabled and/or are you continuously watching it with the Local App ??
And, have you seen (or noticed) it reset twice or more in one day ?
Thanks,
boB
Web access is enabled. I have only noticed it reset once in 24hrs (thats not to say that it hasn't but i havn't noticed it more than once) I don't run the local App all the time. I just log in to the local app now and then over the day.
Kurt
OK, I think we have a work-around for this strange reset.
It appears to be related to DHCP but only with some routers.
Try changing your mode from DHCP to STATIC. This ~should~ stop
the unwanted resets.
If you have Auto-Restart enabled in TWEAKS, that should still
be OK.
On the My Midnite debug page, when you see the 8 on the right side
in the info_flags (for example, 30003280), that means that the
Classic reset due to a Watch dog timeout which can happen
either from Auto-Restart (wanted) or this bug (unwanted).
To get rid of the 8, you will have to power down and power up
the Classic but if you have auto-restart enabled, this 8 will
still show up after midnight.
boB
PS. One router that does this strange reset is a Westell DSL modem/router.
I still get this reset. For the last few days I have been monitoring my batteries as PV input has been very low 0.6. - 1.2Kw/hr for the day.
Today it brightened up and in a few hours there was 1.7KwHr 65Ah then local app said connection lost restarted and the PV Classic was reset, day so far KwHr set to zero and Ah set to zero. Wind Classic ok, second PV classic good too.
WHen the rest occured the Classic was in BULK MPPT but watts was jumping about from about 150watts to 1200 watts as clouds moved over, never went to resting. V about 25.3 throughout.
I notice that 8 is set in flags meaning watchdog reset. What is a watchdog reset and why do I need it? does it serve any useful purpose apart from being involved in these bloody annoying resets? The reset also zaps the Lite's date meaning I have to run the Lite date set program again.
I have always been static IP set and the router works flawlessly.
Am I the only one still seeing these resets? I suspect much of my reporting from this Classic is invalid as a few times I see the date reset back to 2003 which is likely evidence of a random resets.
dgd
DGD, does that resetting Classic have Web Access enabled (My Midnite) as well as being
accessed by the Local App ?
The reason I ask is that it looks like another way it can reset is to have (1) web access
enabled AND (2) one of "those" routers AND (3) accessing the Classic through the Local
App AND (4) being in STATIC IP mode.
If it were in DHCP mode, the resets would ~probably~ be worse and more often.
You're Classic is in static mode so without the Local App talking to it as well as calling
into My Midnite (Web Access), it would probably not reset is my assumption at this
point.
The Watch-Dog reset is necessary to bring the classic out of what would be
an infinite data abort loop.
We're working on this and have localized the bug but there is still work to
be done.
What kind of router is your classic connected to so we can add it to our list and
maybe get one for debugging. The firmware revision of that router may also
be useful if it is a popular router that others are not having trouble with.
Thanks,
boB
Bob:
With a modicum of software ingenuity (perhaps with a small hardware hack on your resetting 150) you should be able to *thread* the Classic 150 watchdog, to see what was on the CPU stack just prior to the reset. This approach should end the guessing game as to the cause of the random resets...
The statistics of the Classic 150 resets are quite strange! Sometimes I can go all day (bright sun or not so bright) and get no reset, then the next day, even before the sun gets above the horizon cloud layer or maybe during the sunny late morning, I may get one reset, or two within a few minutes of each other, or even get three within an hour, then none for the rest of the day. For these resons, it can take days, if not weeks to collect reliable statistics on external causal factors.
FYI: For technical reasons quite unrelated to my Classic or its firmware, I have been unable to load in an old f/w or the latest beta (via USB from an XP laptop, not my 64-bit Vista AMD quad core). Nevertheless, I will give you a fresh list of my configuration data for my 150:
BTW, my network is perhaps slightly unusual. My Classic 150 connects to my PC via a Netgear Pro Series Ethernet switch. This switch is connected to a Netgear WN2500RP Wi-Fi Extender & Bridge, which in turn connects to a Linksys WRT610n simultaneous dual-band Wireless Router on 802.11n. This router (which creates a private subnet here) connects via Ethernet to a port on some other switch in my daughter's basement (don't know the model, but could find out if you need it), which likewise, in turn connects to her router and DSL modem (again don't have the models handy).
I have not used the local app for a couple of weeks, but the resetting continues, as detailed above. Local app was a bit of a pain because it was losing the connection frequently. (Looking forward to something better...how's it coming along?).
FIrmware: 1042 MNGP, 1341 Classic.
MNGP clock is correct
My highest PV kWh ever was a week ago (on 5/2/2013): 2.9 kWh (corresponding highest power 560 W). This day had no resets!
BTW, my battery is 12 V and 420 Ah. The battery also has a Magnum MS2812 attached, together with BMK and ARC50 remote.
AUX1, AUX2 are off (not currently being used).
LED mode: LED 1
MNGP Backlight 300
Volume 504
COMM 110, 00, 502, 2 per sec data.
Time: 23:14:00 (is 35 sec fast)
Date correct
PWRSV OFF
TWEAKS:
VBatt OFFSET 0 V
VPV offset 0 V
AF OFF
GF ON
LMX ON
A-RST ON
Insomnia OFF
NITELOG ON
SHADE ON (I no longer see the shade msgs I used to get on the original factory f/w, even though I get serious shading for a time halfway through afternoon)
TMSYNC ON
FOLLOWME OFF
BTS-NET ON
PSWD OFF
I have been using Static IP addr rather than DHCP (for the whole time since installation).
IP addr. 192.168.1.111; nm 255.255.255.0
SW 192.168.1.1
D1: 192.168.0.1
D2: 0.0.0.0
WEB ACCESS: enabled
MAC address ends in 59
My Classic 150 does usually achieve PV Float after Bulk, and MNGP green light comes on.
Good luck! :) We are expecting great things from our highly esteemed software team.
Al Roxburgh
AJ4RF
Quote from: aroxburgh on May 10, 2013, 02:35:48 AM
Bob:
With a modicum of software ingenuity (perhaps with a small hardware hack on your resetting 150) you should be able to *thread* the Classic 150 watchdog, to see what was on the CPU stack just prior to the reset. This approach should end the guessing game as to the cause of the random resets...
This is exactly how the area was localized. That was pretty easy to catch.
Now, it's just a matter of time until the cause is found. That won't be until at least next week.
But you have changed my theory somewhat as you have not talked with the Classic with
the Local App while it was also talking to My Midnite while in Static mode. But maybe something
else was talking to (or tickled ?) the Classic's IP address at just the right time to cause the
reset ?
Nothing newer than the Local App or My Midnite for the moment though. Sorry about that.
Hopefully this is the last of the reset problems for a while after it is figured out.
Most are having no issues. Wish it was easier !
I will forward this info off. Thank you for the informative and accurate input !
boB
Quote from: boB on May 10, 2013, 12:17:10 AM
DGD, does that resetting Classic have Web Access enabled (My Midnite) as well as being
accessed by the Local App ?
The reason I ask is that it looks like another way it can reset is to have (1) web access
enabled AND (2) one of "those" routers AND (3) accessing the Classic through the Local
App AND (4) being in STATIC IP mode.
yes to all above. 3 Classics -> hub -> Linksys WET54G -> Linksys WRT54G ->internet
Normally all good no resets then spate of several over a day on just the loaded PV Classic. And only when input watts is highly variable like sunny day yesterday with fast moving clouds. I can't make resets happen they appear really random
Thanks for your efforts to resolve this problem
dgd
QuoteAm I the only one still seeing these resets? I suspect much of my reporting from this Classic is invalid as a few times I see the date reset back to 2003 which is likely evidence of a random resets
No I am getting them randomly usually in the evening between 6pm and 10pm while resting. But today I noticed my classic was only showing 5kwh for the day but it must have reset late morning as its pumped out over 9kwh . So I am getting resets although less often during the day.
All my off-line data logs are also showing year 2003 although the date in the live logs is showing year 2013.
So its all a bit of a mess at the moment. I'm just kind of ignoring all the data from the classic keep tabs on battery voltage and instantaneous wattage from the local app as they are reliable.
Any accumulative data logging on the local App I don't trust at the moment. I am relying on my secondary data logger and shunts for the true accumulative data for the day until the bugs get ironed out in the classics logging.
:( At least the classic its still doing a great job at its primary function ...charging the battery's each day. ;)
It can't be a easy job getting the classic and Apps perfect as the feature list grows and grows.
Kurt
My Classic reset during the day a couple of days ago. I was checking the logs on the mymidnite beta website that shows the logged data from my phone and it had about .4 or .5kwh showing when I left work. When I got home the Classic showed 0.0 kwh so it reset somewhere late in the day. This was probably a fluke occurrence but I will be keeping an eye on it. I checked to make sure I didn't have the time set incorrectly like if it passed midnite and reset but the time was correct.
Quote from: Wxboy on May 11, 2013, 11:41:03 PM
My Classic reset during the day a couple of days ago. I was checking the logs on the mymidnite beta website that shows the logged data from my phone and it had about .4 or .5kwh showing when I left work. When I got home the Classic showed 0.0 kwh so it reset somewhere late in the day. This was probably a fluke occurrence but I will be keeping an eye on it. I checked to make sure I didn't have the time set incorrectly like if it passed midnite and reset but the time was correct.
The recent history (Hourly, Minutely) logs should be able to tell you when it reset. That will also tell you
what the kW-Hours were at the time of the reset since it logs every 5 or 10 minutes.
I like to go to the graph view and set it to look at battery voltage so I can see when it went to Float,
then I can move the cursor over to see what time it went back to bulk/absorb. A resetting classic
will always come back up in bulk/absorb mode.
PS. Not that knowing exactly when the reset happened is all that important. It still needs to be fixed
boB
It sounds like I can add myself to group seeing this issue. About 45 minutes ago was twice (in about 5 days), and I can't tell anything happened, or has happened, except that the kwh reset back to zero (midday, it was about 13:00 here) and the classic stops floating and goes back into bulk/absorb for a while (going back through that cycle). Both times so far, it happened during midday when the weather was ranging, often radically from temporarily sunny to rather overcast. I'll presumably have to leave to the more experienced (that would be almost anyone...) to figure out, however. I guess I just thought I'd "chime in".
Quote from: offgridQLD on May 11, 2013, 02:46:58 AM
:( At least the classic its still doing a great job at its primary function ...charging the battery's each day. ;)
Kurt
Yes, at least the Classic still manages to do its main job, despite the resets! ;D
Since watchdog (WD) timeouts have been confirmed by boB as the source of the resets, I'd like to ask him, if he would give us chickens out here in Classic PV land some insight into how the WD is hooked into the Classic code.
Of course, the job of a WD is to timeout and reset a digital system when the software or hardware (as the case may be) fails to "debark" or poke the WD within a timeout period (due to a hardware fault, a soft malfunction caused e.g., by ESD, or a software bug). The best WDs consist of an independent hardware timer, analog or digital (embedded in a CPU or discrete) that works regardless of what software is loaded into the CPU.
Some points that come to mind, related to my own experience in the embedded arena:
1) Simple WDs are poked once per main loop (applicable to old-style code that uses an RTI interrupt to do sampling, and scheduling). Disadvantage of this approach is that often too much is happening in the main loop to easily know which part of it failed, and the various interrupt service routines are not protected.
2) Assuming that the Classic code is based on a modern threaded OS (perhaps even a mealtime OS), the WD would normally be poked by a critical thread, but for debug we can move the WD poke from one OS thread to another. We can also "thread" the WD poke itself (a different use of the word "thread") by dynamically changing which OS thread does the poking. If we do this at a rate slower than the WD timeout, eventually (given enough time) we may get lucky and see a WD timeout-induced system reset. If we had previously used our debugger to setup a pushdown stack (consisting, e.g., of a spare piece of RAM with the beginning location defining a soft stack pointer), when we run our code, every time we poke the WD, we increment this pointer and write a small stack frame which identifies which OS thread did the writing, and a time stamp. Then, after a reset, we can use our debugger (or debug mode) to go and inspect the contents of the last stack frame written before the reset. This approach requires zero (or at least few) hardware changes.
3) It goes almost without saying that a good WD is protected by a "debark" or poke unlock-sequence that is long enough to be unlikely to occur by chance.
4) There should also be a way to run with the WD disabled, which begs the question of what happens to one of these classics that inherited this reset behavior coincident with a certain firmware update version, if the WD is disabled. (Perhaps the bug is in the WD circuit, or in the way in which the WD is now set up, compare to how it was set up, say seven months ago, when, at least for me, with a factory fresh firmware, the reset behavior did not exist).
5) A WD should ideally assert the system hardware reset line so that the system CPU always starts with the same known register state.
6) Since MidNite labs now have a Classic that has the resetting behavior, what happens when boB reverts it back to last year's firmware versions? Since identical resetting behavior has been conformed by many Classic users now, I'd rather, boB, that you reverted your hardware, than I mine (mine is now too busy charging batteries).
7) Has MidNite Solar considered making the Classic firmware open source? This could open the door to a lot of free help! ;)
One company I know of (Flex Radio) sells software-defined radio transceivers that are open source except for some firmware components that they consider to be their "secret sauce."
Their original product, the SDR-1000 first shipped with a complete open source software package written in Visual Basic 6. By releasing the SDRConsole under open source GPL licensing, many radio amateurs have been able to contribute to the radio's ongoing enhancement.
In early 2004, the VB SDR-1000 software was replaced by a completely new version re-written in C#.NET and C. This was a turning point for FlexRadio Systems, enabling the full potential of the SDR-1000 to be realized. Years later, through several generations of improved radio hardware that shares the same technical base, this software continues to be enhanced and upgraded by Flex Radio's software development team, with many new features and capabilities, in addition to ideas contributed or suggested by ustomers.
To some degree Flex was able to protect its commercial interests against the prying eyes of competitors by keeping a layer of proprietary firmware (the "secret sauce"...which boB would undoubtedly call secret sores) inside the radio hardware, independenet of the PC-based GPL software. This fiirmware is loaded completely separately from the GPL software, and is practically considered to be a part of the hardware.
A discussion of the Flex Radio's approach to open source software, which started out published under the GNU GPL License, can be found here: http://www.eham.net/ehamforum/smf/index.php?topic=69728.0;wap2
BTW, the "competitor" mentioned in the forum markets a small hobby radio receiver kit that does not begin to compare to Flex's own full-featured transceivers. In the end, as these hobby radio users begin to desire improved performance and features, I think that the competitor probably generates more Flex Radio hardware sales then fewer.
Of course the solar market is different from the hobby and amateur radio market, but I think there are still a enough similarities to warrant a useful comparison. Best wishes and good luck!
Al Roxburgh
AJ4RF
Quote from: aroxburgh on May 21, 2013, 02:33:37 AM
Yes, at least the Classic still manages to do its main job, despite the resets! ;D
Welllll, yes, overall yes but those zero down spikes take some 20 seconds each away from charging
But a small matter in the big scheme of classicdom
Quote
Some points that come to mind that related to my own experience in the embedded arena:
...
2) Assuming that the Classic code is based on a modern threaded OS (perhaps even a mealtime OS),
I asked this some time ago but boB indicates no OS in the classic, this surprised me but no further info about the classic coding was forthcoming..
Quote
6) Since you now have a Classic that has the resetting behavior, what happens when you revert it back to last year's firmware versions? Since the resetting has been conformed by many Classic users now, I'd rather you reverted your hardware, than I mine (mine is too busy charging batteries).
7) Has MidNite Solar considered making the Classic firmware open source? This could open the door to a lot of free help! ;-)
Again this open source question has been asked many times and always elicits a negative response.
I think MN really see no value in their enthusiastic user base where more than a few users could offer software expertise in debugging and generally developing the MN software.
The local app debacle is just an example, a bug ridden application program that took years to slowly (and painfully) get to where it is now and still contains some whopper bugs eg '-In,Fin,ity' in an info box when it really should be 'No Data' :-\
Dgd
As far as open source the issue is truly that we do not want to just give it to our competitors. However we would entertain working with and or paying someone someones that would be qualified to work on this. Any one interested please email me ryan@midnitesolar.com
Ryan
No open sores. But maybe something else eventually might be useful to be open ?
The WDT timeout period is 5 seconds. The feeding of the WD timer happens in a semi-threaded
manner, meaning that the code must go through at least 2 spots in different areas of the code
before that time is up.
The two main reasons for a WDT reset which is basically a start at 0 reset like a hardware
reset is if the code gets stuck in a loop somewhere. That obviously keeps the WDT from
being fed (reset to 0 seconds). Even if one of the main loops (there are a few of those)
runs, it will keep the WDT from being fed and will reset the Classic.
If you have the auto-reset enabled, this is basically what happens at 23:59 after the
daily logs and such have been saved. This will also set the WDT bit in the info flags
and will be indistinguishable from a crash WDT reset.
Now, what has been happening with the Classic running under certain routers and
DHCP IP number giver-outers is that the Classic gets a data abort and goes into
a data abort loop which, in five seconds, will reset the Classic due to WDT timeout.
The latest firmware (not out yet ?) has a few modbus registers that may be
useful to look at after one of these WDT resets due to the data abort.
DabtU32Debug02 which is register 4342, 4343 (4343, 4344 if using the usual +1 modbus spec)
I have only found this to hold 0x 0000 A4ED and I do not expect to get a different
result until another network code release. This has already narrowed it down
considerably.
So you might keep those numbers handy for the next release so if you find something
happening, you can check that and give us a report that may very well help us out
in debugging.
like I say, I have only found this problem with certain routers so far as I can tell.
Mine at home is a Westell DSL router. I know that Ross W in Australia has seen
this with his Free BSD server.
boB
boB;
I switched from a Linksys WRT54 (GL) to a Dlink router and still get the resets.
Just FYI
When I get a bit more caught up in a couple days I will try one of the other routers I have probably the Belkin.
Tom
Quote from: boB on May 21, 2013, 02:02:15 PM
The latest firmware (not out yet ?) has a few modbus registers that may be
useful to look at after one of these WDT resets due to the data abort.
DabtU32Debug02 which is register 4342, 4343 (4343, 4344 if using the usual +1 modbus spec)
I have only found this to hold 0x 0000 A4ED and I do not expect to get a different
result until another network code release. This has already narrowed it down
considerably.
With current release firmware these registers are hex 0000 0000 and after one of these WD resets are still 0000 0000 (as are all registers above 4327 which is 008e)
Dgd
Quote from: dgd on May 21, 2013, 05:14:35 PM
Quote from: boB on May 21, 2013, 02:02:15 PM
The latest firmware (not out yet ?) has a few modbus registers that may be
useful to look at after one of these WDT resets due to the data abort.
DabtU32Debug02 which is register 4342, 4343 (4343, 4344 if using the usual +1 modbus spec)
I have only found this to hold 0x 0000 A4ED and I do not expect to get a different
result until another network code release. This has already narrowed it down
considerably.
With current release firmware these registers are hex 0000 0000 and after one of these WD resets are still 0000 0000 (as are all registers above 4327 which is 008e)
Dgd
OK, so it may have to be a beta just for you guys then.
boB
Quote from: boB on May 21, 2013, 02:02:15 PM
No open sores. But maybe something else eventually might be useful to be open ?
Perhaps the whole "back end" processing could be open? I've seen some very effective and eye-catching PC-based consoles for solar PV, that make good use of the entire PC screen. A large remote console with data analysis can be a lot more effective as the "face of your product" in the market, than a built-in small LCD and keypad, even though the integrated small console is still very useful for initial setup and validation.
BTW, one of the reasons (apart from the art deco look, which I love) for why I purchased the Classic 150 was MidNite's published networking vision, leveraging Ethernet for remote monitoring and control from anywhere. So, for me, you are headed in the right direction. Now just have to improve the reliability (MTB soft F) by a factor of a million or so....I don't want more than one glitch per year!!! ;)
Quote
The WDT timeout period is 5 seconds. The feeding of the WD timer happens in a semi-threaded
manner, meaning that the code must go through at least 2 spots in different areas of the code
before that time is up.
...Now, what has been happening with the Classic running under certain routers and
DHCP IP number giver-outers is that the Classic gets a data abort and goes into
a data abort loop which, in five seconds, will reset the Classic due to WDT timeout.
...
boB
...so if you can handle the data abort error condition with some additional code, you can get out of the infinite loop and prevent the WD timeout?
Al
AJ4RF
Quote from: boB on May 21, 2013, 02:02:15 PM
...
Now, what has been happening with the Classic running under certain routers and
DHCP IP number giver-outers is that the Classic gets a data abort...which, in five seconds, will reset the Classic due to WDT timeout.
...
boB
boB:
It is great to fix problems, but work-arounds can be effective too, at least as a stop-gap measure.
Therefore, can you give us a list of the offending "certain routers", as well as a list of the proven good models, if any?
Also, does the data you've received from Classic users indicate that there is any dependency on DHCP vs static IP, or any other router or Classic settings?
This way we should be able to determine if the problem only occurs with certain routers/settings, or actually does occur with all routers.
Al
Quote from: aroxburgh on May 22, 2013, 06:20:23 PM
It is great to fix problems, but work-arounds can be effective too, at least as a stop-gap measure.
Therefore, can you give us a list of the offending "certain routers", as well as a list of the proven good models, if any?
Also, does the data you've received from Classic users indicate that there is any dependency on DHCP vs static IP, or any other router or Classic settings?
This way we should be able to determine if the problem only occurs with certain routers/settings, or actually does occur with all routers.
I started working with Bob, Ryan and Andrew on this a week back - but after an initial flurry of activity they've been off on other work for a bit.
My own observations are that in a purely DHCP the classic is constantly requesting and re-requesting an address. Where I was giving it an address from a pool, its address was bouncing around in many cases every few seconds, sometimes it'd last a few minutes.
I still have the classic set for dhcp, but I'm now always assigning it the same IP based on its MAC address, so I can "use" it but still monitor the dhcp problem. It's FREQUENT... - here's the last 20-odd minutes worth:
Thu May 23 08:21:23
Thu May 23 08:21:23
Thu May 23 08:23:56
Thu May 23 08:23:57
Thu May 23 08:26:28
Thu May 23 08:26:29
Thu May 23 08:29:01
Thu May 23 08:29:02
Thu May 23 08:31:34
Thu May 23 08:31:34
Thu May 23 08:34:07
Thu May 23 08:34:07
Thu May 23 08:36:39
Thu May 23 08:36:39
Thu May 23 08:39:12
Thu May 23 08:39:12
Thu May 23 08:41:44
Thu May 23 08:41:46
Thu May 23 08:41:46
Thu May 23 08:44:18
Thu May 23 08:44:18
Thu May 23 08:46:50
Thu May 23 08:46:51
Andrew thinks it may be the DHCPD sending odd values for option58 and/or option59. However, I'm using isc-dhcpd (arguably the "reference" dhcpd) which doesn't (in my version anyway) have any way to set or override these options for IPV4.
Once Andrew gets back on-deck, I think it's our intention to capture some packets and delve into what's being asked, offered, accepted and rejected. My lease times are certainly not a few seconds :)
I'm not (noticing) any rebooting issues with my classic, even though it's constantly doing DHCP requests, but I suppose I should go check! What's the best way to determine it??
% ./classicmodbus `cat classic.addr` 4275 4120\>8
ID Solar2
4275 = 1 (0x1)
4120 = 4
This suggests to me that it's currently in BulkMppt mode, and last "resting" state was "Anti-Click. Not enough power available (Wake Up)" (likely, since sun only came up 90 mins ago, roughly)
This strange reset occurs when Classics are configured with static IP address.
Is this debugging that's leaning towards DHCP culpability mean the dhcp processing in the classic is somehow contributing to the random reset issue? - despite the use of static ip addressing?
Dgd
Quote from: dgd on May 22, 2013, 09:54:41 PM
This strange reset occurs when Classics are configured with static IP address.
Is this debugging that's leaning towards DHCP culpability mean the dhcp processing in the classic is somehow contributing to the random reset issue? - despite the use of static ip addressing?
Dgd
My Classics both have had static IP from the start. The resets occur on my solar Classic but I cannot tell with the Wind Classic yet because it is not working just sitting there powered up waiting for a cable upgrade from the turbine.
Just FYI.
Tom.
Quote from: dgd on May 22, 2013, 09:54:41 PM
This strange reset occurs when Classics are configured with static IP address.
Is this debugging that's leaning towards DHCP culpability mean the dhcp processing in the classic is somehow contributing to the random reset issue? - despite the use of static ip addressing?
OK, I missed that the random resets were only with static IPs.
Mine is still using DHCP, but always assigned the same IP. Same effect as static, but different mechanism - and perhaps helpful distinction.
Graphing my classic "State" and "Reason for resting" seems to be a quick way to spot when (or if) it happens?
(http://ranges.albury.net.au/midnight/State.gif)
Quote from: rossw on May 23, 2013, 03:52:31 AM
Quote from: dgd on May 22, 2013, 09:54:41 PM
This strange reset occurs when Classics are configured with static IP address.
Is this debugging that's leaning towards DHCP culpability mean the dhcp processing in the classic is somehow contributing to the random reset issue? - despite the use of static ip addressing?
OK, I missed that the random resets were only with static IPs.
Tom's problem is a bit different than what I have seen and heard.
My only DHCP problems have been with DHCP enabled, not static.
How can a DHCP server or router give a Classic a new IP address in static mode ?
I don't see how that is possible ?
Now, resetting in static mode is a different story and I have heard of that.
But TomW's issue quite fit the exact same scenario as I have seen with "certain"
routers and DHCP IP address giver-outers.
boB
There appears two different issues here. Dhcp processing and its problems that may or may not be causing resets AND a random reset that probably has nothing to do with networking.
Again I noticed the random reset on my static ip classic connected to PVs. Again it occurred with fast changing input amps, after a couple of 2 amps to 18 amps at 55 to 75 volts swings it reset (probably just coincidence) No local app connection active and not talking to my midnite.
Is there any way to set a modbus register value that indicates the calling routine that starts the WD timer running? This would be useful tech feedback for MN when WD resets occur
Dgd
Quote from: dgd on May 23, 2013, 07:42:20 PM
There appears two different issues here. Dhcp processing and its problems that may or may not be causing resets AND a random reset that probably has nothing to do with networking.
Again I noticed the random reset on my static ip classic connected to PVs. Again it occurred with fast changing input amps, after a couple of 2 amps to 18 amps at 55 to 75 volts swings it reset (probably just coincidence) No local app connection active and not talking to my midnite.
Is there any way to set a modbus register value that indicates the calling routine that starts the WD timer running? This would be useful tech feedback for MN when WD resets occur
Dgd
Very interesting observation !
Yes, there is a register but I will have to release an interim version that just has those registers as we talked
about a bit earlier in this thread. I'll just have to do that this weekend.
boB
Just come back inside and notice the first time I've seen mine do a reset - anything I can check from it that will help, Bob??
Graphs that MAY show what was going on: one particularly MAY be helpful:
This one needs some explaining: the blue is the actual number of average watts AS MEASURED by a precision pyranometer located about 20 feet from the arrays.
The red line is the peak power measured in the sample time (5 minutes)
The green line is the calculated power each sample time, using the calculated position of the sun for this time and day of the year - so it's basically the "clear-sky power".
The black line is a calculated "possible power" available for a tracking array perpendicular to the suns rays, at the current measured actual solar energy. (Pyranometers are cosine corrected to measure power on a horizontal plane)
What this picture shows is that the fog finally broke up and solar energy rapidly spiked at about the time the classic appears to have rebooted.
(http://general.rossw.net/midnite/mn1.gif)
This one is the actual amps measured from each of the arrays
(http://general.rossw.net/midnite/mn2.gif)
Power from the classic, as reported by the classic.
(http://general.rossw.net/midnite/mn3.gif)
Daily amphours/10, and daily kilowatt-hours as reported by the classic.
(http://general.rossw.net/midnite/mn4.gif)
PV voltages as measured by the classic and my old standalone logging.
(http://general.rossw.net/midnite/mn5.gif)
Battery voltage as reported by the classic.
(http://general.rossw.net/midnite/mn6.gif)
PV in and Battery output current as reported by the classic.
(http://general.rossw.net/midnite/mn7.gif)
Temperatures as reported by the classic
(http://general.rossw.net/midnite/mn8.gif)
Classic current state (MSB of register 4120) and Reason for Resting (register 4275)
(http://general.rossw.net/midnite/mn9.gif)
I definitely see the classic reset its kW-hours and amp-hours and the other jumps at
around 13:00 in the afternoon. Yes, looks like the sun finally came out around 13:00
On the bottom graph, MSB of stage/stage is 4 which is StatDispBulkMppt.
Also looks like the Classic never goes to Resting except when it reset the
one time.
so, the clock is set and auto-restart is not enabled in tweaks ?
Definitely weird.
Lots of good information there, Ross !
boB
Quote from: boB on May 26, 2013, 05:08:58 AM
so, the clock is set and auto-restart is not enabled in tweaks ?
Definitely weird.
# ./classicmodbus -t `cat classic.addr`
ID Solar2
ClassicTime 19:19:13 26/05/2013
SystemTime 19:19:45 26/05/2013
Clock is definately "close enough", and I confirm auto-restart is definitely *off*
Hi Bob et al:
I have been noticing some very interesting clues to do with the Classic resets, and what I'm seeing explains a lot of the reports I'm reading on the forum.
I have been restoring my PC due to an impending hard drive failure. As a result, I have been doing a lot of software downloads, many of which (e.g., Microsoft Office with many hundreds of MB) max-out my (admittedly rather puny) 1.3 Mb/s Internet bandwidth (see attached pictures, "First" and "Second", taken at two widely-spaced moments during continued network congestion when my Classic was "resetting like crazy"...see the total bytes count, all at 1.3 Mb/s...i.e., hours of congestion on my Internet connection).
In what follows I was not using the Local App, which I have not yet re-installed on my (restored) PC.
This morning while doing the downloads, I started noticing resets occurring just at short intervals, often only a minute or two between. By the time a realized what was happening, the downloads were mostly done, so starting my stopwatch I only got three successive lap times (approximate time between resets), as follows (mm:ss):
00:00 <---stopwatch started just after a reset
10:13 <--- 20 packets and then a reset
02:24 <---3 or 4 packets and then a reset
01.19 <---2 packets and then a reset
When the "saturation" of my Internet connection relaxed to more usual levels, the resets stopped happening.
Later-on, maxing out the connection caused resets to resume.
So I got to thinking: I think know what's going on...the Classic is dropping packets in its connection to Ryan's mymidnite data collection project...I'll bet they aren't using a handshake to protect the data!
So, I made Wireshark my next re-install, and low and behold, on 192.168.1.111 (the fixed IP address on my Classic on
my local network), I could see UDP packets.
Now, as is well known, TCP uses a handshake to protect the data transfer (an automatic retransmission takes place in the DataLink and Network layers whenever there is a checksum error) which is why it works so well for http. UDP, however, does not. UDP can still be protected by an application layer error check, but typically that is not done, since there is no timely retransmission capability provided in the lower network layers. Therefore, TCP is the protocol of choice for highly reliable, mission critical, data transfer. UDP often sees use for audio and video streaming, because of lower data integrity requirements, since it is relatively easy to mask (not the same as correction) data errors.
I'll bet also, that the Classic's Ethernet interface and your s/w diver are not faring well when the wire is near saturated, perhaps the Ethernet interface gives bogus status under conditions of heavy network congestion. If the Classic software continues to shove out UDP packets regardless of congestion, then there may be a lot of data loss in the logging software that Ryan is using, which will also have its consequences (although that is unlikely to have any influence on the Classic resetting behavior).
From what I've read on the forum, it sounds entirely possible that the Ethernet interface status you are reading in the Classic network driver could be different depending on local network equipment (as I've said previously, my Classic Ethernet data passes through Netgear Pro switch ---> Ethernet port on Netgear Universal Dual Band WiFi Range Extender (WN2500RP) ---> 108 Mb/s 802.11n connection to Linksys WRT610n router --> Ethernet connection to a D-Link
router ---> Ethernet connection to a ZyXEL 1.3 Mb/s DSL interface service...as you can see, there is a fair collection of diverse gear between my Classic and the Internet, with the bottleneck being the DSL connection.
Please seriously consider changing from UDP to TCP in the future, although you'll then have to create a mechanism for dealing with possible out-of-order packets. There would seem to be plenty of time for TCP retransmission caused by adverse network conditions, since after-all, your packets from the Classic are 30 seconds apart...
Here's one of my Classic's 60 byte packets sent to MidNite, of which Wireshark informs me, 6 bytes or 48 bits are actual payload:
0000 ff ff ff ff ff ff 60 1d 0f 00 1b 59 08 00 45 00 ......`. ...Y..E.
0010 00 22 02 31 00 00 40 11 b6 83 c0 a8 01 6f ff ff .".1..@. .....o..
0020 ff ff 06 9a 12 12 00 0e 6c f5 c0 a8 01 6f f6 01 ........ l....o..
0030 00 00 00 00 00 00 00 00 00 00 00 00
Broken down, approximately as follows, by Wireshark:
ff ff ff ff ff ff Destination Address = Broadcast
60 1d 0f 00 1b 59 Source Address = MidNite Solar Classic
08 00 Packet type contained in Ethernet frame = IP
45 Header length (20 bytes)
00 Explicit congestion notification: Not-ECT (Not ECN-Capable Transport) <<<<<<<???
00 22 Total length 34
02 31 ID
00 00 Fragment offset = 0
40 Time to live = 64
11 Protocol = UDP
b6 83 Header checksum (correct)
c0 a8 01 6f Source: 192.168.1.111
ff ff ff ff Destination address
06 9a Source port 1687 (also see 06 97)
12 12 Destination port 4626
00 0e Length 14
6c f5 Bad checksum <<<<<<<<<<<<<<<<<<<<<<<<<<<<<???
c0 a8 01 6f Source address: 192.168.1.111
c0 a8 01 6f f6 01 Data payload (6 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 Padding
I'm not sure about the significance of the two items marked with <<<<<<<<<<<<<<, although the effect of that would be moot if the packet doesn't actually get sent out due to congestion, and gets overwritten in the Classic transmit buffer...a situation possibly exacerbated by faulty network hardware or drivers in the Classic. Clearly there should be some sort of congestion monitoring and control, irrespective of whether the protocol is UDP or TCP.
From what I've seen in my own Classic, and from reading other' posts, the random resets have nothing to do with the amount of sunlight, whether the IP address is static or using DHCP. It seems that they have everything to do with network congestion (even though I don't fully understand the local ~100 Mbps fast network flow control) caused by
the 1.3 Mbps limitation of the DHL modem).
-Al Roxburgh
aj4rf
Al, ain't Wireshark great ??!!!!!!?
The UDP packets you are seeing are Classic advertising packets.
Those are what is used to let the local app (and router ?) know where the
Classic is so it can find it.
The advertise broadcast should happen around every 10 seconds on port 0x1212
"ff ff ff ff ff ff Destination Address = Broadcast"
and
"12 12 Destination port 4626"
Not sure why the bad checksum though.
Everything else is TCP/IP I'm pretty sure.
I know that UDP is used for streaming etc. where you don't care so much.
The Local App only reads the Classic once every 2 seconds these days
and when calling into My Midnite it is even less often.
I wonder though if there might be something to UDP and TCP/IP packets
lining up and "walking" on top of each other ? Pretty far fetched but ?
I tend to agree that power and sunlight do not have much, if anything,
to do with the resets although I can't rule anything out yet.
Please keep up the good detective work though ! It can only help.
boB
Bob:
Interesting! The fact that I'm seeing the broadcast UDP packets but not seeing the TCP packets proves that WS is not putting the Netgear switch shared by my PC and the Classic into "hub" mode...I no longer have the old 100 Mb/s Ethernet hub that I formerly used for such purposes. Next time I'm in the "Freecycle" store I'll see if I can pick one up, hopefully at a bargain price. Last time I was doing this kind of packet sniffing seriously, years ago, was in the Wi-Fi space, where the actual space (pun intended) necessarily acts like a hub, since there can only be one packet "in the air" so to speak, at a time (Linksys USB Wi-Fi dongle and Backtrack Linux...great package that comes with WS and lots of other network tools).
Back to my posted observations...TCP packets...hmmm...that explains why I was seeing so little packet-to-packet change in the 6-byte payload of the UDP packets. Clearly, with a hub I would have seen a lot more...
Anyhow, it does look like a case of extreme congestion in the DSL connection is having a weird effect on the TCP packets (that I cannot see in my current setup). Nevertheless, next time I notice a reset, I'll make sure I notice what is happening on the Network Meter gadget's traffic history graph...
Of course, irrespective of congestion on the network, the main problem is the way that the Classic responds to it (and to any other relevant events) that is the basic problem. Check everything including any hardware errata that the chip manufacturer may have published. Talk to them too, if possible, and to the chip designers, in particular. Also have your Ethernet drivers reviewed by the same people....
Thank you for the further input on the resetting problem. From my side, as an end-user, I'll continue to investigate. (I'll also promise to keep my naive optimism better under control! ;) )
Al
aj4rf
Al, I also noticed that when using wireshark but with the Local App, I could NOT see the outgoing packets TO the Classic but only the return packets FROM the Classic. I'm not sure why that is ? i.e. most all of the destination packets were for my laptop. I even tried changing over to wired Ethernet. No change.
WS does know the return packets are modbus and disassembles those packets correctly.
I bet that the same thing happens with My Midnite packets. Let us know if you figure out how to make wireshark see the outgoing packets.
I have looked online for an answer but not intensely.
Thanks for the CSI work !
boB
Quote from: boB on June 02, 2013, 02:38:41 PM
Let us know if you figure out how to make wireshark see the outgoing packets.
I have looked online for an answer but not intensely.
boB:
I looked on amazon.com and found that there is still at least one hub on the market!!!
Netgear EN104TP 4-Port 10 Mbps Ethernet Hub RJ-45 with Uplink Button
Price: $108.00
If you hook up your PC running wireshark, your Classic, and a wire to your Internet router/switch, you should be able to see all packets coming and going from the Classic. This approach keeps things simple, without any of that "promiscuous mode" hokey-pokey required if a managed switch is used instead of a hub. Should not matter that it does not support 100 Mbps.
This item is too spendy for me at present, so I'd encourage you to get one and try it. I'll continue to look for a hub from "Freecycle" or similar.
It is definitely a hub, and indeed costs several the price of a similar-looking Netgear 4-port switch (high price = low sales volume). Although people sometimes confuse "hub" with "switch", even more so nowadays since switches now dominate, whether we need the additional performance offered by a switch, or not. Some of the amazon reviewers confirm it is an actual hub:
"I needed another Ethernet Hub for a software development project I'm working on. Hubs are difficult to find these days as low cost network switches are a dime a dozen, and provide isolation between network ports. But for network hardware development you do not want this isolation when you are trying to monitor network traffic between devices. That is where an Ethernet Hub comes in. Yes you can use "managed" network switches but those are more expensive than the garden variety network switch. This Hub was available at a fair price, and works fine. If I need another one I would purchase again."and
"When you need a hub and not a switch, this is what you need. It is perfect for running Wireshark. At this price I should have bought an extra one. The one I received works great and looks brand new with no scratches or scuffs."
-Al
aj4rf
For what it is worth:
I have not noticed any resets since I quit watching the Classics with the Local App for long periods of time.
I monitor it with a local log and via an online graph page using a little binary RossW cooked up that uses the ethernet and reads Modbus registers. Thanks Ross!
Just FYI and not certain it helps sort out what is going on with resets.
Tom
boB:
I have been copying files back from a local server all day today, and no resets with local traffic approaching 100 Mbit/s (see attached screen dump).
The difference is that I have not been causing congestion on the DSL connection (described a couple of postings ago).
It would seem that a sure way to cause the resets is to saturate the Internet connection, even though the local network traffic is many times higher than the 1.3 Mb/s DSL limitation.
As before, I am no longer using the Local App (for several weeks now), so my most recent resetting behavior seems to somehow involve the My MidNite traffic traversing the Interest from my Classic to MidNite Solar.
Note that I did not get any of the random resetting behavior with my Classic 150 unit new-out-of-the-box last November, but not quite factory-fresh. ;) Due to its manufacture date, its firmware had to be updated before it could even talk to other devices over Ethernet. It was only after Ethernet was added that the resetting problem started happening, and it got worse when the Local App was running. Only belatedly did I notice that resets happen most often when my 1.3 Mb/s DSL connection is congested for seconds or minutes at a time. I have not yet proven that all of the resets correlate with Internet congestion.
Therefore, it would seem to be very clear that the cause of the random resets is the Classic's Ethernet hardware and/or software drivers, and/or the something about the way that the application layer is talking to the Ethernet driver. It would be great if others can glance over at their Network Meter widget (as well as the Classic display) whenever they hear the Classic resetting...and report their findings here.
Good luck with setting up an Ethernet hub to monitor all of the packet traffic in and out of your Classic.
Al
aj4rf
Coincidence or not, my Classics have not been sending data to mymidnite during the time of not seeing resets, either?
Just what I am (not) seeing here.
Tom
Quote from: TomW on June 03, 2013, 08:39:46 PM
Coincidence or not, my Classics have not been sending data to mymidnite during the time of not seeing resets, either?
As reported to Bob in IRC yesterday - mine reset shortly before midday local time.
Mine is not set to send data to mymidnite at all. This is (I think) the 2nd time I've caught mine reset in as many weeks.
Quote from: rossw on June 03, 2013, 09:58:50 PM
As reported to Bob in IRC yesterday - mine reset shortly before midday local time.
Mine is not set to send data to mymidnite at all. This is (I think) the 2nd time I've caught mine reset in as many weeks.
Ross:
My apologies for asking such an obvious question, but is is your clock off by 12 hours? (Not so likely since it is a 24-hour setting)
Also, did the 1st reset that you mention occurred in the past two week happen at a similar time, i.e. just before the end of 12 hours or 24 hours?
Moreover, was solar generation rate near maximum during these resets? (Others have suggested this, although none of my resets have correlated with solar output.)
Finally, is your Classic actually connected to your LAN?
If so, perhaps your device
is actually active on your LAN, in which case problems in the Ethernet interface/driver/Classic firmware could interact with other network traffic on your LAN.
What are your Classic's network settings?
Thanks for your input! ;D
Al
aj4rf
Ross:
IRC? I'm not familiar with that in a MidNite Solar context. Please fill me in.
Thanks!
Al
Quote from: aroxburgh on June 04, 2013, 01:59:25 PM
Quote from: rossw on June 03, 2013, 09:58:50 PM
As reported to Bob in IRC yesterday - mine reset shortly before midday local time.
Mine is not set to send data to mymidnite at all. This is (I think) the 2nd time I've caught mine reset in as many weeks.
Ross:
My apologies for asking such an obvious question, but is is your clock off by 12 hours? (Not so likely since it is a 24-hour setting)
Nope, clock is close.
./classicmodbus -t `cat classic.addr`
ID Solar2
ClassicTime 06:34:47 05/06/2013
SystemTime 06:35:24 05/06/2013
Quote
Also, did the 1st reset that you mention occurred in the past two week happen at a similar time, i.e. just before the end of 12 hours or 24 hours?
"near" yes - about 90 minutes from a 12-hour boundary I think.
Quote
Moreover, was solar generation rate near maximum during these resets? (Others have suggested this, although none of my resets have correlated with solar output.)
One was near a rapid transition from low to near-full output as the last of the fog broke up.
Quote
Finally, is your Classic actually connected to your LAN?
If so, perhaps your device is actually active on your LAN, in which case problems in the Ethernet interface/driver/Classic firmware could interact with other network traffic on your LAN.
What are your Classic's network settings?
Thanks for your input! ;D
Well, yes, it is connected to the LAN, as it has always been - and I haven't said otherwise. What I did say is that it is not configured to send data to mymidnite.
The classic, and three small PLCs are in my "battery room", where I achieve isolation by using a WRT54GL wireless router (reflashed to run DD-WRT) in bridged mode. None of the other devices connected to its ethernet are experiencing any problems, nor have they in the couple of years they have been running.
Quote from: aroxburgh on June 04, 2013, 02:02:18 PM
Ross:
IRC? I'm not familiar with that in a MidNite Solar context. Please fill me in.
Internet Relay Chat. Bob and Ryan are frequently in attendance.
(As are several other midnite forum members!)
You can rock up and say g'day - irc.rossw.net in channel #otherpower
Quote from: rossw on June 04, 2013, 04:41:20 PM
Well, yes, it is connected to the LAN, as it has always been - and I haven't said otherwise. What I did say is that it is not configured to send data to mymidnite.
Ross, thank you for your reply. However, since your Classic is connected to your LAN, it
will be interacting with it, sending and receiving packets...DHCP, ARP, broadcast UDP packets, etc. Therefore, the question of what are the network settings of a Classic that does the random reset thing is quite relevant. When you get time to look, please post your Classic network settings; I would find it useful to compare my settings (which we included in an earlier post) with yours.
The relevance of discussing your Classic's Ethernet interface is that much of the evidence suggests that things happening on the LAN connected to the Classic cause a condition, either in the Ethernet hardware, the Ethernet driver, or the Classic firmware code, that leads to watchdog timeout. The resets happen irrespective of whether the Local App is in use (in my case that's not even still installed). I don't know yet if turning off communication to Ryan's mymidnite data collection effort makes any difference to the frequency of resets. Actually, perhaps Ryan could answer that one already, since he will probably be aware if there are any Classic users experiencing the resets, who are not sending data to mymidnite.
Thanks!
Al
aj4rf
Quote from: aroxburgh on June 04, 2013, 07:39:03 PM
Thank you for your replay. However, since your Classic is connected to your LAN, it will be interacting with it, sending and receiving packets...DHCP, ARP, broadcast UDP packets, etc. Therefore, the question of what are the network settings of a Classic that does the random reset thing is quite relevant. When you get time to look, please post your Classic network settings; I would find it useful to compare my settings (which we included in an earlier post) with yours.
OK. Pretty sure I have stp enabled, and as the wireless link is bridged to the internal 5-port *SWITCH*, there should be minimal "other" traffic hitting it. Sure, broadcasts will, ARP requests (but not replies except to the classic itself) will, but there will be not much other unsolicited traffic hitting it.
We already know it's "chattering" DHCP far more than it should. There's something funny going on there, and I suppose it's possible that will have some effect. I have the classic set to obtain an address via DHCP, but my DHCP server always gives it the same IP. It's on a live IP, I don't run NAT, so I'd prefer not to print the addresses in a public forum ;)
Primary and secondary DNS are being assigned by the DHCPD, and point to a caching, recursive nameserver on the local network. Gateway is my local filtering box which in turn forwards packets in and out via the actual router.
Which other network details (specifically) do you want?
Ross: That amount of detail is perfect for now. After I get my hands on an old "free-pile" Ethernet hub, I'll be back on track with wrieshark. However, I'm also hoping that boB will get himself a hub and do some more exhaustive packet sniffing as well.
The mystery in my setup is why I can make the reset by causing congestion on my (relatively slow, compared to my LAN) DSL modem. As described earlier, my current favorite source of congestion (not by choice, due to a computer recovery) is Microsoft's software update service, which can put out very steady packet streams at a high rate.
The commonality between your system (which does not talk to mymidnite) and mine (which does) is the Classic's Ethernet hardware, Ethernet driver, and the Classic's firmware. Somewhere in there there has to be a serious "boog". ;)
Ideally, I'd like to see the Ethernet hardware put through a standards compliance process, and run an exhaustive battery of timing, noise, and congestion stress tests using a data pattern generator and eye test scope.
Al
aj4rf
Quote from: aroxburgh on June 04, 2013, 08:40:01 PM
Ross: That amount of detail is perfect for now. After I get my hands on an old "free-pile" Ethernet hub, I'll be back on track with wrieshark. However, I'm also hoping that boB will get himself a hub and do some more exhaustive packet sniffing as well.
Sniffing on my gateway box for the IP and/or MAC address of the midnight means I can pretty much see what's going on without needing a hub. (Just for reference - as hubs become harder to find, many managed switches have TAP or port mirroring functionality which allows you to achieve the same thing)
Quote
The mystery in my setup is why I can make the reset by causing congestion on my (relatively slow, compared to my LAN) DSL modem.
With zero insight to the software, my musing is unfounded. However, it's possible that there's *something* in the midnight that periodically goes off to do "stuff". Eg, NTP sync or DNS lookups for NTP.
If your outside link is congested, it could be that a blocking request could cause the WD to time out.
With my config (FreeBSD box with ipfw and dummynet) allows me to introduce delays, artificial bandwidth restrictions, "packet loss" etc to test such theories as may evolve.
Quote from: aroxburgh on June 04, 2013, 07:39:03 PM
Quote from: rossw on June 04, 2013, 04:41:20 PM
Well, yes, it is connected to the LAN, as it has always been - and I haven't said otherwise. What I did say is that it is not configured to send data to mymidnite.
.. much of the evidence suggests that things happening on the LAN connected to the Classic cause a condition, either in the Ethernet hardware, the Ethernet driver, or the Classic firmware code
Al,
I have a Classic not network connected but serial port connected to a rPi that collects data every few minutes via modbus.
The firmware is the latest. This Classic has reset twice in 10 days and once I was watching as the output wattage rose quickly
from about 120watts to 1400watts as a raincloud moved away and the cloud edge brightness rapidly increased.
So I have no doubts there may be network issues causing watchdog resets but there may be other reasons too.
I am waiting on boB's minor firmware release that sets modbus registers identifying who caused the reset. I suspect when he
starts to get this feedback the debugging process will accelerate.. :P
dgd
Ross:
Nice monitoring setup. I have used managed switches, but never for packet sniffing, preferring to just grab a hub off the shelf to do that. Last time I checked, suitable managed switches were still far more expensive than the EN104TP hub product that is still available from Netgear for about $110. Many of the old hubs sitting around are faster than the Netgear, which is limited to 10 Mbps.
dgd:
Yes, there is enough evidence to suggest multiple causes for the reset. Still, it may turn out that there is a single underlying cause. I'll be watching developments with great interest once boB gets the USB/serial debug enhanced. With new and improved tools in place, hopefully all of this discussion will soon become a distant memory.... I have other projects on hold, such as diverting excess power from my Classic 150 to heat my hot water...speaking of which, I wonder if anyone on the forum has experience with installing an aftermarket 12 V heater in a Suburban 120 VAC/propane 6 gallon water heater. Would I be better to just replace it with one of the triple-power-source variety?
Al
aj4rf
Quote from: aroxburgh on June 05, 2013, 02:23:35 AM
.. I have other projects on hold, such as diverting excess power from my Classic 150 to heat my hot water...
I would suggest moving on with these other projects as they, the hot water one anyway, should not be effected by these random resets. I suppose the good news is that the Classic just keeps working despite these resets so its really only reporting that gets messed up and in the big RE scheme that's only a sideshow.
Dgd
boB:
Some thoughts on the Classic firmware...
We all would not be so concerned about the random resets if their impact were less (although of course the cause or causes needs to be found, and fixed, to reduce the possibility, down the road, of further unintended side-effects).
Right now it would appear that the Classic has no clearly defined cold start and warm start states.
A cold start is defined as power-on reset after having sat powered down long enough for all RAM locations to decay below logic thresholds; all variables are initialized to default values or values based on flash/EEPROM storage.
In a warm start, the Classic would use a special mechanism to determine (with a high measure of probability) that a reset has occurred, but was not caused by a power-up from cold. A warm-start state would allow key variables to be restored to or remain at the value they had prior to the reset. In particular I am thinking of kWh and Ah. I expect that there are others too. This would typically be achieved by having the reset handler code write a special key (unlikely bit pattern) to one or more RAM locations, but not before the handler looks in those locations to see if the key values have already been written. If they have been, then we set the warm-start flag. We then initialize all relevant variables using conditional initialization (the condition is: NOT warm_start). Those variables that are normally initialized by writing them from literal values stored in the firmware code (as opposed to restoring the values from flash/EEPROM) are left "as is," perhaps with a test to ensure that they are still in-range. Some variables, e.g., the clock time, are already preserved across reset, but that may be merely due to reading the time from a battery-backed-up time chip.
In summary, I'd like to see you define a warm-start state, so that in the event of the kind of resets we are seeing at the moment, the parameters that are most important, namely kWh and Ah can be relied on, as we monitor the energy performance of our renewable energy systems. Of course, probably like many other users, I too would like to see remote monitoring (including password-protected system configuration) using a web browser, voice alerts for conditions such as low battery, and improved presentation of the performance results, but am willing to wait for these, if there could be some small additions to the code to make it more practically useful and reliable where it counts.
It is good, as several have pointed out, that Classic energy generation continues largely unabated during the random resets, but at the end of the day it is vital to know how many kWh were generated. A big part of energy management and planning is knowing how big your energy resource is! Otherwise it's little better than touch wood and hope for the best. :(
Al
aj4rf
Quote from: aroxburgh on June 06, 2013, 01:07:24 PM
boB:
Some thoughts on the Classic firmware...
We all would not be so concerned about the random resets if their impact were less (although of course the cause or causes needs to be found, and fixed, to reduce the possibility, down the road, of further unintended side-effects).
Right now it would appear that the Classic has no clearly defined cold start and warm start states.
A cold start is defined as power-on reset after having sat powered down long enough for all RAM locations to decay below logic thresholds; all variables are initialized to default values or values based on flash/EEPROM storage.
In a warm start, the Classic would use a special mechanism to determine (with a high measure of probability) that a reset has occurred, but was not caused by a power-up from cold. A warm-start state would allow key variables to be restored to or remain at the value they had prior to the reset. In particular I am thinking of kWh and Ah. I expect that there are others too. This would typically be achieved by having the reset handler code write a special key (unlikely bit pattern) to one or more RAM locations, but not before the handler looks in those locations to see if the key values have already been written. If they have been, then we set the warm-start flag. We then initialize all relevant variables using conditional initialization (the condition is: NOT warm_start). Those variables that are normally initialized by writing them from literal values stored in the firmware code (as opposed to restoring the values from flash/EEPROM) are left "as is," perhaps with a test to ensure that they are still in-range. Some variables, e.g., the clock time, are already preserved across reset, but that may be merely due to reading the time from a battery-backed-up time chip.
In summary, I'd like to see you define a warm-start state, so that in the event of the kind of resets we are seeing at the moment, the parameters that are most important, namely kWh and Ah can be relied on, as we monitor the energy performance of our renewable energy systems. Of course, probably like many other users, I too would like to see remote monitoring (including password-protected system configuration) using a web browser, voice alerts for conditions such as low battery, and improved presentation of the performance results, but am willing to wait for these, if there could be some small additions to the code to make it more practically useful and reliable where it counts.
It is good, as several have pointed out, that Classic energy generation continues largely unabated during the random resets, but at the end of the day it is vital to know how many kWh were generated. A big part of energy management and planning is knowing how big your energy resource is! Otherwise it's little better than touch wood and hope for the best. :(
Al
aj4rf
I like the idea of a "warm start" as you say and that COULD be done of course. The only issue that I
have with that is, what if the variables are corrupted ? Then, you would warm boot with corrupted
states and numbers. At this point, we would, as you say, have a high confidence that they
would be in good shape.
I'd rather just get the resets fixed so we don't have to worry about that. I suppose that warm
boot mode could be selectable so if it is only network problems causing resets as it looks like
right now, then this could be usable. Normally this would be disabled of course.
If we don't figure this weird situation out soon, I may just do something like you are proposing.
BTW, did you guys get the newest and latest code for the My Midnite calling in fix ??
http://fusion.midnitesolar.com/MidNiteSolarSetup_6-6-2013_v3.72.exe
boB
Hi All,
Just want to put my two bits in..
I have a midnite 200 that is currently regulating my (new) 500w 48v turbine for a 24v 1600Ah battery bank in my rops setup.
The mfg says the turbine should be kept in a voltage range between 48 and 150.
Yesterday, we (finally) got good wind (40-50 kph, ~25 to 30mph) to make up for lack of sun and, in the process of checking how the turbine was performing, I noticed that the controller reset - several times. In the time the controller takes to get back up and regulating, the voltage got up to, at one point, 184v. I know this because I have a hand built, arduino based logger that logs stats on my whole setup.
Now, I appreciate those with midnites regulating their pvs saying the resetting is not that big a deal because the controller is still 'making power', but please spare a thought or two for those of us with turbines that MUST be loaded.. I hate to be demanding but we need to have a solution (or workaround) found now.
I am sure you guys can appreciate that my better half is not best pleased that I am turning our only source of generation off because I cannot trust the controller (that *I* told her was the greatest thing since sliced bread)
Some details:
The controller is a 200v rev 4, about two months old (It replaced another that failed)
It is on a network with a static ip.
It *seems* to reset when there is a wild swing in current being delivered to the batts.
I don't run the local app all day.
It *can* have web access but I am on a limited data plan so I cannot be sending and receiving lots of data (should someone need to remote troubleshoot).
Thanks for reading and please advise
Quote from: dogfox on June 06, 2013, 06:26:34 PM
Hi All,
Just want to put my two bits in..
I have a midnite 200 that is currently regulating my (new) 500w 48v turbine for a 24v 1600Ah battery bank in my rops setup.
The mfg says the turbine should be kept in a voltage range between 48 and 150.
Yesterday, we (finally) got good wind (40-50 kph, ~25 to 30mph) to make up for lack of sun and, in the process of checking how the turbine was performing, I noticed that the controller reset - several times. In the time the controller takes to get back up and regulating, the voltage got up to, at one point, 184v. I know this because I have a hand built, arduino based logger that logs stats on my whole setup.
Now, I appreciate those with midnites regulating their pvs saying the resetting is not that big a deal because the controller is still 'making power', but please spare a thought or two for those of us with turbines that MUST be loaded.. I hate to be demanding but we need to have a solution (or workaround) found now.
I am sure you guys can appreciate that my better half is not best pleased that I am turning our only source of generation off because I cannot trust the controller (that *I* told her was the greatest thing since sliced bread)
Some details:
The controller is a 200v rev 4, about two months old (It replaced another that failed)
It is on a network with a static ip.
It *seems* to reset when there is a wild swing in current being delivered to the batts.
I don't run the local app all day.
It *can* have web access but I am on a limited data plan so I cannot be sending and receiving lots of data (should someone need to remote troubleshoot).
Thanks for reading and please advise
dogfox, do you have a clipper installed on your turbine ?
You did not mention if you had a dump load or not.
How did the first controller fail ? Was it overvoltaged ?
A Clipper is necessary to keep the turbine loaded even if the Classic
is on and running because when the batteries get full or exceeds
the capacity of the power of the turbine, the turbine will be unloaded
and the turbine will rise very high. 184V will not hurt the Classic but
the Classic by itself will not load the turbine down with a battery
connected in high winds.
A clipper will also load the turbine at a fail-safe voltage even if the
Classic is off, reset or disconnected.
Thanks !
boB
dogfox, Another question...
What kind of power or current did you see during the current swings when you saw it reset ?
Thanks,
boB
BTW folks....
The newest firmware...
http://fusion.midnitesolar.com/MidNiteSolarSetup_6-6-2013_v3.72.exe
has the data abort information registers in them.
If your Classic has done a reset, check these registers if you have modbus reading capability.
Otherwise, PM or email me.
Registers 4340 through 4343 (addresses 4339 through 4342)
Those registers should contain the information we need to help track this problem
down due to the watch-dog resets.
Thanks,
boB
Quotedogfox, do you have a clipper installed on your turbine ?
No, I don't.
QuoteYou did not mention if you had a dump load or not.
Yes, I have a dump load capable of dissipating 2000w.
QuoteHow did the first controller fail ? Was it overvoltaged ?
Not that I am aware. Unfortunately, I cannot say for sure. I had lowered the old turbine (24v 500w) at the start of the summer as I don't need the added wind power then. At the end of the summer I raised the old turbine and, at the next moderate wind event, I noticed that the controller was putting out NO current.. Everything else was fine (was accepting firmwares, display looked correct, voltage was accurate, etc). I was most upset when the realization dawned that the controller died and I had no idea when, nor why.
Quote
A Clipper is necessary to keep the turbine loaded even if the Classic
is on and running because when the batteries get full or exceeds
the capacity of the power of the turbine, the turbine will be unloaded
and the turbine will rise very high.
I have been eyeing the clipper but, once my arduino logger is fully operational, it will be doing fail safe braking with pwm.
Quote
184V will not hurt the Classic but
the Classic by itself will not load the turbine down with a battery
connected in high winds.
With all due respect, I think you missed my point. The turbine should not rise past 150v, and it did. I did because the controller was resetting. When the controller *was* operating properly, the turbine was being held at approx 18 amps on the curve I'm currently playing with (which relates to approx 100v). I saw gusts push the amps up to 30 but that was still only 105v and a bit. My curve's last two points are 30A 105v and 48A 106v.
Quote
A clipper will also load the turbine at a fail-safe voltage even if the
Classic is off, reset or disconnected.
I do understand the purpose of the clipper, I'm just disappointed that I'll need to purchase another midnite product as a backup to my existing midnite product.
Quote from: dogfox on June 06, 2013, 07:41:56 PM
Quotedogfox, do you have a clipper installed on your turbine ?
No, I don't.
QuoteYou did not mention if you had a dump load or not.
Yes, I have a dump load capable of dissipating 2000w.
QuoteHow did the first controller fail ? Was it overvoltaged ?
Not that I am aware. Unfortunately, I cannot say for sure. I had lowered the old turbine (24v 500w) at the start of the summer as I don't need the added wind power then. At the end of the summer I raised the old turbine and, at the next moderate wind event, I noticed that the controller was putting out NO current.. Everything else was fine (was accepting firmwares, display looked correct, voltage was accurate, etc). I was most upset when the realization dawned that the controller died and I had no idea when, nor why.
Quote
A Clipper is necessary to keep the turbine loaded even if the Classic
is on and running because when the batteries get full or exceeds
the capacity of the power of the turbine, the turbine will be unloaded
and the turbine will rise very high.
I have been eyeing the clipper but, once my arduino logger is fully operational, it will be doing fail safe braking with pwm.
Quote
184V will not hurt the Classic but
the Classic by itself will not load the turbine down with a battery
connected in high winds.
With all due respect, I think you missed my point. The turbine should not rise past 150v, and it did. I did because the controller was resetting. When the controller *was* operating properly, the turbine was being held at approx 18 amps on the curve I'm currently playing with (which relates to approx 100v). I saw gusts push the amps up to 30 but that was still only 105v and a bit. My curve's last two points are 30A 105v and 48A 106v.
Quote
A clipper will also load the turbine at a fail-safe voltage even if the
Classic is off, reset or disconnected.
I do understand the purpose of the clipper, I'm just disappointed that I'll need to purchase another midnite product as a backup to my existing midnite product.
Is your 2 kW dump load on the battery side of the controller ? If so, there is no way that the controller can keep the
turbine below 150 volts if there is enough wind to put the controller into current limit, which can happen. When that
happens, the controller will raise its input (turbine) voltage to keep its output current at current limit or, if the
battery side dump load cannot keep the battery voltage down, the CC will raise the input (turbine) voltage
to keep the battery voltage at the Absorb or Float set-point.
Now, if there is always someone there to bring down the turbine during an upcoming storm, then you
won't have that problem but that's not very automatic.
Once the wind gets high enough to push the output above the highest power curve point ( 48A 106v ?),
it can still go higher in voltage and output current.
Still, the resets are not wanted and in normal wind conditions, it will unload the turbine while it re-boots.
What is your PWM braking technique you are working on with the Arduino ? Will it PWM the turbine
on the turbine side ? If so, will it do it on the AC side of the turbine rectifier ? That is the best way
as then you don't need to add a diode between the rectifier DC output and the controller input
terminals. That diode is to keep the input terminals on the controller from driving the dump
load on the input from power coming through the controller from the battery.
I am wondering why your Classic tended to reset when you saw high current swings ??
Were the multiple resets at ~approximately~ a minute between each other ??
Was there higher power each time that you could tell or did the high current
surge maybe just appear to start the string of resets ?
The time that I saw the reset happen in front of me with my home router, there was
very little or no power running through the Classic but once it started resetting,
it was kind of like sneezing... It happened multiple times in a row at around
1 minute intervals.
boB
dogfox,
I have watched my Classic 250 reset when the turbine was making power in a blustery rainstorm. No Clipper but I did have a 3phase dump load in use. This load was online when the reset occured and the Classic restarted. The turbine voltage rose to about 135 before the Classic re-enabled the dump load.
Just FYI the load was six 2ohm 300W resistors from Missouri wind and solar, 3 sets of two in series. Each set was connected to a live AC output from the turbine, the other ends to the A1 A2 and A3 inputs oof a crydom D53PH25D SSR, the B1, B2 and B3 all connected together. The two control inputs connected to the Classic AUX1. Aux1 set PV HIGH voltage 110v
This voltage was the max I wanted to see my 48V turbine make.
This voltage limiter worked well. I never had a runaway turbine. All up cost was about $180
dgd
What an in-depth response!
So many questions.. I'll tackle them one at a time.
Dump load is on turbine side of a 3 phase rectifier (200A). Dump load is switched on with 3-32v dc to three 50A SSRs turned on currently by one of the auxs on the midnite. Each SSR connects to a phase of the turbine. Dumpload is three 10ohm resistors wired in a delta config, one phase to each point. DC output of the rectifier is then fed into the midnite.
The turbine *should not* ever get to the 48A point as that would be ~1300 watts from a 500w turbine and it *should* have furled by then. But, if a serious storm (winds expected above 80kph) is forcast, I do lower the turbine for safety sake. Lowering takes about 5 mins so not that big a deal. I do have to be home tho..
The arduino will eventually turn on the dumpload ssrs on under certain conditions (soc > 99.9, batt volts > 30, turbine volts > 120, turbine amps> 25) and use pwm to slow the turbine using more and more load until it is nearly stopped.
QuoteI am wondering why your Classic tended to reset when you saw high current swings ??
So am I ;)
Quote
Were the multiple resets at ~approximately~ a minute between each other ??
Not that I saw.
I went into the local app to try and export logs to see exactly what happened. The logs showed one particular reset where "Kwh" went from .1 to 0 but that .1 was not added to "total kwh". Timestamps were still 2 secs apart even tho "Battery Current", "Watts", "kWh", "charge state", and "Input current" all were zero (must have been resetting?). During that particular time, input volts went to a high of 123.6.
The next reset was 2 mins 2 secs later. Watts were not particularly high for each (according to the log). What was interesting is for each even the fet temp went DOWN and kept going down but the PCB temp went UP briefly then went down. During this reset, input volts went to a high of 165.7.
Also according to the logs, there are several places where "kWh" go from a value, say 2.2, in one row, to 0 on the next row with no corresponding increase in "total kwh".. So those must be resets as well.
I am wondering if the logs are not a bit suspect tho as there was a bit of the log where the timestamps went from 6/6/2013 5:19:03 then 6/6/2013 11:53:22 then 6/5/2013 21:20:21 on three consecutive rows and the values for each row were clearly from different times.
I may be grasping at straws with some or all of this...
Quote
Was there higher power each time that you could tell or did the high current
surge maybe just appear to start the string of resets ?
Didn't seem like a string of resets. Now looking at the logs, it might not have even been high current triggered.
Baffling.
I just want to get out there that I love the product and can see great potential in it. However, this particular issue is a real showstopper for me as, for now, I cannot trust the CC nor any of the data coming out of it.
I can attach csvs of the logs if you want
Cheers
Quote from: dgd on June 07, 2013, 12:42:17 AM
dogfox,
I have watched my Classic 250 reset when the turbine was making power in a blustery rainstorm. No Clipper but I did have a 3phase dump load in use. This load was online when the reset occured and the Classic restarted. The turbine voltage rose to about 135 before the Classic re-enabled the dump load.
Just FYI the load was six 2ohm 300W resistors from Missouri wind and solar, 3 sets of two in series. Each set was connected to a live AC output from the turbine, the other ends to the A1 A2 and A3 inputs oof a crydom D53PH25D SSR, the B1, B2 and B3 all connected together. The two control inputs connected to the Classic AUX1. Aux1 set PV HIGH voltage 110v
This voltage was the max I wanted to see my 48V turbine make.
This voltage limiter worked well. I never had a runaway turbine. All up cost was about $180
dgd
A very similar setup to mine, with exactly the same aux1 setup except the voltage set point for me was 104. Problem was, while the Classic is rebooting, aux1 is off..
Quote from: boB on June 06, 2013, 07:41:24 PM
The newest firmware...
http://fusion.midnitesolar.com/MidNiteSolarSetup_6-6-2013_v3.72.exe
has the data abort information registers in them.
If your Classic has done a reset, check these registers if you have modbus reading capability.
Otherwise, PM or email me.
Registers 4340 through 4343 (addresses 4339 through 4342)
Those registers should contain the information we need to help track this problem
down due to the watch-dog resets.
Thanks for that update, installed and awaiting next reset,although no doubt Sods law will men no reset for ages.. :-\
just wishing for those date and time settable registers now ;D
dgd
Quote from: dogfox on June 07, 2013, 01:23:02 AM
Quote from: dgd on June 07, 2013, 12:42:17 AM
...
This voltage limiter worked well. I never had a runaway turbine. All up cost was about $180
dgd
A very similar setup to mine, with exactly the same aux1 setup except the voltage set point for me was 104. Problem was, while the Classic is rebooting, aux1 is off..
yes of course, I was thinking of AUX1 PV High Hold time but a reset just disables AUX while rebooting.
I suppose the way would be a little circuit with a latch and timer to hold relay on for 20 seconds ::) then again removing the bug is what we need.
But as boB says the solution to protecting the turbine is a Clipper, albeit somewhat expansive. Please share your PWM progressive load system when you get it designed, I'm sure there would be a lot of interest in it :)
dgd
Quote from: dogfox on June 07, 2013, 01:19:39 AM
Dump load is on turbine side of a 3 phase rectifier (200A). Dump load is switched on with 3-32v dc to three 50A SSRs turned on currently by one of the auxs on the midnite. Each SSR connects to a phase of the turbine. Dumpload is three 10ohm resistors wired in a delta config, one phase to each point. DC output of the rectifier is then fed into the midnite.
Just a small comment if I may. When switching a dumpload across a 3-phase circuit in either star or delta, you only need *TWO* relays. You could pull that third one out and keep it for a spare or something :)
Quote from: boB on June 06, 2013, 07:41:24 PM
The newest firmware...
...
has the data abort information registers in them.
Bob, talking to a couple of guys, the new firmware appears to do something bad to the ethernet comms.
Modbus reads that used to be virtually instant are refusing connections for anything up to around 30 seconds.
dogfox,
I need to know a few more things about your setup...
You are connected to internet or local network in static IP mode.
Was web access enabled or disabled when it reset ?
Were you connected to the classic with the Local App to view the Classic when it reset ?
What kind of router do you have ?
On your clipper, sounds like you are doing it correctly.
Since you are a techno kind of guy, you may be able to add a suitable failsafe
self-trigger by using the DC output of the rectifier to turn on your SSR input when
that DC voltage rises above a preset set-point, say, 150 volts DC.
If the SSR uses an LED input coming from the Classic's Aux output, you can use
a diode to OR in your fail-safe trigger to light that LED and trigger the SSR on to
load the turbine. Since the input voltage may be high (150 VDC) you could add
a current source so that you do not overdrive the LED when you want it to trigger.
Or, just do like you mentioned and let the Arduino do the work. That sounds a lot
funner. Just use a resistor voltage divider and input that to one of its A/D converter
inputs.
Sorry, I did not catch what kind of SSR you were using or if it was a relay or contactor.
boB
Something to consider on Emergency Stop systems for a wind turbine. I prefer to have them fail safe, one can not assume or guarantee any electronic device will stay running 100%. I mean a breaker could trip or the Cat could hit the breaker and turn it off. I know our clipper is pricey and for most people who like to tinker it is easy to build there own stuff.
So what I prefer to do is use a pilot relay to drive my SSR's, that switch the resistors or short the phases. This way my Pilot relay can be NC and the Classics Aux Logic can be reversed. It is a little more wasteful do to coil draw but it will make for a fail safe system.
Anyhow to the point Andrew is looking into this now and needs as much info as any one can provide. Is there any real trigger that anyone sees or is it real random? Also if anyone experiencing this can tell us there routers brand and model so we can try to duplicate it for Andrew that would be great.
Ryan
Quote from: RossW on June 07, 2013, 01:52:07 AM
Quote from: dogfox on June 07, 2013, 01:19:39 AM
Dump load is on turbine side of a 3 phase rectifier (200A). Dump load is switched on with 3-32v dc to three 50A SSRs turned on currently by one of the auxs on the midnite. Each SSR connects to a phase of the turbine. Dumpload is three 10ohm resistors wired in a delta config, one phase to each point. DC output of the rectifier is then fed into the midnite.
Just a small comment if I may. When switching a dumpload across a 3-phase circuit in either star or delta, you only need *TWO* relays. You could pull that third one out and keep it for a spare or something :)
Hi Ross,
Really? I would love to see a circuit diagram, cuz as it happens, I need another for a different project. TIA
Quote from: dogfox on June 07, 2013, 06:19:51 AM
Quote from: RossW on June 07, 2013, 01:52:07 AM
Quote from: dogfox on June 07, 2013, 01:19:39 AM
Dump load is on turbine side of a 3 phase rectifier (200A). Dump load is switched on with 3-32v dc to three 50A SSRs turned on currently by one of the auxs on the midnite. Each SSR connects to a phase of the turbine. Dumpload is three 10ohm resistors wired in a delta config, one phase to each point. DC output of the rectifier is then fed into the midnite.
Just a small comment if I may. When switching a dumpload across a 3-phase circuit in either star or delta, you only need *TWO* relays. You could pull that third one out and keep it for a spare or something :)
Hi Ross,
Really? I would love to see a circuit diagram, cuz as it happens, I need another for a different project. TIA
Ahhh.... it's simple!
Turbine Dumpload
A -----------] [-----------/\/\/\/----|
B------------] [-----------/\/\/\/----|
C--------------------------/\/\/\/----|
Put your two relay contacts as shown. (This is drawn as star, but works the same for delta)
When relay 'A' and 'B' are open, you don't have to open 'C' as no current can flow anyway!
Quote from: boB on June 07, 2013, 03:02:45 AM
dogfox,
I need to know a few more things about your setup...
You are connected to internet or local network in static IP mode.
Yes
Quote
Was web access enabled or disabled when it reset ?
Enabled. It was after the second reset that I started researching whether others were experiencing these issues and I read about web access possibly being a culprit. I have since turned web access off. I have no reliable way of seeing if its still resetting or not.
Quote
Were you connected to the classic with the Local App to view the Classic when it reset ?
Don't recall if I was for the first reset. I am sure local app was running for the second tho. I know that doesn't help troubleshooting.
Quote
What kind of router do you have ?
The Classic and the arduino are connected to a router I picked up from a local electronics house
http://www.jaycar.com.au/productView.asp?ID=YN8305
That router forms a wireless bridge to get to my home router, a netcomm 3G18WV
The netcomm is configured to use 3g permanently for web access.
Quote
On your clipper, sounds like you are doing it correctly.
Since you are a techno kind of guy, you may be able to add a suitable failsafe
self-trigger by using the DC output of the rectifier to turn on your SSR input when
that DC voltage rises above a preset set-point, say, 150 volts DC.
If the SSR uses an LED input coming from the Classic's Aux output, you can use
a diode to OR in your fail-safe trigger to light that LED and trigger the SSR on to
load the turbine. Since the input voltage may be high (150 VDC) you could add
a current source so that you do not overdrive the LED when you want it to trigger.
I thought about that solution but it was rather limiting.. I need to be able to turn on the dumpload under several different conditions.
Quote
Or, just do like you mentioned and let the Arduino do the work. That sounds a lot
funner. Just use a resistor voltage divider and input that to one of its A/D converter
inputs.
I am currently doing exactly that. The divider is set up so that I can read up to 212 volts.
Quote
Sorry, I did not catch what kind of SSR you were using or if it was a relay or contactor.
boB
relay model SSR 50 DA
Thanks Bob for trying to get to the bottom of this.
Quote from: dogfox on June 07, 2013, 07:17:09 AM
The Classic and the arduino are connected to a router I picked up from a local electronics house
http://www.jaycar.com.au/productView.asp?ID=YN8305
Hah, I hadn't caught that you're another .au. Western Vic, you can't be more than 4 or 5 hours drive from me (on the NSW/Vic border, on the Hume Hwy).
Do you have a linux or FreeBSD box on your network? Might have something useful to monitor your box...
Quote from: RossW
Just a small comment if I may. When switching a dumpload across a 3-phase circuit in either star or delta, you only need *TWO* relays. You could pull that third one out and keep it for a spare or something :)
Turbine Dumpload
A -----------] [-----------/\/\/\/----|
B------------] [-----------/\/\/\/----|
C--------------------------/\/\/\/----|
Put your two relay contacts as shown. (This is drawn as star, but works the same for delta)
When relay 'A' and 'B' are open, you don't have to open 'C' as no current can flow anyway!
Of course. Brilliant.. Thanks RossW
Quote from: RossW on June 07, 2013, 07:22:08 AM
Quote from: dogfox on June 07, 2013, 07:17:09 AM
The Classic and the arduino are connected to a router I picked up from a local electronics house
http://www.jaycar.com.au/productView.asp?ID=YN8305
Hah, I hadn't caught that you're another .au. Western Vic, you can't be more than 4 or 5 hours drive from me (on the NSW/Vic border, on the Hume Hwy).
Do you have a linux or FreeBSD box on your network? Might have something useful to monitor your box...
Up the Hume eh. Lovely country up there.
Nope no linux boxen round here. Which 'box' are you referring to ?
Quote from: dogfox on June 07, 2013, 07:45:44 AM
Up the Hume eh. Lovely country up there.
Nope no linux boxen round here. Which 'box' are you referring to ?
Oh well. I was thinking of a way for you to read data from your classic and log locally, but my code has only been compiled and tested for Linux, FreeBSD, OS/X and the RaspberryPi at this stage.
Quote from: Halfcrazy on June 07, 2013, 05:52:54 AM
Something to consider on Emergency Stop systems for a wind turbine. I prefer to have them fail safe, one can not assume or guarantee any electronic device will stay running 100%. I mean a breaker could trip or the Cat could hit the breaker and turn it off. I know our clipper is pricey and for most people who like to tinker it is easy to build there own stuff.
So what I prefer to do is use a pilot relay to drive my SSR's, that switch the resistors or short the phases. This way my Pilot relay can be NC and the Classics Aux Logic can be reversed. It is a little more wasteful do to coil draw but it will make for a fail safe system.
That is what I am endevouring to do, eventually. The dumpload trigger will be normally 'on' and powered by its own power supply and the arduino will just turn it 'off' under the right conditions.
Quote
Anyhow to the point Andrew is looking into this now and needs as much info as any one can provide. Is there any real trigger that anyone sees or is it real random? Also if anyone experiencing this can tell us there routers brand and model so we can try to duplicate it for Andrew that would be great.
Ryan
If there is anything I can do or provide, just ask
Quote from: Halfcrazy on June 07, 2013, 05:52:54 AM
Something to consider on Emergency Stop systems for a wind turbine. I prefer to have them fail safe, one can not assume or guarantee any electronic device will stay running 100%. I mean a breaker could trip or the Cat could hit the breaker and turn it off. I know our clipper is pricey and for most people who like to tinker it is easy to build there own stuff.
So what I prefer to do is use a pilot relay to drive my SSR's, that switch the resistors or short the phases. This way my Pilot relay can be NC and the Classics Aux Logic can be reversed. It is a little more wasteful do to coil draw but it will make for a fail safe system.
Ryan
I thought about this last year when I made a 'clipper'. Problem is when that cat (or cockatoo in my case) trips the main battery inverter and all power is down then that pilot relay has no energy to make the ssr live hence no dump resistors in the turbine ac.
A normally closed contractor would be final fail safe just stopping the turbine, the ssr/resistor setup is useful to slow the turbine but keep it spinning and making power.
So a NC contactor on AUX1 with active PV LOW set to max voltage and hold time set to stop contractor chattering is a good voltage clipper and fail safe device. No power contactor goes NC turbine shuts down.
Dogfox will have similar issues if his electronics dies as ssr will not close, interesting to see his design around this with the arduino :)
Dgd
Thanks dogfox et. al. (who would want to eat Al anyway ? Yech !)
Digesting the information and our man in France is making some headway.
DGD, have you looked at our latest modbus document that talks about
setting the time and date via special functions 0x68 and 0x69 (104/105) ??
boB
Just noticed I'd had another couple of resets yesterday.
Not much sun, currents and temperatures low all day, no sudden changes in output etc..
(http://general.rossw.net/midnite/reset1-7jun13.gif)
(http://general.rossw.net/midnite/reset2-7jun13.gif)
(http://general.rossw.net/midnite/reset3-7jun13.gif)
I don't have the latest firmware so can't report the "where did it fail" state for you Bob (sorry!).
Not planning to upgrade to it just yet because of the ethernet problems as discussed.
OK, try this newest and latest...
http://fusion.midnitesolar.com/MidNiteSolarSetup_6-8-2013_v3.73.exe
I hadn't actually seen the third party modbus over ethernet problems but I just tried this with
modpol and it does work. I do have to wait just a moment before reading the Classic a second
time, but I only stopped the batch file (it runs in a loop) and re-run it right away and it works
and reads the Classic again.
I ~think~ that Andrew made a change that ~might~ fix the resets... I don't know for sure.
boB
Quote from: boB on June 08, 2013, 06:13:38 PM
OK, try this newest and latest...
http://fusion.midnitesolar.com/MidNiteSolarSetup_6-8-2013_v3.73.exe
I hadn't actually seen the third party modbus over ethernet problems but I just tried this with
modpol and it does work. I do have to wait just a moment before reading the Classic a second
time, but I only stopped the batch file (it runs in a loop) and re-run it right away and it works
and reads the Classic again.
I ~think~ that Andrew made a change that ~might~ fix the resets... I don't know for sure.
Bob, applied this latest firmware to my box. At least it doesn't seem to have the ethernet problems of the previous version. I'm logging now and will see what happens when (if) I get another spontaneous reset.
No, I haven't made any released changes to fix the resets.
What I would like to see done when possible is for those that are having reset issues to
unplug their Ethernet/internet from their Classic for a day or two and see if they still
have resets.
Temporarily plugging in the Ethernet to check to see if it has reset should be OK though
if it is unplugged as soon as the information has been gathered or downloaded.
This will narrow down if it is still part of the network or something else.
Thanks,
boB
Quote from: boB on June 11, 2013, 03:22:39 AM
What I would like to see done when possible is for those that are having reset issues to
unplug their Ethernet/internet from their Classic for a day or two and see if they still
have resets.
Bob, as I mentioned in IRC, I'm interstate for a couple of days.
I can't unplug the ethernet, but I *HAVE* firewalled it both directions from the internet.
It can't initiate a connection out to anywhere, and nowhere outside can reach it.
Will see if it makes any difference. (It will of course still see local network broadcasts, ARP requests etc)
Quote from: RossW on June 11, 2013, 03:32:49 AM
Quote from: boB on June 11, 2013, 03:22:39 AM
What I would like to see done when possible is for those that are having reset issues to
unplug their Ethernet/internet from their Classic for a day or two and see if they still
have resets.
Bob, as I mentioned in IRC, I'm interstate for a couple of days.
I can't unplug the ethernet, but I *HAVE* firewalled it both directions from the internet.
It can't initiate a connection out to anywhere, and nowhere outside can reach it.
Will see if it makes any difference. (It will of course still see local network broadcasts, ARP requests etc)
This will be a good Pre-test before you get back, Ross.
Thanks !
boB
Quote from: dogfox on June 07, 2013, 07:17:09 AM
Quote from: boB on June 07, 2013, 03:02:45 AM
dogfox,
Was web access enabled or disabled when it reset ?
Enabled. It was after the second reset that I started researching whether others were experiencing these issues and I read about web access possibly being a culprit. I have since turned web access off. I have no reliable way of seeing if its still resetting or not.
I have had web access turned off since then and (I might be tempting fate here) I have not logged any voltage spikes above what I have set on the Classic's Aux1 for triggering the dump load. We had pretty high winds (40-50kph) here all day yesterday and all night long and, thankfully, no resets that I can see.
Please look into the code for creation of the csv log files from the local app. There seem to be irregulatities in the data (missing time periods, date/times reverting back to previous periods, etc.) I can send you my files to check out if you wish.
Cheers
Quote from: dogfox on June 12, 2013, 06:09:39 PM
Please look into the code for creation of the csv log files from the local app. There seem to be irregularities in the data (missing time periods, date/times reverting back to previous periods, etc.) I can send you my files to check out if you wish.
Cheers
Yeah there is a bug in the Date Stamp formula that gets replicated incorrectly. The data in the time stamp column is correct. If you re-replicate the first cell of the Date Time formula all the way down your first column in Excel the Date and Time will get corrected. In Daily dumps from the app I get two days worth of data and I get one line showing the next day and the following line shows the formula reverting back to using cell B5 so all the dates come out incorrectly as is should be using the next B cell in sequence.
Quote from: boB on June 06, 2013, 07:41:24 PM
BTW folks....
The newest firmware...
http://fusion.midnitesolar.com/MidNiteSolarSetup_6-6-2013_v3.72.exe
has the data abort information registers in them.
If your Classic has done a reset, check these registers if you have modbus reading capability.
Otherwise, PM or email me.
Registers 4340 through 4343 (addresses 4339 through 4342)
Those registers should contain the information we need to help track this problem
down due to the watch-dog resets.
Thanks,
boB
boB,
My pv classic just crashed a few minutes ago and rest the kw/hr to zero. 200BA94A fw 1401 network 1194
Noticed it when running local app froze. First crash for a couple of weeks.
Modbus registers contain data
reg decimal hex
4339 0 0000
4340 18 0012
4341 58240 e380
4342 61440 f000
4343 57633 e121
dgd
Quote from: dgd on June 21, 2013, 07:29:54 PM
Modbus registers contain data
reg decimal hex
4339 0 0000
4340 18 0012
4341 58240 e380
4342 61440 f000
4343 57633 e121
This from three I'm watching at the moment (none have recently reset)
4131=0x3200 <-- Useful register, as it shows the WD Reset bit
4341=0x0012 <-- these 4 however are identical values to yours
4342=0xe380 <-- but are you showing registers or addresses?
4343=0xf000 <-- yours appear to be 1 lower, suggesting address not register?
4344=0xe121
Quote from: RossW on June 21, 2013, 08:27:17 PM
Quote from: dgd on June 21, 2013, 07:29:54 PM
Modbus registers contain data
reg decimal hex
4339 0 0000
4340 18 0012
4341 58240 e380
4342 61440 f000
4343 57633 e121
This from three I'm watching at the moment (none have recently reset)
4131=0x3200 <-- Useful register, as it shows the WD Reset bit
4341=0x0012 <-- these 4 however are identical values to yours
4342=0xe380 <-- but are you showing registers or addresses?
4343=0xf000 <-- yours appear to be 1 lower, suggesting address not register?
4344=0xe121
registers..
04130 is 0x3280
Are your registers that are the same values as mine just showing what happened at last reset?
04130 ic cleared each day end.
dgd
Quote from: dgd on June 21, 2013, 08:34:09 PM
registers..
04130 is 0x3280
Are your registers that are the same values as mine just showing what happened at last reset?
04130 ic cleared each day end.
Odd, the numbers you quote as "registers" being 1 short of what I observe AND what's in the midnite modbus register map/pdf.
I have not yet seen any of those registers contain anything different to what they are now. Ever.
After a reset, before a reset, in the morning, at noon or night. Ever.
I looked at my other 'live' classic and it has same modbus values. Maybe boB has not implemented reset debugging yet :-\
dgd
Quote from: dgd on June 22, 2013, 01:13:32 AM
I looked at my other 'live' classic and it has same modbus values. Maybe boB has not implemented reset debugging yet :-\
dgd
Hi guys...
These values,
4340 18 0012
4341 58240 e380
4342 61440 f000
4343 57633 e121
....appear to NOT be a result of a watch dog reset but default values when
the Classic first powers up.
I think that if you power down the Classic and power it back up again normally
that you will see the same values. In fact, maybe you could give that
a try just to make sure.
Remember that if, on, MyMidnite, your flags register shows an 0x00000080 bit
set that that is a Data Abort or, WDT reset. It ~could~ be that your
classic is resetting for some entirely different reason ? Possibly an internal
power supply brownout ? That appears to be what Ross is experiencing ?
OK, off to the science museum in Munich for the day. I'll probably be back
when you guys all wake up.
böB
Quote from: boB on June 23, 2013, 05:11:27 AM
Possibly an internal power supply brownout ? That appears to be what Ross is experiencing ?
I've got around 1500AH of AGM cells in reasonable condition, the inverter will call for the generator long before the midnight should ever see a voltage within 5% of nominal. (And since the midnite will work on a 12V system, surely nothing a 48V system could give it would EVER come close to a problem??)
Quote from: RossW on June 23, 2013, 06:21:52 AM
Quote from: boB on June 23, 2013, 05:11:27 AM
Possibly an internal power supply brownout ? That appears to be what Ross is experiencing ?
I've got around 1500AH of AGM cells in reasonable condition, the inverter will call for the generator long before the midnight should ever see a voltage within 5% of nominal. (And since the midnite will work on a 12V system, surely nothing a 48V system could give it would EVER come close to a problem??)
I'm just saying that something else must be making the processor reset besides WDT timeout. I wish I knew
what it was and could see it here. Internal auxiliary power supply dropout is one probably cause in
addition to some weird jump to memory zero bug.
boB
I reset both Classics a few minutes ago and on 200BA94A the hex flags changed from
10043280 to
100432C0 then
10043200
so it seems only a power off/on reset will clear the ..80 flag. I though this was supposed to clear every day 11:59pm? The MyMN shows it as an Internal reset and really needs to be auto reset at least daily.
the modbus registers are:
04340 0x0012
04341 0xe380
04342 0xf000
04343 0xe121
so these are just the normal power on values.
I have definitely noticed that since changing to 1401 firmware these random resets are much less frequent
dgd
Quote from: dgd on June 23, 2013, 04:43:31 PM
I reset both Classics a few minutes ago and on 200BA94A the hex flags changed from
10043280 to
100432C0 then
10043200
so it seems only a power off/on reset will clear the ..80 flag. I though this was supposed to clear every day 11:59pm? The MyMN shows it as an Internal reset and really needs to be auto reset at least daily.
the modbus registers are:
04340 0x0012
04341 0xe380
04342 0xf000
04343 0xe121
so these are just the normal power on values.
I have definitely noticed that since changing to 1401 firmware these random resets are much less frequent
dgd
Those registers 434x content are default and what come up normally.
No, it does not clear. You CAN clear it by just resetting that register bit 0x80 though.
Check the registers 434x when the flags equal 10043280 (or at least the 0x80 bit) and then those
registers should show something different. When you say change to 1401 firmware, is that BACK TO
1401 from the newer firmware ? The trick is to catch the numbers after an 10043280 flat setting
so we can see what is going on.
(I can't remember off the top of my head if 1401 is new or old) (too lazy and going to sleep now)
boB
Firmware 1401 is latest AFAIK. I will await another random reset then see whats in those 43xx registers
dgd
Quote from: dgd on June 24, 2013, 05:50:28 AM
Firmware 1401 is latest AFAIK. I will await another random reset then see whats in those 43xx registers
Really really crap day today. Getting around 100W from my 3.6KW arrays... but had a reset.
24/Jun/2013 12:55:01
4131=0x3200 <-- watchdog flag not set.
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
24/Jun/2013 13:00:02
4131=0x3280 <-- watchdog flag set.
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
24/Jun/2013 13:05:00
4131=0x3200 <-- watchdog flag reset after earlier condition.
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
(Basically, I check every 5 mins. If the WD flag is set, I send an SMS alert message to myself, clear the flag, and keep logging.)
Ross;
Good info! I just grepped my rather short 3 days of logs and see no instance of the reset. I was logging to the SD card on the Pi so was clearing them regularly to keep the space free.
With your recent update (.17) I shifted logging to the 32 gig USB stick so should be able to log every couple minutes for a long time without concern for filling the space.
You are not using the Local App are you? I got convinced that it was the Local App causing resets here but it was not exactly a detailed troubleshooting result just an "educated guess".
Tom
Quote from: RossW on June 24, 2013, 07:24:45 AM
Quote from: dgd on June 24, 2013, 05:50:28 AM
Firmware 1401 is latest AFAIK. I will await another random reset then see whats in those 43xx registers
Really really crap day today. Getting around 100W from my 3.6KW arrays... but had a reset.
24/Jun/2013 12:55:01
4131=0x3200 <-- watchdog flag not set.
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
24/Jun/2013 13:00:02
4131=0x3280 <-- watchdog flag set.
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
24/Jun/2013 13:05:00
4131=0x3200 <-- watchdog flag reset after earlier condition.
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
(Basically, I check every 5 mins. If the WD flag is set, I send an SMS alert message to myself, clear the flag, and keep logging.)
Those registers ~SHOULD~ be giving different values, ~IF~ the Classic reset due to a Data Abort like
my unit did.
So, there are two other ways this could happen...
One requires the Auto-Restart be enabled, which should trigger at 23:59 (Midnight)
I think that we already went over this one and your A-RST was NOT enabled and
also your clock is correct.
The other way this could happen is if the Classic got stuck in a ~normal~ loop
for 5.0 seconds or more... (I try not to do moderately long loops but sometimes ya gotta)
I will look into the "other" way now. The timing profiles I have done, which are very
accurate, have never been anywhere near 5 seconds long so I must look harder now !
Maybe your EEprom is hanging up or something ? I'll start there.
I'm still in Germany so will start looking in a couple of days.
Thanks for the info ! This is exactly the type of thing I needed to know !
boB
just started MyMinite and it shows internal reset on my Classic 250, 9CF96252, fw 1401, modbus registers same as before:
04340 0x0012
04341 0xe380
04342 0xf000
04343 0xe121
so it would seem whatever is causing this reset in not being detected by the watchdog monitoring that reports info to these registers.
dgd
Quote from: boB on June 24, 2013, 03:15:50 PM
Thanks for the info ! This is exactly the type of thing I needed to know !
Just happened again - I wish I had some time to stop and look, but its not going to happen in the next week or so!
25/Jun/2013 10:30:00
4131=0x3200
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
25/Jun/2013 10:35:02
4131=0x3280
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
Quote from: RossW on June 24, 2013, 08:41:27 PM
Quote from: boB on June 24, 2013, 03:15:50 PM
Thanks for the info ! This is exactly the type of thing I needed to know !
Just happened again - I wish I had some time to stop and look, but its not going to happen in the next week or so!
25/Jun/2013 10:30:00
4131=0x3200
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
25/Jun/2013 10:35:02
4131=0x3280
4341=0x0012
4342=0xe380
4343=0xf000
4344=0xe121
Yeah, unless I'm missing something, it's stuck in a loop and timing out the WDT.
I'll get it now. The hardest part is duplicating YOUR problem !
I may be making some special software to try, Ross. Others may also need to try it.
I may also add to that special software, a WDT enable/disable bit just for you to
try out. I don't want that to be a permanent option though because if it really does
crash, you want the Classic to reset gracefully.
Ross, did you ever try your Classic for a couple of days without the Ethernet connected to
see if it still resets ? Anybody else try that ? DGD ?
DGD..... " shows internal reset on my Classic 250, 9CF96252, fw 1401,"
Is "9CF96252" your ID or the flags register on My Midnite ? If flags, it is not
showing a WDT reset.
ONE more thing... Has anybody noticed if the Classic ever resets while is is "Resting" ???
Is it ALWAYS running and charging when you notice it ? I don't suppose people are going
to stare at a Classic while is is Resting, but they might notice that the kW-Hours went to
zero before 23:59 and after the sun went down.
boB
Quote from: boB on June 25, 2013, 04:51:59 AM
I may also add to that special software, a WDT enable/disable bit just for you to
try out. I don't want that to be a permanent option though because if it really does
crash, you want the Classic to reset gracefully.
Ross, did you ever try your Classic for a couple of days without the Ethernet connected to
see if it still resets ? Anybody else try that ? DGD ?
I have a Classic 150 at an isolated location and its not ethernet connected. No random reset, ever. There is a new broadband link being installed there next week and then the Classic will be network connected and fwupdated to latest. It will be interesting to see if it starts getting these random resets.
Quote
DGD..... " shows internal reset on my Classic 250, 9CF96252, fw 1401,"
Is "9CF96252" your ID or the flags register on My Midnite ? If flags, it is not
showing a WDT reset.
Sorry thats just the Classic ID.
Quote
ONE more thing... Has anybody noticed if the Classic ever resets while is is "Resting" ???
Is it ALWAYS running and charging when you notice it ? I don't suppose people are going
to stare at a Classic while is is Resting, but they might notice that the kW-Hours went to
zero before 23:59 and after the sun went down.
Yes, this has happened, reset after dark while resting, sets KW/hr to zero and then at 11:59 logs show energy for day was zero.
dgd
Quote from: boB on June 25, 2013, 04:51:59 AM
I'll get it now. The hardest part is duplicating YOUR problem !
Yeah, I get special problems :)
Quote
I may also add to that special software, a WDT enable/disable bit just for you to
try out. I don't want that to be a permanent option though because if it really does
crash, you want the Classic to reset gracefully.
Agreed.
Quote
Ross, did you ever try your Classic for a couple of days without the Ethernet connected to
see if it still resets ?
I'm still trying to get to it. Been stupid busy and not likely to be any less so for at least another 10 days.
Quote
ONE more thing... Has anybody noticed if the Classic ever resets while is is "Resting" ???
Is it ALWAYS running and charging when you notice it ? I don't suppose people are going
to stare at a Classic while is is Resting
I don't have to. I've got a script monitoring it all the time, collecting and logging data.
And examining the WD-RESET bit. If that bit is set, it sends me an email, and a text message immediately.
It then resets the WD-RESET bit and resumes monitoring. I've never had one when there hasn't been at least some sun.
Doesn't mean it can't happen, but I've not witnessed one. (out of about 30 resets, 100% have been during "charging" time)
DGD said... "I have a Classic 150 at an isolated location and its not ethernet connected. No random reset, ever. There is a new broadband link being installed there next week and then the Classic will be network connected and fwupdated to latest. It will be interesting to see if it starts getting these random resets."
I need a bit more information. Has "THAT" particular unit reset when it was plugged into Ethernet ??
To troubleshoot this, I need a Classic that is resetting when plugged into Ethernet/Internet to be
unplugged from Ethernet/Internet to see if it is the Ethernet or something else.
I think that only TomW has actually done this.
RossW, your connection that monitors all the time and emails you "IS" connected so that
does not count as being disconnected I don't think. You would have to watch it just
once in a while to see if it resets or not when disconnected. If you let it sit for a day
unconnected and then either look at it to see that it did not reset its kW-Hours
and THEN BRIEFLY connect to it to read the 4131 register to see if it did a WDT reset,
that is what we need to see I think.
boB (boarding the plane now in Munich)
Just wanted to report in..
Since I DISabled 'web access', I have not had a reset that I could detect. My arduino logger has not picked up any turbine voltage spikes that would illustrate a reset (because
I am currently running my dump load off of aux2 and aux2 would not work if the classic was resetting-allowing a spike).
I initially thot that current surges were playing a part but we have had numerous wind events where gusts would produce current surges of up to 600w and no probs.
Thanks again for looking into this.
QuoteONE more thing... Has anybody noticed if the Classic ever resets while is is "Resting" ???
Is it ALWAYS running and charging when you notice it ? I don't suppose people are going
to stare at a Classic while is is Resting, but they might notice that the kW-Hours went to
zero before 23:59 and after the sun went down.
boB
Yes! I was out fiddling around in the garage (where the Classic is) late one evening and noticed that it had suddenly reset the kwh back to zero, and I'd noticed that it had a kwh hour value (total) for the day just before that.
Keeping with the theme here, I have not, however, noticed a reset unless the classic is on-line/connected (ethernet cabled). It does seem to be remarkably random. I've seen it do it two or three times in a single day, and I've had it go a week or two without doing it...
Lee.
Quote from: justmeleep on July 22, 2013, 12:18:24 PM
QuoteONE more thing... Has anybody noticed if the Classic ever resets while is is "Resting" ???
Is it ALWAYS running and charging when you notice it ? I don't suppose people are going
to stare at a Classic while is is Resting, but they might notice that the kW-Hours went to
zero before 23:59 and after the sun went down.
boB
Yes! I was out fiddling around in the garage (where the Classic is) late one evening and noticed that it had suddenly reset the kwh back to zero, and I'd noticed that it had a kwh hour value (total) for the day just before that.
Keeping with the theme here, I have not, however, noticed a reset unless the classic is on-line/connected (ethernet cabled). It does seem to be remarkably random. I've seen it do it two or three times in a single day, and I've had it go a week or two without doing it...
Lee.
Lee, this is good information.
I wonder though if you haven't seen it reset while the Ethernet was unplugged because the Ethernet is
normally plugged in and it hasn't had a chance to reset ?
Another question... What do you remember about the battery voltage and loads on the battery when
it was resetting during the day ? Do you have any other charging sources going into that battery bank ?
boB
QuoteLee, this is good information.
I wonder though if you haven't seen it reset while the Ethernet was unplugged because the Ethernet is
normally plugged in and it hasn't had a chance to reset ?
Another question... What do you remember about the battery voltage and loads on the battery when
it was resetting during the day ? Do you have any other charging sources going into that battery bank ?
boB
It is possible that I haven't seen it because the ethernet is normally connected. I have seldom disconnected it, since I first got it to work. I do have the classic reset itself every night, and occasionally will lose connectivity for a day, or whatever, but other than that, it's almost always connected. I've just lived with the re-sets. Lately, mymidnite has said it's undergoing "maintenance" so I've wondered if I should just unplug it, at least when I'm not home and not accessing it that way either (like is the case right now - my house (and charge controller) is in one state, and I'm in another). I really like the information I get on mymidnite, when I get it, which is why I've lived with it. On the other hand, I haven't seen a random reset at all, in weeks (knocking loudly on wood ;)).
I do not have any other charging sources going into my classic, other than the solar panels on my roof (currently a supposed 2k worth - 8 250watt panels - 4 more are on order). I do have a load on the battery bank - like my fridge, freezer, all of my computers, and I have it set to where if the battery voltage is high enough it also turns on a (portable) air conditioner, with the "excess power"). So, my load varies, but it always available - I try not to let potential solar power go to waste. This does cause the battery voltage to vary, both with the load, and of course with sun conditions. And, it does seem like I've seen more resets when that is exactly what is happening, than when the sun is constant, and the load is as constant as it gets.
I hope this is useful/helpful information to know,
Lee.
Quote from: justmeleep on July 26, 2013, 04:34:11 PM
I do have the classic reset itself every night,
You mean you have auto-restart set to ON in tweaks ? It resets at 23:59 at night ?
boB
QuoteYou mean you have auto-restart set to ON in tweaks ? It resets at 23:59 at night ?
Yes, boB, exactly what I meant.
Lee.
Hi all
Any advance to solve this odd behaviour? I have a couple of customers with this "lights out & restart"
Quote from: Photon on August 07, 2013, 02:44:29 PM
Hi all
Any advance to solve this odd behaviour? I have a couple of customers with this "lights out & restart"
OK, do you know what their battery size and types of loads are ?
I am wondering if the battery voltage is maybe rising sharply above
the absorb or float set point.
Oh, has anyone caught the 3 Classic LEDs on the control board doing their reset "dance" when
the unit resets ?
boB
One of them sent me a video (heavy, 8 Mb) I am uploading to youtube so you can check it out.
http://youtu.be/d3BPVKSWQEU
He is using these values:
BULK 2,4V/e
FLOAT 2,23 V/e
ECU 2,65 V/e
And his battery bank is a 12v set of TAB 5 TOPzS442 575C100
http://tab.com.es/Documentos/Topzs/NAVODILA%20-%20Operating%20instructions%20for%20stationary%20batteries%202009.pdf
I have been told that during this reset the dial in the local APP goes to 0.
Thank you, is a wonderful machine, and regards to Robin.
Quote from: Photon on August 08, 2013, 02:35:07 PM
One of them sent me a video (heavy, 8 Mb) I am uploading to youtube so you can check it out.
http://youtu.be/d3BPVKSWQEU
He is using these values:
BULK 2,4V/e
FLOAT 2,23 V/e
ECU 2,65 V/e
And his battery bank is a 12v set of TAB 5 TOPzS442 575C100
http://tab.com.es/Documentos/Topzs/NAVODILA%20-%20Operating%20instructions%20for%20stationary%20batteries%202009.pdf
I have been told that during this reset the dial in the local APP goes to 0.
Thank you, is a wonderful machine, and regards to Robin.
Ryan says.....
"that is normal expected behavior. There is a bug in the newer code on the MNLP that causes it to basically reboot the MNLP for a lack of a better term. I have seen mine do that repeatedly. It is on Andrews list
Ryan"
But that does not explain the local app showing zero if that is happening exactly at this time.
However, when the Classic does its solar sweep, the power meter will go to zero for a moment.
Maybe that's it ?
boB
Could be that indeed, so I´ll ask for a re-check or a video to see what triggers that.
My Classic reset not once but twice today. Accumulated 2.3 kwh then back to zero, then .6 kwh, then back to zero, then another .1 kwh to close out the day. Time was correct and nothing else was out of the ordinary today.
OK, Wxboy, what is your Classic's software/firmware revision and date ?
To find it, press the STATUS button a few times until that information screen
comes up.
Also, what kind of router are you using ?
I believe it's version 1370 because it had an April date but I will confirm when I get home. I have a Linksys router.
Confirmed 1370 4/8.
Quote from: Wxboy on August 12, 2013, 07:58:44 PM
Confirmed 1370 4/8.
OK, that's new enough. Have you seen it do this since then ?
How often has it reset during the day that you know of ?
boB
Quote from: boB on August 13, 2013, 12:55:37 AM
OK, that's new enough. Have you seen it do this since then ?
How often has it reset during the day that you know of ?
Bob, I have some additional information to bring to the table.
Reading this thread reminded me that I hadn't had an alarm from mine for ages.
I thought it was simply because I'd got sick of it and turned them off... but on going back and reviewing my log data, day/time on which I've had a reset (determined by register 4131 having bit 7 set, eg, 0x3280) finishes thus:
18/Jul/2013 08:05:01
18/Jul/2013 09:00:01
18/Jul/2013 11:25:02
18/Jul/2013 13:15:00
18/Jul/2013 13:20:01
18/Jul/2013 15:20:02
19/Jul/2013 09:45:02
19/Jul/2013 10:25:00
19/Jul/2013 10:40:00
19/Jul/2013 12:25:00
19/Jul/2013 14:05:00
19/Jul/2013 15:00:01
20/Jul/2013 11:15:01
20/Jul/2013 15:20:00
22/Jul/2013 11:35:00
Several things from this.
1. It's only ever happened during the day, when there's at least SOME power from my PV.
2. I've sifted the log to find the number of resets each day, then sifted that for the number of days for each number of resets, and come up with:
Days Resets
9 1
8 2
6 3
5 4
2 5
2 6
3 7
(Remember, I've only had the device online for a short time!)
3. And this is the really interesting fact: it hasn't had a SINGLE RESET since it broke (recall we chatted in IRC at length, something went screwy, we removed R57 and got it limping along again....)
Well, the thing is: it is still connected to the ethernet, using the same cable, router etc that it's always had. (never unplugged it). It is still polled by my newmodbus utility every 5 minutes like it always has. It is still connected to the same battery bank. It still has the same firmware version.
The ONLY changes I am aware of are:
1. Changed settings from the standard solar mode, to "legacy" mode per your instructions.
2. Reduced PV input from 3.6KW to about 400W
Anything there give you anything to go on?
VERY interesting stats, Ross ! Thank you !
I don't think that R57 has anything to do with it.
>>>2. Reduced PV input from 3.6KW to about 400W
I would try adding back some more power to it and see if it starts resetting again.
boB
Quote from: boB on August 13, 2013, 02:15:30 AM
VERY interesting stats, Ross ! Thank you !
I don't think that R57 has anything to do with it.
>>>2. Reduced PV input from 3.6KW to about 400W
I would try adding back some more power to it and see if it starts resetting again.
I'll have to do a bunch of rewiring to put the classic back in full production after I moved it back to the flexmax-80, so that'll have to wait.
What would be perhaps more interesting would be to find someone who has the same problem and see if they can make it go away (and come back) on demand, by changing to legacy mode!
Ross, from your stats, do you think that it could have been resetting when your batteries
were full rather than needing a good charge ? Or, maybe when the batteries were
full AND loads were light ?
boB
Quote from: boB on August 13, 2013, 03:26:42 AM
Ross, from your stats, do you think that it could have been resetting when your batteries
were full rather than needing a good charge ? Or, maybe when the batteries were
full AND loads were light ?
Bob, I don't think so. The times don't fit with the batteries being full. So I've done some further analysis of the logs. The following is the date/time I detected the RESET (so some time in the previous 5 mins). The next 3 fields are the battery volts, the charging power and charge state (register 4120), followed by what the same three were immediately PRIOR to the reset...
06/Jul/2013 09:35:01 49.9V 0W Resting Prev: 51.0V 1039W BulkMppt
06/Jul/2013 10:20:02 50.1V 0W Resting Prev: 49.3V 431W BulkMppt
06/Jul/2013 11:10:02 55.2V 2274W BulkMppt Prev: 51.5V 1078W BulkMppt
07/Jul/2013 10:20:02 49.8V 0W Resting Prev: 52.5V 2719W BulkMppt
07/Jul/2013 11:25:03 50.5V 0W Resting Prev: 51.2V 1727W BulkMppt
07/Jul/2013 13:05:00 49.2V 396W BulkMppt Prev: 49.3V 222W BulkMppt
07/Jul/2013 13:45:01 49.2V 526W BulkMppt Prev: 49.1V 364W BulkMppt
07/Jul/2013 14:40:01 48.7V 132W BulkMppt Prev: 48.7V 170W BulkMppt
07/Jul/2013 15:00:00 48.8V 386W BulkMppt Prev: 48.6V 176W BulkMppt
07/Jul/2013 16:45:02 49.3V 511W BulkMppt Prev: 49.7V 843W BulkMppt
08/Jul/2013 08:20:02 52.5V 189W BulkMppt Prev: 52.7V 380W BulkMppt
08/Jul/2013 10:45:02 54.0V 2710W BulkMppt Prev: 51.5V 1714W BulkMppt
09/Jul/2013 09:10:00 51.3V 1848W BulkMppt Prev: 51.1V 1619W BulkMppt
09/Jul/2013 09:15:01 51.6V 2095W BulkMppt Prev: 51.3V 1848W BulkMppt
09/Jul/2013 12:35:02 50.8V 132W BulkMppt Prev: 57.8V 2372W Absorb
09/Jul/2013 14:55:00 50.1V 419W BulkMppt Prev: 50.9V 1002W BulkMppt
10/Jul/2013 16:55:01 50.0V 430W BulkMppt Prev: 50.4V 466W FloatMppt
11/Jul/2013 08:55:07 48.9V 0W Resting Prev: 49.0V 961W BulkMppt
11/Jul/2013 09:55:01 50.9V 1715W BulkMppt Prev: 50.6V 1168W BulkMppt
11/Jul/2013 11:55:01 51.4V 1961W BulkMppt Prev: 51.9V 2208W BulkMppt
12/Jul/2013 08:35:00 49.8V 0W Resting Prev: 50.2V 65W BulkMppt
12/Jul/2013 08:50:02 50.8V 1359W BulkMppt Prev: 50.8V 1285W BulkMppt
12/Jul/2013 09:10:00 50.4V 592W BulkMppt Prev: 50.1V 724W BulkMppt
12/Jul/2013 09:15:00 50.6V 365W BulkMppt Prev: 50.4V 592W BulkMppt
12/Jul/2013 13:25:02 50.0V 586W BulkMppt Prev: 49.7V 449W BulkMppt
12/Jul/2013 13:45:00 52.5V 1481W BulkMppt Prev: 50.5V 1008W BulkMppt
12/Jul/2013 13:50:00 52.7V 1870W BulkMppt Prev: 52.5V 1481W BulkMppt
13/Jul/2013 10:25:00 51.0V 1174W BulkMppt Prev: 50.5V 1064W BulkMppt
13/Jul/2013 10:30:00 53.7V 2570W BulkMppt Prev: 51.0V 1174W BulkMppt
13/Jul/2013 10:35:00 51.8V 1466W BulkMppt Prev: 53.7V 2570W BulkMppt
13/Jul/2013 13:10:02 49.6V 283W BulkMppt Prev: 49.5V 253W BulkMppt
13/Jul/2013 13:30:01 50.0V 662W BulkMppt Prev: 50.0V 522W BulkMppt
14/Jul/2013 13:25:02 47.8V 0W Resting Prev: 47.9V 182W BulkMppt
14/Jul/2013 15:55:01 51.7V 0W Resting Prev: 51.8V 51W BulkMppt
15/Jul/2013 12:35:00 48.8V 116W BulkMppt Prev: 48.8V 102W BulkMppt
16/Jul/2013 12:10:00 49.8V 989W BulkMppt Prev: 50.2V 975W BulkMppt
16/Jul/2013 13:50:00 48.7V 0W Resting Prev: 48.3V 24W BulkMppt
16/Jul/2013 15:00:01 48.7V 248W BulkMppt Prev: 48.5V 92W BulkMppt
16/Jul/2013 16:35:02 48.1V 53W BulkMppt Prev: 48.2V 72W BulkMppt
17/Jul/2013 09:05:00 49.9V 331W BulkMppt Prev: 50.6V 1041W BulkMppt
17/Jul/2013 09:10:01 49.7V 289W BulkMppt Prev: 49.9V 331W BulkMppt
17/Jul/2013 15:40:00 48.4V 43W BulkMppt Prev: 48.6V 175W BulkMppt
17/Jul/2013 16:25:02 48.1V 48W BulkMppt Prev: 48.2V 57W BulkMppt
18/Jul/2013 08:05:01 56.4V 490W BulkMppt Prev: 53.9V 37W BulkMppt
18/Jul/2013 09:00:01 49.4V 0W Resting Prev: 50.1V 412W BulkMppt
18/Jul/2013 11:25:02 57.6V 1954W Absorb Prev: 57.7V 1980W Absorb
18/Jul/2013 13:15:00 49.9V 517W BulkMppt Prev: 49.9V 444W BulkMppt
18/Jul/2013 13:20:01 50.7V 1463W BulkMppt Prev: 49.9V 517W BulkMppt
18/Jul/2013 15:20:02 49.7V 318W BulkMppt Prev: 50.1V 516W BulkMppt
19/Jul/2013 09:45:02 49.4V 372W BulkMppt Prev: 49.9V 350W BulkMppt
19/Jul/2013 10:25:00 50.0V 516W BulkMppt Prev: 50.4V 499W BulkMppt
19/Jul/2013 10:40:00 50.2V 549W BulkMppt Prev: 50.0V 542W BulkMppt
19/Jul/2013 12:25:00 50.7V 651W BulkMppt Prev: 51.2V 194W BulkMppt
19/Jul/2013 14:05:00 49.9V 0W Resting Prev: 50.6V 641W BulkMppt
19/Jul/2013 15:00:01 49.0V 226W BulkMppt Prev: 49.1V 177W BulkMppt
20/Jul/2013 11:15:01 57.6V 2570W Absorb Prev: 50.3V 342W BulkMppt
20/Jul/2013 15:20:00 49.2V 437W BulkMppt Prev: 49.2V 113W BulkMppt
22/Jul/2013 11:35:00 51.9V 167W BulkMppt Prev: 52.5V 94W BulkMppt
i have to chip in here because I am having the same issue I posted earlier that the machine goes into resting
/tracking but what it seems to be is that the kw/h keep resetting. today I had poor sunshine and was at 5kw/h
at 12 o clock and when I got home I was at 1.8kw/h
I do monitor my system from work using software that came with classic
Quote from: boB on August 13, 2013, 12:55:37 AM
Quote from: Wxboy on August 12, 2013, 07:58:44 PM
Confirmed 1370 4/8.
OK, that's new enough. Have you seen it do this since then ?
How often has it reset during the day that you know of ?
boB
It has not reset again since my post and this was the first time I've noticed it reset in months.
Quote from: robertd on August 13, 2013, 09:38:29 PM
i have to chip in here because I am having the same issue I posted earlier that the machine goes into resting
/tracking but what it seems to be is that the kw/h keep resetting. today I had poor sunshine and was at 5kw/h
at 12 o clock and when I got home I was at 1.8kw/h
I do monitor my system from work using software that came with classic
When the Classic reset, were the batteries full or close to being full ??
boB
Thought I would add my observations:
Just got my Midnite Classic 150 Lite installed a few days ago. It had a couple of resets yesterday in "Solar" mode, mid-day I switched to Legacy and today I've had at least 4(nice sunny day). I am static IP, and watching with the local app, and mymidnite. The "Daily values" KWh collected so far gets set to zero after the reset. I get "The Connection was Closed" & disconnected from the Local App and am able to instantly re-open it.
My "Lifetime values" do not seem to be updating properly as well.
Using MyMidnite.com "Energy" graph, I can see the resets in that "Energy Collected" will gradually go up, then you see 'mid-day' it go down to 0 and start going up again.
No firmware updates from 1181 it came with, though it seems those here who have updated are still having the resets, perhaps wait until the next-one which I would hope will resolve the issue?
later.
Again, I must ask, are your batteries full at all during the day when you see these resets ?
boB
Quote from: boB on August 19, 2013, 05:41:25 PM
Again, I must ask, are your batteries full at all during the day when you see these resets ?
For me, it resets all through the day(12.2V) on the way up to and including absorb(14.4) and float(13.3).
Had a few more resets today...
After a reset it forgets it was ever in/finished absorb and trys putting it in absorb for X hours/mins before going to float again.. So I force float manually in config.
Having the "Lite" I just have the first 2 jumpers set to custom, and configure Static IP and most everything else from Local App.
The first couple days I ran it stock(jumpered) 12v, dynamic IP etc, I only noticed it reset once, I suppose I should put it back and see how much more stable it is there.
Quote from: Onlooker on August 20, 2013, 01:16:49 PM
Quote from: boB on August 19, 2013, 05:41:25 PM
Again, I must ask, are your batteries full at all during the day when you see these resets ?
For me, it resets all through the day(12.2V) on the way up to and including absorb(14.4) and float(13.3).
Had a few more resets today...
After a reset it forgets it was ever in/finished absorb and trys putting it in absorb for X hours/mins before going to float again.. So I force float manually in config.
Having the "Lite" I just have the first 2 jumpers set to custom, and configure Static IP and most everything else from Local App.
The first couple days I ran it stock(jumpered) 12v, dynamic IP etc, I only noticed it reset once, I suppose I should put it back and see how much more stable it is there.
Dang ! OK, I was kind of hoping it was happening only when batteries were full.
I don't suppose you have ever noticed it reset while resting ? RossW seems to see that his only resets while running.
boB
Didn't touch/open "Local App" today, made no other changes... No detected resets for me today(vs 4+ each day previous couple of days).
Will have to test it a few more days, but looks like it has something to do with Local App interaction(when in custom config through local App, possibly). Static IP etc...
Quote from: Onlooker on August 21, 2013, 05:26:41 PM
Didn't touch/open "Local App" today, made no other changes... No detected resets for me today(vs 4+ each day previous couple of days).
Will have to test it a few more days, but looks like it has something to do with Local App interaction(when in custom config through local App, possibly). Static IP etc...
Well, it used to be related to the local app and/or connections to the Classic over the Ethernet but I thought
we had fixed that.
Yes, please let it go another day or two and let's see if that keeps it from resetting.
Thank you for doing that !
boB
Bob, please feel free to move this elsewhere if its more appropriate.
Tom (and at least one other forum member that I know of) has been having an issue where the classic communications just "stops". The classic still responds to ICMP echo-request (ping) packets, and is "listening" in as much as you can attempt to connect via TCP on the modbus port (502), however the classic refuses connections. When this happens, it appears the only way to recover is to reboot the classic.
It's been getting quite annoying for some.
Well, today I logged in on one of Tom's rPi's and wrote some simple code. (If anyone else wants to try this, let me know and I'll post it here). Basically, I set off a tcpdump which constantly monitored communications to/from one classic. A circular buffer holds the last couple of hundred lines of output. When this condition is detected (identified by the logging stopping), I write out the buffer to see what happened immediately before. (This is so I don't go wearing out his flash memory!)
Caught one just now.
It looks like everything was completely normal right up to the connection close, but the following attempt to connect failed. So I don't think it's my newmodbus - but happened after this reading and before the next.
Have the full packet contents if you want it, but here's the end of the last working poll and the start of the next.
192.168.2.88 is the rpi, .129 is the classic.
22:33:02.474832 b8:27:eb:32:ef:5f > 06:1f:d0:00:08:8f, ethertype IPv4 (0x0800), length 66: 192.168.2.88.40784 > 192.168.2.129.502: Flags [P.], seq 73:85, ack 459, win 14600, length 12
22:33:02.475738 06:1f:d0:00:08:8f > b8:27:eb:32:ef:5f, ethertype IPv4 (0x0800), length 163: 192.168.2.129.502 > 192.168.2.88.40784: Flags [P.], seq 459:568, ack 85, win 546, length 109
22:33:02.477794 b8:27:eb:32:ef:5f > 06:1f:d0:00:08:8f, ethertype IPv4 (0x0800), length 54: 192.168.2.88.40784 > 192.168.2.129.502: Flags [F.], seq 85, ack 568, win 14600, length 0
22:33:02.478527 06:1f:d0:00:08:8f > b8:27:eb:32:ef:5f, ethertype IPv4 (0x0800), length 60: 192.168.2.129.502 > 192.168.2.88.40784: Flags [F.], seq 568, ack 86, win 546, length 0
22:33:02.478660 b8:27:eb:32:ef:5f > 06:1f:d0:00:08:8f, ethertype IPv4 (0x0800), length 54: 192.168.2.88.40784 > 192.168.2.129.502: Flags [.], ack 569, win 14600, length 0
22:33:44.169613 06:1f:d0:00:08:8f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 60: 192.168.2.129.14177 > 255.255.255.255.4626: UDP, length 6
22:33:53.675032 06:1f:d0:00:08:8f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 60: 192.168.2.129.14178 > 255.255.255.255.4626: UDP, length 6
22:34:01.980791 b8:27:eb:32:ef:5f > 06:1f:d0:00:08:8f, ethertype IPv4 (0x0800), length 74: 192.168.2.88.40795 > 192.168.2.129.502: Flags [S], seq 897832033, win 14600, options [mss 1460,sackOK,TS val 75025465 ecr 0,nop,wscale 6], length 0
22:34:01.981958 06:1f:d0:00:08:8f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.2.88 tell 192.168.2.129, length 46
22:34:01.982043 b8:27:eb:32:ef:5f > 06:1f:d0:00:08:8f, ethertype ARP (0x0806), length 42: Reply 192.168.2.88 is-at b8:27:eb:32:ef:5f, length 28
22:34:02.981658 b8:27:eb:32:ef:5f > 06:1f:d0:00:08:8f, ethertype IPv4 (0x0800), length 74: 192.168.2.88.40795 > 192.168.2.129.502: Flags [S], seq 897832033, win 14600, options [mss 1460,sackOK,TS val 75025566 ecr 0,nop,wscale 6], length 0
22:34:02.982370 06:1f:d0:00:08:8f > b8:27:eb:32:ef:5f, ethertype IPv4 (0x0800), length 60: 192.168.2.129.502 > 192.168.2.88.40795: Flags [.], ack 897832034, win 546, length 0
22:34:03.680484 06:1f:d0:00:08:8f > b8:27:eb:32:ef:5f, ethertype IPv4 (0x0800), length 60: 192.168.2.129.502 > 192.168.2.88.40795: Flags [S.], seq 2111088, ack 897832034, win 546, options [mss 546], length 0
22:34:03.680671 b8:27:eb:32:ef:5f > 06:1f:d0:00:08:8f, ethertype IPv4 (0x0800), length 54: 192.168.2.88.40795 > 192.168.2.129.502: Flags [.], ack 1, win 14600, length 0
Hi,
I am seeing similar behavior here. I have four classic 250's running v1401. Two days ago at 1500 eastern one of them stopped talking to mymidnite. It continued to respond to the local status panel application. i rebooted it a few hours later and it started talking immediately to mymidnite.
Last might at 2330 another stopped talking to mymidnite. I haven't rebooted it yet. Sometime between last night at 2330 and this morning it also stopped responding to the local status panel application.
And the plot thickens....
This refusal to communicate is pesky but I am not sure it is the same fault that makes it reset? Seems most of us do a power cycle to recover and that obviously resets the Classic.
I have had mine blocked from communicating with mymidnite to see if it was part of the issue. It is not. I may start dumping via the USB port and see if that yields some clues.
Ross has mine under constant scrutiny so maybe a pattern will emerge.
Just my current observations.
Tom
My Midnite and other communications from the Ethernet port are different, I'm pretty sure, from
the resetting of the Classic itself.
Some of the My Midnite trouble bay be My Midnite itself or in the Classic or of course, both in
some way.
We are still working on the problem.
If the Local App quit communicating with the Classic, make sure the Classic itself is running
and charging batteries, which is its main function, but the communications is very important
too.
boB
Quote from: boB on August 26, 2013, 01:39:14 PM
If the Local App quit communicating with the Classic, make sure the Classic itself is running
and charging batteries, which is its main function, but the communications is very important
too.
boB
boB;
I don't want to cloud the waters but..
I seldom use the Local App but mine both seem to work just fine as controllers and seem to display correct KWH totals before the reboot required to recover communications . I will take a closer look when it happens again.
When I did use the L.A. the communication fault required a reboot to reconnect and of course the data resets. I never noticed it reset while the L.A. was able to communicate with the Classic?
Do people see the data reset with no L.A. connection issues? My logs do not seem to show data loss or resets other than from the recovery power cycle? If that makes sense?
Curiouser and curiouser.
Tom
I dont use my midnite, nor the local app, and currently running 1370. Just use newmodbus and related code. Here im pretty sure ive never seen a full spontaneous reset, and can verify that from the logs. And newmodbus was running perfectly on an intel 686 platform for some months. However trying to use it on an embedded arm board, results in the above pattern of closed ethernet port about once a day.
Most times newmodbus will timeout waiting for a response but other times the classic will refuse the connections. It will do this sporadically on and off for few hours, then finally closing completely. At that point the local app will not be able to connect if you try, either. The classic appears to continue to operate as normal, just if you want to talk to it, youll have to reboot it.
Its actually very very reminiscant of how the local app used to work with 1070.
Now im mindful that i have 10m of 5e betw the classic and switch. And that the insides of a charge controller is probably one of the noisiest environments known to man, so i will try adding another switch closer to the classic. And removing the cable tie restraint i have from the 5e to one of the power cables.
Why it works on one computer but not on the other is so far still a mystery to me. But i will say this, that battling the ethernet port on the classic is starting to wear me down. I NEED reliable data out of the thing. The combination of classic and arm board is to me the optimum solution from a power consumption point of view. If i need to add another switch, sigh, i can live with it. Its still less than the 20W from the intel fileserver, which runs, along with the wifi, during daylight hours / on demand only.
To rule out newmodbus, youll recall i have previously tried using phpmodbus and the python modbus library. All exhibit the same pattern.
Quote from: zoneblue on August 27, 2013, 05:28:12 PM
use newmodbus and related code. Here im pretty sure ive never seen a full spontaneous reset, and can verify that from the logs. And newmodbus was running perfectly on an intel 686 platform for some months. However trying to use it on an embedded arm board, results in the above pattern of closed ethernet port about once a day.
Quote
To rule out newmodbus, youll recall i have previously tried using phpmodbus and the python modbus library. All exhibit the same pattern.
Interesting.
Tom is having similar issues, and is running a raspberry pi.
He has compiled *exactly* the same source code that I have, yet I've never had loss of communications to my classic
I'm running newmodbus on a FreeBSD box (local home server), CPU is:
CPU: VIA Esther processor 1200MHz (1200.01-MHz 686-class CPU)
Origin = "CentaurHauls" Id = 0x6a9 Family = 6 Model = a Stepping = 9
The classic and several other ethernet devices are out in the battery room, connected (by choice - "air gap" isolation) a WRT54GL reflashed with DD-WRT. This gives me a local 5-port switch and wireless bridge in one convenient box, so all the physical ethernet cables there are standard 1.8 or 2m cables - not screened or specal, just cheap patch leads.
Perhaps newmodbus needs compiled with different compiler optimisations? Any suggestions?
Quote from: zoneblue on August 27, 2013, 05:28:12 PM
Why it works on one computer but not on the other is so far still a mystery to me. But i will say this, that battling the ethernet port on the classic is starting to wear me down. I NEED reliable data out of the thing. The combination of classic and arm board is to me the optimum solution from a power consumption point of view. If i need to add another switch, sigh, i can live with it. Its still less than the 20W from the intel fileserver, which runs, along with the wifi, during daylight hours / on demand only.
To rule out newmodbus, youll recall i have previously tried using phpmodbus and the python modbus library. All exhibit the same pattern.
Zone;
Well, that kind of makes me wonder.
Guess I will put another X86 computer online, disable the PI logging and see if I can get steady data with that a few days.
Color me confused. I guess "standards" are not. Anyway, interesting angle Iwas touching on in my quest for what is going on.
And, I agree, battling this issue has gotten on my last nerve.
More info if / when I find it.
I see I sat on this a bit too long and Ross chimed in but here it is anyway
Tom
Putting this all in context, i am close to a "proof of concept" release of come code for "the black box" project. Ive basically taken the quick and dirty php i initially coded, that was necessarily tailored to the handful of registers that interested me, and refactored it to be web ui configurable. So you can choose which datapoints to show on what part of the screen, what size and style, and which graphs to show, size, series datapoint(s), color, etc. Another week or 2 til theres something to see.
Ross. the x86 box that works is an intel atom dual core. When i said that the coms issues occured with phpmodbus as well, that was with 1070 and the atom. I havent tried python modbus on the cubie, but sounds like i ought to. I also need to try 1549 , but i gather there is another coming, so will wait for that. Hours in the day.
Just put a Classic 150 in service a week ago. Like others, it resets about noon. Not sure about other times as I am prepping for winter and not around the equipment during the day.
I did the basic programing and let it go. There is a date somewhere in the menu of 12-01-12 but just going off memory. Was just getting ready to find the latest firmware, thinking that must be it but not sure now? Not running any networking or apps, just the 150 hooked up doing its thing. Guess I will watch this thread?
Rick
Rick
If it is resetting around noon my money is the clock is set incorrectly. The Classic uses military time or 24hr clock. This has gotten me many times. I would check and see if the Clock is set wrong.
Ryan
The Classic won't do a hard reset once a day (midnight) unless the A-RST or Auto Restart is turned on
in Tweaks. However, at midnight, every day, (or what the Classic thinks is midnight 23:59) it will
zero out the daily kW-Hours, add it into the Life-Time kW-Hours and start a new bulk cycle in
preparation for the next day.
Also, if for some reason the "Time Synch" gets turned OFF in Tweaks, the MNGP will stop
setting the time in the Classic itself. This Tweak is usually on unless turned off though
but might be worth a check.
boB
OK Ryan, I feel like a real dummy. I did indeed have the clock set wrong. My bad.
Glad you mentioned the Time Synch, boB. I'm trying to understand the Classic. After coming from 8 years with the MX60 I'm feeling my way around the Classic. Gotta learn these things because I have several more of the 150's to install!
Thanks for your quick response gent's. By the way, the firmware update instructions are right-on, appreciate the detailed instructions.
Rick
Quote from: RickW on September 01, 2013, 01:53:51 AM
OK Ryan, I feel like a real dummy. I did indeed have the clock set wrong. My bad.
Glad you mentioned the Time Synch, boB. I'm trying to understand the Classic. After coming from 8 years with the MX60 I'm feeling my way around the Classic. Gotta learn these things because I have several more of the 150's to install!
Thanks for your quick response gent's. By the way, the firmware update instructions are right-on, appreciate the detailed instructions.
Rick
Excellent, Rick ! Glad you got it going OK.
The old MX60 is a good controller, too.
boB
Just as another data point I have been running 1370 firmware on the classic for some time along with Local App V0.3.27 with Web Access Disabled and have not come across any in day resets. I do an Auto Reset at midnight for what it is worth. Classic is networked through a RadioLabs USB Wifi Router Repeater - WiJacker with a CaptiFi USB WiFi antenna from RadioLabs.
Just as an interesting aside, on a lite,auto reset doesnt really work, or works rather interestingly.
Im using it at the moment to resolve a closed ethernet port issue, but becasue the lite doesnt have a RTC, its tricky to get it to restart at midnite. Nominally it appears to reboot at 00:00:00 but im not sure what happens but it seems to end up rebooting both morning and evening all sorts of odd times. I havent figured the pattern out yet, but am monitoring it.
We are supposed to have a local app soon that allows you to set the time/date on
the Classic.
Guess it didn't quite make the latest one though. Maybe next one ?
Thanks for the info ! Still working on this.
boB
Bob:
I updated soon after 1401 was made available for the Classic. Since then I have had no resets! (not including the A-RST = on midnight resets)! Great job!!!!
Other than moving (temporarily to a worse solar aspect ~0.3 kWh per day, and now to a much better one than previously, ~3 kWh per day ), there have been no significant changes to my hardware setup/situation.
I have not used the local app much during this time, preferring not to run my PC around the clock to log the data (which also goes against the grain since the data is already logged internally in the Classic, so any good local app should be able to access that, which the current one does not).
Also in the time I've been using 1401, I have not saturated my Internet connection with other traffic, a situation previously reported to you as causing resets.
FYI, my generation for the past week (1st week of Sept 2013) is as follows:
Date Energy Peak Power
2 Mon 2.5 kWh 1095 W (= 94% of array rating).
3 Tue 3.0 kWh 923 W
4 Wed 1.9 kWh 1071 W
5 Thu 1.0 kWh 201 W
6 Fri 0.7 kWh 262 W
7 Sat 2.9 kWh 794 W
BTW, is the absence of resets in 1401 an accident, or was a specific bug identified and fixed?
Right now I am very happy with performance of my system. The only thing on my current wish list is remote access of the Classic's internally logged data from any browser. ;-)
Al
aj4rf
QuoteThe only thing on my current wish list is remote access of the Classic's internally logged data from any browser. ;-)
Well theres mymidnite. Soon there will be the blackbox project as well. Its a tiny computer that can talk to the classic, and do far more extensive logging than the classic alone can do, owing to its finite memory. Draws a little over 1W, and can store a whole lifetime of realttime data. Watch this space. Another week or so maybe.
Quote from: aroxburgh on September 08, 2013, 07:07:00 PM
Bob:
I updated soon after 1401 was made available for the Classic. Since then I have had no resets! (not including the A-RST = on midnight resets)! Great job!!!!
.... .... ....
BTW, is the absence of resets in 1401 an accident, or was a specific bug identified and fixed?
Al
aj4rf
Ahhh... Wonderful !
No, not an accident. At least I hope not. We've been working on that resetting for a while now and have implemented various fixes
in more than one release. It's getting better and better.
Thank you for the input ! MUCH appreciated !
Still lots to do ! Some addressing your other wants and needs.
boB
Hi,
I've noticed 4 resets over the last 2 weeks.
Firmware:
- Classic Rev: 1549
- Network Rev: 1547
- MGNP Rev: 1552
dRdoS7
There is always a chance the resets are hardware. If you want to PM or Email me I am happy to work on that side of it as well
ryan@midnitesolar.com
I had resets quite regularly for a long time.
Happy to say, my last known reset was a couple months ago. Before that it was every couple of days.
May have been self healing resets I am unaware of but I would have seen the missing data.
Just FYI
Tom
Yeah I think we have had a "Few" hardware resets if you will. Software wise I think we have it nailed. Still waiting for a report from Ross on his new one.
Ryan
Yes, I know there have been no posts on this thread for many months, and it's been a similarly long time since I was on the forum. In the interim I've been generating a lot of PV power. But just wanted to share that I have had no resets in what seems like about a year! AFAIAC you guys certainly nailed it! :-)
Cheers,
Al
P.S. At the end of May in Portland, Oregon, sunny days give me up to 4.8 kWh from my 1.2 kW array.
I forgot to mention that I've left my system "as is" for so long that it is still on:
1370 4/13/13 MNGP
1401 6/8/13 Classic
Quote from: aroxburgh on May 29, 2014, 01:44:19 AM
I forgot to mention that I've left my system "as is" for so long that it is still on:
1370 4/13/13 MNGP
1401 6/8/13 Classic
Thank you for the information.
We have also noticed BTW that the Ethernet communications drops have dropped significantly with 1849....
(knock on wood)