search

st-one-io / node-red-contrib-s7

A Node-RED node to interact with Siemens S7 PLCs
GNU General Public License v3.0
111 stars 58 forks source link

periodic Bad Values #21

Closed Riebandt closed 6 years ago

Riebandt commented 6 years ago

Hi I have this project were we are using Node-Red to pull the Values out of a s7-300 plc. Our variable list is: db10,x0.0.300;VF5.Area100.Alarms db10,x38.0.300;VF5.Area200.Alarms db10,x190.0.300;VF5.Handeler.Alarms db20,s0.13;VF5.OrderNumber db50,x0.0;VF5.Area100.Started db50,x0.1;VF5.Area100.SafeNotOk db50,x0.2;VF5.Area100.AlarmActive db50,x0.3;VF5.Area100.Delivered_Ok db50,x0.4;VF5.Area100.Delivered_NotOk db50,x46.0;VF5.Area200.Started db50,x46.1;VF5.Area200.SafeNotOk db50,x46.2;VF5.Area200.AlarmActive db50,x46.3;VF5.Area200.Delivered_Ok

We then use these values to trigger a TCP message to a SQL Database.

But some times we have an error telling us that it has received bad values..

What could be the cause of this error.

Riebandt commented 6 years ago

We are using the 1.4.1 version.. Is there any way to update it Offline?

gfcittolin commented 6 years ago

Bad values can happen in a different number of cases. It may happen when you have intermittent connection to your PLC, or when you have wrong addresses in your variable list, for example. Unfortunately we can't get the root cause out of the library we use.

You can update perform an offline upgrade of the package by manually downloading it from here or from npm, and manually replacing the package folder in your installation. The step-by-step instructions however would depend on your current setup (npm version, installation path and method, etc.)

temmat commented 6 years ago

It seems that the "Bad values" error is somewhat corellated to timing/high CPU usage too. To explain better: I start getting "Bad values" errors periodically and with a high degree of repeatability when the core that runs the node-red process goes to 100% utilization and stays there for some time (which is quite often if you use Node-red on smaller / embedded devices ).

I would understand getting an occasional timeout error in such situations, but in fact I get numerous "Bad values" errors.

gfcittolin commented 6 years ago

Indeed. There are timeouts that can be triggered if the CPU goes 100% or if you have unstable network connection. That's also why you can configure a timeout on the node's configuration. You can try increasing it a bit and check if it gets better.

Note that "Bad values" here does not necessarily means that corrupted data is coming over the wire, it may just mean that the application does not have "good values" to deliver in that situation. System overload (my it be CPU, network, I/O, etc.) can cause this sort of issue in any protocol or protocol implementation that has time-based constrictions, as it's the case here.

Maybe your hardware is undersized for your application. We have this reading hundred of variables (~800) every 500 ms on our embedded hardware, including displaying them on a web dashboard without much performance impact. We have there a configured timeout of 5000 ms, but mainly because of network issues there.

Riebandt commented 6 years ago

First thanks for this great node and keep up the good work. It is very much appreciated.

Our setup has the node-red locally installed on a computer. We then get roughly 1500 variables most of them located in 5 arrays. And depending on those variables we will send a tcp msg to a Receiver which will store it on a SQL database. Both the receiver and the SQL are both installed on the same computer as the Node-red.

The cycle time is 1 sec and the timeout is 3 sec.

Raising the timeout, wouldn’t that just fix the timeout errors? Those we don’t have. But the network problem. Maybe network overload we might have. They also have other networks issues on the plant.

We will try to see the CPU usage if this might indicate anything.

Den 6. apr. 2018 kl. 16.30 skrev Guilherme Francescon notifications@github.com<mailto:notifications@github.com>:

Indeed. There are timeouts that can be triggered if the CPU goes 100% or if you have unstable network connection. That's also why you can configure a timeout on the node's configuration. You can try increasing it a bit and check if it gets better.

Note that "Bad values" here does not necessarily means that corrupted data is coming on the wire, it may just mean that the application does not have "good values" to deliver in that situation. System overload (my it be CPU, network, I/O, etc.) can cause this sort of issue in any protocol or protocol implementation that has time-based constrictions, as it's the case here.

Maybe your hardware is undersized for your application. We have this reading hundred of variables (~800) every 500 ms on our embedded hardware, including displaying them on a web dashboard without much performance impact. We have there a configured timeout of 5000 ms, but mainly because of network issues there.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/netsmarttech/node-red-contrib-s7/issues/21#issuecomment-379270978, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Aj0EkyQNa0E9jRMKF6gCEaaBB2HT5bZHks5tl3vtgaJpZM4SwrHj.

gfcittolin commented 6 years ago

I'm closing this issue for now. Please let us know if the issue persists with the latest version