Git Product home page Git Product logo

mbusd's Introduction

About mbusd

mbusd

mbusd is open-source Modbus TCP to Modbus RTU (RS-232/485) gateway. It presents a network of RTU slaves as single TCP slave.

That is a TCP-Slave (or server) which acts as a RTU-master to get data from Modbus RTU-slave devices.

Features:

  • Small footprint - suitable to run on embedded devices and SBCs like Raspberry Pi
  • Multi-master - multiple TCP masters can access slave devices in RTU network using same gateway
  • Robustness - can retry requests with mismatched response CRC
  • Flexible RTU modes - speed/parity/stop-bits/timeouts can be configured for RTU network
  • Support for both of automatic and manual (using RTS bit) direction control types for RS-485 transceivers

Supported function codes:

  • 01: Read coil status
  • 02: Read input status
  • 03: Read holding registers
  • 04: Read input registers
  • 05: Force single coil
  • 06: Preset single register
  • 07: Read exception status
  • 15: Force multiple coils
  • 16: Preset multiple registers

Please note all other function codes (including vendor-specific extensions) are supported on a "best-effort" basis and most likely will fail.

Installation instructions:

$ git clone https://github.com/3cky/mbusd.git mbusd.git
$ cd mbusd.git
$ mkdir -p build && cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..
$ make
$ sudo make install

Compile time options can be altered in many ways, e.g. by using the following tools in the build dir:

  • ccmake - usually in the package cmake-curses-gui
  • cmake-gui - usually in the package cmake-qt-gui

Usage:

   mbusd [-h] [-d] [-L logfile] [-v level] [-c cfgfile] 
         [-p device] [-s speed] [-m mode] [-S]
         [-t] [-r] [-y sysfsfile] [-Y sysfsfile] 
         [-A address] [-P port] [-C maxconn] [-N retries]
         [-R pause] [-W wait] [-T timeout] [-b]

   -h     Usage help.
   -d     Instruct mbusd not to fork itself (non-daemonize).
   -L logfile
          Specifies log file name ('-' for logging to STDOUT only, relative path or bare filename
          will be stored at /var/log, default is /var/log/mbusd.log).
   -v level
          Specifies log verbosity level (0 for errors only, 1 for warnings and 2 for informational 
          messages also). If mbusd was compiled in debug mode, valid log levels are up to 9, 
          where log levels above 2 adds logging of information about additional internal events.
   -c cfgfile
          Read configuration from cfgfile.
   -p device
          Specifies serial port device name.
   -s speed
          Specifies serial port speed.
   -m mode
          Specifies serial port mode (like 8N1).
   -S     Enable RS-485 support for given serial port device (Linux only)
   -t     Enable RTS RS-485 data direction control using RTS, active transmit.
   -r     Enable RTS RS-485 data direction control using RTS, active receive.
   -y sysfsfile
          Enable RS-485 direction data direction control by writing '1' to sysfs file
          for transmitter enable and '0' to file for transmitter disable.
   -Y sysfsfile
          Enable RS-485 direction data direction control by writing '0' to sysfs file
          for transmitter enable and '1' to file for transmitter disable.
   -A address
         Specifies TCP server address to bind (default is 0.0.0.0).
   -P port
          Specifies TCP server port number (default is 502).
   -C maxconn
          Specifies maximum number of simultaneous TCP connections (default is 32).
   -N retries
          Specifies maximum number of request retries (0 disables retries, default is 3).
   -R pause
          Specifies pause between requests in milliseconds (default is 100ms).
   -W wait
          Specifies response wait time in milliseconds (default is 500ms).
   -T timeout
          Specifies connection timeout value in seconds (0 disables timeout, default is 60).
   -b
          Instructs mbusd to reply on a broadcast.

Please note running mbusd on default Modbus TCP port (502) requires root privileges!

Configuration file:

mbusd can read the configuration from a file specified by -c command line flag. Please see example configuration file for complete list of available configuration options.

systemd:

mbusd has systemd support. The build system detects whether the system has systemd after which sudo make install installs the [email protected] file on systems with systemd active.

The mbusd service can be started via:

# systemctl start mbusd@<serial port>.service

where <serial port> is escaped serial port device short name (like ttyUSB0 for /dev/ttyUSB0 device name or serial-rs485 for /dev/serial/rs485 device name).

mbusd started by systemd will read its configuration from file named /etc/mbusd/mbusd-<serial port>.conf. This way it's possible to run multiple mbusd instances with different configurations.

To see the mbusd service status:

# systemctl status mbusd@<serial port>.service

To monitor the mbusd service:

# journalctl -u mbusd@<serial port>.service -f -n 10

To start the mbusd service on system boot:

# systemctl enable mbusd@<serial port>.service

Please check systemd documentation for other usefull systemd commands.

Docker:

mbusd can be launched in Docker container with the following command:

docker run -d --privileged \
    --name=mbusd \
    -p 502:502 \
    -v /dev:/dev \
    -v /path/to/mbusd.conf:/etc/mbusd.conf \
    3cky/mbusd:latest

where /path/to/mbusd.conf is the path to mbusd config file in the local filesystem.

Contributing:

Reporting bugs

Please file issue with attached debug log in verbose (-v9) mode, i.e.:

   # mbusd -L/tmp/mbusd.log -p /dev/ttyUSB0 -s 9600 -P 502 -d -v9

Unless you were prompted so or there is another pertinent reason (e.g. GitHub fails to accept the bug report), please do not send bug reports via personal email.

Workflow for code contributions

  1. Fork it and clone forked repository
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Make your changes
  4. Commit your changes (git commit -am 'Add some feature')
  5. Push to the branch (git push origin my-new-feature)
  6. Create new Pull Request

Building and Testing

Dependencies: please see the correct OS-distribution section in the .gitlab-ci.yml

With all dependencies met, one is able to build and execute tests issuing the following bash commands:

# build
mkdir output.dir/ && cd $_
cmake ../ && make
# execute all tests
(cd ../ && python tests/run_itests.py output.dir/mbusd)

Author:

Victor Antonovich ([email protected])

Contributors:

Andrew Denysenko ([email protected]):

  • RTS RS-485 data direction control
  • RTU response receiving by length

James Jarvis ([email protected]):

  • file based RS-485 data direction control

Luuk Loeffen ([email protected]):

  • systemd support

Nick Mayerhofer ([email protected]):

  • CMake build system

License:

This project is distributed under the BSD license. See the LICENSE file for the full license text.

mbusd's People

Contributors

3cky avatar cian avatar dgoo2308 avatar dwyer-employee avatar jpmeijers avatar jschlyter avatar kb0thn avatar kpr0th avatar krystiand avatar luuloe avatar mbs38 avatar nickma82 avatar vicencb avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mbusd's Issues

Service not starting after boot, but service running fine when started manually

Hi there, I'm running this on a raspberry pi 3b, latest raspbian.

I can start mbusd via command line:
pi@pi-modbus:~ $ sudo mbusd -c /etc/mbusd/mbusd-ttyUSB0.conf
I can also start as a service:
pi@pi-modbus:~ $ sudo systemctl start [email protected]
It runs just fine like that (log below for service start):

pi@pi-modbus:~ $ sudo journalctl -u [email protected] -f -n 10
-- Logs begin at Thu 2019-02-14 11:11:59 CET. --
May 14 16:00:41 pi-modbus systemd[1]: Started Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:00:41 pi-modbus mbusd[15393]: 14 May 2020 16:00:41 mbusd-0.4.1 started...
May 14 16:00:43 pi-modbus mbusd[15393]: 14 May 2020 16:00:43 conn_open(): accepting connection from 192.168.40.32
May 14 16:00:53 pi-modbus mbusd[15393]: 14 May 2020 16:00:53 conn_close(): closing connection from 192.168.40.32
May 14 16:00:53 pi-modbus mbusd[15393]: 14 May 2020 16:00:53 conn_open(): accepting connection from 192.168.40.32
May 14 16:01:03 pi-modbus mbusd[15393]: 14 May 2020 16:01:03 conn_close(): closing connection from 192.168.40.32
May 14 16:01:03 pi-modbus mbusd[15393]: 14 May 2020 16:01:03 conn_open(): accepting connection from 192.168.40.32
May 14 16:01:13 pi-modbus mbusd[15393]: 14 May 2020 16:01:13 conn_close(): closing connection from 192.168.40.32
May 14 16:01:13 pi-modbus mbusd[15393]: 14 May 2020 16:01:13 conn_open(): accepting connection from 192.168.40.32
May 14 16:01:23 pi-modbus mbusd[15393]: 14 May 2020 16:01:23 conn_close(): closing connection from 192.168.40.32
May 14 16:01:23 pi-modbus mbusd[15393]: 14 May 2020 16:01:23 conn_open(): accepting connection from 192.168.40.32
May 14 16:01:33 pi-modbus mbusd[15393]: 14 May 2020 16:01:33 conn_close(): closing connection from 192.168.40.32
May 14 16:01:33 pi-modbus mbusd[15393]: 14 May 2020 16:01:33 conn_open(): accepting connection from 192.168.40.32

But when I enable the service:

pi@pi-modbus:~ $ sudo systemctl enable [email protected]
Created symlink /etc/systemd/system/multi-user.target.wants/[email protected] → /lib/systemd/system/[email protected].

And reboot the raspberry:
pi@pi-modbus:~ $ sudo reboot
I only get a "Failed to start ..." message in the logs:

pi@pi-modbus:~ $ sudo journalctl -u [email protected] -f -n 500
-- Logs begin at Thu 2020-05-14 16:02:10 CEST. --
May 14 16:02:13 pi-modbus systemd[1]: Started Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:13 pi-modbus mbusd[298]: 14 May 2020 16:02:13 mbusd-0.4.1 started...
May 14 16:02:13 pi-modbus mbusd[298]: 14 May 2020 16:02:13 sock_create_server(): unable to bind() socket (Cannot assign requested address)
May 14 16:02:13 pi-modbus mbusd[298]: 14 May 2020 16:02:13 conn_init(): can't create listen socket (Cannot assign requested address)
May 14 16:02:13 pi-modbus mbusd[298]: 14 May 2020 16:02:13 conn_init() failed, exiting...
May 14 16:02:14 pi-modbus systemd[1]: [email protected]: Main process exited, code=exited, status=99/n/a
May 14 16:02:14 pi-modbus systemd[1]: [email protected]: Failed with result 'exit-code'.
May 14 16:02:15 pi-modbus systemd[1]: [email protected]: Service RestartSec=1s expired, scheduling restart.
May 14 16:02:15 pi-modbus systemd[1]: [email protected]: Scheduled restart job, restart counter is at 1.
May 14 16:02:15 pi-modbus systemd[1]: Stopped Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:15 pi-modbus systemd[1]: Started Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:15 pi-modbus mbusd[412]: 14 May 2020 16:02:15 mbusd-0.4.1 started...
May 14 16:02:15 pi-modbus mbusd[412]: 14 May 2020 16:02:15 sock_create_server(): unable to bind() socket (Cannot assign requested address)
May 14 16:02:15 pi-modbus mbusd[412]: 14 May 2020 16:02:15 conn_init(): can't create listen socket (Cannot assign requested address)
May 14 16:02:15 pi-modbus mbusd[412]: 14 May 2020 16:02:15 conn_init() failed, exiting...
May 14 16:02:15 pi-modbus systemd[1]: [email protected]: Main process exited, code=exited, status=99/n/a
May 14 16:02:15 pi-modbus systemd[1]: [email protected]: Failed with result 'exit-code'.
May 14 16:02:16 pi-modbus systemd[1]: [email protected]: Service RestartSec=1s expired, scheduling restart.
May 14 16:02:16 pi-modbus systemd[1]: [email protected]: Scheduled restart job, restart counter is at 2.
May 14 16:02:16 pi-modbus systemd[1]: Stopped Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:16 pi-modbus systemd[1]: Started Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:16 pi-modbus mbusd[414]: 14 May 2020 16:02:16 mbusd-0.4.1 started...
May 14 16:02:16 pi-modbus mbusd[414]: 14 May 2020 16:02:16 sock_create_server(): unable to bind() socket (Cannot assign requested address)
May 14 16:02:16 pi-modbus mbusd[414]: 14 May 2020 16:02:16 conn_init(): can't create listen socket (Cannot assign requested address)
May 14 16:02:16 pi-modbus mbusd[414]: 14 May 2020 16:02:16 conn_init() failed, exiting...
May 14 16:02:16 pi-modbus systemd[1]: [email protected]: Main process exited, code=exited, status=99/n/a
May 14 16:02:16 pi-modbus systemd[1]: [email protected]: Failed with result 'exit-code'.
May 14 16:02:17 pi-modbus systemd[1]: [email protected]: Service RestartSec=1s expired, scheduling restart.
May 14 16:02:17 pi-modbus systemd[1]: [email protected]: Scheduled restart job, restart counter is at 3.
May 14 16:02:17 pi-modbus systemd[1]: Stopped Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:17 pi-modbus systemd[1]: Started Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:17 pi-modbus mbusd[464]: 14 May 2020 16:02:17 mbusd-0.4.1 started...
May 14 16:02:17 pi-modbus mbusd[464]: 14 May 2020 16:02:17 sock_create_server(): unable to bind() socket (Cannot assign requested address)
May 14 16:02:17 pi-modbus mbusd[464]: 14 May 2020 16:02:17 conn_init(): can't create listen socket (Cannot assign requested address)
May 14 16:02:17 pi-modbus mbusd[464]: 14 May 2020 16:02:17 conn_init() failed, exiting...
May 14 16:02:17 pi-modbus systemd[1]: [email protected]: Main process exited, code=exited, status=99/n/a
May 14 16:02:17 pi-modbus systemd[1]: [email protected]: Failed with result 'exit-code'.
May 14 16:02:19 pi-modbus systemd[1]: [email protected]: Service RestartSec=1s expired, scheduling restart.
May 14 16:02:19 pi-modbus systemd[1]: [email protected]: Scheduled restart job, restart counter is at 4.
May 14 16:02:19 pi-modbus systemd[1]: Stopped Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:19 pi-modbus systemd[1]: Started Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:19 pi-modbus mbusd[475]: 14 May 2020 16:02:19 mbusd-0.4.1 started...
May 14 16:02:19 pi-modbus mbusd[475]: 14 May 2020 16:02:19 sock_create_server(): unable to bind() socket (Cannot assign requested address)
May 14 16:02:19 pi-modbus mbusd[475]: 14 May 2020 16:02:19 conn_init(): can't create listen socket (Cannot assign requested address)
May 14 16:02:19 pi-modbus mbusd[475]: 14 May 2020 16:02:19 conn_init() failed, exiting...
May 14 16:02:19 pi-modbus systemd[1]: [email protected]: Main process exited, code=exited, status=99/n/a
May 14 16:02:19 pi-modbus systemd[1]: [email protected]: Failed with result 'exit-code'.
May 14 16:02:20 pi-modbus systemd[1]: [email protected]: Service RestartSec=1s expired, scheduling restart.
May 14 16:02:20 pi-modbus systemd[1]: [email protected]: Scheduled restart job, restart counter is at 5.
May 14 16:02:20 pi-modbus systemd[1]: Stopped Modbus TCP to Modbus RTU (RS-232/485) gateway..
May 14 16:02:20 pi-modbus systemd[1]: [email protected]: Start request repeated too quickly.
May 14 16:02:20 pi-modbus systemd[1]: [email protected]: Failed with result 'exit-code'.
May 14 16:02:20 pi-modbus systemd[1]: Failed to start Modbus TCP to Modbus RTU (RS-232/485) gateway..

Waiting does not help, but restarting fixes it:
pi@pi-modbus:~ $ sudo systemctl restart [email protected]

Since I do not want to have to do this after every reboot I'm asking:

How can I fix this? I am no linux expert but have never seen this with other services (like openhab, homebridge etc..).

Inversed register order

It seems that mbusd changes the register order for multi-register requests from what modpoll reads directly from RTU.

Modpoll reads 16bit (-t 4 flag) as
register 57734: 6
register 57735: 0

32bit (-t:int flag) as
register 57734: 6

inversed register 32bit (-t:int -i flags) "Slave operates on big-endian 32-bit integers"
register 57734: 393216

With mbusd reading single registers results in the same values as with modpoll, but reading a 32bit word from register 57734 results in the register inversed value 393216.

Is there a way to retain the original register order / inverse the current order?

Service Fails to start raspberry pi

If I run the command manually it starts with the specified configuration file no problem. If I try to run it as a service it fails.

`root@raspberrypi:~# systemctl status mbusd@ttyUSB0
[email protected] - Modbus TCP to Modbus RTU (RS-232/485) gateway.
Loaded: loaded (/lib/systemd/system/[email protected]; enabled)
Active: failed (Result: start-limit) since Sun 2018-02-18 21:01:15 UTC; 36s ago
Process: 675 ExecStart=/bin/mbusd -d -v2 -L - -c /etc/mbusd/mbusd-%i.conf -p /dev/%i (code=exited, status=203/EXEC)
Main PID: 675 (code=exited, status=203/EXEC)

Feb 18 21:01:15 raspberrypi systemd[1]: [email protected] holdoff time over, scheduling restart.
Feb 18 21:01:15 raspberrypi systemd[1]: Stopping Modbus TCP to Modbus RTU (RS-232/485) gateway....
Feb 18 21:01:15 raspberrypi systemd[1]: Starting Modbus TCP to Modbus RTU (RS-232/485) gateway....
Feb 18 21:01:15 raspberrypi systemd[1]: [email protected] start request repeated too quickly, refusing to start.
Feb 18 21:01:15 raspberrypi systemd[1]: Failed to start Modbus TCP to Modbus RTU (RS-232/485) gateway..
Feb 18 21:01:15 raspberrypi systemd[1]: Unit [email protected] entered failed state.
root@raspberrypi:#
root@raspberrypi:
#
root@raspberrypi:#
root@raspberrypi:
# mbusd -d -v2 -L - -c /etc/mbusd/mbusd-ttyUSB0.conf -p /dev/ttyUSB0
18 Feb 2018 21:02:09 mbusd-0.3.0 started...
`

Allow both TCP/IP and Unix Domain socket connections

I would like other programs on the same machine that runs mbusd to be able to access the Modbus backend. I could use the Ethernet loopback but it seems heavy. A better way would be to allow an inter process communication to happen. Unix Domain socket seem like the most logical IPC as it is very similar to the TCP sockets without the networking overhead. It also uses a lot of the same functions so the unique code between the two socket type could be minimal.

Can't Work with ION SETUP or /dev/ttyO2

Hello , i am using ION Setup program for read devices. i am also trying to make rtu/tcp gateway with my custom emb linux board. when i try to read devices with ION Setup program , just nothing happens.

so dou you have any idea ?

image

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

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.

cmake error

Try compile on raspbian jessie
Have error:

-- The C compiler identification is unknown
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-3.6/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "/usr/bin/cc" is not able to compile a simple test program.

Service Failed to start

Hi Victor
I'm trying to use mbusd on my raspberry Pi as a Modbus TCP 2 serial server and every time I reboot the pi it always displayed a message : "Failed to start Modbus TCP to Modbus (RS-232/485) gateway.
Here is output form systemctl

root@raspberrypi:/home/pi# systemctl status [email protected][email protected] - Modbus TCP to Modbus RTU (RS-232/485) gateway.
   Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2020-04-12 20:40:31 BST; 3min 7s ago
  Process: 317 ExecStart=/usr/local/bin/mbusd -d -v2 -L - -c /usr/local/etc/mbusd/mbusd-ttyUSB0.conf -p /dev/ttyUSB0 (code=exited, status=255/EXCEPTION)
 Main PID: 317 (code=exited, status=255/EXCEPTION)

Apr 12 20:40:31 raspberrypi systemd[1]: [email protected]: Service RestartSec=1s expired, scheduling restart.
Apr 12 20:40:31 raspberrypi systemd[1]: [email protected]: Scheduled restart job, restart counter is at 5.
Apr 12 20:40:31 raspberrypi systemd[1]: Stopped Modbus TCP to Modbus RTU (RS-232/485) gateway..
Apr 12 20:40:31 raspberrypi systemd[1]: [email protected]: Start request repeated too quickly.
Apr 12 20:40:31 raspberrypi systemd[1]: [email protected]: Failed with result 'exit-code'.
Apr 12 20:40:31 raspberrypi systemd[1]: Failed to start Modbus TCP to Modbus RTU (RS-232/485) gateway..

I've noticed the messages saying that:
"Start request repeated too quickly"
"Failed with result 'exit-code'

Please advice on this matter. Thanks

Modbus RTU over TCP

Hi! Are you planning to add modbus RTU over TCP feature? For example, instead of using Modbus TCP packet, deploy Modbus RTU over TCP packet. It's very comfortable thing for getting info via virtual COM port (emulating Modbus RTU device using TCP connection).

TCP over TCP [feature][enhancement]

I know this sounds ridiculous, but there are instances where the slave is Modbus-TCP but only allows one connection, when new master tries to poll, there might be an option to either drop existing connection or refuse the new one.

It would be beneficial to have the slave side of mbusd as modbus TCP to over come this issue and allow multiple masters to poll the slave.

systemctl gives "failed to lookup unit file state"

I managed to navigate all (most) of the installation song and dance on raspberry Pi (stretch)
but there are some loose ends...

When I try to run
sudo systemctl enable mbusd@/dev/ttyAMA0.service
I get
Failed to lookup unit file state: Invalid argument

Apparently this is common with systemd / systemctl:
"you did it wrong and I'm not going to tell you anything about how"

I thought, well, if the default device is /dev/ttyS0 (whoever heard of AMA0?) I would try that.
Same thing.
I have gone through the song and dance of disabling serial port login and enabling serial port
and the port is available as shown by gpio readall
so presumeably there is some secret systemd incantation yet to be found...

I also expect some kind of port/register/IP-address mapping configuration
like other TCP/RTU gateways so that the RTU-Master will poll via the serial connection,
and mbusd will then act as TCP-Master to retrieve data from the TCP-slave end-device

man -k mbusd turned up nothing appropriate,
I looked for details in the doc/mbusd.8 file but there's nothing interesting in there...

It is now dawning on me that this is not a bidirectional gateway...
i.e. it is only a TCP-Slave which then acts as a RTU-master to get data from RTU-slave devices
which is the reverse of what I need

mbusd stops responding and goes into spin shortly after being started

Just started playing with mbusd to have a tcp interface to my modbus devices the RS485 bus (there is currently three devices on the bus). Maybe I'm doing something fundamental wrong, but I can't make much out of the debugging output.

Shortly, at least within a few minutes after being started, mbusd stops responding. When I run in the the foreground with debugging enabled I get the output below. Have played around with the timeout parameters (-T and -W respectively but can't get any difference). What could be the issue?

$ sudo ./mbusd -d -v 9 -p /dev/ttyPort0 -s 9600 -t
01 Jan 2019 17:11:14 mbusd-0.3.1 started...
01 Jan 2019 17:11:14 tty: state now is TTY_PAUSE
01 Jan 2019 17:11:14 conn_loop(): select(): max_sd = 4, t_out = 000000:100000
01 Jan 2019 17:11:14 conn_loop(): select() returns 0
01 Jan 2019 17:11:14 tty: state now is TTY_READY
01 Jan 2019 17:11:14 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:16 conn_loop(): select() returns 1
01 Jan 2019 17:11:16 conn_open(): accepting connection from 127.0.0.1
01 Jan 2019 17:11:16 queue_new_elem(): length now is 1
01 Jan 2019 17:11:16 conn[127.0.0.1]: state now is CONN_HEADER
01 Jan 2019 17:11:16 conn_loop(): select(): max_sd = 5, t_out = 000060:000000
01 Jan 2019 17:11:16 conn_loop(): select() returns 1
01 Jan 2019 17:11:16 conn[127.0.0.1]: state now is CONN_RQST_FUNC
01 Jan 2019 17:11:16 conn[127.0.0.1]: read request fc 3
01 Jan 2019 17:11:16 conn[127.0.0.1]: state now is CONN_RQST_TAIL
01 Jan 2019 17:11:16 conn[127.0.0.1]: request: [03][03][00][2b][00][01]
01 Jan 2019 17:11:16 conn[127.0.0.1]: state now is CONN_TTY
01 Jan 2019 17:11:16 tty: state now is TTY_RQST
01 Jan 2019 17:11:16 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:16 conn_loop(): select() returns 1
01 Jan 2019 17:11:16 tty: written 8 bytes
01 Jan 2019 17:11:16 tty: request written (total 8 bytes)
01 Jan 2019 17:11:16 tty: state now is TTY_RESP
01 Jan 2019 17:11:16 tty: estimated 7 bytes, waiting 515624 usec
01 Jan 2019 17:11:16 conn_loop(): select(): max_sd = 4, t_out = 000000:515624
01 Jan 2019 17:11:16 conn_loop(): select() returns 1
01 Jan 2019 17:11:16 tty: read 7 bytes
01 Jan 2019 17:11:16 tty: rx offset is 0
01 Jan 2019 17:11:16 tty: read 7 bytes of 7, offset 0
01 Jan 2019 17:11:16 tty: state now is TTY_PROC
01 Jan 2019 17:11:16 tty: response read (total 7 bytes, offset 0 bytes)
01 Jan 2019 17:11:16 tty: response is correct
01 Jan 2019 17:11:16 tty: response: [03][03][02][00][01][00][44]
01 Jan 2019 17:11:16 conn[127.0.0.1]: state now is CONN_RESP
01 Jan 2019 17:11:16 tty: state now is TTY_PAUSE
01 Jan 2019 17:11:16 conn_loop(): select(): max_sd = 5, t_out = 000000:100000
01 Jan 2019 17:11:16 conn_loop(): select() returns 1
01 Jan 2019 17:11:16 conn[127.0.0.1]: state now is CONN_HEADER
01 Jan 2019 17:11:16 conn_loop(): select(): max_sd = 5, t_out = 000000:099508
01 Jan 2019 17:11:16 conn_loop(): select() returns 1
01 Jan 2019 17:11:16 conn_close(): closing connection from 127.0.0.1
01 Jan 2019 17:11:16 queue_delete_elem(): length now is 0
01 Jan 2019 17:11:16 conn_loop(): select(): max_sd = 4, t_out = 000000:098566
01 Jan 2019 17:11:16 conn_loop(): select() returns 0
01 Jan 2019 17:11:16 tty: state now is TTY_READY
01 Jan 2019 17:11:16 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped 0 bytes
01 Jan 2019 17:11:23 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
01 Jan 2019 17:11:23 conn_loop(): select() returns 1
01 Jan 2019 17:11:23 tty: dropped

Connecting Modbus RTU master to Modbus TCP slave

Hi,

Could you please let me know if I can use your gateway for connecting a Modbus RTU master (RS-485 interface) to a Modbus TCP slave (Ethernet interface, acts as a TCP server)? For example, can mbusd work as a TCP client and connect to a remote TCP server?

Thanks,
Maks.

Modbus function 6 response reading error

Спасибо большое за оперативный ответ!

Собрал новую версию. С настройками связи тут все нормально, так как чтение с регистров идет на УРА!
Но вот с записью та же проблема - после попытки изменить регистр 6 функцией вылетает ошибка, а демон зацикливается.

Запускал так: sudo mbusd -p /dev/ttyUSB0 -s 9600 -P 502 -d -v9

mbus.txt

debug option to see modbus info from serial device

Is there any way to log what mbusd is retrieving via /dev/ttyUSB0 before it is encapsulating into tcpip. Also because im kind of new to this, how would my scada system need to communicate with a device that only understood rtu? Would i need to create a device that read rtu over tcp or does mbusd treat it as actual modbus tcp? The configuration i have is ... ignition scada system ->vpn-concentrator ->celular lte modem->raspbeerypie vpn client->raspberrypie-mbusd->/dev/ttyUSB0 ->waterlog-350xl(waterlogger). I can trace packets at each of the vpn end points and everything seems to be going ok but i cannot see what mbusd is getting and sending (not at the mbusd device anyway) If that makes any sence.

Abnormal function on RPI

I'm having problems trying to running mbusd on RPI with ScadaBR. Here my setup:

image

I made one mod on the PCB that converts RS485 to serial to suporto 3.3V, it works, but sometimes i have problems.

image

I'm have two of those making the conection between Rpi and energy meter

image

Without them, the conection works nice, but with them i have the following messages

Jul 28 23:38:30 raspberrypi mbusd[954]: 28 Jul 2019 23:38:30 conn_open(): accepting connection from 127.0.0.1
Jul 28 23:38:30 raspberrypi mbusd[954]: 28 Jul 2019 23:38:30 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:30 raspberrypi mbusd[954]: 28 Jul 2019 23:38:30 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:30 raspberrypi mbusd[954]: 28 Jul 2019 23:38:30 tty: error in read() (port closed)
Jul 28 23:38:30 raspberrypi mbusd[954]: 28 Jul 2019 23:38:30 tty: error in read() (port closed)
Jul 28 23:38:31 raspberrypi mbusd[954]: 28 Jul 2019 23:38:31 tty: error in read() (port closed)
Jul 28 23:38:33 raspberrypi mbusd[954]: 28 Jul 2019 23:38:33 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:33 raspberrypi mbusd[954]: 28 Jul 2019 23:38:33 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:33 raspberrypi mbusd[954]: 28 Jul 2019 23:38:33 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:33 raspberrypi mbusd[954]: 28 Jul 2019 23:38:33 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:36 raspberrypi mbusd[954]: 28 Jul 2019 23:38:36 tty: error in read() (port closed)
Jul 28 23:38:36 raspberrypi mbusd[954]: 28 Jul 2019 23:38:36 tty: error in read() (port closed)
Jul 28 23:38:36 raspberrypi mbusd[954]: 28 Jul 2019 23:38:36 tty: error in read() (port closed)
Jul 28 23:38:39 raspberrypi mbusd[954]: 28 Jul 2019 23:38:39 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:39 raspberrypi mbusd[954]: 28 Jul 2019 23:38:39 tty: error in read() (port closed)
Jul 28 23:38:39 raspberrypi mbusd[954]: 28 Jul 2019 23:38:39 tty: error in read() (port closed)
Jul 28 23:38:41 raspberrypi mbusd[954]: 28 Jul 2019 23:38:41 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:41 raspberrypi mbusd[954]: 28 Jul 2019 23:38:41 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:41 raspberrypi mbusd[954]: 28 Jul 2019 23:38:41 tty: error in read() (port closed)
Jul 28 23:38:41 raspberrypi mbusd[954]: 28 Jul 2019 23:38:41 tty: error in read() (port closed)
Jul 28 23:38:41 raspberrypi mbusd[954]: 28 Jul 2019 23:38:41 tty: error in read() (port closed)
Jul 28 23:38:44 raspberrypi mbusd[954]: 28 Jul 2019 23:38:44 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:44 raspberrypi mbusd[954]: 28 Jul 2019 23:38:44 tty: error in read() (port closed)
Jul 28 23:38:44 raspberrypi mbusd[954]: 28 Jul 2019 23:38:44 tty: error in read() (port closed)
Jul 28 23:38:47 raspberrypi mbusd[954]: 28 Jul 2019 23:38:47 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:47 raspberrypi mbusd[954]: 28 Jul 2019 23:38:47 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:47 raspberrypi mbusd[954]: 28 Jul 2019 23:38:47 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:47 raspberrypi mbusd[954]: 28 Jul 2019 23:38:47 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:47 raspberrypi mbusd[954]: 28 Jul 2019 23:38:47 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:49 raspberrypi mbusd[954]: 28 Jul 2019 23:38:49 tty: error in read() (port closed)
Jul 28 23:38:49 raspberrypi mbusd[954]: 28 Jul 2019 23:38:49 tty_reopen(): can't open tty device /dev/ttyS0 (Input/output error)
Jul 28 23:38:49 raspberrypi mbusd[954]: 28 Jul 2019 23:38:49 tty: error in read() (port closed)
Jul 28 23:38:52 raspberrypi mbusd[954]: 28 Jul 2019 23:38:52 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:52 raspberrypi mbusd[954]: 28 Jul 2019 23:38:52 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:52 raspberrypi mbusd[954]: 28 Jul 2019 23:38:52 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:52 raspberrypi mbusd[954]: 28 Jul 2019 23:38:52 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:55 raspberrypi mbusd[954]: 28 Jul 2019 23:38:55 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:55 raspberrypi mbusd[954]: 28 Jul 2019 23:38:55 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:55 raspberrypi mbusd[954]: 28 Jul 2019 23:38:55 tty: error in read() (Resource temporarily unavailable)
Jul 28 23:38:57 raspberrypi mbusd[954]: 28 Jul 2019 23:38:57 tty: error in read() (port closed)
Jul 28 23:38:57 raspberrypi mbusd[954]: 28 Jul 2019 23:38:57 tty: error in read() (port closed)
Jul 28 23:38:57 raspberrypi mbusd[954]: 28 Jul 2019 23:38:57 tty: error in read() (port closed)

With USB dongle showed on the first photo, the system works, but not flawless. I have thoughts that mbusd doesn't read config file correctly

My conf file is:

device = /dev/ttyS0
speed = 9600
mode = 8n1
trx_control = rts
address = 0.0.0.0
port = 502
maxconn = 32
timeout = 60
retries = 0
pause = 2000
wait = 2000

Thanks!

mbusd uart

Hello
Tell me how to connect and configure Mbusd
I have Loxberry installed
trying to connect modbus to UART 0 or Uart1 Raspberry pi
port / dev / ttyAMA0
/ dev / ttyS0
tell me where to change what settings?

does mbusd support RS422

Hi,

The introduction of mbusd mentioned it is RS232/RS485 Modbus Gateway.
Because RS485 and RS422 are a little different in half-duplex and full-duplex, does mbusd also have RS422 Modbus Gateway function ?

Regards,
shaotang

file INSTALL cannot copy file

I'm running Installation instructions to the last step
"sudo make install"
I got some error below

➜ build git:(master) sudo make install
Password:
[100%] Built target mbusd
Install the project...
-- Install configuration: ""
-- Installing: /usr/bin/mbusd
CMake Error at cmake_install.cmake:36 (file):
file INSTALL cannot copy file
"/Users/willy/Documents/Vulnerabilities_Scan/mbusd.git/build/mbusd" to
"/usr/bin/mbusd".

How can I fix it?
Thanks~

Concurrent connections fail

I've noticed that if I have 2 clients with overlapping connections, one will fail. Is it possible to queue requests and service them all in turn?

Problems changing parity

I have mbusd setups working well with default 8N1 option.
When I try to config with Odd (-m 8O1) or Even (-m 8E1) parity, it's not working properly.
It seems I always can communicate with my devices with 8N1 setup no matter what '-m' option I choose, but never been able to talk with 8E1 or 8O1 devices.
EDIT1: Compiled with default 8O1 on tty.h and showing it on mbusd -h but no changes, tty is working in 8N1 mode

cmake is heavyweight

Running the latest version of cmake is a heavy requirement to build in place on embedded and older systems. Building it really just comes down to:

gcc *.c -DPACKAGE=\"mbusd\" -DVERSION=\"fromGIT20180104\" -DLOG -DTRXCTL -DDEBUG -o mbusd

Basic understanding

Hello!

Could not get mbusd to work.
The request ([c8][03][00][01][00][01]) seems to be ok but there is a "tty: response timeout".
(tested with -v9 which gave no further information what is sent to serial device)
Maybe i do not understand the basic functionality of mbusd.
Is it the same as modbusgw?
Which is working but has a huge memory leak.

-m option not documented in mbusd's man page

Hi,
I was looking for a configuration option for serial parity bits and only found it in the source code. Maybe it should be added to the man page as well.

Best regards & thanks for the good work

Windows port

Hi. I'm very interested in your project as I was about to code the exact same thing but for windows.

I readed here that it's possible to run this app under Cygwin. Could you please orient me how to do that? I need to access a couple of Modbus/RTU devices from the net and found this to be the best choice to do that.

Thanks for sharing!

Flow Control with RTS pulled HIGH

Have been running with a USB -> RS485 adapter on a Rpi for a while now without issues. This adapter supports ADDC or at least it works with that config.

Am now busy trying a RS485 Module ( TTL -> RS485 based on MAX481 chipset) directly connected to Rpi serial0 on GPIO 8 & 10, so no flow control. RTS is pulled high on the module itself and I can't get it to communicate.

Would I have to use file based flow control in this case?

RTU/ASCII protocol selection and Modbus Master Mode questions

Hi,

We have checked Advantech EKI-122x Modbus gateway device and have two questions want to raise.

  1. The mbusd does not have RTU/ASCII protocol selection in parameter list. Why users do not need to specify the RTU/ASCII mode for mbusd ?

  2. There are two kinds of Modbus gateway as below. It seems mbusd support slave mode, will it support master mode in the future?

(1) master mode: translate RTU/ASCII to TCP
[SCADA Server]---serial---[DUT]----ethernet---[PLC]

(1) slave mode: translate TCP to RTU/ASCII
[PLC]---serial---[DUT]----ethernet---[SCADA Server]

Thanks for your advice.

Regards,
Shaotang

mbusd getting hanged behind Ubuntu loaded on VirtualBox ( VM )

Hi,

I installed successfully now, it works intialy good for 5-10 seconds and then program mbusd needs to be restarted again

Not sure what the issue , though there is only one master polling. I see following messages continuously

7 Sep 2018 18:59:00 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:05 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:10 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:15 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:20 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:25 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:30 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:35 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:40 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:45 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:50 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 18:59:55 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 19:00:00 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 19:00:03 conn[10.0.2.2]: timeout, closing connection
27 Sep 2018 19:00:03 conn_close(): closing connection from 10.0.2.2
27 Sep 2018 19:00:05 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 19:00:07 conn[10.0.2.2]: timeout, closing connection
27 Sep 2018 19:00:07 conn_close(): closing connection from 10.0.2.2
27 Sep 2018 19:00:10 conn_open(): accepting connection from 10.0.2.2
27 Sep 2018 19:00:11 conn[10.0.2.2]: timeout, closing connection
27 Sep 2018 19:00:11 conn_close(): closing connection from 10.0.2.2

questions about the parameters

Hi Expert,

Could we ask some questions about the parameters provided ?
The testbed should be as below.
PC(Modbus Client)---------DUT(Modbus Server-Modbus Gateway-Modbus Master)-------Modbus Slaver

-N retries
Specifies maximum number of request retries (0 disables retries).
==> does this parameters for the interface between DUT and Modbus Slaver, and if request sent to Modbus slaver fail or timeout, it will retry?

-R pause
Specifies pause between requests in milliseconds.
==> The request is from PC(Modbus Client) to Modbus Slaver device. Does it mean the codebase can add some milliseconds when DUT receive request from PC, and then send to Modbus Slaver ?

-W wait
Specifies response wait time in milliseconds.
==> Does this parameters for TCP connection between PC and DUT?
Does it mean wait time for each Modbus command?

-T timeout
Specifies connection timeout value in seconds (0 disables timeout).
==> Does this parameters for TCP connection between PC and DUT?
TCP connection timeout socket parameter.

Regards,
shaotang

Readable socket never gets read, conn_loop degrades into busy loop

Hi,

we recently noticed some strange behaviour of mbusd in some of our more complex multimaster setups.
We use mbusd to read multiple devices one rtu bus from multiple modbus tcp masters.

After working flawlessly for some time, we noticed to mbusd started to cause a suspicious amount of cpu load.

Since this a production system and mbusd was compiled without the debug option,
I tried strace and observed the following sequence of syscalls:

$ strace -p $(pidof mbusd) -e _newselect, read
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=532417}) = 1 (in [8], left {tv_sec=0, tv_usec=532409})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=532122}) = 1 (in [8], left {tv_sec=0, tv_usec=532115})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=531826}) = 1 (in [8], left {tv_sec=0, tv_usec=531819})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=531533}) = 1 (in [8], left {tv_sec=0, tv_usec=531526})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=531242}) = 1 (in [8], left {tv_sec=0, tv_usec=531235})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=530950}) = 1 (in [8], left {tv_sec=0, tv_usec=530943})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=530655}) = 1 (in [8], left {tv_sec=0, tv_usec=530648})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=530364}) = 1 (in [8], left {tv_sec=0, tv_usec=530358})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=530072}) = 1 (in [8], left {tv_sec=0, tv_usec=530065})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=529778}) = 1 (in [8], left {tv_sec=0, tv_usec=529771})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=529483}) = 1 (in [8], left {tv_sec=0, tv_usec=529476})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=529190}) = 1 (in [8], left {tv_sec=0, tv_usec=529184})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=528899}) = 1 (in [8], left {tv_sec=0, tv_usec=528893})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=528604}) = 1 (in [8], left {tv_sec=0, tv_usec=528597})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=528309}) = 1 (in [8], left {tv_sec=0, tv_usec=528302})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=527991}) = 1 (in [8], left {tv_sec=0, tv_usec=527984})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=527694}) = 1 (in [8], left {tv_sec=0, tv_usec=527687})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=527402}) = 1 (in [8], left {tv_sec=0, tv_usec=527395})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=527109}) = 1 (in [8], left {tv_sec=0, tv_usec=527102})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=526815}) = 1 (in [8], left {tv_sec=0, tv_usec=526808})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=526520}) = 1 (in [8], left {tv_sec=0, tv_usec=526513})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=526225}) = 1 (in [8], left {tv_sec=0, tv_usec=526218})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=525931}) = 1 (in [8], left {tv_sec=0, tv_usec=525924})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=525640}) = 1 (in [8], left {tv_sec=0, tv_usec=525634})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=525347}) = 1 (in [8], left {tv_sec=0, tv_usec=525340})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=525055}) = 1 (in [8], left {tv_sec=0, tv_usec=525048})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=524761}) = 1 (in [8], left {tv_sec=0, tv_usec=524754})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=524470}) = 1 (in [8], left {tv_sec=0, tv_usec=524463})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=524179}) = 1 (in [8], left {tv_sec=0, tv_usec=524172})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=523885}) = 1 (in [8], left {tv_sec=0, tv_usec=523878})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=523593}) = 1 (in [8], left {tv_sec=0, tv_usec=523586})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=523300}) = 1 (in [8], left {tv_sec=0, tv_usec=523294})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=523007}) = 1 (in [8], left {tv_sec=0, tv_usec=523001})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=522716}) = 1 (in [8], left {tv_sec=0, tv_usec=522709})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=522422}) = 1 (in [8], left {tv_sec=0, tv_usec=522416})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=522128}) = 1 (in [8], left {tv_sec=0, tv_usec=522121})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=521835}) = 1 (in [8], left {tv_sec=0, tv_usec=521828})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=521543}) = 1 (in [8], left {tv_sec=0, tv_usec=521537})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=521249}) = 1 (in [8], left {tv_sec=0, tv_usec=521243})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=520957}) = 1 (in [8], left {tv_sec=0, tv_usec=520950})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=520666}) = 1 (in [8], left {tv_sec=0, tv_usec=520659})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=520374}) = 1 (in [8], left {tv_sec=0, tv_usec=520367})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=520081}) = 1 (in [8], left {tv_sec=0, tv_usec=520074})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=519789}) = 1 (in [8], left {tv_sec=0, tv_usec=519782})
_newselect(9, [3 4 5 6 8], [], NULL, {tv_sec=0, tv_usec=519498}) = 1 (in [8], left {tv_sec=0, tv_usec=519491})

As you can see the fd 8 has data pending to be read but no read syscall occurs.
mbusd did not recover until I killed the process responsible for the tcp connection behind 8.

I replicated the scenario on a test system with a debug build:

04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475635 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475581 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475528 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475475 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475422 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475368 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475314 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475259 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475205 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475152 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475099 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:475045 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474990 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474937 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474883 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474829 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474773 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474720 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474666 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474612 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474558 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474503 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474449 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474394 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474341 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474286 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474233 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474179 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474126 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474072 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:474019 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473965 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473911 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473857 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473802 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473749 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473694 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473640 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473586 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 
04 Jul 2019 15:17:58 conn_loop(): select(): max_sd = 8, t_out = 000000:473533 
04 Jul 2019 15:17:58 conn_loop(): select() returns 2 

The strace output looked similar to one above.
I can reliably recreate this situation regardless of the hardware used (rs485 adapter and modbus rtu devices), by connecting 4 modbus TCP clients and then causing a timeout on the rtu bus (eg. by power-cycling the rtu device).

Naturally I did some prodding and poking to see why this one socket descriptors never gets read.
I changed the logging to print conn->sd instead of the ip address and added some log messages at interesting points in the code.
Relevant for the following explanation are two of those changes:

  1. Logging of the sds in sdsetrd and sdsetwr after the select and the state of the corresponding connection. See here
  2. Logging of curconn->sd in the while loop servicing the tcp connections See here.

Triggering the problem with those changes in place resulted in this output:

05 Jul 2019 14:38:40 conn_loop(): select(): max_sd = 8, t_out = 000000:083186 
05 Jul 2019 14:38:40 conn_loop(): select() returns 1 
05 Jul 2019 14:38:40 conn[8]: can read.
05 Jul 2019 14:38:40 conn[8]: state is CONN_HEADER
05 Jul 2019 14:38:40 conn[5] is being serviced.
05 Jul 2019 14:38:40 conn[6] is being serviced.
05 Jul 2019 14:38:40 conn[7] is being serviced.
05 Jul 2019 14:38:40 conn[7] is being serviced.
05 Jul 2019 14:38:40 conn_loop(): select(): max_sd = 8, t_out = 000000:083167 
05 Jul 2019 14:38:40 conn_loop(): select() returns 1 
05 Jul 2019 14:38:40 conn[8]: can read.
05 Jul 2019 14:38:40 conn[8]: state is CONN_HEADER
05 Jul 2019 14:38:40 conn[5] is being serviced.
05 Jul 2019 14:38:40 conn[6] is being serviced.
05 Jul 2019 14:38:40 conn[7] is being serviced.
05 Jul 2019 14:38:40 conn[7] is being serviced.
05 Jul 2019 14:38:40 conn_loop(): select(): max_sd = 8, t_out = 000000:083148 
05 Jul 2019 14:38:40 conn_loop(): select() returns 1 
05 Jul 2019 14:38:40 conn[8]: can read.
05 Jul 2019 14:38:40 conn[8]: state is CONN_HEADER
05 Jul 2019 14:38:40 conn[5] is being serviced.
05 Jul 2019 14:38:40 conn[6] is being serviced.
05 Jul 2019 14:38:40 conn[7] is being serviced.
05 Jul 2019 14:38:40 conn[7] is being serviced.

As you can see the while loop iterates twice of the connection with sd 7, but never reaches the one with 8.
This means there is a control flow path through the switch statement for the connection state,
which skips the curconn = queue_next_elem(&queue, curconn); in lines 860 or 878.
Hence the sd 8 is never read and the next select statement terminates immediately.

Due to the complexity of the of the control flow in this section of the code I have been unable to determine the exact path leading to this problem.
Likely an additional break somewhere, but I'm not confident that I understand the code well enough to spot it.

However the condition of the surrounding while(len--) loop suggests that it was never intended to iterate over the same connection twice.
Therefore I would propose to move the curconn = queue_next_elem(&queue, curconn); out of the switch statement and into the while loop, since curconn has to advance regardless of the connections state.
See this commit.

After applying this fix, I have not been able to reproduce the busy loop behaviour.

This might also partially explain the behaviour described in #41

can this tool acts as a tcp client?

i want to use mbusd to transfer modbus tcp to modbus rtu, could you add a feature that mbusd as a tcp client connect to iot server on internet? in many cases most of iot devices in LAN ,sever on internet

Patch to support extended baud rates

I ask you to add the following patch to support 230400, 500000 and 1000000 Baud.
I have successfully tested these speeds on Fedora 31 and Raspbian 10.
The patch is for version 0.4.0.

--- src/tty.c.orig	2020-07-13 18:48:41.397491648 +0200
+++ src/tty.c	2020-07-16 20:06:23.600114131 +0200
@@ -306,6 +306,21 @@
     tspeed = B115200;
     break;
 #endif
+#if defined(B230400)
+  case 230400:
+    tspeed = B230400;
+    break;
+#endif
+#if defined(B500000)
+  case 500000:
+    tspeed = B500000;
+    break;
+#endif
+#if defined(B1000000)
+  case 1000000:
+    tspeed = B1000000;
+    break;
+#endif
   default:
     tspeed = DEFAULT_BSPEED;
     break;

On Broadcast write mbusd wait's for feedback and provides feedback

A write to unitId 0 is considered a broadcast and no devices should acknowledge although mbusd wait's for a response from servers, which it should not do as the servers are not allowed to acknowledge this.

This leads also to resends due to the time-outs and blocks the bus during that time () of waiting 3 times for 8 bytes.

Log unpatched:

Jul 28 18:47:19 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:19 conn[192.168.1.55]: state now is CONN_RQST_FUNC
Jul 28 18:47:19 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:19 conn[192.168.1.55]: state now is CONN_RQST_TAIL
Jul 28 18:47:19 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:19 conn[192.168.1.55]: request: [00][05][00][e5][ff][00]
Jul 28 18:47:19 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:19 conn[192.168.1.55]: state now is CONN_TTY
Jul 28 18:47:19 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:19 tty: state now is TTY_RQST
Jul 28 18:47:19 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:19 tty: state now is TTY_RESP
Jul 28 18:47:19 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:19 tty: estimated 8 bytes, waiting 508332 usec
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: response timeout
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: attempt to retry request (1 of 3)
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: state now is TTY_RQST
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: state now is TTY_RESP
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: estimated 8 bytes, waiting 508332 usec
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: response timeout
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: attempt to retry request (2 of 3)
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: state now is TTY_RQST
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: state now is TTY_RESP
Jul 28 18:47:20 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:20 tty: estimated 8 bytes, waiting 508332 usec
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 tty: response timeout
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 tty: attempt to retry request (3 of 3)
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 tty: state now is TTY_RQST
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 tty: state now is TTY_RESP
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 tty: estimated 8 bytes, waiting 508332 usec
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 conn[192.168.1.55]: state now is CONN_RQST_FUNC
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 conn[192.168.1.55]: state now is CONN_RQST_TAIL

# read starts within the broadcast cycle after 2 seconds wait!
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 conn[192.168.1.55]: request: [14][04][00][08][00][03]
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 conn[192.168.1.55]: state now is CONN_TTY
Jul 28 18:47:21 bpi-iot-ros-ai mbusd[30096]: 28 Jul 2020 18:47:21 tty: response timeout

solution tested for FC05 broadcast

diff --git a/src/conn.c b/src/conn.c
index 6540da7..d52a83a 100644
--- a/src/conn.c
+++ b/src/conn.c
@@ -556,35 +556,50 @@ conn_loop(void)
 #ifdef DEBUG
           logw(7, "tty: request written (total %d bytes)", tty.txlen);
 #endif
-          state_tty_set(&tty, TTY_RESP);
-          switch (tty.txbuf[1]) {
-            case 1:
-            case 2:
-              tty.rxlen = 5 + (tty.txbuf[4] * 256 + tty.txbuf[5] + 7)/8;
-              break;
-            case 3:
-            case 4:
-              tty.rxlen = 5 + tty.txbuf[5] * 2;
-              break;
-            case 7:
-              tty.rxlen = 5;
-              break;
-            case 11:
-            case 15:
-            case 16:
-              tty.rxlen = 8;
-              break;
-            default:
-              tty.rxlen = tty.txlen;
-              break;
-          }
-          if (tty.rxlen > TTY_BUFSIZE)
-            tty.rxlen = TTY_BUFSIZE;
-          tty.timer += DV(tty.rxlen, tty.bpc, tty.speed);
+		  if (tty.txbuf[1]==5 && tty.txbuf[0]==0 )
+		  { // broadcast FC05
+			  // DANNY at work
+			  tty.rxlen=0;
+			  logw(5, "tty: Done, Broadcast");
+			  tty.timer=0;
+			  tcflush(tty.fd, TCIFLUSH);
+			  state_tty_set(&tty, TTY_PAUSE);
+			  state_conn_set(actconn, CONN_HEADER);
+			  continue;
+		  }
+		  else
+		  {
+				state_tty_set(&tty, TTY_RESP);
+			  switch (tty.txbuf[1]) {
+				case 1:
+				case 2:
+				  tty.rxlen = 5 + (tty.txbuf[4] * 256 + tty.txbuf[5] + 7)/8;
+				  break;
+				case 3:
+				case 4:
+				  tty.rxlen = 5 + tty.txbuf[5] * 2;
+				  break;
+				case 7:
+				  tty.rxlen = 5;
+				  break;
+				case 11:
+				case 15:
+				case 16:
+				  tty.rxlen = 8;
+				  break;
+				default:
+				  tty.rxlen = tty.txlen;
+				  break;
+			  }
+				
+			  if (tty.rxlen > TTY_BUFSIZE)
+				tty.rxlen = TTY_BUFSIZE;
+			  tty.timer += DV(tty.rxlen, tty.bpc, tty.speed);
 #ifdef DEBUG
-          logw(5, "tty: estimated %d bytes, waiting %lu usec", tty.rxlen, tty.timer);
+			  logw(5, "tty: estimated %d bytes, waiting %lu usec", tty.rxlen, tty.timer);
 #endif
-        }
+			}
+		}
       }
 
     if (FD_ISSET(tty.fd, &sdsetrd))

Log with patched version:

Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select() returns 1
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn[192.168.1.55]: state now is CONN_RQST_FUNC
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select(): max_sd = 5, t_out = 000060:000000
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select() returns 1
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn[192.168.1.55]: read request fc 5
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn[192.168.1.55]: state now is CONN_RQST_TAIL
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn[192.168.1.55]: request: [00][05][00][e5][ff][00]
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn[192.168.1.55]: state now is CONN_TTY
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 tty: state now is TTY_RQST
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select() returns 1
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 tty: written 8 bytes
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 tty: request written (total 8 bytes)
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 tty: Done, Broadcast
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 tty: state now is TTY_PAUSE
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn[192.168.1.55]: state now is CONN_HEADER
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select(): max_sd = 5, t_out = 000000:100000
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select() returns 0
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 tty: state now is TTY_READY
Jul 29 00:05:50 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:50 conn_loop(): select(): max_sd = 5, t_out = 000060:000000
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select() returns 1
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn[192.168.1.55]: state now is CONN_RQST_FUNC
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select(): max_sd = 5, t_out = 000060:000000
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select() returns 1
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn[192.168.1.55]: read request fc 4
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn[192.168.1.55]: state now is CONN_RQST_TAIL

# read after broadcast start
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn[192.168.1.55]: request: [14][04][00][08][00][03]
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn[192.168.1.55]: state now is CONN_TTY
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: state now is TTY_RQST
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select(): max_sd = 4, t_out = 000060:000000
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select() returns 1
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: written 8 bytes
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: request written (total 8 bytes)
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: state now is TTY_RESP
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: estimated 11 bytes, waiting 509895 usec
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select(): max_sd = 4, t_out = 000000:509895
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select() returns 1
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: read 11 bytes
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: rx offset is 0
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: read 11 bytes of 11, offset 0
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: state now is TTY_PROC
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: response read (total 11 bytes, offset 0 bytes)
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: response is correct
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: response: [14][04][06][05][53][05][53][fe][99][66][8d]
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn[192.168.1.55]: state now is CONN_RESP
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: state now is TTY_PAUSE
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select(): max_sd = 5, t_out = 000000:100000
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select() returns 1
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn[192.168.1.55]: state now is CONN_HEADER
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select(): max_sd = 5, t_out = 000000:099446
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select() returns 0
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 tty: state now is TTY_READY
Jul 29 00:05:51 bpi-iot-ros-ai mbusd[18405]: 29 Jul 2020 00:05:51 conn_loop(): select(): max_sd = 5, t_out = 000060:000000

Result no more timeouts and a working solution.

  1. Please advice if that would be the apropriate place to do this.
  2. I only changed for FC05, according spec that should be for all writes.

Connection close on tty: response timeout

Hi there.
Let me congratulate you an excelent piece of software that i use on a daily basis.
And now to a problem that I have.

I have a small debian based PC running mbusd and connected to Modbus/CANBUS gateway over RS232.
Modbus/CANBUS gateway is connected over CANBUS to 20 devices.
Modbus queries to debian PC running your software I can read from all 20 devices over Modbus/TCP.

Problem starts is when one of CANBUS devices is switched off:
I am not a programmer or any expert, but it looks like this scenario somehow clogs up mbusd or Modbus/Gateway.

Clogs up, means I that Modbus reading goes fine with some CANBUS devices and doesn't work with others. Timeout setting doesn't seem to have any affect.

Software querying devices is not written by me and i have no idea how it operates, but works fine when all devices ur powered up.

For my test I disconneected all devices and started querying software on one, switched offdevice only.

mbus.log shows:

20 Jul 2018 12:53:01 tty: state now is TTY_PAUSE
20 Jul 2018 12:53:01 conn_loop(): select(): max_sd = 4, t_out = 000000:001000
20 Jul 2018 12:53:01 conn_loop(): select() returns 0
20 Jul 2018 12:53:01 tty: state now is TTY_READY
20 Jul 2018 12:53:01 conn_loop(): select(): max_sd = 4, t_out = 000010:000000
20 Jul 2018 12:53:11 conn_loop(): select() returns 0
20 Jul 2018 12:53:11 conn_loop(): select(): max_sd = 4, t_out = 000010:000000
20 Jul 2018 12:53:15 conn_loop(): select() returns 1
20 Jul 2018 12:53:15 conn_open(): accepting connection from 10.3.8.7
20 Jul 2018 12:53:15 queue_new_elem(): length now is 1
20 Jul 2018 12:53:15 conn[10.3.8.7]: state now is CONN_HEADER
20 Jul 2018 12:53:15 conn_loop(): select(): max_sd = 5, t_out = 000010:000000
20 Jul 2018 12:53:15 conn_loop(): select() returns 1
20 Jul 2018 12:53:15 conn[10.3.8.7]: state now is CONN_RQST_FUNC
20 Jul 2018 12:53:15 conn[10.3.8.7]: read request fc 3
20 Jul 2018 12:53:15 conn[10.3.8.7]: state now is CONN_RQST_TAIL
20 Jul 2018 12:53:15 conn[10.3.8.7]: request: [14][03][00][a2][00][01]
20 Jul 2018 12:53:15 conn[10.3.8.7]: state now is CONN_TTY
20 Jul 2018 12:53:15 tty: state now is TTY_RQST
20 Jul 2018 12:53:15 conn_loop(): select(): max_sd = 4, t_out = 000010:000000
20 Jul 2018 12:53:15 conn_loop(): select() returns 1
20 Jul 2018 12:53:15 tty: written 8 bytes
20 Jul 2018 12:53:15 tty: request written (total 8 bytes)
20 Jul 2018 12:53:15 tty: state now is TTY_RESP
20 Jul 2018 12:53:15 tty: estimated 7 bytes, waiting 4015624 usec
20 Jul 2018 12:53:15 conn_loop(): select(): max_sd = 4, t_out = 000004:015624
20 Jul 2018 12:53:19 conn_loop(): select() returns 0
20 Jul 2018 12:53:19 tty: response timeout
20 Jul 2018 12:53:19 conn_close(): closing connection from 10.3.8.7
20 Jul 2018 12:53:19 queue_delete_elem(): length now is 0
20 Jul 2018 12:53:19 conn_loop(): select(): max_sd = 4, t_out = 000004:015624
20 Jul 2018 12:53:23 conn_loop(): select() returns 0
20 Jul 2018 12:53:23 tty: response timeout

I have no idea what this log means :) All i know that device is not there and when I use standard libmodbus example Modbus/Gateway responds:
./modbus_client --debug -mtcp -t0x03 -a13 -r13 -p502 10.3.8.6 -c1
Connecting to 10.3.8.6:502
[00][01][00][00][00][06][0D][03][00][0D][00][01]
Waiting for a confirmation...
ERROR Connection timed out: select
ERROR occured!

Is there any modification in conn.c I can do for mbusd to drop a connection like that go to the next one in the que without retrying anything?

My mbusd start line is:
/usr/bin/mbusd -v 0 -p /dev/ttyO0 -P 502 -s 9600 -R 1 -T 5 -C 128 -N 3

Kind regards

Delay after sending frame via tty

Hi!
Faced with trouble when sending frames via tty with parity enabled. RTS changes with gpio via sysfs. The solution was in extending delay after sending frame otherwise RTS changes every time on last byte and corrupt it. Maybe delay was calculated not taking into account that parity add extra bit to frame?

Request to set address

This looks like a really nice, small and highly usable utility. Compliments!

To my surprise, there is no way to set an IP address, is that correct? At the very least localhost would be interesting.

Also, I would appreciate IPv6 support, though in reality I would probably add an access-constraining gateway that could limit World access. I'd then run this daemon on localhost only.

Although I doubt you'll need it, here is some code similar to your socket module that I wrote elsewhere:
https://gitlab.com/arpa2/kip/blob/initial/src/socket.c
You're welcome to use (any part of) this, of course.

Concurrency issues?

I used to get crashes when logging "conn_open(): error in accept()", in particular, the call strerror(errno) crashes. After some reading it seems strerr is not re-entrant safe http://stackoverflow.com/questions/900338/why-cant-i-use-strerror. I am not sure if re-entrancy is the cause of the crash but after removing the function call and logging only errno, the software doesn't crash anymore.

However, it still sometimes get the error:
1485184829:392664 conn_open(): error in accept() (11)
1485184829:413938 tty: error in read() (11)
and sometimes only the accept error without the tty error.
I'll get the error more often if I use two clients to make requests.

I wonder if this error is caused by re-entrancy issues? Maybe there is a need to put mutexes on some function calls to make them thread safe?

Have doubt about the software

Hi,

Suppose I have 12 slave devices connected on RTU , how will I select the slave device for whose data I want to read via TCP modbus ?

FC-16 Write Multiple Holding Registers fails

As per the ReadMe.md neither writing a single register or multiple registers are supported.

There is a statement:

"Please note all other function codes (including vendor-specific extensions) are supported on a "best-effort" basis and most likely will fail."

I would like to extend this to support writing multiple register requests, where do you feel the shortcomings are specifically?

Interestingly the problem I experience is writing a single register (Function Code 6) works but an app that I am trying to use the gateway with is writing a single register using Write Multiple Holding Registers (Function Code 16) and this fails.

General starting problem

Sorry for posting here an issue but i did not found any discussion-forums.

I tried to get mbusd working on arm-linux (mbusd -s 19200 -d -p /dev/ttyAMA0 -v 9 -m 8N1) and get the following error:

1454870063:339873 conn_open(): accepting connection from 10.0.0.222
1454870063:340152 queue_new_elem(): length now is 1
1454870063:340529 conn[10.0.0.222]: state now is CONN_HEADER
1454870063:340804 conn_loop(): select(): max_sd = 5, t_out = 000060:000000 
1454870063:342242 conn_loop(): select() returns 1 
1454870063:342785 conn[10.0.0.222]: state now is CONN_RQST
1454870063:343036 conn[10.0.0.222]: state now is CONN_TTY
1454870063:343256 tty: state now is TTY_RQST
1454870063:344516 conn_loop(): select(): max_sd = 4, t_out = 000060:000000 
1454870063:344862 conn_loop(): select() returns 1 
1454870063:351361 tty: written 8 bytes
1454870063:352617 tty: request written (total 8 bytes)
1454870063:353804 tty: state now is TTY_RESP
1454870063:354926 tty: estimated 7 bytes, waiting 57811 used
1454870063:356035 conn_loop(): select(): max_sd = 4, t_out = 000000:057811 
1454870063:415078 conn_loop(): select() returns 0 
1454870063:416256 tty: response timeout

To ensure my modbus device is working, I wrote a short test program with libmodbus (modus_read_registers) which work as expected.

Can you please point me to the right direction where to start?

Robert

RTU over TCP?

Hi,

Can I use your tool to map Modbus TCP to Modbus RTU over an IP network?

I'm using an Ethernet to Serial adaptor so can use socat to create a virtual serial port over IP, but the packet format is still RTU and socat is a little unstable through resets.

I was looking for something that proxy Modbus TCP to RTU but use an IP network (TCP or UDP)

Can't run Make, make script links to specific automake/aclocal version

Trying to do a clean install of mbusd (cloned from git), once I get to the make step I run into the error below. This is on a clean install of the latest stable Debian (8) amd64, who's latest stable automake is 1.14.1. with aclocal 1.14.1

It is my understanding that make scripts shouldn't reference specific versions at all, for example:
http://stackoverflow.com/a/37669184

This is the output I get when I run make on a system with the latest debian stable automake/aclocal installed, 1.14


root@modbus:~/mbusd.git# make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /root/mbusd.git/missing aclocal-1.15 -I m4
/root/mbusd.git/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
http://www.gnu.org/software/automake
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
http://www.gnu.org/software/autoconf
http://www.gnu.org/software/m4/
http://www.perl.org/
Makefile:406: recipe for target 'aclocal.m4' failed
make: *** [aclocal.m4] Error 127


automake version:
root@modbus:~/mbusd.git# automake --version
automake (GNU automake) 1.14.1

aclocal version:
root@modbus:~/mbusd.git# aclocal --version
aclocal (GNU automake) 1.14.1

Mbusd as TCP client and TCP master at the same time

Hi. I have Modbus TCP slave which accept only one master and I would like to connect more to it. I believe it wouldn’t be that difficult for you gentleman to add extra function to mbusd to sort out this issue.
This might be useful to more people than me and could extend your great application by extra function?
Maybe you have any other ideas?
Big mbusd fan.
Kind regards

Need to know the services necessary to make mbusd work

I have a 2 pi's one with raspbian image and another with another image with less services.
mbusd is working fine on raspbian not on other image with less services.
Please let me know the services required to make it work. So i can install it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.