More robust ethernet communication

[boB]

Good news, sorta...  Andrew has duplicated the problem and knows what is happening.

It's a packet memory re-allocation problem.  When this happens, the Classic can not fill
the requested packet with data but it can ping, etc. since that doesn't require packet memory.

So, we are well on our way to finally getting this fixed.  Not sure exactly when but this
is the highest priority at the moment so sooner rather than later I expect.

boB

boB, is this going to fix just the disconnects we have been seeing or is it going to fix the reset/reboot issue Kurt showed in his video also?

Not exactly sure about reboots.  This is mainly for the problem of disconnects.  Reboots kind of fix the disconnect problems
by rebooting but you don't want rebooting either.  We want to eliminate all reasons for rebooting the classic, either automatically
or manually.

Try doing THAT with Microsoft windoze !

boB

[2twisty]

Dangit, boB, where's the LIKE button when you need it!

[Resthome]

I think this thread has brought up at least three different issues that relate to data logging. Here is what I have heard in this thread and experienced myself.

1.   The OP had brought up the issue when the Classic Ethernet disconnects and you can not        reestablish the connection with the LA or MyMidNite without rebooting/resetting the Classic. While Auto-Reset may reestablish the connection after mid night, downloadable data is lost.
2.   Disconnects that occur with the LA that with manual intervention can be reestablish.
3.   The non initialed in day reboot/reset (Watchdog timer resets) that lose daily downloadable data and Lifetime accumulate data.

It sounds like there maybe a fix coming for #1. Not sure if the fix will address #2. And #3 is not part of this ethernet disconnect fix.

I consider the Classic a process computing device that needs to dependable and reliable. I don’t classify it as a home/business computing device therefore I don’t compare the Classic to a Windows device.

MidNite is a great company that offers excellent support. I look forward to having MidNite resolve these three issue that effect accurate recording and downloading of the Classic data.

[boB]

Dangit, boB, where's the LIKE button when you need it!

I have wanted to do that several times here !

[boB]

I think this thread has brought up at least three different issues that relate to data logging. Here is what I have heard in this thread and experienced myself.

1.   The OP had brought up the issue when the Classic Ethernet disconnects and you can not        reestablish the connection with the LA or MyMidNite without rebooting/resetting the Classic. While Auto-Reset may reestablish the connection after mid night, downloadable data is lost.
2.   Disconnects that occur with the LA that with manual intervention can be reestablish.
3.   The non initialed in day reboot/reset (Watchdog timer resets) that lose daily downloadable data and Lifetime accumulate data.

It sounds like there maybe a fix coming for #1. Not sure if the fix will address #2. And #3 is not part of this ethernet disconnect fix.

I consider the Classic a process computing device that needs to dependable and reliable. I don’t classify it as a home/business computing device therefore I don’t compare the Classic to a Windows device.

MidNite is a great company that offers excellent support. I look forward to having MidNite resolve these three issue that effect accurate recording and downloading of the Classic data.

#1...  If it gets fixed by auto-restarting at midnight, then that days' logs (downloadable data) will still be available because
auto-restart/reset saves the data first.   If you manually reset or it resets somehow during the day then right, the data
won't save to EEprom.

#2.  Depends on what is meant by manual intervention.  If it is manual reset of the Classic, then that would be like #1 manual reset.

#3.  During the day reboot/reset (WDT) is sort of understood, in that we know a scenario or two where this watchdog reset can happen
when two computers (2 MNGPs or MNGP and Local App), access a lot of EEprom, like daily or minutely logs at the same time.  That one is easily understood.

But what about other WDT issues that are from something else ?   Well, I/We have not seen this happen lately, BUT, there is
a debug method that was put into place in the Classic to save some of the states and information after one of these WDT
resets.  In the Local App, it is shown in the "info" screen (I think) under Debug05 I think it is.  After a reset during the day,
this number should be noted so we can figure out what happened.  The more of those informational numbers we have,
the closer we will be to a fix for that.  This number is also accessible by reading a modbus register but the LA is easy.
Also, remember that in the "secret screen" on the MNGP you can tell if the Classic did a WDT reset by going to the
secret screen (as I call it) from main status and looking at the RFR or Reason For Resting.  At normal boot up it will
be 111 but WDT it will show  104  at the top middle of the LCD.

boB

[zoneblue]

Which regisister/address is debug5?

#3.  During the day reboot/reset (WDT) is sort of understood, in that we know a scenario or two where this watchdog reset can happen when two computers (2 MNGPs or MNGP and Local App), access a lot of EEprom, like daily or minutely logs at the same time.  That one is easily understood.

But what about other WDT issues that are from something else ?   Well, I/We have not seen this happen lately, BUT, there is a debug method that was put into place in the Classic to save some of the states and information after one of these WDT resets.  In the Local App, it is shown in the "info" screen (I think) under Debug05 I think it is.  After a reset during the day, this number should be noted so we can figure out what happened.  The more of those informational numbers we have, the closer we will be to a fix for that.  This number is also accessible by reading a modbus register but the LA is easy.

[RossW]

Which regisister/address is debug5?

wdt=`grep "^4131 " classicdata | /usr/local/bin/gawk '{print and($2, 128)}'`
if [ $wdt -eq 128 ]; then
        mail -s "Midnight watchdog reset $$" rossw@*obfuscated.com* < classicdata
        # and now clear the reset flag.
        ./newmodbus  `cat classic.addr` 4131=12800
fi

[boB]

Which regisister/address is debug5?

wdt=`grep "^4131 " classicdata | /usr/local/bin/gawk '{print and($2, 128)}'`
if [ $wdt -eq 128 ]; then
        mail -s "Midnight watchdog reset $$" rossw@*obfuscated.com* < classicdata
        # and now clear the reset flag.
        ./newmodbus  `cat classic.addr` 4131=12800
fi

The last LR register contents before the WDT reset are in kept in these two modbus register addresses...

4386    DabtU32Debug05        (low 16 bits)

4387    DabtU32Debug05 +2  (high 16 bits)

These values will read the last LR registers' contents right after the Classic reboots from the WDT.

boB

[Resthome]

#2.  Depends on what is meant by manual intervention.  If it is manual reset of the Classic, then that would be like #1 manual reset.

No it would be more like closing the LA and then restart the LA. Some folks have said they may restart Windows. Then the connection is reestablished.

#3.  During the day reboot/reset (WDT) is sort of understood, in that we know a scenario or two where this watchdog reset can happen when two computers (2 MNGPs or MNGP and Local App), access a lot of EEprom, like daily or minutely logs at the same time.  That one is easily understood.

But what about other WDT issues that are from something else ?   Well, I/We have not seen this happen lately.

boB .. Does not sound like you noticed one of these reset in the video Kurt posted earlier in this thread using the Android app. So the resets are not just with the LA. I’m glad you brought up posting the debug info, so more people are aware of it and will report that info but they would have to be using the LA. If I remember correctly they show all zero when things are working fine.

https://m.youtube.com/watch?v=2DokCstXyQY

[offgridQLD]

Are we talking about this (debug info?) below from the info tab of the local app on both classics.

From my shed classic
DB1: 0x-604b092d
DB2: 0x110d244b
DB3: 0x3a18e3a9
DB4: 0x3a18e3a9
DB5: 0x0

From my house classic
DB1: 0x30b2e0c0
DB2: 0x-5070000
DB3: 0x43d04000
DB4: 0xdfa000
DB5: 0x0

Kurt

[boB]

Are we talking about this (debug info?) below from the info tab of the local app on both classics.

From my shed classic
DB1: 0x-604b092d
DB2: 0x110d244b
DB3: 0x3a18e3a9
DB4: 0x3a18e3a9
DB5: 0x0

From my house classic
DB1: 0x30b2e0c0
DB2: 0x-5070000
DB3: 0x43d04000
DB4: 0xdfa000
DB5: 0x0

Kurt

Yes....  And they are 0x0 so either no WDT reset or very old code

[zoneblue]

My local app also says 0x0, appears to always have done so. However the last reboot was a WDT reboot, 5 days ago.

peter@cubie:$ ./newmodbus 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 20:23:14  08/01/2003
4380 10 (0xA)
4381 378 (0x17A)
4382 57 (0x39)
4383 0 (0x0)
4384 0 (0x0)
4385 576 (0x240)
4386 193 (0xC1)
4387 31720 (0x7BE8)
4388 2 (0x2)
4389 0 (0x0)
4390 64599 (0xFC57)

[boB]

My local app also says 0x0, appears to always have done so. However the last reboot was a WDT reboot, 5 days ago.

peter@cubie:$ ./newmodbus 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 20:23:14  08/01/2003
4380 10 (0xA)
4381 378 (0x17A)
4382 57 (0x39)
4383 0 (0x0)
4384 0 (0x0)
4385 576 (0x240)
4386 193 (0xC1)
4387 31720 (0x7BE8)
4388 2 (0x2)
4389 0 (0x0)
4390 64599 (0xFC57)

That should be it !   Are these addresses or register numbers ?

What version of software too ?

boB

[offgridQLD]

For me it's.....

classic Firmware:     
- Classic Rev: 1849
- Network Rev: 1839

Local app Version 0.3.61

Kurt

[zoneblue]

Im also 1849. Latest local app. Newmodbus uses registers, ie starting at 4101.

My local app also says 0x0, appears to always have done so. However the last reboot was a WDT reboot, 5 days ago.

peter@cubie:$ ./newmodbus 192.168.0.223 4380-4390
ID CLASSIC
ClassicTime 20:23:14  08/01/2003
4380 10 (0xA)
4381 378 (0x17A)
4382 57 (0x39)
4383 0 (0x0)
4384 0 (0x0)
4385 576 (0x240)
4386 193 (0xC1)
4387 31720 (0x7BE8)
4388 2 (0x2)
4389 0 (0x0)
4390 64599 (0xFC57)

That should be it !   Are these addresses or register numbers ?

What version of software too ?

boB