Issues with node-red-node-serialport Module

General
1

Hello,

I have encountered issues while using the node-red-node-serialport v2.0.2 (latest version). Here are the configuration parameters for the "serial request" node:

  1. msg.timeout is the timeout (in ms) after which the incoming message is propagated to the output with msg.status set to "ERR_TIMEOUT" and no payload. If not present, the default value is 10000 ms (10s).
  2. msg.count if set, will override the configured number of characters as long as it is less than the configured number.
  3. msg.waitfor must be a single character, escape code, or hex code. If set, the node will wait until it matches that character in the stream and then start the output.

My requirement is to find a configuration to achieve the following: I have a device that, when I send a serial command, returns a message. The delay between sending and receiving is not fixed and can vary, sometimes it’s 100 ms, 300 ms, or even 1 second. I want to set a fixed msg.timeout to wait for the serial response. If the device does not return any data within the defined timeout, it should return "ERR_TIMEOUT". However, if the device returns data within the timeout, the data should be displayed immediately without waiting for the msg.timeout to finish.

I do not want any splitting of the returned data since the responses from the device contain different characters each time. Here are some examples of responses:

  • Response 1: contains "\n\r xxxx \r\n"
  • Response 2: contains "\n\r xxxx"
  • Response 3: contains "xxxx \r\n"
  • Response 4: contains "xxxx"

In my Node-RED flow, I have followed all the steps to use this serial request configuration, but I encountered a problem. When using msg.timeout and receiving, for example, the following response: "\n\r xxxx \r\n", it immediately splits the response and only displays "\n".

serial request configuration :

image
image1203×797 50.5 KB

2

What exactly is "the device"?

What is the serial protocol?

Are you in control of what the device sends back (i.e. if it doesnt have a well defined response pattern/protocol, are you in a position to change that?)

I ask because if it ALWAYS ended with a specific control character, then this would be pretty simple.

If not, there there are a few threads on the forum about reconstructing the serial data using a temporary buffer.

3

The device I'm referring to is an industrial card connected via an RS232 cable. Each time a command is sent to it, it returns a different response. As I explained earlier:

  • Response 1 for Command 1: contains "\n\r xxxx \r\n"
  • Response 2 for Command 2: contains "\n\r xxxx"
  • Response 3 for Command 3: contains "xxxx \r\n"
  • Response 4 for Command 4: contains "xxxx" And so on.

Regarding the serial protocol, unfortunately, the device doesn't adhere to a consistent response pattern or protocol. It returns varying responses based on the command sent.

I'm not directly in control of what the device sends back, and it doesn't consistently end with a specific control character. This variability in response patterns complicates the data handling process.

If you have any suggestions or guidance on reconstructing the serial data using a temporary buffer, I would greatly appreciate it.

Thank you for your assistance.

4

Is that what you have determined from looking at the node-red debug?

what i mean to say is, it kinda looks like each response is terminated with \n\r but your current setup is splitting on a time base & you are getting part responses.

You might need to do a serial capture and post that for us to see if we can formulate a better means of correctly handling your data.

5

I agree. I would start by setting it to always split on \n and then monitor the debug. I would then remove any \r before further processing.

6

image
image1608×2412 182 KB

debug node-red

7

Sorry but your image is at least 70% darkgrey with nothing in it and the detail parts are too small to read.

Also, please answer questions posted.

Lastly, a screenshot is not really a serial capture. A serial capture is either a hardware or software device that logs the EXACT bytes transmitted and received. It would be helpful to determine the best way to handle this.

8

image
image1901×789 48 KB

Is that what you have determined from looking at the node-red debug?

-->yes

1 Like
9

then it seems to be messed up due to your settings.

As far as I can see, every response is terminated with CRLF but there are (it appears) some extra CRLFs in there - possibly due to your serial port settings but on the whole, it looks like whoever wrote the protocol didn't really care about the pain it would cause an integrator. It looks more suited to a telnet session!

Question: Where was the data in that screenshot generated? From your node-red data?

Question: Can you post that as text instead of a screenshot?

Question: Can you capture raw bytes to file (without any pre-processing? e.g. does it REALLY send <CR><LF> or did you interpret those for readability?

10

Question: Where was the data in that screenshot generated? From your node-red data?

Answer: "No, it was from Docklight scripting, which is a serial reading software."

Question: Can you post that as text instead of a screenshot?

2024-04-01 : 07:15:53,8548[TX]::GN 1 2E7A<CR>
2024-04-01 : 07:15:54,0561[RX]::<LF><CR>ME20002004 OK 54b5<CR><LF>
2024-04-01 : 07:15:54,3459[TX]::MI 1 39F9<CR>
2024-04-01 : 07:15:54,5469[RX]::<LF><CR>32 OK 5a87<CR><LF>
2024-04-01 : 07:15:54,7968[TX]::ME 89A7<CR>
2024-04-01 : 07:15:54,9966[RX]::<LF><CR>3 OK 11ba<CR><LF>
2024-04-01 : 07:15:55,2295[TX]::GN 2 7B29<CR>
2024-04-01 : 07:15:56,2801[RX]::<LF><CR>1SAG10234621 OK 0bef<CR><LF>
2024-04-01 : 07:15:56,4610[TX]::GY 0878<CR>
2024-04-01 : 07:15:56,6620[RX]::<LF><CR>2024/04/01-W1 07:18:55 80 OK c800<CR><LF>
2024-04-01 : 07:15:56,8120[TX]::SN 7 "253972606_B" ABA6<CR>
2024-04-01 : 07:15:57,0145[RX]::<LF><CR>OK c4c8<CR><LF>
2024-04-01 : 07:15:57,1085[TX]::GN 7 84DC<CR>
2024-04-01 : 07:15:57,3094[RX]::<LF><CR>25398566_B OK 5000<CR><LF>
2024-04-01 : 07:15:59,7265[TX]::SP 1 1ADB<CR>
2024-04-01 : 07:16:01,7770[RX]::<LF><CR>OK c4c8<CR><LF>
2024-04-01 : 07:16:03,3317[TX]::CB 0 DB7F<CR>
2024-04-01 : 07:16:03,5335[RX]::<LF><CR>þ˜ž˜ xàx˜€
2024-04-01 : 07:16:09,1439[TX]::GN 1 2E7A<CR>
2024-04-01 : 07:16:09,3455[RX]::<LF><CR>ME240900002004 OK 54b5<CR><LF>
2024-04-01 : 07:16:09,4115[TX]::SC "U0JPWAAAAAAAAAAAAAAAAAUAAAAACkFFUy0xMjgtS1cFEAAAAAdrZXlfMDAxBgAAAAAFU0hBLTEAAAAAAAAAAE1FVEEAAAEAAAAABzg1MjU0MTQAAAAAAAAAAAAAAAAATUVUQQAAAgAAAAAJMjUzOTcyNjA2AAAAAAAAAAAAAABNRVRBAAACEAAAAA5LU04yNDA1MTE0Mjg2MQAAAAAAAEdTREMAAEtGAAAAENfsJl5t51KWu+jhyNqf1PwAAAAf8hnjn9eI8W5XiIADuYhAqJobV8Clb6QlwAAqmDfWwfpCY4ilweJC+cSNJ17qAgAAAAAAAAAAAAAAAEdTREMAAVJEAAAAOEOhG0Ue981BexEyvFxmL8eTIPPelZddR5GAqZHc8Cf52uAzKwiZ3ZsbcLGLdPDnpywCtIqiuTV9AAAAAAAAAAAR1NEQwABAQYAAAAoVjimDNOQytu9dsd2Xz/rx8s0OhChnIOK8BUty9or3NMFMJsOGPUhDQAAAAAAAAAAAAAAAEdTREMAAQEhAAAAKFY4pgzTkMrbvXbHdl8/68fLNDoQoZyDivAVLcvaK9zTBTCbDhj1IQ0AAAAAAAAAAAAAAABHU0RDAAEBIgAAACj69/KUOEuYrhbfpLDWk+IuSBmOkcAQ3p5QDuGaQFy3ASNxPZIxdKT+AAAAAAAAAAAAAAAAR1NEQwABAQEAAAAonBQKahoKNWaBNsO0mBKgf8hnjn9eI8W5XiIADuYhAqJobV8Clb6QlwAAAAAAAAAAAAAAAEdTREMAAQEgAAAAKGodEdlVj9Pv9mjUGUq4Qkwk2mjie8+zEfAm09ORXQtPO5TEJS/AV88AAAAAAAAAAAAAAABHU0RDAAFMSwAAAGiA0ZlLFenyeOsIOBLQQrA+xoPbTSR4fxbvgbaAH4IZ4VvWkevRwcRuwFVrejCa8feOEI0oo5i5c/uQdk/gvJPbKKZtWXZdcHRbvbFA0lcra6SKLUnxjsbcLGLdPDnpywCtIqiuTV95/AAAAAAAAAAAAAAAAFNJR05HkfvExcIDAEFMuihR+jiyG4u1xfq6XkfyIhtB+ITETj9Ca2K1JDfB" 04B6<CR>
2024-04-01 : 07:16:14,4646[RX]::<LF><CR>"U0JPWAAAAAAAAAAAAAAAAAUAAAAACkFFUy0xMjgtS1cFEAAAAAdrZXlfMDAxBgAAAAAFU0hBLTEAAAAAAAAAAE1FVEEAAAEAAAAABzg1MjU0MTQAAAAAAAAAAAAAAAAATUVUQQAAAgAAAAAJMjUzOTcyNjA2AAAAAAAAAAAAAABNRVRBAAACEAAAAA5LU04yNDA1MTE0Mjg2MQAAAAAAAE1FVEEAABAAAAAABFBBU1NNRVRBAAAQAQAAAAAAACkFFUy0xMjgtS1cFEAAAAAdvrqDR8lQmypfuObsRQx298zd/xmBU9NZ122ClJ2Cc=" OK 1800<CR><LF>
2024-04-01 : 07:16:25,7810[TX]::FR E3B2<CR>
2024-04-01 : 07:16:52,7116[RX]::<LF><CR><CR><LF> Resetting ext flash..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................OK<CR><LF> Resetting...<LF><CR>We<CR><LF>Service components: 23, DB size: 174 bytes.<CR><LF>Cosem objects: 719, DB size: 6232 bytes, 2 records.<CR><LF>Total DB size: 6406 bytes.<CR><LF>lcome on the CLI monitor<LF><CR>Type - at any time to go back to root menu<LF><CR>(Press ? for help or ? <command> for help on a specific command)<LF><CR>
2024-04-01 : 07:16:54,2598[TX]::IC FFC1<CR>
2024-04-01 : 07:16:54,4597[RX]::<LF><CR> OK f386<CR><LF>

Question: Can you capture raw bytes to file (without any pre-processing? e.g. does it REALLY send or did you interpret those for readability?

Response: "The card itself sends '\r\n', not me." In certain returns, it does not contain "", for example: "<LF><CR>þ˜ž˜ xàx˜€"

11

Is there a FIFO method without waiting for CR LF or any specific command (similar to TCP principles)?

12

This is a huge clue.

the interface is designed for human interaction (as I guessed earler)

Unless the device has a proper integration protocol (like ModBus or other well formated protocol) this is not going to be a pleasant task,

You can invent whatever you need to get the job done.

For example, you could use context and JS arrays in a function node to store each incoming value in an array and use the built in push / pop / shift / unshift functions to make a FIFO

Some resources:

  1. Array - JavaScript | MDN
  2. Working with context : Node-RED
13

Is there a First In, First Out method in the configuration of the node-red-node-serialport node (i.e., data received is directly sent to the output node without delimiter (split) characters), or do I need to modify the node-red-node-serialport code to meet my requirements?

Regarding the Modbus node, I will test this node. Can we change the baud rate with the Modbus node and open/close the connection like with the serialport node?

14

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