RS485 or RS232?

General
1

Greetings. I have this weigh indicator transmitting data to a Raspberry Pi via RS232, specifically:

image
image857×322 45.2 KB

and being received by the standard Node-RED serial in node. It works fine, but for reasons that are unclear to me, after 2 or 12 or 18 hours or some other time period, the serial port stops receiving data. It starts reflowing again once I restart Node-RED or redeploy the flow. I have done a lot of reading on this and believe it may be due to flow control. You can see from the above that the Rice Lake unit is ONLY transmitting data, i.e. there is no 2-way communication that is usually in place with RS232.

The Rice Lake unit also supports RS485, which I am comfortable setting up and working with in Node-RED. However, before I go there, I wanted to ask a general question about RS485. Can RS485 be configured to always flow into the Pi, or if it can only be received by polling the device (i.e. using the Modbus getter node to poll every n seconds)? For my particular application, polling once per second would be too slow. I need closer to 25ms or so. Does anyone see a problem with that? For receiving weights from a scale, is there any advantage or disadvantage of RS485 vs RS232 that I may not be aware of?

2

Rs485 is a type of hardware, you should read the documentation to understand if it uses the modbus system, or a simple serial at system or something custom.
On pdf that you link there's a 3.13 chapter it seem good for your need.

3

It isn't clear to me why you want to do this. The device you show does not use hardware flow control, and neither will the pi unless you specifically enable it. Are you suggesting that the device is using software flow control in some way?
You say that what you have works ok for some time, but then seem to suggest that if you use 485 you will have to change the Comms to modbus polling. How does it currently work?
Show us how you have configured the serial node. If you power cycle the weigh indicator does it restart? What status does the serial node show when it stops?

4

Thanks both of for your replies. I will admit that I am in a situation where I am stabbing in the dark. And maybe this problem has nothing to do with Node-RED, so for that, one of the moderators can remove this post if they wish. And I really don't like long forum posts, but here goes...

OK, backing up a few days....The flow that I have in place uses the value from the Rice Lake unit by receiving it using the serial node, configured as shown below. It works great usually for hours at a time, then suddenly data stops arriving, but Node-RED is still running (and Node-RED shows no error messages that I can find). If one looks at the weight on the Rice Lake unit, it's correct and will change if material is added or removed from the scale. The problem happens downstream from there, i.e. the Pi stops receiving the data. Everything works again once I restart Node-RED.

image
image631×791 66.2 KB

My original plan of attack was to view the Node-RED logs, but all I continue to get is the [info] logs (not [debug], despite changing the settings.js file).

My next idea was to see if the Pi was overheating or something else, so I installed Telegraf to send the data to Influx. But that did not go smoothly (this is my first Telegraf installation) and I am still trying to work it out via the InfluxDB forum..

I next thought that the serial port (or perhaps the serial cable) randomly stopping was causing this. Some posts I found on this topic:

In addition to swapping out the cables, I could also swap the Pi with an identical one. And then I thought that maybe changing the comm protocol (RS485, i.e. two way communication, instead of RS232, which per the above is doing only one way communication) might help, but now I am less inclined to think that will help.

The next time it starts and I am near the equipment, I will power cycle the Rice Lake unit to see if that does anything to help Node-RED resume, but like I said above, the Rice Lake unit always keeps displaying the correct weight throughout the whole debacle, so I do not believe that is the source of the problem.

5

removed from user

6

In the mode you are currently using it does the device regularly send the weight? If so then either that stops, or node-red stops seeing it. If you have access to a scope then connect that to the wires so you can see whether it is still transmitting.
Also make sure that you have a debug node showing directly what is coming from the serial node to see what happens there when it stops, and note what status the serial node shows then, if any.

7

Why do that until the problem has been fully diagnosed?

8

In the mode that I am currently using, yes the device transmits the weight very fast (several readings per second).

image
image1243×699 124 KB

When it stops, the debug pane just shows the last reading sent. No error message or corrupted serial reading.

You said I should note what status the serial node shows upon stopping, if any. Is there something else that I should be monitoring in debug pane besides what I have already? (not sure what you mean by "status").

9

The doctor sometimes prescribes different medications to determine which one works best.
Grant does not say how he connected the device. Which RS232 converter does he use? If the hardware structure is ok, you can concentrate on the software.

10

This is the converter that I am using: https://www.amazon.com/USB-Serial-Adapter-Prolific-PL-2303/dp/B00GRP8EZU

The total distance of the run is about 4m (12 ft).

My plan is to monitor everything on the Pi (via Telegraf and stored in Influx) to see what the conditions are when the serial port seemingly stops working.

11

The text shown below the node.

A very common problem when using usb to serial is that for some reason the usb disconnects and reconnects with a different device ID. If you are using something like /dev/ttyUSB0 (or ASM) then it may reconnect as usb1. If you are using that then watch /var/log/syslog and plug in the adaptor and you will see a device identifier string. Then look at /dev/serial/by-id/ and you should see the device there. Use /dev/serial/by-id/the-identifier and it will not change. There is a good chance that is the problem.

12

Not usually while waiting for the results of some simple tests.

13

Serial communication is not always reliable. But I don't think 485 would be much different.
I can only speak about (20 years of) my experience with POS printers + Teletask home-control board, sadly I know only basics about the actual communication protocol of those.

  1. If the cable is NOT shielded, any small 230V interference can cause the data flow to become "crasy".
  2. Without Flow control + parity bit the whole communication can suddenly stop.
  3. If using USB-RS232 converters, most of them are unusable craps, mostly because the bad written driver.
  4. Always update the driver directly downloaded from the webpage of the manufacturer. (If it's not a reliable manufacturer, you won't find a proper, updated one.)
  5. You may consider using some direct pin of the RPi for RS232 communication, and not the USB for that!

So first I would recommend to:

  • Try to set those DTS (on) + Parity (even) at least on the Pi side, maybe the device you are communicating with is set to "auto", so it can happen it will activate those, allowing better + stable communication
  • Make sure you use the latest, fixed Serial-node !
  • Change the RS232 cable to a shielded, quality one. (maybe ROLINE ... was good, if I recall it right...)
  • Buy a good USB-Serial converter (search for user-rates) OR use the RPi Pins for that
14

Thank you @PizzaProgram for the tips.

On Tuesday, I changed the USB-to-RS232 (9 pin) cable from one that uses the Prolific chip to one that uses the FTDI chip. This cable does not appear to be shielded, but so far has been far more stable. The serial data has stopped flowing only 2 or 3 times in over 48 hours of runtime, whereas when the old cable (Prolific) was in use, serial data would stop 5 or 7 times every 24 hours.

To address the other points raised...

  • Tomorrow (when I will have a chance to work on this), I will follow @Colin 's advice and use /dev/serial/by-id/the-identifier

  • I will try to convert everything to shielded cable

You said to try to set DTS (on) and Parity (even) on the Pi side. Where is the DTS setting on the serial node (and yes, I am using the latest one for Node-RED)? I do not see anything in the settings below

image
image527×590 17.3 KB

15

Sorry, 10 years has past, did not remember the letters correctly.
You may try to set those others (DTR, RTS, CTS, DSR) I don't know exactly what is what, please search for details. I think "software flow control Xon/Xoff what helped me back then ...

Check the weigh indicator device manual too! (But usually those things are purely documented.)

16

@grant1 ,

Try installing mbusd from the github link:

Although it says ModbusTCP to ModbusRTU, it kind of assists ModbusRTU (serial) communication very well. Have been using this for a few years now and never had a problem be it RTU or TCP nodes. Worth giving it a try on a test board first. You can configure ModbusRead and ModbusWrite nodes and to read serial data over locahost (127.0.0.1) and a particular port you configure on mbusd configuration file

then enable mbusd@ttyUSBx.service.

I use it to read Serial Modbus Data over USBxRS485 (or RS232) and it works fine.

17

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.