Now bad quality status received from sensors resets PLC connection. #84
Conversation
|
Is this always the right thing to do? What about the case where a large number of values are being requested and one of them doesn't exist in the PLC, like a data block offset that doesn't exist? What is the issue that this commit fixes? |
|
Sorry for not discussing the issue before. We had some problems here using the node red S7 library, that the PLC didn't reconnect properly after disconnecting (see st-one-io/node-red-contrib-s7#30). So I found that I could force it to reconnect when receiving bad quality values. If you can find a better solution we'll appreciate. |
|
Thanks @edkb for the PR and all the effort you put into it, but I also that the way it's done here can have other unintended implications. If we indeed need to trigger a reconnection, we could do it from the Node-Red Node, even though nodes7 should already reconnect when necessary. |
|
I pushed a commit that takes some of the improvements from the nodepccc project for reconnecting that may help with your issue. |
|
Thanks for the feedback guys. @plcpeople I tested with your update but unfortunately I didn't find any difference in the PLC behavior. @gfcittolin I don't know where this issue is located (Node Red Node or this S7 library), but the bad quality symptom comes from here and since we don't use this value it's still the only solution for our case. Anyway, it would be great if you find other way to know when the PLC is down. |
|
@edkb @gfcittolin when Node-red (and your flow) receive "bad values" like in the trace reported on the original issue, what happens? Does it try again to request values? I think what is happening is that the bad packet coming from the LOGO is causing the connection to reset once, but then this doesn't happen instantly, and while you're waiting for it to reset, it returns bad values. That is why the fix in the PR worked - constantly re-triggering the reconnect will eventually return good values. But if you always request new values after you receive a reply from nodeS7 (with good or bad values) then it should work. Or is this not practical/possible? |
|
The Node-RED node always tries to read the values again, regardless of the quality of the result. It also even monitors whether the callbacks with results are being called, because of an issue we had in the past where callbacks weren't being called in some circumstances. So trying to read the values again is probably not the issue here. @edkb I was taking another look on the log section you posted on the original issue, and, on that case, the issue was a packet timeout. How's your physical network between LOGO and your Node-RED instance? And what's the ping average to the PLC? If this is an issue, try increasing the timeout on the configuration at Node-RED, from the 1500ms default to something like 5000ms. Other than that, I'm a bit out of clue without testing it, or checking the full logs, so if the suggestion above doesn't result to any improvement, we could try to arrange a proper way for testing/simulating the issue. |
|
@gfcittolin I changed timeout but still no difference. |
|
The logs being different is something expected. Before the first connection happens we're on a different internal state, the read packets haven't been optimized yet, and so on. But if you look closely, the root cause is the same |
|
Yes, it keeps sending this unreachable state log for a long time (15 min, maybe more, maybe less) until eventually reconnect. |
|
If the host is unreachable, how does resetting the connection in nodeS7 on bad quality (with the modification in the PR) help anything connect any faster? |
|
Because the host is actually reachable, the PLC was reconnected to the power, but the libraries doesn't detect that. So resetting the connection when the PLC is up and reporting bad quality works just fine. |
|
This library already performs reconnection in case of issues with the underlying socket, and this is why you're seeing |
|
You can also send the logs/dumps privately if that's a concern |
|
@edkb Can the 15 min time frame before the reconnect be adjusted? I haven't managed to find where the 15 min setting is coming from. |
|
@exvarkin There's no setting to this, those 15 min its just a rough estimation that I counted manually in one of the tests, but it can take longer or shorter than that. Actually, it should be instantaneous, and why it is taking so long is really a good question. |
|
I see, I've seeing 15 min delay myself so I assumed it was configured that way somewhere. In my case, the PLC is becoming unreachable, (Host running nodeS7 can't ping the PLC) for about 1-2min. But the nodeS7 connection always waits 15 min before resetting the connection automatically. I've manual reset the node script after the communication was back up (before the connection auto restarts) and can read the PLC. Was hoping for a way to shorten that delay while I try to figure out the root cause of my periodic communication issue. |
No description provided.