3cky / mbusd

Open-source Modbus TCP to Modbus RTU (RS-232/485) gateway.
BSD 3-Clause "New" or "Revised" License
566 stars 216 forks source link

I need to connect to a legacy device from a rockwell plc via a vpn over cell connection. #39

Closed shawnggraham closed 5 years ago

shawnggraham commented 6 years ago

Everything is worked out with the acception of the last bit between the vpn micropc that is connected via a usb-2-rs232 converter to the modbus device.

I can modbus scan the device with modpoll if i plug directly into it but when i try and connect via tcp to the rpie running mbusd with it connected to the modbus device i get "Gateway Target Device Failed exception response!" I cannot run modpoll on the actual rpie (no arm version) but i do get logs that might help.

root@raspberrypi:~# mbusd -L/tmp/mbusd.log -p /dev/ttyUSB0 -s 9600 -P 502 -d -N 0 -v9 11 Oct 2018 17:32:07 mbusd-0.3.1 started... 11 Oct 2018 17:32:07 tty: state now is TTY_PAUSE 11 Oct 2018 17:32:07 conn_loop(): select(): max_sd = 4, t_out = 000000:100000 11 Oct 2018 17:32:07 conn_loop(): select() returns 0 11 Oct 2018 17:32:07 tty: state now is TTY_READY 11 Oct 2018 17:32:07 conn_loop(): select(): max_sd = 4, t_out = 000060:000000 11 Oct 2018 17:32:13 conn_loop(): select() returns 1 11 Oct 2018 17:32:13 conn_open(): accepting connection from 192.168.15.56 11 Oct 2018 17:32:13 queue_new_elem(): length now is 1 11 Oct 2018 17:32:13 conn[192.168.15.56]: state now is CONN_HEADER 11 Oct 2018 17:32:13 conn_loop(): select(): max_sd = 5, t_out = 000060:000000 11 Oct 2018 17:32:13 conn_loop(): select() returns 1 11 Oct 2018 17:32:13 conn[192.168.15.56]: state now is CONN_RQST_FUNC 11 Oct 2018 17:32:13 conn[192.168.15.56]: read request fc 4 11 Oct 2018 17:32:13 conn[192.168.15.56]: state now is CONN_RQST_TAIL 11 Oct 2018 17:32:13 conn[192.168.15.56]: request: [01][04][00][63][00][64] 11 Oct 2018 17:32:13 conn[192.168.15.56]: state now is CONN_TTY 11 Oct 2018 17:32:13 tty: state now is TTY_RQST 11 Oct 2018 17:32:13 conn_loop(): select(): max_sd = 4, t_out = 000060:000000 11 Oct 2018 17:32:13 conn_loop(): select() returns 1 11 Oct 2018 17:32:13 tty: written 8 bytes 11 Oct 2018 17:32:13 tty: request written (total 8 bytes) 11 Oct 2018 17:32:13 tty: state now is TTY_RESP 11 Oct 2018 17:32:13 tty: estimated 205 bytes, waiting 721874 usec 11 Oct 2018 17:32:13 conn_loop(): select(): max_sd = 4, t_out = 000000:721874 11 Oct 2018 17:32:14 conn_loop(): select() returns 0 11 Oct 2018 17:32:14 tty: response timeout 11 Oct 2018 17:32:14 conn[192.168.15.56]: state now is CONN_RESP 11 Oct 2018 17:32:14 tty: state now is TTY_PAUSE

This is the basic rundown of my configureation. ROCKWELL_PLC -> tcp(ethernet)->rpie_mbusd->ttyUSB0->RS_232(RTU modbus_device_waterloger).

Mostly i'm just trying to work out if this is possible to do this with mbusd ?

Thanks ahead of time for your help.

shawnggraham commented 6 years ago

I seem to be making some headway, I moved everything off the rpie and am working from my toughbook. I can poll the slave now and get some data the big problem was i only have 10 counters to work with and the default on the modprobe was set to 100. This device is very slow to respond (waterlog h-350XL) and is hit and miss when i poll with rtu over rs232 but for the most part i get a response every 3 seconds or so. However if i use tcp mbusd seems to be overrun and i just get a Reply time-out!. Ive tried dialing back everthing that has to do with time and frequency of poling but it still seems to fast. Im using this "mbusd -L/tmp/mbusd.log -W 10000 -N 1 -R 10000 -p /dev/ttyUSB0 -s 9600 -P 502 -d -v9"

shawnggraham commented 6 years ago

I GOT IT!! I just needed to increase the time out on the poller program to 10 seconds and BOOYAAA!.

However the one problem i do have is after restarting the mbusd service i have to pole it with rtu one time before tcpip will work?

shawnggraham commented 6 years ago

Ok im able to get this working but only if i launch it in the foreground. mbusd -L/tmp/mbusd.log -p /dev/ttyUSB0 -s 9600 -P 502 -d -v9 I've tried configuring the /etc/mbusd/mbusd-ttyUSB0.conf with the exact same configuration minus the logging and foreground fork.
######### Serial port settings #############

Serial port device name

device = /dev/ttyUSB0

Serial port speed

speed = 9600 ############# TCP port settings #############

TCP server port number

port = 502

Connection timeout value in seconds

timeout = 10 It just will not work.

when i look at the log file it claims resource :tty not ready?

Second issue: I have to first probe it with rtu from my toughbook that is connected to the modbus device otherwise all i get is... "Gateway Target Device Failed exception response!" This i could work around accept, the modbus prob im working with will not run on arm arch. so im kinda sunk and i cant find a prober that will run on arm arch.

3cky commented 6 years ago

Hi @shawnggraham,

when i look at the log file it claims resource :tty not ready?

Could you post the entire log file? This message looks quite weird to me.

shawnggraham commented 6 years ago

Late last night i got fed up, it was all weird. I grabbed a rpie-v3 did a fresh raspbian install on it and walked through the compile process for mbusd again on it. I cant find a single step i did any different but this one seems to work fine. The only problem i have found is that i cannot run a modbus probe on the rtu at the same time my other machines are probing via tcpip. But the only reason i wanted to do that was because i was verifying the rpie could actually communicate with the waterloger so its not something i need to be able to do at the same time im polling via tcpip. So im good to go now! Im going to recreate this on the other rpie-v2b just for followup (and i have a grip of those to work with) and ill let you know how it goes. Also just because somebody else may want to be able to modbus rtu poll from the rpie..i did finally get that working with mbpoll from here -> https://github.com/epsilonrt/mbpoll/ It works mucho goodo!!

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.