Serial Port Configuration - Windows

Hardware
1

I am new to getting data from serial device with Node RED. Can have the serial port

  1. What is the purpose of settings DTR, RTS, CTS and DSR in serial port configuration? Is this impact while fetching data from serial device?
  2. Ideally which of the following statement is correct according to the Node RED?
    a. Serial device is sending data to "serial request" node. (Device to Node RED)
    b. "serial request" node is fetching data from serial device. (Node RED to Device)

Over period of time or in random scenario we are receiving empty string from device.

My flow as following:

[{"id":"c8d9b582.438dd8","type":"inject","z":"eedcc5ab.020cc8","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"1","payloadType":"num","x":500,"y":400,"wires":[["cda2d5c3.ac5828"]]},{"id":"cda2d5c3.ac5828","type":"serial request","z":"eedcc5ab.020cc8","name":"","serial":"165287c3.b06ea8","x":650,"y":320,"wires":[["48c7a8c9.021908","5d8fb72b.33b878"]]},{"id":"5d8fb72b.33b878","type":"debug","z":"eedcc5ab.020cc8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":780,"y":400,"wires":[]},{"id":"165287c3.b06ea8","type":"serial-port","serialport":"COM3","serialbaud":"2400","databits":"8","parity":"none","stopbits":"1","waitfor":"","newline":"\\n","bin":"false","out":"char","addchar":"false","responsetimeout":"3000"}]

image

2

These are sequence control signals that are usually attached to wires (or simulated in software). How they are set depends on the hardware you are talking to. Defaults should be ok for most communications. Otherwise, refer to the devices information for physical connection wiring and settings.

The serial request node both sends (to the serial device) and receives data (from the serial device). It waits for a response to the data you sent.

It is quite possible that you are not actually receiving an empty payload but instead, non-printable character(s). Change the serial config settings to output a buffer then you can inspect the bytes. For converting these bites back into a string you could use a function node or the buffer-parser contrib node.

3

Actually it's worse than that :-)... the setting just set the pins to the state defined... so if set they no longer act as control pins. In theory this is useful for some devices that use those pins to provide parasitic power to some sensor ... so yes by default - never touch them :slight_smile:

1 Like
4

Which one is the best practice?
1. Use of "serial in" node
2. Use of "serial request" node

What is the difference between these two? Currently we are using "serial request" node? Is this right way? Or any ?

5

depends if you want request / response.

"Serial request" is solicited.
"Serial in" is unsolicited.

What is the serial device you are communicating with? How is it designed to operate?

6

Great information.

If we are use "serial request" node, we have to send some value in "msg.payload". Is this request hit the device? or how it is working?

7

Correct. That is how it works.

8

Is "msg.payload" request hitting the device? Is this request influence the device in any manner?

We are trying to get a data from "weighing indicator". We don't know about how it is designed.

Usage of "serial in" or "serial request" node depends on serial device design?

9

Yes.

If the device is designed to just "spit out" data then use "serial in"

If the device is designed to respond to a command, then use the serial request OR the serial in + serial out.

1 Like
10

Thanks for the clarification.

So, "serial request" node hits the device. "serial in" node will not hit the device. Is this correct?

11

Yes. Correct.

1 Like
12

Thanks for the confirmation. I have following queries belongs to the same topic.

  1. If "msg" object having more number of properties and values with "msg.payload", how it will behave?
  2. Is there any restriction over the "msg" object size? Or any other properties available in "msg" object influence the response from device?
13

Perfectly fine. serial node only uses msg.payload.

Short answer: No, msg is an object so is passed by reference.
Long answer: Maybe! If you have a really large object that is passed down 2 wires to 2 different nodes, then one of the messages will be a clone (i.e. if your msg has a property with Megabytes of data in an array then pass that msg down multiple wires will cause it to be cloned and could be problematic).

1 Like
14

If "msg.payload" having a large data (megabytes) or JSON with more number of properties, Is this will affect the serial device response?

What will be the valid value have to send in "msg.payload"? Is this depends on device?

15

Yes it depends on the device. You need to know what command text the device expects to get so that it will send back whatever information you want to get.

1 Like
16

If the device designed such a way that "spit out", can we use "serial request" node? If yes, what data have to send with "msg.payload"?

17

I'm pretty sure the request node only replies after something has been sent.

1 Like
18

Why would you do that? Use a Serial In node which will listen all the time until the device sends something.

1 Like
19

Yes. Using "serial in" we can continuously consume the data. But our requirement is we need data by on demand basis.

If we are consume continuously, we don't know the connectivity loss and whether data is up to date (latest).
@Colin

20

Then we can't use "serial request" node for "spit out" kind of devices? @Steve-Mcl