Serial in/serial out issues - memory leak?

General
1

Hi folks,

5 Aug 22:10:48 - [info] Node-RED version: v1.3.5
5 Aug 22:10:48 - [info] Node.js  version: v12.22.1
5 Aug 22:10:48 - [info] Linux 5.10.17-v7+ arm LE
5 Aug 22:10:49 - [info] Loading palette nodes
5 Aug 22:10:54 - [info] Dashboard version 2.29.1 started at /ui

I'm working on a reasonable sized project for my day job, it's heavily reliant on RS485 communications to a proprietary device for production line testing purposes, in simple terms I've built a piece of test equipment and I'm writing some Node Red to control it.

So I've been having some intermittent serial in/serial out comms issues. This is RS485 using some USB-RS485 adapters I have been using for years with LabVIEW without any problems. It's not a USB device issue, I'm 99.9% certain of that.

There are a couple of complications I have had to/chosen to try and handle;

  • firstly - when the device I'm connecting to boots up it sends a couple of lines of strings out via the RS485 port
  • secondly - to make some reusable code and to handle all the different commands I need to send via the RS485 I created a sub-flow with pre-configured environmental variables

My sub flow was designed using the serial request node, this worked but couldn't handle the boot up strings, and I eventually got intermittent issues. So I re-worked this to have a serial in node in my main flow and a serial out in my sub-flow, this also worked for a while, the boot up messages were handled and the replies to my sent serial commands worked OK as well . . . but again intermittently I would get issues and timeouts when the comms started failing. If I went in and deleted the serial port settings from both nodes and recreated them things would start working again.

Then during a re-start of my Raspberry pi and restart of Node Red I noticed the following in the console window:

5 Aug 22:10:55 - [info] Starting flows
5 Aug 22:10:56 - [info] Started flows
(node:937) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ready listeners added to [EventEmitter]. Use emitter.setMaxListeners() to increase limit
(node:937) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 closed listeners added to [EventEmitter]. Use emitter.setMaxListeners() to increase limit
5 Aug 22:10:56 - [info] [serialconfig:a735c45c.b4efd8] serial port /dev/ttyUSB0 opened at 115200 baud 8N1

I've managed to get rid of these memory leak messages by disabling the serial in and serial out nodes . . . further more they come back when I enable the serial out node in the sub-flow and Deploy . . .

6 Aug 16:58:37 - [info] Starting modified nodes
6 Aug 16:58:38 - [info] Started modified nodes
(node:936) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ready listeners added to [EventEmitter]. Use emitter.setMaxListeners() to increase limit
(node:936) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 closed listeners added to [EventEmitter]. Use emitter.setMaxListeners() to increase limit

I really don't understand what is happening, maybe this is happening because I'm using serial out from a sub-flow ?

I'm meant to be on holiday this week but have been working on this project from home to try and catch up . . . I'm getting very delayed due to this problem, any help any can give would be a big help.

kind regards,

Simon G

2

Why are you putting the aerial nodes in subfow? And how many instances of the subflow are there?

Ps, that warning isn't a memory leak but is a warning you might have multiple event handlers for the same event (and potentially you are allocating without deallocating and therefore possibly a bug in you code).

This will make more sense to me when you answer the 2 questions.

3

Hi Steve,

I have many various commands I need to send via the RS485 comms, these take the form of a 4 letter mnemonic with a value (for a write). So for ease of use and code reuse I built a sub-flow with the mnemonic ID preset in a drop down selection, a Read Write option, scaling option (for the read values) and a value field for written values . . . .

image
image968Ă—487 33.8 KB

. . . when I get the reply from the serial out I need to process the reply, it made sense to me to do all this within the subflow.

Currently I have approx 23 instances of this subflow . . . but I will have many more when I'm done.

4

Ok. So every subflow creates a new instance of the serial nodes. Those serial nodes have event handlers (inside) and that'll be the reason for the warning.

I would personally recommend moving the serial nodes out of the subflow and leave the processing logic inside.

Alternatively, use something like node-red-contrib-components which gives you subroutine-alike functionality (meaning you don't create multiple instances of the serial nodes)

1 Like
5

OK, thanks Steve . . . I did wonder if it might be something like you describe, this is where my lack of knowledge lets me down.

So I'll probably break my subflow into two subflows and link them to the serial in and serial out using links . . . I'll let you know how it goes.

Thanks for the help.

6

Indeed. I always like to think of things like serial ports as being real physical things, so I try to only have one out and one in. And use links or wires to link other nodes to them.

1 Like
7

It's going better . . . I've reverted to an earlier implementation which passes the serial out message via a global variable to be picked up by the solitary serial out node with the replies from the solitary serial in node going to an array stored to another global, it's not pretty but it's working for now.

It is at least allowing me to make progress with the rest of the code . . . e.g. writing the firmware to the ti MSP430 device (this is working well) and creating the rest of the test sequence.

Thanks again.

8

That sounds horrible. Watch out for the situation where the next message comes in and overwrites the global before the previous value has been used. It is best to avoid globals for this sort of use case unless there is no other practical option.

9

Yup, you aren't wrong . . . it's not pretty but it is working. The risk is fairly minimal because the only time there are incomming comms without a request is after boot up, so I know when I am expecting comms in.

Also, I am saving the reply messages to an array so I would have the option to find the correct reply by searching the array if needed.

I'm making progress overall now though without having to constantly scratch my head about the comms issue, I'll revisit the comms later and see what I can do to make it more robust if not elegant.

1 Like
10

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