• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Problems with the communication of the RS485 interface
#1
Hello,
I use NIOT-E-NPI3-51-EN-RE with RS485 Interface NIOT-E-NPIX-RS485 Rev#2
The basic software on the netPI is balena with debian container and python3.

For enabling the RS485 interface GPIO17 is set to '1'.

I used the following python script for checking the communication:
Code:
import logging
from pymodbus.client.sync import ModbusSerialClient as ModbusClient #initialize a serial RTU client instance

client= ModbusClient(method = "RTU", port = "/dev/ttyS0", stopbits = 1, bytesize = 8, parity = 'N', baudrate = 9600, timeout=0.1)
connection = client.connect()

FORMAT = ('%(asctime)-15s %(threadName)-15s'
' %(levelname)-8s %(module)-15s:%(lineno)-8s %(message)s')
logging.basicConfig(format=FORMAT)
log = logging.getLogger()
log.setLevel(logging.DEBUG)

def processResponse(result):
   log.debug(result)

rr = client.read_holding_registers(0, 1, unit=0x01)
assert(not rr.isError())     # test that we are not an error
log.debug(rr)

client.close()


Now I have the problem that the communication with the device (in this case a temperature sensor) is not stable. Only every 3rd-5th read out is successful.
See attachment.

.txt   check_client_S0.txt (Size: 14.2 KB / Downloads: 5)


To check the correct operation of the installation, I checked the communication with the device using a normal USB-Modbus-Adapter on the same netPI.
In this case every read out is successful.

.txt   check_client_usb0.txt (Size: 11.67 KB / Downloads: 2)

May be someone has an idea, why the communication with the internal RS485 interface is not stable?

I checked the orginal node-red image for the nedPI. In this case 'rtu-buffered' must be used to get stable values. Otherwise the same problem occurs.

Thanks.
Peter
  Reply
#2
Well Peter,

first of all the physics:

In the NPIX manual located here https://www.netiot.com/fileadmin/user_up..._07_EN.pdf in the chapter 4. NIOT-E-NPIX-RS485 you see the schematics of the RS485 module's circuit. There is not much in it other than the gavanic isolation chip named SI8642BC-B-IS1 and in #REV2 the bus driver MAX13488E with auto-direction control if you set BCM17 = TX_EN to high state. I think you agree that this physical setup is straight and just forwarding signals BCM14 and BCM15 from and to the CPU. So from this point of view I can exclude a hardware problem.

As next I am very interested in your overall RS485 setup, cause I think you know that RS485 needs end termination at each end of the line, else the bus level does not automatially falls back to idle and prevents reflection on the wire as described here https://e2e.ti.com/blogs_/b/analogwire/a...t-properly. 120 ohms is the recommended value. It might be that you USB stick has a terminator integrated.
What I also see is that in all case the temperature sensor tries to send back a response ... this means sending through NPIX-RS485 works always, right?

Then to the software:

I guess setting Node-RED to "rtu-buffered" in the Modbus RTU node means that all Rx data that is received is first of all put in a internal buffer directly in the interrrupt service routine the time it is received instead of sending each byte by byte to the application. But this is only a guess. Maybe your python driver does not work the same. I don't know.

There is another thing: In general, the socalled Mini-UART used for this communication path has one big pitfall. It doesn't have its own clock source, so the UART bitrate depends on the CPU clock. Which means you have to set a fixed CPU clock for reliable communication. With original netPI OS we use the force_turbo=1 parameter in the config.txt to prevent the CPU clock from throttling, but I don't know if balena OS is supporting it as well.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
Thanks for your reply Smile

(April-28th-2020, 08:53 AM)Armin@netPI Wrote: ... that RS485 needs end termination at each end of the line ...
The temperature sensor has the possibility to use an internal 120 Ohm resistor. This function is activated.
It is only this device connected with about 10 cm cable. Nothing else.

(April-28th-2020, 08:53 AM)Armin@netPI Wrote: ... this means sending through NPIX-RS485 works always, right?
Rigtht, sending is working

(April-28th-2020, 08:53 AM)Armin@netPI Wrote: I guess setting Node-RED to "rtu-buffered" in the Modbus RTU node means that all Rx data that is received is first of all put in a internal buffer directly in the interrrupt service routine the time it is received instead of sending each byte by byte to the application. But this is only a guess. Maybe your python driver does not work the same. I don't know.
Here the definition for rtu and rtu-buffered:
Code:
RTU

... your device doesn't split never response messages

RTU Buffered

... your device is splitting response messages sometimes or every time - you got CRC errors or expected errors

Python uses the normal pymodbus library in version 2.3.0.
I didn't find a corresponding function (rtu-buffered) there.

(April-28th-2020, 08:53 AM)Armin@netPI Wrote: There is another thing: In general, the socalled Mini-UART used for this communication path has one big pitfall. It doesn't have its own clock source, so the UART bitrate depends on the CPU clock. Which means you have to set a fixed CPU clock for reliable communication. With original netPI OS we use the force_turbo=1 parameter in the config.txt to prevent the CPU clock from throttling, but I don't know if balena OS is supporting it as well.
I'll check that.

Thanks
Peter
  Reply
#4
Meanwhile I checked the source code of the RTUbuffered mode to see what it is doing: https://github.com/yaacov/node-modbus-se...redport.js

I see in there that whenever the serialport node (used by Modbus RTU node: https://github.com/serialport/node-serialport) raises the event 'data' on each Rx byte that then it is checkin if a complete Modbus RTU message has been received to the end. This is possible since with the previously sent Modus command you know exactly how long the response of the server will be.

Is your python code doing the same thing? I don't know.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#5
No, probably not.
I've to check the pymodbus lib, especially the read_holdng_register function.

That means, the problem has to be solved in the python code by myself?
All other users have no problem with the RS485 interface in this case?

Thanks for your help.
Peter
  Reply
#6
Well Peter,

I cannot tell you under which language our netPI users are using the neither the RS485 nor the RS232 interface. It can be any serial porotocol not modbus or they could use it only uni-directional, I don't know.

To this time I can confirm that nobody ever indicated any problem with the interfaces to me. During the 48hours climatic test of theses modules we used indeed the most simplest Node-RED flow and serialport node along with a device that was just echoing back the sent data. There was no error at all indicated and of course we compared the sent data with the echoed data telegram by telegram.

If you really need to change the python lib I don't know. You should probably check google search engine first with terms like "mini UART problems python" "raspberry". My personal opinion is that the root cause is not balena OS, not the hardware, but the software driver ... it may be indeed special with this mini UART that it has no hardware Rx buffer like other UARTs and gives you back byte by byte and not a complete Modbus Rx telegram.

Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#7
Which driver do you mean exactly?

Seems so, that the same behavior occurs already using the following recommended package:

https://hub.docker.com/r/hilschernetpi/n...dockerfile

I installed the container on the recommended (original) netPI OS and the fault free communation were only possible, if I use 'rtu-buffered' in node-red.
That looks like, that there is exactly the same problem. I connected another Modbus-RTU device (electrical meter) with the same results. 

It is not possible for us to use node-red for our coming project. Therefore we need another solution.

The easiest way is at the moment, that we use an external USB Adapter instead of the internal RS485 interface.
I will diskuss that in our next internal team meeting.
  Reply
#8
I mean the python software driver you are using right now.

And yes I expected it will work in rtu-buffered mode only ... this is exactly what I was writing in one of my previous posts where I was analysing what exactly this buffered node.js code is doing.

And my result after examination was that based on the code I see the "buffered" software waits for a complete Modbus RTU receive message and is buffering it while it is incomplete and only sends back a complete message back to the application. And this was the reason for me asking you if python does it the same. You answered "No, probably not.". I share your opinion without looking into the python coding.

Does the the ModbusClient() function you are calling has more than just the "timeout" value as parameter, for examplean "inter-character-timeout" that usually defines how long to wait between the single characters in a stream after a start character has been detected? I can't answer since I don't know the API.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#9
Here the docu of pymodbus:
https://buildmedia.readthedocs.org/media...modbus.pdf

I don't see the possibility to handle that problem.
  Reply
#10
Well I have another proposal that maybe could help.

The Raspbian OS can be configured to switch the two Raspberry Pi CPU integrated UARTs. By default the full featured UART is confgured to drive the Bluetooth (/dev/ttyAMA0) connection and the second one called mini UART (/dev/ttyS0) to be available for any other purpose.

But this function can be switched using the "dtoverlay=miniuart-bt" in the config.txt start file of Raspbian as described here https://github.com/raspberrypi/linux/blo...ays/README for the latest kernel 4.19.x. So I don't know if balena OS can switch the two UARTs too. After switching you can use /dev/ttyAMA0 to drive the BCM14 and 15 pins. Maybe this works better. A drawback could be that then you are no longer able to use the bluetooth function of the CPU.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  NPIX-RS485 with auto direction control now available Armin@netPI 11 88 May-15th-2020, 10:46 PM
Last Post: EnergyKonnex
  connecting Mitsubishi via RS485 COswald 11 49 January-14th-2020, 10:58 AM
Last Post: Armin@netPI
  Dual RS485 Ports primmer 2 24 September-25th-2019, 09:43 AM
Last Post: primmer
  Is there a demand for a RS422 interface? Armin@netPI 0 3 April-29th-2019, 10:58 AM
Last Post: Armin@netPI
  Communication between BCM2837 and netX51 on netPI RTE 3 Armin@netPI 0 117 December-3rd-2017, 01:19 PM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)