April-28th-2020, 09:26 AM
Thanks for your reply
It is only this device connected with about 10 cm cable. Nothing else.
Python uses the normal pymodbus library in version 2.3.0.
I didn't find a corresponding function (rtu-buffered) there.
Thanks
Peter
(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