Open jpillman opened 6 years ago
Got your point. I'll have to think about a bit on how to solve this, as the node-ethernet-ip
used underneath doesn't report when each cycle has completed, and therefore we only get an event that a variable has changed. We could implement this rate-limit approach internally, but it's an ugly solution and can be done at the flow level instead (as you have done).
I'll check what options the library offers us so we can work around this.
I did wonder how easy it would be to fix. For now, the work around isn't really a big problem. If I can be of any help, let me know. I really appreciate your responsiveness to these issues!
Hi, I have the same issue here and since november 2018 there's no feedback about a soluton. In my case, I was expecting to have a "diff" checkbox as it is written in the read-me file for the single variable mode. (Single variable: A single variable can be selected from the configured variables, and a message is sent every cycle, or only when it changes if diff is checked. msg.payload contains the variable's value and msg.topic has the variable's name.). I need all the tags to be refreshed every 10 seconds even if any of them have changed within the cycle time.
Can anyone answer about where's the diff checkbox? Or, if there's no diff checkbox then why do we have a cycle time parameter to adjust? One last thing, did this issue will be solved soon?
Regards!
I had the same issue and solved it by using the All variables, one per message
mode and then the join
node to join the values into a single message.
I had the same issue and solved it by using the
All variables, one per message
mode and then thejoin
node to join the values into a single message.
I tried the same thing, but logging 200 Integer Tags every 50ms lead to connection issues with the node after a few hours of testing. I got a few disconnects that lasted minutes and eventually the node disconnected completely and the connection to the PLC couldn't be reestablished without redeploying the flow manually.
Fortunately I came across Maxim Krylovs blog post about creating an open source data historian. He made a custom ethernet-ip.js in an optional section of his guide where he fixed this issue. His solution fixed the disconnection issues i had too. I didn't get any disconnects during a 24 hour test at least (running at 25ms cycle time). Unfortunately, using his ethernet-ip.js my node-red crashes whenever I redeploy my flow, requiring a restart. That's only an annoyance in development though, since the node worked perfectly fine besides that.
I uploaded his version as an attachment to this post, his changes to the node are between the "// =====...". ethernet-ip.zip
I also found a fork by @SerafinTech , which seems to have a major rewrite of the ethernet-ip.js but it isn't well documented and it doesn't seem to include a fix for this. The github link on node-red also only links here unfortunately.
I'm reading a list of BOOL, DINT and REAL tags from a CompactLogix PLC. The ether-ip node is set to "All Tags" Mode. Cycle Time is set to 10,000 ms.
I would expect to receive one message every 10 seconds with all the tags. Instead, I will receive multiple messages with all the tags all sent at exactly the same time. See screenshot below...
The issue seems to be related to tags with frequently changing values and the eth-ip node report-by-exception feature. If no tags change value between cycles, no message is sent. (expected behavior but an option to override this could be nice) If one tag changes between cycles, one message is sent with the values for all the tags. (expected as well) Then things get interesting:
If two tags change between cycles two identical messages are sent with exactly the same timestamp and exactly the same data for all the tags. If three tags change, three identical messages are sent and so on... If I have a large number of tags change my flow gets hammered with a series of identical messages that I need to manually weed out.
As a work-around I put in a delay node with a rate limit. Ideally, the eth-ip node would be updated to only send out one message every cycle regardless of how many tags change.