Node-RED crashes because of S7-comm

S7-comm is running fine on Node-RED, but lately more and more times Node-RED crashes after (re)start because of S7-comm. Finally I found the cause and this is what I wanted to share with you all.

Solution:
Don't start with read and/or write requests until there is a stable connection, otherwise Node-RED will crash !! In order to determine if there is a stable connection, take a status node and monitor the status of one S7 node. If the status is 'connected' , only then you can start with read and/or write requests.
afbeelding

2 Likes

A node should not crash node-red. That indicates that it does not have sufficient error checking. So please do raise an issue on the node's GitHub repo for the author to fix it. Thanks.

I note that node-red-contrib-s7comm (node) - Node-RED (nodered.org) hasn't been updated for over 4 years though - if you don't get a response from the author after a few weeks. You may wish to downvote the node in the flows site so that others get to know that there are issues with it.

Indeed, but I raised more issues and suggestions to the author, but he doesn't respond.


Then you should give it a 1-star evaluation on the flows site.

Are there alternatives? Or could you use a node.js package in a function node instead?

@TotallyInformation , You're right I will raise the issue any way and also the (temporary) solution to it.

As to the alternatives, I can see there are basically 2 nodes that can do the job, that is node-red-contrib-s7comm and node-red-contrib-s7.

The s7comm has been made by people from the Hilscher-company, they are well know for all kinds communication solutions in the "plc world", I can tell because I am from this world too :slightly_smiling_face:. There approach is to define ranges of registers to be read from and write to a plc. As a plc is sequential machine rather then an event driven machine, best practice is to make a send and receive area there, to communicate with, and send and receive data in 1 block message.
The S7 solution is more "old school". A plc has many kind of variables that are located grouped together. These people made the choice of direct approach of these variables, one by one they cannot be grouped together, this is not really very efficient. As you probably need to configure lots of variables, they made it possible to import and export these to and from a csv-file, a nice solution I must say.

I have tried both packages and s7-comm turns out to be the most stable. It's running now for over 1 year.
In the first half year without any problems whatsoever. But lately more and more trouble seem to occur. I guess it's because of the lack of maintenance.
The `node-red-contrib-s7 nodes I also tried, but they suffer a lot of time-outs on the communication, even lately I have tried again, but still happening a lot of times. So that's no real solution at this point for me.

I hope that the Hilscher people will pick up maintenance again very soon, It would be a shame when this node gets outdated!!

I don't know what you mean by that, and how that works.

Specialist nodes generally use an underlying node.js library as I think is the case here. Recent changes to node-red let you consume node.js libraries directly in function nodes. You have to turn on the capability in settings.js but then you can directly install and use node.js packages - details in the docs.

Of course, this requires some JavaScript knowledge in order to be able to use the library. But sometimes the library's documentation is enough to get something to work even with limited JS knowledge.

@TotallyInformation , thanks I will give it a look. I hope I can do something with that. I already know that nodes7.js is at the hart of these s7-nodes. So maybe I can do something there.

Or indeed once you dig in it may be good to fork the “old” node and fix it and republish it. Sometimes the original owner is happy to pass it on. And if no response it can be renamed.

1 Like

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