Hey All -
I have been working on connecting to a Classic 150 for a preserve to be able to display the data. I first used the newmodbus utility via LAN and a raspberry pi with internet access disabled on the Classic 150. That worked for about 2 weeks and then the classic stopped responding. The only way to fix it was to power cycle the Classic 150. Figuring it was a local network issue I put together a RS-232/RJ-11 cable and connected to the modbus port on the Classic 150 and read the holding registers directly with the Pi and Python libraries. That worked perfectly for about 10 days. Now the charger is not responding again and I'm really not sure what the issue is... anyone ever run into anything like this?
And I have midnight reset turned ON, but it doesn't seem to do anything once the classic 150 goes into this failed state.
What version of the firmware is it ?
Did you ever try to see your data on Mymidnite website ?
Quote from: ClassicCrazy on August 16, 2015, 03:11:59 PM
What version of the firmware is it ?
Did you ever try to see your data on Mymidnite website ?
According to the MyMidnite website it is:
FW Revision: 1849
It's a pretty remote property but I can definitely update the firmware next time I'm out there.
We did originally try to see the data on the MyMidnite website and it's a similar issue, it works for a while then falls offline. The internet is really bad satellite internet, so the latency is about 1 second.
I think some of the firmware updates may have resolved some of the problems you are having - worth updating to find out anyway.
Larry
Quote from: ClassicCrazy on August 16, 2015, 04:01:08 PM
I think some of the firmware updates may have resolved some of the problems you are having - worth updating to find out anyway.
Larry
OK, I will try that. My next step is going to be to put a microcontroller controlled relay between the Charger and the panels/battery bank. That way if the RPi doesn't get a response it can trip the relays and remotely reset it. I'd rather solve it in software than with something like though.
Yikes, yes looks like my firmware version (1849) is quite a bit older than the current 2054.
Guess I am out of date too. I didn't know about that newest 2054 update - not sure if it was ever announced on the forums . Next time I am out I will update my system too !
Larry
1849 should be ok. There are a long standing bug in the ethernet stack, for which a fix is promised, actually about to be released anyday.
I currently have a fairly stable setup using a daemon version of newmodbus, it maintains a single open RTU connection. When and if the classic reboots, the daemon opens a new connection. This arrangement is stable in that it never refuses a connection, however i do get more frequent watchdog reboots. What doesnt presently work for any one for any period is open, read and close. If you do this regularly, the controller network stack will stop responding after anywhere from hours to days. On the other hand people have been using rs232, and havent had issues.
1849 dicusssion here http://midnitesolar.com/Forum/index.php?topic=1814.5
The april alpha for network fixes http://midnitesolar.com/Forum/index.php?topic=2364.0
Quote from: zoneblue on August 16, 2015, 04:44:31 PM
1849 should be ok. There are a long standing bug in the ethernet stack, for which a fix is promised, actually about to be released anyday.
I currently have a fairly stable setup using a daemon version of newmodbus, it maintains a single open RTU connection. When and if the classic reboots, the daemon opens a new connection. This arrangement is stable in that it never refuses a connection, however i do get more frequent watchdog reboots. What doesnt presently work for any one for any period is open, read and close. If you do this regularly, the controller network stack will stop responding after anywhere from hours to days. On the other hand people have been using rs232, and havent had issues.
1849 dicusssion here http://midnitesolar.com/Forum/index.php?topic=1814.5
The april alpha for network fixes http://midnitesolar.com/Forum/index.php?topic=2364.0
My setup is completely RS-232 at this point. I don't even have the ethernet cable plugged into the Classic 150 anymore. I guess there is a remote possibility that someone went into the battery box and knocked my cable loose, but I really liked the firmware answer as that's easy to fix. ;D I'll check things out on Tuesday and update the firmware.
My RS-232 code is basically:
#!/usr/bin/python
import minimalmodbus
midnite = minimalmodbus.Instrument('/dev/ttyAMA0', 10) # port name, slave addr
# Read Batt Voltage
try:
print(mindnite.read_register(4114))
except IOError:
print("Failed to read from midnite")
# Read PV Term V
try:
print(mindnite.read_register(4115))
except IOError:
print("Failed to read from midnite")
And so on for each register of interest
Apparently we are waiting for the new MY Midnite web site to come on line before we see the firmware that is suppose to fix the network issues.
An no there was no announcement of the new firmware but there has been a lot of discussion on 2050 and 2054. They was a bug with 2050 and winXP installs. boB suggested using 2054 which was not on the web site it may be there now.
Looks like 2054'is there now
Quote from: TeslasPigeons on August 16, 2015, 05:39:37 PM
My setup is completely RS-232 at this point. I don't even have the ethernet cable plugged into the Classic 150 anymore. I guess there is a remote possibility that someone went into the battery box and knocked my cable loose, but I really liked the firmware answer as that's easy to fix. ;D I'll check things out on Tuesday and update the firmware.
1849 is very stable when reading serial port modbus registers.
I have had one Classic 150, in the #6100 range, with 1849/1839 firmware running a simple webserver on an UNO since March 5th this year. It reads a block of registers once a second from rs232 port and updates a web page.
No ethernet connected to Classic.
Has not failed or reset or hung up in any way.
I could never get my Rpi mod B to run any more than about 3 weeks before something crapped out. It just did not seem stable using ethernet.
If you are trying to do a log file download from the Classic via serial port then the Classic can go dead, there seems to be a known bug when two devices try to access the log file - this may be in the 2054 fix list.
dgd
Quote from: dgd on August 16, 2015, 07:47:12 PM
1849 is very stable when reading serial port modbus registers.
I have had one Classic 150, in the #6100 range, with 1849/1839 firmware running a simple webserver on an UNO since March 5th this year. It reads a block of registers once a second from rs232 port and updates a web page.
No ethernet connected to Classic.
Has not failed or reset or hung up in any way.
Yes it is rather puzzling to me. It seems it's failing in the same way as when I was using ethernet, but it's hard to diagnose without some kind of more specific error than the device simply not responding to my modbus commands.
Quote from: dgd on August 16, 2015, 07:47:12 PM
I could never get my Rpi mod B to run any more than about 3 weeks before something crapped out. It just did not seem stable using ethernet.
I agree, I know RossW has had success with it, but I went away from it for two reasons: the network there is really bad so I wanted to isolate the system away from it and since I didn't write the newmodbus utility it made it difficult to troubleshoot when it stopped working. The RPi still runs the rest of the script that is controlling an IP camera and databasing some other data things connected to the network, so it's not the RPi losing connection.
Quote from: dgd on August 16, 2015, 07:47:12 PM
If you are trying to do a log file download from the Classic via serial port then the Classic can go dead, there seems to be a known bug when two devices try to access the log file - this may be in the 2054 fix list.
I am polling the holding registers directly using the modbus protocol through the serial port, however... the way it is failing the same as with ethernet makes me think something else is going on.
So you are not actually sure if the Classic is not responding or the rPi is misbehaving?
The rs232 shield I use has RX and TX LEDs so its easy to see if the Classic is responding. TX when Arduino requests data snd RX when Classic sends data. No RX=dead Classic, no TX=Arduino stuffed.
Since your rPi has a script thats doing other things it could be just the part of the script dealing with serial modbus that is crook. Do you have rx and tx serial port leds?
I have seen some code someone sent me for a modbus serial port reader. It went about a week then stopped.
It turned out to be memory problem with aan array that just kept growing
dgd
Quote from: dgd on August 17, 2015, 02:17:51 AM
So you are not actually sure if the Classic is not responding or the rPi is misbehaving?
I don't
believe the rpi is misbehaving. I can remotely reboot it and the problem still persists. I have another rpi at my house that runs my weather station and its serial port has never given me any issues. With that said, I cannot
prove it is not the rpi as its at a remote location and all I can do is SSH into the device. Previously with the ethernet issue, rebooting the rpi did nothing, but rebooting the classic (temporarily) solved the issue... so it seems like the classic is falling into some kind of fault mode. I just don't understand how the ethernet and modbus issues are related.
Quote from: dgd on August 17, 2015, 02:17:51 AM
It turned out to be memory problem with aan array that just kept growing
I don't think that's the case here. I am not saving the data on the rpi. I am creating a text file, using a shell script to read and database the text file and then deleting the text file. Rebooting the rpi would clear out the RAM and I can do that with no resolution. I am using the same method for another script I am running and it is still running successfully. However, the classic is the only thing connected to the UART port of the rpi.
It could be that the rpi goes haywire and sends a signal that violates the modbus protocol and trips the classic 150. So I guess what I am really trying to figure out is how to find out what kind of error state the classic is in. I couldn't see anything specific in the datasheet.
Its probably the Classic then.
However, I would use an rs232 breakout box with activity leds just to be sure its the Classic not responding.
Or you could just add two leds to the ttl side of the port with resistors. Something like in this circuit:
https://arduinodiy.wordpress.com/2012/03/19/serial-connection-for-your-arduino-atmega/ (https://arduinodiy.wordpress.com/2012/03/19/serial-connection-for-your-arduino-atmega/)
dgd
Another thought is the python modbus module, when i tried is very slow, at least compared to a custom rolled solution. The reason Ross's newmodbus works for him is his sample rate is 5mins. Its only when you go faster than that when issues arise. It also seemed to make a difference how fast the computer was.... timing, memory who knows. My intel atom worked better than the cubie at the same sample rate. Fingers crossed for the next firmware.
Dgd, still curious to know if you close your serial connection each second, or keep it open.
The serial port stays open all of the time, I don't actually know how it could be opened/closed.
I can't see an issue with the various Classics I use when reading registers every second.
With the rPi and Classic is the Classic still working (battery charging) when the data comms over serial port is no longer working?
Also try the other serial port on the Classic and see if the problem persists.
dgd
Quote from: dgd on August 17, 2015, 11:39:16 PM
With the rPi and Classic is the Classic still working (battery charging) when the data comms over serial port is no longer working?
I believe the charging is still working. There isn't much of a load on the batteries but it appeared they were full when I went to reset everything. I went through all the menus and one thing I did notice is before I reset the Classic 150 in the menu section that has MODE, TIME and SENSTVY ours was at:
MODE: 0
TIME: 0
SENSTVY: 00
and below it says ARC FAULT MODE NORMALLY = 1
After I reset it this same menu said:
MODE: 1
TIME: 4
SENSTVY: 10
So I'm not sure what that means... I couldn't quite find the section about it in the datasheet.
I updated the new firmware so I guess I'll see how long it stays online.
I am not around my Classic right now - but I think there was a setting for what kind of data comes out of the serial port so that might be what the mode is. Can't remember where that is documented but remember reading it somewhere.
Larry
OK I found the relevant sections in the datasheet:
"... from low power arcing to devastating high power arcing, the Classic will detect and shut down with an audible and visible alert to announce that there is a problem in the PV side of the system. When an arc is detected the Classic has to be manually cleared."
Mode: Is assigned a 1 from factory default and it should stay that way unless instructed by MidNite Solar.
Time: This sets the length of arc the Classic has to monitor before tripping the Arc fault detection. This parameter is set to 4 from the factory.
Sensitivity: This parameter determines how sensitive the Arc fault detector with 1 being the most sensitive and 15 the least. This parameter is set to 10 from the factory.
Now the real question is: Is an arc actually happening randomly every 2 weeks or is the communication system failing and just messing up all other systems... ???
We have had a couple of customers that actually had arcs that were detected by the Classic.
If your Classic's arc fault is just too sensitive, crank up the sensitivity numbers all the way and reboot
the Classic for the new numbers to take effect. (power off and on is one way to reset it)
Lower numbers are MORE sensitive and higher numbers for time and sensitivity are LESS sensitive
to arcs. Higher numbers should give less tripping.
If it is not too sensitive and you ~might~ have an arc somewhere or some appliance that is causing it
to trip, try turning on and off appliances... Vacuum cleaner, drill, saw, etc. and see if you can make it trip.
Also you might try banging on or wiggling PV and/or battery cables just to make sure there is not a loose
connection there.
It can be a good tool to find bad connections if it is something like that causing the tripping.
Ground Fault detectors are also good for finding wiring problems. Maybe even a better use than what they
are intended for in the first place !
boB