search

simonvetter / modbus

Go modbus stack (client and server)
MIT License
286 stars 90 forks source link

Issue with reading when parity is EVEN #43

Open munnik opened 7 months ago

munnik commented 7 months ago

Hi,

Thank you for the great work with this library! I have an issue which I can't really understand. We have multiple installations with this Modbus slave https://www.emuag.ch/files/manual/1485_Manual_Modbus-Interface_Professional-II_EN.pdf. On one installation, I changed the default config of this device and set the parity from EVEN to NONE, like we are also using on other Modbus devices. When I use your library to collect data from this Modbus slave, everything works as expected.

On the next installations I didn't bother to change the config on the device but rather change the config of the software. So I changed the Modbus connection to use EVEN parity. This runs fine for a couple of minutes, but then I get protocol error errors. There are multiple locations in your code that can issue a protocol error so I'm not sure what is causing this error.

When I let our software run (it's a daemon) and on the command line issue this command modbus -s 1 -b 19200 -p 1 -P e /dev/ttyUSB4 8999 9000 (https://github.com/favalex/modbus-cli) the software starts to receive Modbus data again. I'm not sure what is going on. For now, I've created a cronjob that runs the modbus command every minute, that keeps the data flowing.

In the serial library you are using, there is a config option for RS485 https://github.com/goburrow/serial/blob/master/serial.go. But I'm unable to pass that through via your library. I'm also not sure if I can resolve my issue with this config option? More info is available at https://www.kernel.org/doc/html/latest/driver-api/serial/serial-rs485.html.

We are using your library without any issues to connect to https://www.aspar.com.pl/katalogi/IOMODULES/16I_en.pdf, they have set parity to NONE. And also to connect to Modbus slaves over TCP without any issues.

simonvetter commented 1 month ago

Hi Martijn,

thanks for the kind words!

Did you ever find the root cause of your issue ? Since it works for a while then mysteriously starts misbehaving, and since you can resume normal operation without restarting your daemon or target device, I'm wondering if something on your host might be modifying serial parameters. Are you sure no other process is attempting to open or change the serial port's configuration? Something like getty for example ? Or could the kernel be using the serial port as console? (look for "console=" in /proc/cmdline)

I have multiple linux and freebsd dataloggers running without issue, each with months of uptime, so this looks more like a local configuration issue than a bug, but you never know.