M503 modbusses
-
Hi,
Neuron M503 has two RS485 ports (1.1 and 2.1)
ls -la /dev/extcomm/1 gives 0 -> /dev/pts/1
ls -la /dev/extcomm/2 gives 0 -> /dev/pts/2So...does /dev/pts/1 point to port 1.1 and /dev/pts/2 to port 2.1?
Thx,
Vesa -
This is true for the UniPi overlay on GitHub. For our UniPian image they point to /dev/ttyNS[0...N] instead or /dev/pts/[0...N].
The pts serial ports cannot change parity, stop bits or support certain features, and are also slower, as they are done via software emulation in the Modbus server.
All of the RS485 ports should also be available in /dev/extcomm/0/[0...N]
-
-
I would recommend using the UniPian ( https://files.unipi.technology/s/public?path=%2FSoftware%2FOpen-Source Images ) if you are not already, as it includes our kernel drivers http://git.unipi.technology:3000/UniPi/neuron-kernel, which are much more robust than the PTS library. In particular speed and parity settings function properly. This is a drawback of the Linux PTS library, and there's really nothing we co do about it.
Other than that it's hard to know what's going wrong. We have successfully interfaced the Neuron RS485 with a very wide range of Modbus-based devices, but the protocol standards aren't always stringently followed. If possible try using a short twisted-pair cable and play with the terminator resistor settings. It's also possible that you may see problems due to electrical interference; one of our customer uses a Neuron to drive a heavy, electro-magnetically powered hydraulic press, which can cause the line to drop out momentarily under heavy interference. This can be mitigated with shielded cables, but I assume that's not an issue in this case.
e: It looks like the Modbus module uses Even parity by default. With the non-kernel PTS this has to be set via a register on the Neuron board https://files.unipi.technology/s/public?path=%2FProducts%2FNeuron%2FModbus Registers Maps#pdfviewer . The kernel drivers are able to handle it normally via TTY commands.
-
@tomas_knot
Hi,
Now i have UniPian-Neuron-OS-2018-03-09.img.zip in my SD. Actually meter is on my desk, so there is no any electro-magnetics :)
Kampstup Multical's Modbus address is 67 and it is connected to RS485 port 2.1
pi@M503-sn47:~ $ mbpoll /dev/extcomm/2/0 -a 67 mbpoll 1.3-3 - FieldTalk(tm) Modbus(R) Master Simulator Copyright (c) 2015 epsilonRT, All rights reserved. This software is governed by the CeCILL license <http://www.cecill.info> Protocol configuration: Modbus RTU Slave configuration...: address = [67] start reference = 1, count = 1 Communication.........: /dev/extcomm/2/0, 19200-8E1 t/o 1.00 s, poll rate 1000 ms Data type.............: 16-bit register, output (holding) register table -- Polling slave 67... Ctrl-C to stop) Read output (holding) register failed: Connection timed out -- Polling slave 67... Ctrl-C to stop) Read output (holding) register failed: Connection timed out -- Polling slave 67... Ctrl-C to stop) Read output (holding) register failed: Connection timed out
Any ideas?
Vesa
-
Do you see the RX light blink at all? That would indicate that a valid reply is being received.
You could try to whip a quick evok device definition to read the first 6 registers, or even better do it directly via a Modbus library, such as PyModbus. I doubt that mbpoll is going wrong, but I don't know it in detail.
The UART is ultimately done via off-the-shelf chips, and so there isn't much electrically that can go wrong.
You can find some information about the uart device in /sys/devices/platform/unipi_plc/.
e: If possible it might be a good idea to test it with the Mervis IDE first, which would help us rule out problems and capture the data travelling on the bus
-
@tomas_knot
Hi,
Actually TX light flashes every polling round.
Also there is no unipi_plc directory.
Vesa
-
Right - but does RX?
unipi_plc is only on the beta image, apologies
And I would try Mervis if possible. It has drivers done via a different library, and has better debugging facilities. Though if the RX light does not turn on Mervis won't be able to do much - it will just display constant timeouts.
e: More specifically no RX light means that there are no replies, TX light simply means that something is sent, regardless of whether the settings are correct or not.