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
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.
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)
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)
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
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)
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
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?
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)
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.
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
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
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.
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?
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
Ok, thanks TomW.
Out of the box, it seems one could use haproxy for this proxy/arbiter function. At the house I don't have a Linux box but I provide config example below for haproxy to have single backend tcp connection to port 502 on the CLassic from haproxy backend, and have various clients connect to the haproxy frontend.
frontend modbus-proxy- to-classic 0.0.0.0:502
mode tcp
maxconn 5
default_backend classic
backend classic
mode tcp
server my-classic <clsssic-IP>:502 maxconn 1
Quote from: laszlo on August 08, 2013, 05:29:35 PM
Out of the box, it seems one could use haproxy for this proxy/arbiter function.
I'd be surprised if it worked properly. Modbus isn't entirely stateless, if you have more than one device communicating at a time, there is a mechanism to ensure overlapped reads and writes don't mess things up, and a proxy/arbiter without specific modbus awareness is unlikely to function properly.
There are also other issues which probably won't affect most (possibly all) midnite users, that is that a session once opened and unlocked will hold the device in read/write mode until the connection is closed. With a proxy that maintains the connection open, this layer of protection would be defeated.
That's not to say there isn't a modbus proxy out there, but it would need to be an application specific to the task.
Quote from: RossW on August 08, 2013, 05:36:14 PM
Quote from: laszlo on August 08, 2013, 05:29:35 PM
Out of the box, it seems one could use haproxy for this proxy/arbiter function.
I'd be surprised if it worked properly. Modbus isn't entirely stateless, if you have more than one device communicating at a time, there is a mechanism to ensure overlapped reads and writes don't mess things up, and a proxy/arbiter without specific modbus awareness is unlikely to function properly.
There are also other issues which probably won't affect most (possibly all) midnite users, that is that a session once opened and unlocked will hold the device in read/write mode until the connection is closed. With a proxy that maintains the connection open, this layer of protection would be defeated.
That's not to say there isn't a modbus proxy out there, but it would need to be an application specific to the task.
I like the idea of a proxy. Something that reads the registers of the Classic once every so often (programmable how often and what it reads maybe ?) and then any number of other applications could work through that proxy. That would leave the Classic to do what it really needs to do (charge batteries) and let the other multi comm. stuff to the external (to the classic) proxy software.
boB
Well amost 24 hours exactly later newmodus stopped connecting again. And stays that way for, well a half hour so far. Havent rebooted the classic yet. Want to see what happens. Last time newmodus returned "connection refused" this time its just hanging there waiting. Local app gets "device not available".
The dump for about 3 minutes is below, ie three 1 minute cron job intervals:
root@cubie#contrab -lu peter
* 6-18 * * * /usr/bin/php-cgi -f /home/tasks/classic.php >/dev/null 2>&1
0 19-5 * * * /usr/bin/php-cgi -f /home/tasks/classic.php >/dev/null 2>&1
root@cubie:# tcpdump -nS host 192.168.0.223
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:21:02.669924 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [S], seq 4584834 81, win 14600, options [mss 1460,sackOK,TS val 18644196 ecr 0,nop,wscale 7], len gth 0
11:21:02.670085 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [S.], seq 668100 , ack 458483482, win 546, options [mss 546], length 0
11:21:02.670831 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [.], ack 668101, win 14600, length 0
11:21:02.671187 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [P.], seq 458483 482:458483494, ack 668101, win 14600, length 12
11:21:02.671350 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [.], ack 4584834 94, win 0, length 0
11:21:07.677543 ARP, Request who-has 192.168.0.223 tell 192.168.0.3, length 28
11:21:07.677639 ARP, Reply 192.168.0.223 is-at 60:1d:0f:00:1b:95, length 46
11:21:34.500531 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [F.], seq 668101, ack 458483494, win 546, length 0
11:21:34.505536 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [F.], seq 458483494, ack 668102, win 14600, length 0
11:21:34.506094 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [.], ack 458483495, win 546, length 0
11:21:39.507932 ARP, Request who-has 192.168.0.223 tell 192.168.0.3, length 28
11:21:39.508473 ARP, Reply 192.168.0.223 is-at 60:1d:0f:00:1b:95, length 46
11:22:03.934420 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [S], seq 1658402901, win 14600, options [mss 1460,sackOK,TS val 18650322 ecr 0,nop,wscale 7], length 0
11:22:03.935021 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [S.], seq 668588, ack 1658402902, win 546, options [mss 546], length 0
11:22:03.941634 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [.], ack 668589, win 14600, length 0
11:22:03.942589 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [P.], seq 1658402902:1658402914, ack 668589, win 14600, length 12
11:22:03.943082 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [.], ack 1658402914, win 0, length 0
11:22:35.534570 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [F.], seq 668589, ack 1658402914, win 546, length 0
11:22:35.538119 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [.], ack 668590, win 14600, length 0
11:22:35.545204 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [F.], seq 1658402914, ack 668590, win 14600, length 0
11:22:35.545739 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [.], ack 1658402915, win 546, length 0
11:23:03.689447 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [S], seq 2520130533, win 14600, options [mss 1460,sackOK,TS val 18656298 ecr 0,nop,wscale 7], length 0
11:23:03.690156 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [S.], seq 669068, ack 2520130534, win 546, options [mss 546], length 0
11:23:03.696109 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [.], ack 669069, win 14600, length 0
11:23:03.700622 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [P.], seq 2520130534:2520130546, ack 669069, win 14600, length 12
11:23:03.701075 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [.], ack 2520130546, win 0, length 0
11:23:35.568166 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [F.], seq 669069, ack 2520130546, win 546, length 0
11:23:35.573236 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [F.], seq 2520130546, ack 669070, win 14600, length 0
11:23:35.573789 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [.], ack 2520130547, win 546, length 0
11:23:40.577989 ARP, Request who-has 192.168.0.223 tell 192.168.0.3, length 28
11:23:40.578594 ARP, Reply 192.168.0.223 is-at 60:1d:0f:00:1b:95, length 46
11:24:03.009132 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [S], seq 36759640, win 14600, options [mss 1460,sackOK,TS val 18662230 ecr 0,nop,wscale 7], length 0
11:24:03.009742 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [S.], seq 669540, ack 36759641, win 546, options [mss 546], length 0
11:24:03.015692 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [.], ack 669541, win 14600, length 0
11:24:03.018925 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [P.], seq 36759641:36759653, ack 669541, win 14600, length 12
11:24:03.019428 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [.], ack 36759653, win 0, length 0
11:24:34.600835 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [F.], seq 669541, ack 36759653, win 546, length 0
11:24:34.601333 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [F.], seq 36759653, ack 669542, win 14600, length 0
11:24:34.601475 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [.], ack 36759654, win 546, length 0
11:25:03.613372 IP 192.168.0.3.56012 > 192.168.0.223.502: Flags [S], seq 746372578, win 14600, options [mss 1460,sackOK,TS val 18668290 ecr 0,nop,wscale 7], length 0
11:25:03.613979 IP 192.168.0.223.502 > 192.168.0.3.56012: Flags [S.], seq 670024, ack 746372579, win 546, options [mss 546], length 0
11:25:03.618790 IP 192.168.0.3.56012 > 192.168.0.223.502: Flags [.], ack 670025, win 14600, length 0
11:25:03.621126 IP 192.168.0.3.56012 > 192.168.0.223.502: Flags [P.], seq 746372579:746372591, ack 670025, win 14600, length 12
11:25:03.621711 IP 192.168.0.223.502 > 192.168.0.3.56012: Flags [.], ack 746372591, win 0, length 0
^C
44 packets captured
44 packets received by filter
0 packets dropped by kernel
From systems availability perspective, proxy makes a lot of sense. If you or RossW wanted to pursue writing a modbus proxy, I would still suggest to use a well-established proxy platform and contribute the module to them. This would cut down on having to manage various OS platforms and to navigate the quirks of tcp/ip client/server stuff.
Quote from: boB on August 08, 2013, 06:38:09 PM
Quote from: RossW on August 08, 2013, 05:36:14 PM
Quote from: laszlo on August 08, 2013, 05:29:35 PM
Out of the box, it seems one could use haproxy for this proxy/arbiter function.
I'd be surprised if it worked properly. Modbus isn't entirely stateless, if you have more than one device communicating at a time, there is a mechanism to ensure overlapped reads and writes don't mess things up, and a proxy/arbiter without specific modbus awareness is unlikely to function properly.
There are also other issues which probably won't affect most (possibly all) midnite users, that is that a session once opened and unlocked will hold the device in read/write mode until the connection is closed. With a proxy that maintains the connection open, this layer of protection would be defeated.
That's not to say there isn't a modbus proxy out there, but it would need to be an application specific to the task.
I like the idea of a proxy. Something that reads the registers of the Classic once every so often (programmable how often and what it reads maybe ?) and then any number of other applications could work through that proxy. That would leave the Classic to do what it really needs to do (charge batteries) and let the other multi comm. stuff to the external (to the classic) proxy software.
boB