hi there i have a issue of mc-protocol which is that it goes to Timeout and i have to reload the nodered url localhost:1880 to make it work now i dont have time to watch it whole day for that issue instead i use status node and function node to solve one issue which was it goes to Not Connected but now it solved, i got new issue which is Timeout now i need to reload that flow or whole localhost:1880 using function or what ever we can use. please help me with this issue.
That is often the last course of action. If there is an issue with MC Protocol nodes not recovering or not recoverable, then an issue should be raised on the MC Protocol nodes GH repository and the nodes should be fixed.
however
You should first establish if it is possible to recover by automation:
- when you get a timeout, try manually injecting
msg.disconnect: truefollowed bymsg.connect: true- are you now able to read data?
Also, when you get a timeout, is it because of a network issue OR are you requesting too fast and too often?
@Steve-Mcl
As i told i have covered that
i use status node and function node to solve one issue which was it goes to Not Connected but now it solved
Also, when you get a timeout, is it because of a network issue OR are you requesting too fast and too often?
Note that i tried with timeout till 20000ms and same issue is happening so instead of that i observed when i reload the page it gets solve so i need to solve the issue.
Yes, I read what you wrote, but it was lacking clarification of whether you actually tried MANUAL INJECT of disconnect, connect whenthe timeout occurs.
Since you have NOT shown us how your status node and function node are configured, it could be as simple as you are not checking the right things and it might not be sending the disconnect/connect messages. Thats why I said " * when you get a timeout, try manually injecting msg.disconnect: true followed by msg.connect: true - are you now able to read data?"
Exactly how did you "reload page"?
Node-RED Editor is just a web page and has NOTHING to do with the connection you your PLC.
Exactly how did you "reload page"?
Node-RED Editor is just a web page and has NOTHING to do with the connection you your PLC.
by click refresh button on browser or F5 it gets solved
Since you have NOT shown us how your status node and function node are configured, it could be as simple as you are not checking the right things and it might not be sending the disconnect/connect messages. Thats why I said " * when you get a timeout, try manually injecting
msg.disconnect: truefollowed bymsg.connect: true- are you now able to read data?"
[
{
"id": "c8872b90babd16ea",
"type": "MC Read",
"z": "12858bec79eb2936",
"name": "",
"topic": "",
"connection": "a1c447f77520f1bf",
"address": "topic",
"addressType": "msg",
"outputFormat": "1",
"errorHandling": "throw",
"outputs": 1,
"x": 480,
"y": 1840,
"wires": [
[]
]
},
{
"id": "f9590f0e917216dd",
"type": "function",
"z": "12858bec79eb2936",
"name": "function 23",
"func": "// Check if the status text is \"not connected\"\nif (msg.status && msg.status.text === \"not connected\") {\n // Set msg.connect to true to trigger reconnection\n msg.connect = true;\n return msg;\n} else {\n // If not \"not connected\", do nothing\n return null;\n}\n",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 330,
"y": 2020,
"wires": [
[
"c8872b90babd16ea"
]
]
},
{
"id": "2207ea92ec4cd738",
"type": "status",
"z": "12858bec79eb2936",
"name": "",
"scope": [
"c8872b90babd16ea",
"394cbe96cb5ae8ba"
],
"x": 160,
"y": 1980,
"wires": [
[
"15cf5d70025b1534",
"f9590f0e917216dd"
]
]
},
{
"id": "15cf5d70025b1534",
"type": "debug",
"z": "12858bec79eb2936",
"name": "debug 9",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "true",
"targetType": "full",
"statusVal": "",
"statusType": "auto",
"x": 340,
"y": 1960,
"wires": []
},
{
"id": "a1c447f77520f1bf",
"type": "MC Protocol Connection",
"name": "",
"host": "192.168.2.10",
"port": "45237",
"protocol": "TCP",
"frame": "3E",
"plcType": "Q",
"ascii": false,
"PLCStation": "",
"PCStation": "",
"PLCModuleNo": "",
"network": "",
"octalInputOutput": false,
"timeout": "15000"
}
]
here is the flow
No, the only thing pressing F5 does is to refresh the text on your browsers screen. It does not recover connection to the PLC. They are completely different things. Pressing F5 refreshes the client (your browser) - it has zero affect on the server (Node-RED Runtime).
Think of it this way, the browser might be on the other side of the world - pressing F5 will do nothing to the server side.
When a timeout occurs, just click inject again - you will either get data or you wont - use DEBUG nodes connected to the output of the MC READ to REALLY see if the data is coming though or if it is timing out.
Regarding the status: The status is "what happened last time" only! To make the status update, send a new msg into the MC READ.
No, the only thing pressing F5 does is to refresh the text on your browsers screen. It does not recover connection to the PLC. They are completely different things. Pressing F5 refreshes the client (your browser) - it has zero affect on the server (Node-RED Runtime).
As you told i understand certainly it gets issue solved but still the same thing happened what is a proper solution on this as i increased my time to 30000ms and i just connected 1 thing still same issue as per your info i have connected debug and its shows me timeout
-
What shows timeout? Show me a screenshot.
-
Can you get it to actually work (and I dont mean clear the "timeout" status using F5, I mean can you actually get GOOD data into a debug node?)
-
Have you ever received GOOD data from the PLC?
As for why it times out:
You will need to understand your network, your bandwidth, your Node-RED flows and whatever else is being requested on connection.
for example:
-
Are you polling too fast?
-
Are you making requests to more than one MC READ at the same time?
-
Is your network stable?
-
Do you know how to use wireshark to analyse the communication packets?
- What shows timeout? Show me a screenshot.
it was coming from mc-protocol node
- Can you get it to actually work (and I dont mean clear the "timeout" status using F5, I mean can you actually get GOOD data into a debug node?)
YES & NO Both the Thing, when i refresh sometimes it work with a refresh and sometime it does not so
- Have you ever received GOOD data from the PLC?
the output
{"plcname":"Puller6_Unit3","P4 Position":0,"Last Length":10977,"P4 Speed":0,"pic":0,"P1 Speed":800,"P2 Speed":71,"P3 Speed":199,"P1 Position":30083,"P2 Position":14259,"P3 Position":15654,"Puller Speed Set":500,"Puller Force Set":30,"yeild count":1,"Saw Length":36000,"P1 Start SET":12780,"P1 Drag speed":800,"P2 Start set":12780,"P1 Return speed":1800,"P2 Drag speed":800,"P2 Return speed":1800,"P1 Drag length":6500,"P1 Open length":1800,"P2 Drag length":6500,"P2 Open length":1800,"P3 Start set":300,"P4 Back Speed":300,"P1 Actual":17376,"P2 Actual":1485,"P3 Actual":2059,"P4 Actual":0,"P3 Speed":195,"P1 Rotat":823,"P2 Rotat":72,"P3 Rotat":-142,"P4 Rotat":0,"P1 Error No":0,"P1 Alram No":0,"P1 Status":32,"P2":12780,"P3 Start Position":300,"P4 Length SET":690}
This is what i get when it is working on 20000ms or above
- Are you polling too fast?
I have set in input node for 1sec of interval
- Are you making requests to more than one MC READ at the same time?
i do have connected 4 things to mc read and the output is good as above output
- Is your network stable?
Yes Network is strong and stable
- Do you know how to use wireshark to analyse the communication packets?
No i am newbie to wireshark and i dont know how to use it
- Attach a debug directly to the MC READ node
- Set the DEBUG to "Show Complete Message"
- Capture a full message when a timeout occurs using the
copy valuebutton - Paste the captured FULL msg into a code block reply
show me a screenshot
Are you continuously monitoring the connection to the PLC using PING or some other means?
Are there any other Ethernet communications happening to the PLC on the same IP and same PORT?
@Steve-Mcl
Below is Show Complete Message from debug
{"_msgid":"17c57ceda2eb22f6","topic":"D12,41","_linkSource":[{"id":"a476eecb5397aedbfd519facca98","node":"4e726d59b82c7d02"}],"error":{"message":"Error: timeout","source":{"id":"394cbe96cb5ae8ba","type":"MC Read","name":"","count":1},"stack":"Error: timeout\n at handleError (/home/omsoftware/.node-red/node_modules/node-red-contrib-mcprotocol/nodes/read.js:74:17)\n at Timeout._onTimeout (/home/omsoftware/.node-red/node_modules/node-red-contrib-mcprotocol/nodes/read.js:270:17)\n at listOnTimeout (node:internal/timers:581:17)\n at process.processTimers (node:internal/timers:519:7)"}}
Below is the image which shows the flow and second image which shows mc read and status node
the real output
{"plcname":"Puller6_Unit3","P4 Position":0,"Last Length":28626,"P4 Speed":0,"pic":1,"P1 Speed":0,"P2 Speed":174,"P3 Speed":0,"P1 Position":12763,"P2 Position":37741,"P3 Position":13583,"Puller Speed Set":500,"Puller Force Set":30,"yeild count":1,"Saw Length":36000,"P1 Start SET":12780,"P1 Drag speed":800,"P2 Start set":12780,"P1 Return speed":1800,"P2 Drag speed":800,"P2 Return speed":1800,"P1 Drag length":8500,"P1 Open length":1800,"P2 Drag length":8000,"P2 Open length":1800,"P3 Start set":300,"P4 Back Speed":300,"P1 Actual":-17,"P2 Actual":24978,"P3 Actual":3,"P4 Actual":0,"P3 Speed":0,"P1 Rotat":0,"P2 Rotat":179,"P3 Rotat":0,"P4 Rotat":0,"P1 Error No":0,"P1 Alram No":0,"P1 Status":32,"P2":12780,"P3 Start Position":300,"P4 Length SET":690}
Are you continuously monitoring the connection to the PLC using PING or some other means?
yes i do ping it continuously with ping node
Are there any other Ethernet communications happening to the PLC on the same IP and same PORT?
No
The timeout is coming from the link-call because the MC-Protocol has not responded. We can handle that by passing the error into the LINK-OUT node.
But first. We need to establish a controlled environment.
Disable the 1s interval on the inject & operate the inject manually (mouse clicks only) until you get a timeout THEN STOP for 60 seconds until all the debug messages have stopped coming through. Then operate it again - do you get good data?
My Theory:
- You have 16 calls to the READ subroutine.
- When a REAL timeout occurs, you are still polling every second.
- Eventually the MC READ times out (20s) but you have triggered 20 more reads in that time. They too will all timeout eventually.
In short this needs to be improved for:
- better error handling & detection
- auto recovery
- interlock / pause polling until connection is good
If you share that TAB of flow I will add some bits that will make this a bit more stable.
@Steve-Mcl
i have exported the whole flow
flows.json (60.2 KB)
Here is a rework. There are still ways to improve it, but this should give you some ideas.
Changes:
- Set PLC timeout to 3sec - this is more than enough
- Set all of the LINK-CALL timeouts to 5sec - keep this slightly higher than the PLC timeout
- Added "Error Check" nodes to ensure there is NOT an error before moving to the next READ
- Modified the PLC Read Subroutine to pass the error back (stops the LINK-CALL timeout)
- Add a flow context STATE flag to prevent repeated polling when the comms are busy or broke
- Added statuses to functions so you can see what is happening
- Add a "Auto Recovery" routine and a "RECOVER COMMS NOW" button to reset the PLC comms
Demo
I will post follow ups and flows in next post
Recommended Follow ups
The whole point of requesting multiple registers from the PLC in 1 go is to reduce unnecessary COMMS to the PLC & improve data consistency.
Remember, reading "lots of small things" is MUCH SLOWER than reading "a few large things".
I suspect it will be possible to get all of the data you need in as little as 5 MC READS (D0,100 , D100,100 , D200,100 ... etc)
Regardless of whether you do that, here are some of the easier ones that stand out
Here are the flows for the above demo
Puller_6.json (45.1 KB)
@Steve-Mcl
Thanks For the Flow But can you explain me how you did what are controls and poll monitor also recovery etc
Really? you want me to explain over 1 hours work in words?
- DISABLE POLLING prevents the "Poll timer" inject msg getting to the MC READ
- ENABLE POLLING allows the "Poll timer" inject msg to be passed to the MC READ
- RECOVER COMMS NOW - is it not obvious?!!!
You know I posted the flows - you can take a look at what it does!
Or you could simply watch the GIF I made that demonstrates it...
and read the description I painstakingly wrote out
and try the demo flow out for your self?
@Steve-Mcl
I know you worked for me and spend your time for me to help me out. and i appreciate it but if you could tell me a bit of this
means of Read PLC Subroutine and Recovery
so that if something get wrong then will it automatically get recovered means some error or not connected or timeout.
Since i dont know about it and i didnt even used what you have done.
The Recovery section
When a msg is sent to the LINK node named "RECOVER PLC COMMS", it does this
Yes. The flow will detect timeout not connected and error and will update the flow context
Polling
The first INJECT node simply fires every 1 second.
Next, the "Poll Monitor" function will check the flow context values and decide whether to send a trigger
- POLL - run the MC READs
- or WAIT (becuase it is still busy)
- or RECOVER (because it detected a problem)
- or DO NOTHING (because polling is disabled)
Important
Please watch this playlist: Node-RED Essentials. The videos are done by the developers of node-red. They're nice & short and to the point. You will understand a whole lot more in about 1 hour. A small investment for a lot of gain.
It covers context and many other things done in this work
