Local app problems on day 2

[ChrisOlson]

Really strange - I can telnet to one of the controllers that's offline on port 502 and it responds.  I'm not sure if the Classic has telnet capability but when I telnet to the solar controller (that's running on port 503 and working normally with the Local App) it comes up with the same response - "Press any key to continue".

So the networking adapter in the controller that is offline with the Local App is working and the port is open and communicating.  Just that it won't talk to the Local App.
--
Chris

[ChrisOlson]

I have decided that something had to have gotten corrupted during the update of two of my controllers.  It's impossible to have one that works flawlessly if there's something wrong in the code.

So I deleted everything on my computer (including the Status Panel .com folder in Application Data in my user account), redownloaded the firmware updat and status panel installer, and am going to re-install everything on both of the controllers I've been having problems with.

Hopefully it will fix the problem.  I got to thinking about this and I had updated the Solar controller (which has continued to work with no problems) first, and didn't do the two turbine controllers until a day later because both turbines were running at the time.  With the SNAFU with my com port, something may have gotten screwed up.
--
Chris

[boB]

I have decided that something had to have gotten corrupted during the update of two of my controllers.  It's impossible to have one that works flawlessly if there's something wrong in the code.

If this is the case, and of course it can be, I would suspect the PC side if anything.

If it's XP, the directory where the settings and things are stored is in the Documents and Settings ---  USER---
Local Applications directory I think.

On my new windoze 7 system it is here...

C:\Users\boBWin7\AppData\Roaming\com.midnitesolar.LocalStatusPanel\Local Store

You can just delete that directory which I have done in the past.  I don't understand
how it would cause things to disconnect after a while though.

I would be surprised if it is in the Classic but you could try updating it too.

boB

[ChrisOlson]

boB, I think it just has to be.  I've worked with computers and computerized systems long enough to know that you cannot have one unit operate flawlessly, and two that don't, all under the same conditions, and have something wrong in the code.  I hate to have Andrew looking for something that's not wrong.

So I just updated both of those controllers again, plus the MNGP on both, deleted everything on my computer, including all the registry entries that remain, and re-installed it.  And I'll see what happens.  It's all working perfectly again right now after I re-did all of it.

With the com port issue I had I think I re-booted both of those controllers too fast and too many times trying to get it to work.  Something may have gotten corrupted in the controllers doing that too.  I think that because both of them, when rotating their logs, ended up with invalid dates on some of the days.  The solar controller that has been working fine hasn't done that.  I attached an example from one of them, and this is really weird because it logged .5 kWh on Day 23 on 2/22/2094 - and Day 22 shows as Invalid.  The turbine was not even running on those days.  It was off the tower for three days because I put up a new tower and moved the machine to the new tower.  The controller was not powered down during that time frame, although the DC input breaker was shut off while I re-wired the service from the new tower.  And this is what it stored in its logs.

That indicates to me that I screwed something up in the firmware updates on those units.
--
Chris

[boB]

That indicates to me that I screwed something up in the firmware updates on those units.
--
Chris

OK, we'll see.   But, I DO see weird time/date stuff once in a while and so that may (or may not)  be
a real problem.  When you turn on the Classic/MNGP main battery switch, remember that the MNGP
sends the time/date to the Classic itself every minute or so.

Maybe the Classic tried to log while either the MNGP was sending data (highly unlikely) OR maybe before
the MNGP had sent the time/date info to the Classic for the first time after power up (Classic starts up
at year 2000 or 2003 I think it is), but I thought I remembered the Classic as not being able to log
until after the time/date had been set.

Also, realize that inside the MNGP code, it will sometimes increment/decrement the day number (the day
index) and the actual logging day may not inc/dec.   That is something I need to look into, but the date/time
can pretty much be trusted.  The index day number is there in addition to the time/date to tell where in
the 380 day or data point log you are at.  But it should coincide !
   It may be that you incremented the day index but it was trying to go to a day that had not  been filled yet ?
I must admit that there have been some reports of bogus or double/redundant logging days which I have yet
to figure out but at least the time/date is usually there and not invalid.

Thanks for keeping us posted.

boB

[ChrisOlson]

Thanks boB.  It's possible I'm wrong.  But I felt, knowing what I did, that I should at least try a clean install of everything to rule out a corruption in the code caused by improper re-booting.  I'm pretty sure that if you take a regular computer and just flip the switch on and off several times while it's booting up it's going to come up with something pretty bad in short order with corrupted files on the boot section of the disc.  That's basically what I did with those two controllers when I had a com port conflict.   

I know on at least one of them I got too eager and flipped off the breaker before I got the message in the command window "Successfully Updated".  It was at 100% but if you wait for a bit you get that message and THEN you reboot it.  It can take 10-15 seconds for that message to appear, and maybe other folks have gotten too impatient and done the same thing, so they're having problems too.

I'll know in a couple days if it "fixed" it.   
--
Chris

[boB]

I know on at least one of them I got too eager and flipped off the breaker before I got the message in the command window "Successfully Updated".  It was at 100% but if you wait for a bit you get that message and THEN you reboot it.  It can take 10-15 seconds for that message to appear, and maybe other folks have gotten too impatient and done the same thing, so they're having problems too.

I'll know in a couple days if it "fixed" it.   
--
Chris

Maybe it's kinda like wondoze applications where it counts up to 100% but it's obviously still doing "something".

I could add a wait countdown timer after the 100% done shows up in the update application.

boB

[Lya72]

Hi Bob,

I agree with the latest remark.

If you don't read the manual with a lot of attention, when you see in the update window, the 100% done information, you think that the update is finished.

You must wait one minute after, to have this window automatically closed!

Yann

[ChrisOlson]

Guys, I think it's been over 48 hours since I re-updated the controllers that were having a problem.  I have not had a problem since, with either of them.

It was not the Local Application.  It was the controllers.  The reason I know it was not the Local Application is because I only replaced that in one computer and left it in the other one.  The controllers have been communicating fine with the Local Status Panel ever since, on both computers.  This is the longest those controllers have stayed communicating with it since the original update.

So I'm going to guess by not waiting for that final message and flipping the breaker off as soon as it says 100% screws something up.  The controller still works, but it can have problems.

I don't think there's anything wrong with Andrew's code.  It was my own screwup.
--
Chris

[boB]

Guys, I think it's been over 48 hours since I re-updated the controllers that were having a problem.  I have not had a problem since, with either of them.

It was not the Local Application.  It was the controllers.  The reason I know it was not the Local Application is because I only replaced that in one computer and left it in the other one.  The controllers have been communicating fine with the Local Status Panel ever since, on both computers.  This is the longest those controllers have stayed communicating with it since the original update.

So I'm going to guess by not waiting for that final message and flipping the breaker off as soon as it says 100% screws something up.  The controller still works, but it can have problems.

I don't think there's anything wrong with Andrew's code.  It was my own screwup.
--
Chris

OK, thanks Chris !!  Very interesting !

  I will take a look at the update code and see if I can make that work a bit better.  I can change the message ending to
make it say whatever it needs to say at the proper time to get things to work more consistently for you and others.

boB

[ChrisOlson]

Well, the real test is time.  It's been a week and not a single problem with it.

So I can only conclude that my problem with communications with the Local App was being caused by a corrupted firmware update in the controller - caused by me.  I'm sure that what I did was to flip off the breaker to power the controller down before I got that message in the command window that says it was successfully updated.
--
Chris