News:

To visit MidNite Solar click this link www.midnitesolar.com

Main Menu

Modbus utility

Started by zoneblue, August 07, 2013, 12:01:49 AM

Previous topic - Next topic

zoneblue

Given that the documentation for rossws modbus program is scattered about, this is my attempt to consolidate it, Any corections let me know and ill fix itt.


NAME
   newmodbus - reads modbus over ethernet

USAGE
  ./newmodbus [options] IPADDRESS [registers]
 
DESCRIPTION
  Reads modbus registers over ethernet, from compatible devices, particularly
  midnite classic charge controllers. The default mode is single mode, which
  reads or writes one or more registers, outputs to stout, then exists. Continuous
  mode repeats at specifed intervals either using the same conection or new ones each read.
  Note that register numbers used here are as per the midnite classic manual, some other
  implementations have an address=register+1 implementation.

OPTIONS:
  -c  continuous, read repeatedly every 1sec, keeping the modbus connection alive
  -d  debugging info
  -dd more verbose debugging info
  -f   read configuration file
  -i{N} interval, where N is number of seconds between outputs in c mode. (broken? 1sec only)
  -p  power, summary in english
  -r  reopen, with c, closes and reopens the connection. useful if other devices need access as well.
  -s  serial number, needed to write to classic if locked.
  -t  set classic date/time to local time
  -v  version
  -w  write, sends an http request to rossw's server, either once for single mode, or
       once every 5 minutes in continuous mode.
 
EXAMPLES:
  ./newmodbus 192.168.0.223  4153       #read min absorb time
  ./newmodbus 192.168.0.223  4150-4160  #read several registers
  ./newmodbus 192.168.0.223  4153=1800  #set min absorb time to 30 mins
  ./newmodbus -t 192.168.0.223          #set classic clock
  ./newmodbus -ci5 192.168.0.223 4101-4299/1 #reads 200 registers repeating every 10 seconds
  ./newmodbus -ci5 -l/var/log/ 192.168.0.223  #ditto saving to file

AUTHOR
  RossW 2013
6x300W CSUN, ground mount, CL150Lite, 2V/400AhToyo AGM,  Outback VFX3024E, Steca Solarix PL1100
http://www.zoneblue.org/cms/page.php?view=off-grid-solar

RossW

Quote from: zoneblue on August 07, 2013, 12:01:49 AM
Continuous  mode repeats at specifed intervals either using the same conection or new ones each read.
  Note that register numbers used here are as per the midnite classic manual, some other
  implementations have an address=register+1 implementation.

My "continuous" mode reads every second (optionally closing and re-opening the connection each time), displays selected information to stdout every second, and (optionally) writes it to a local file every (n) seconds.

I've repeatedly warned people to be wary of the differences between "address" and "register".
The midnite document uses "addresses". My code talks to and expects info from the user the same way. Internally, it does the conversion to "register" (where register = address-1)


Quote
  -f   read configuration file
Not currently implemented.

Quote
  -i{N} interval, where N is number of seconds between outputs in c mode. (broken? 1sec only)
Not broken, mis-understood :)
The output to stdout is every second. The output to the log file is every (N) seconds.

Quote
  -p  power, summary in english
Actually -p was meant to be Print-Info.  Not just power, but "useful info for People"


Quote
  -s  serial number, needed to write to classic if locked.
Actually, that was the intention. But since then, I found that (by design or by error, unsure which), you can actually read the devices serial number from the device - and then use that to unlock it. Totally bypasses the "lock jumper" security but is more convenient from my point of view! Just make sure your classic can't be accessed by untrusted (ie, anyone) on the global internet.

Quote
  -t  set classic date/time to local time
Assuming the local host has the correct time isn't always safe, but mine are so thats why I did it.
Also, the classic with MNGP seems to happily update the time, but within 30 seconds - clobbers it with whatever the MNGP RTC is. So this switch is likely useful on a lite without MNGP, but not so useful otherwise. The best "fix" for this is to work out how to (or if it's even possible to) update the MNGP RTC (too/instead)

Quote
  -w  write, sends an http request to rossw's server, either once for single mode, or
       once every 5 minutes in continuous mode.
In time, I'll provide for this to accept a FQDN so you can log wherever you like.
 
Quote
EXAMPLES:
  ./newmodbus 192.168.0.223  4153       #read min absorb time
  ./newmodbus 192.168.0.223  4150-4160  #read several registers
  ./newmodbus 192.168.0.223  4153=1800  #set min absorb time to 30 mins
  ./newmodbus -t 192.168.0.223          #set classic clock
  ./newmodbus -ci5 192.168.0.223 4101-4299/1 #reads 200 registers repeating every 10 seconds
  ./newmodbus -ci5 -l/var/log/ 192.168.0.223  #ditto saving to file
OK, there are a few things I'd like to add here.
They are not immediately intuitive.

Displaying an address has a few primitives that can be applied. They are:
  /    division. (floating point answer)
  *   multiplication
  >  Shift bits right
  %  modulo
   f   Convert degC to degF

The = operator is used to assign a value which can be either a number OR A STRING.

Examples:
./newmodbus `cat classic.addr` 4115       (show battery voltage)
4115 482 (0x1E2)       (answer is not very intuitive)

but
./newmodbus `cat classic.addr` 4115/10      (divide the answer by 10)
4115 48.2     (48.2 volts is much more obvious)


./newmodbus `cat classic.addr` 4120       (show charge state)
4120 1027 (0x403)   (want upper byte only, only visible in hex string)

./newmodbus `cat classic.addr` 4120\>8       (need to escape the > for obvious reasons)
4120   4     (BulkMppt mode)

./newmodbus `cat classic.addr` 4210=Solar2    (Sets the device ID to the string "Solar2")


There are a heap of things on the table to do, but not enough time to do them.
3600W on 6 tracking arrays.
7200W on 2 fixed array.
Midnite Classic 150
Outback Flexmax FM80
16 x LiFePO4 600AH cells
16 x LiFePO4 300AH cells
Selectronics SP-PRO 481 5kW inverter
Fronius 6kW AC coupled inverter
Home-brew 4-cyl propane powered 14kVa genset
2kW wind turbine

laszlo

#2
Ross has graciously helped me obtain the program.  It is very clever. Of note: I had to turn off the LocalApp in order to connect on port 502 to the Classic. It does not seem to alow multiple concurremnt tcp connections.  Midnite folks -- is there a setting for the Classic that may allow multiple concurrent conenctions?


las$ ./newmodbus.1.0.14-OSX    -p 192.168.2.250
Laszlo Display Panel 1.0.14, RossW
State BulkMppt
Firmware 1370
ClassicTime 19:22:00  07/08/2013
  349 Watts out
49.4 Volts (Battery)
49.9 Volts (PV)
  7.1 Amps (Battery)
22.7 kWh today (431 amphours)




4.6KW offgrid PV system, Classic 200, MX60, dual Magnum PAE 4448 inverters, Midnite combiner and disconnect boxes, e-panel,  WBJr, and 8 MN SPDs

RossW

Quote from: laszlo on August 07, 2013, 08:23:18 PM

  349 Watts out
49.4 Volts (Battery)
49.9 Volts (PV)
  7.1 Amps (Battery)

49.4V(batt) and 49.9V(PV) seems wrong.
V1.0.14 was I think the first version I put the -p switch in, perhaps I messed up there.
I appear not to have put up the OSX V1.0.18 code, so will do that soon. That might fix that particular problem.
(But it can't fix the one connection at a time issue with the classic)
3600W on 6 tracking arrays.
7200W on 2 fixed array.
Midnite Classic 150
Outback Flexmax FM80
16 x LiFePO4 600AH cells
16 x LiFePO4 300AH cells
Selectronics SP-PRO 481 5kW inverter
Fronius 6kW AC coupled inverter
Home-brew 4-cyl propane powered 14kVa genset
2kW wind turbine

RossW

Quote from: laszlo on August 07, 2013, 08:23:18 PM

las$ ./newmodbus.1.0.14-OSX    -p 192.168.2.250
Laszlo Display Panel 1.0.14, RossW

ok, just put the correct version on my page:

rossw$ Downloads/newmodbus.1.0.18-OSX -p `cat solar2.addr`
Solar2 Display Panel 1.0.18, RossW
State BulkMppt
Firmware 1401
ClassicTime 10:48:52  08/08/2013
  283 Watts out
56.4 Volts (Battery)
73.4 Volts (PV)
  5.0 Amps (Battery)
  0.6 kWh today (12 amphours)

You can grab the updated version from http://support.rossw.net/midnite/newmodbus.1.0.1.18-OSX
3600W on 6 tracking arrays.
7200W on 2 fixed array.
Midnite Classic 150
Outback Flexmax FM80
16 x LiFePO4 600AH cells
16 x LiFePO4 300AH cells
Selectronics SP-PRO 481 5kW inverter
Fronius 6kW AC coupled inverter
Home-brew 4-cyl propane powered 14kVa genset
2kW wind turbine

laszlo

#5
Actually, the PV voltage appears to be correct. It's the end of the day now so there is not so much irradiation. I'm letting the Classic charge as long as it can. (This  is controlled from Charger->Limits->MinVolt)

The Classic can get the PV  voltage very close to the Battery voltage. Actually, boB says PV volts can also go slightly lower than battery volts, but I have only seen them to be real close to each other, but PV slightly higher, as below.

las$ ./newmodbus.1.0.14-OSX    -p 192.168.2.250
Laszlo Display Panel 1.0.14, RossW
State BulkMppt
Firmware 1370
ClassicTime 20:00:46  07/08/2013
   68 Watts out
48.8 Volts (Battery)
49.1 Volts (PV)
  1.4 Amps (Battery)
22.8 kWh today (433 amphours)
4.6KW offgrid PV system, Classic 200, MX60, dual Magnum PAE 4448 inverters, Midnite combiner and disconnect boxes, e-panel,  WBJr, and 8 MN SPDs

TomW

Ross;


./newmodbus -p 192.168.2.104
WIND Display Panel 1.0.18, RossW
State Resting because FET temperature too high
Firmware 1401
ClassicTime 20:08:40  07/08/2013
    0 Watts out
25.0 Volts (Battery)
10.5 Volts (PV)
  0.0 Amps (Battery)
  0.4 kWh today (16 amphours)



No input and no heat so the FET error has to be wrong?

Local App says:Temperature:
FET: 28.8°C     PCB: 36.2°C
BAT: 25.2°C

Any idea whats up?
Solar seems right tho


./newmodbus -p 192.168.2.129
SOLAR Display Panel 1.0.18, RossW
State Resting because Not enough power available
Firmware 1397
ClassicTime 20:04:06  07/08/2013
    0 Watts out
25.0 Volts (Battery)
90.0 Volts (PV)
  0.0 Amps (Battery)
  4.0 kWh today (149 amphours)


Just curious. Different firmware versions maybe?


Tom


Do NOT mistake me for any kind of "expert".

( ͡° ͜ʖ ͡°)


24 Trina 310 watt modules, SMA SunnyBoy 7.7 KW Grid Tie inverter.

I thought that they were angels, but much to my surprise, We climbed aboard their starship and headed for the skies

RossW

Quote from: TomW on August 07, 2013, 09:18:45 PM
Ross;


./newmodbus -p 192.168.2.104
WIND Display Panel 1.0.18, RossW
State Resting because FET temperature too high
Firmware 1401
ClassicTime 20:08:40  07/08/2013
    0 Watts out
25.0 Volts (Battery)
10.5 Volts (PV)
  0.0 Amps (Battery)
  0.4 kWh today (16 amphours)



No input and no heat so the FET error has to be wrong?
Just curious. Different firmware versions maybe?

Strewth, I hope firmware versions don't change the message!
The resting reason text as described has come straight from the document provided by midnite:

        char const* RestingReason[]={
                "Not Defined",  // 0
                "Not enough power available",
                "Insane Ibatt Measurement"
                "Negative Current (load on PV input ?)",
                "PV Input Voltage lower than Battery V",
                "Too low of power out",
                "FET temperature too high",
                "Ground Fault Detected",
                "Arc Fault Detected",
                "Too much negative current while operating (backfeed from battery out of PV input)",
                "Battery is less than 8.0 Volts",
                "V is rising too slowly. Low Light or bad connection",
                "Voc has gone down from last Voc or low light.",
                "Voc has gone up from last Voc enough to be suspicious.",
(etc etc)

Can you have a look at register 4275 and post what that is?


3600W on 6 tracking arrays.
7200W on 2 fixed array.
Midnite Classic 150
Outback Flexmax FM80
16 x LiFePO4 600AH cells
16 x LiFePO4 300AH cells
Selectronics SP-PRO 481 5kW inverter
Fronius 6kW AC coupled inverter
Home-brew 4-cyl propane powered 14kVa genset
2kW wind turbine

TomW

Ross;

Here you go;


tomw@pi ~/ROSS/NEW $ ./newmodbus 192.168.2.104 4275
ID WIND
ClassicTime 21:13:50  07/08/2013
4275 5 (0x5)
tomw@pi ~/ROSS/NEW $ ./newmodbus -p 192.168.2.104
WIND Display Panel 1.0.18, RossW
State Resting because FET temperature too high
Firmware 1401
ClassicTime 21:14:41  07/08/2013
    0 Watts out
24.8 Volts (Battery)
10.0 Volts (PV)
  0.0 Amps (Battery)
  0.4 kWh today (16 amphours)



Do NOT mistake me for any kind of "expert".

( ͡° ͜ʖ ͡°)


24 Trina 310 watt modules, SMA SunnyBoy 7.7 KW Grid Tie inverter.

I thought that they were angels, but much to my surprise, We climbed aboard their starship and headed for the skies

RossW

Quote from: TomW on August 07, 2013, 10:24:45 PM
4275 5 (0x5)

State Resting because FET temperature too high

ok, so riddle me this!

        int n;
               
        char const* RestingReason[]={
                "Not Defined",  // 0
                "Not enough power available",
                "Insane Ibatt Measurement"
                "Negative Current (load on PV input ?)",
                "PV Input Voltage lower than Battery V",
                "Too low of power out",
                "FET temperature too high",
                "Ground Fault Detected",
                "Arc Fault Detected",
                "Too much negative current while operating (backfeed from battery out of PV input)",
                "Battery is less than 8.0 Volts",
                "V is rising too slowly. Low Light or bad connection",
                "Voc has gone down from last Voc or low light.",
(etc)
                "OCP in a mode other than Solar or PV-Uset",
                "Peak negative battery current > 90.0 amps"};

        for(n=0; n<30; n++)
                printf("%02d -> %s\n",n,RestingReason[n]);


Compile, run:

00 -> Not Defined
01 -> Not enough power available
02 -> Insane Ibatt MeasurementNegative Current (load on PV input ?)
03 -> PV Input Voltage lower than Battery V
04 -> Too low of power out
05 -> FET temperature too high
06 -> Ground Fault Detected

Arghh!    Missing comma!


Tom, you've got the source there still - on or about source line 416
change 
   "Insane Ibatt Measurement"
to
  "Insane Ibatt Measurement",

recompile and that should be fixed.
3600W on 6 tracking arrays.
7200W on 2 fixed array.
Midnite Classic 150
Outback Flexmax FM80
16 x LiFePO4 600AH cells
16 x LiFePO4 300AH cells
Selectronics SP-PRO 481 5kW inverter
Fronius 6kW AC coupled inverter
Home-brew 4-cyl propane powered 14kVa genset
2kW wind turbine

TomW

Quote from: RossW on August 07, 2013, 11:31:51 PM
Quote from: TomW on August 07, 2013, 10:24:45 PM
4275 5 (0x5)

State Resting because FET temperature too high

ok, so riddle me this!

        int n;
               
        char const* RestingReason[]={
                "Not Defined",  // 0
                "Not enough power available",
                "Insane Ibatt Measurement"
                "Negative Current (load on PV input ?)",
                "PV Input Voltage lower than Battery V",
                "Too low of power out",
                "FET temperature too high",
                "Ground Fault Detected",
                "Arc Fault Detected",
                "Too much negative current while operating (backfeed from battery out of PV input)",
                "Battery is less than 8.0 Volts",
                "V is rising too slowly. Low Light or bad connection",
                "Voc has gone down from last Voc or low light.",
(etc)
                "OCP in a mode other than Solar or PV-Uset",
                "Peak negative battery current > 90.0 amps"};

        for(n=0; n<30; n++)
                printf("%02d -> %s\n",n,RestingReason[n]);


Compile, run:

00 -> Not Defined
01 -> Not enough power available
02 -> Insane Ibatt MeasurementNegative Current (load on PV input ?)
03 -> PV Input Voltage lower than Battery V
04 -> Too low of power out
05 -> FET temperature too high
06 -> Ground Fault Detected

Arghh!    Missing comma!


Tom, you've got the source there still - on or about source line 416
change 
   "Insane Ibatt Measurement"
to
  "Insane Ibatt Measurement",

recompile and that should be fixed.

That fixed it.

Thanks.

Tom
Do NOT mistake me for any kind of "expert".

( ͡° ͜ʖ ͡°)


24 Trina 310 watt modules, SMA SunnyBoy 7.7 KW Grid Tie inverter.

I thought that they were angels, but much to my surprise, We climbed aboard their starship and headed for the skies

zoneblue

#11
On the subject, can you think of material differences between rPi and A10 devices? Today for the second time, newmodbus 'seems' to have caused the classic to refuse modbus connections from anywhere. This never happend using the ubuntu compiled version on an intel atom/debian. Im now using the rPI version on the cubieboard which has a differnent arm chip than the rPi . Thoughts? Could the classic be opening a connection and failing to close it somehow?

Edit, A10 is Armv7 instruction set, rPi is Armv6. Maybe we need to compile a new version for A10 devices?

http://en.wikipedia.org/wiki/ARMv6#ARM_cores
6x300W CSUN, ground mount, CL150Lite, 2V/400AhToyo AGM,  Outback VFX3024E, Steca Solarix PL1100
http://www.zoneblue.org/cms/page.php?view=off-grid-solar

RossW

Quote from: zoneblue on August 08, 2013, 12:27:36 AM
On the subject, can you think of material differences between rPi and A10 devices? Today for the second time, newmodbus 'seems' to have caused the classic to refuse modbus connections from anywhere. This never happend using the ubuntu compiled version on an intel atom/debian. Im now using the rPI version on the cubieboard which has a differnent arm chip than the rPi . Thoughts? Could the classic be opening a connection and failing to close it somehow?

There was some kind of issue turned up in a recent version of the classic firmware that would basically prevent it permitting another connection within about 30 seconds or something. Andrew tweeked some settings and the next version was much better - but I still notice mine *SOMETIMES* won't accept a connection, but if I wait 20 seconds it will. When I've caught this, running tcpdump shows the packets getting to the classic, I just can't remember now if the classic was sending back connection refused responses, or just not responding at all.
3600W on 6 tracking arrays.
7200W on 2 fixed array.
Midnite Classic 150
Outback Flexmax FM80
16 x LiFePO4 600AH cells
16 x LiFePO4 300AH cells
Selectronics SP-PRO 481 5kW inverter
Fronius 6kW AC coupled inverter
Home-brew 4-cyl propane powered 14kVa genset
2kW wind turbine

laszlo

I'd like dwell a bit more on  how the Classic is handling tcp connections for the modbus.

It's a small OS,  so probably the  modbus stuff is single-threaded.  Fine, so  some simple locking mechanism could be provided so only one request is serviced at the time whilst the other is put in blocking wait.

It seems like Midnite  is considering open sourcing some of the misc util stuff, so philosophically it would be great that nice clean interface is created for the modbus.

Worst case, one can create a modbus request proxy using an external program but it would be more elegant if the Classic handled this internally. What are the prospects for this?




4.6KW offgrid PV system, Classic 200, MX60, dual Magnum PAE 4448 inverters, Midnite combiner and disconnect boxes, e-panel,  WBJr, and 8 MN SPDs

TomW

Quote from: laszlo on August 08, 2013, 12:38:35 PM
it would be great that nice clean interface is created for the modbus.

Worst case, one can create a modbus request proxy using an external program but it would be more elegant if the Classic handled this internally. What are the prospects for this?

Ross and I have been tossing around the proxy idea awhile so that might happen in an external app which is certainly not ideal but seems workable with a small external processor. Simply a process that sits between the Classic and other devices passing data between them.

Tom
Do NOT mistake me for any kind of "expert".

( ͡° ͜ʖ ͡°)


24 Trina 310 watt modules, SMA SunnyBoy 7.7 KW Grid Tie inverter.

I thought that they were angels, but much to my surprise, We climbed aboard their starship and headed for the skies