Hello,
We have connected NR to our industrial printers. Everything works correctly so far but I cannot find any way to close active connection with the printers.
Why: If any error occurs in our NR logic we want to let PLC connect to the printers to intercept essential functions until someone fixes the issue. After someone looks on the issue we want to restore TCP connection between NR and printers.
We are using "tcp request" node with option "Close: never - keep connection open".
Is it even possible to close TCP connection?
you should be able to kill the connection with msg.reset set to boolean true.
Hi!
Unfortunately it doesn't work. My local NR instance is on 3.1.5 version.
When msg.reset is set to true I get error.
Here is my testing flow:
[
{
"id": "93772702ba702f70",
"type": "tab",
"label": "TCP tests",
"disabled": false,
"info": "",
"env": []
},
{
"id": "bf15c7214b4493d2",
"type": "tcp in",
"z": "93772702ba702f70",
"name": "TCP Server (Listen on 8006)",
"server": "server",
"host": "",
"port": "8006",
"datamode": "stream",
"datatype": "buffer",
"newline": "",
"topic": "",
"trim": false,
"base64": false,
"tls": "",
"x": 280,
"y": 140,
"wires": [
[
"c8de7779c97be3f6"
]
]
},
{
"id": "c00764e0854f5a70",
"type": "tcp out",
"z": "93772702ba702f70",
"name": "Reply to TCP",
"host": "",
"port": "",
"beserver": "reply",
"base64": false,
"end": false,
"tls": "",
"x": 950,
"y": 140,
"wires": []
},
{
"id": "44822ab4c87fce3a",
"type": "tcp request",
"z": "93772702ba702f70",
"name": "",
"server": "localhost",
"port": "8006",
"out": "sit",
"ret": "buffer",
"splitc": " ",
"newline": "",
"trim": false,
"tls": "",
"x": 530,
"y": 400,
"wires": [
[
"bcbf6902c9417b79"
]
]
},
{
"id": "bcbf6902c9417b79",
"type": "debug",
"z": "93772702ba702f70",
"name": "debug 119",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "true",
"targetType": "full",
"statusVal": "",
"statusType": "auto",
"x": 730,
"y": 400,
"wires": []
},
{
"id": "15993346ef171a92",
"type": "inject",
"z": "93772702ba702f70",
"name": "msg.reset = true",
"props": [
{
"p": "reset",
"v": "true",
"vt": "bool"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"x": 300,
"y": 440,
"wires": [
[
"44822ab4c87fce3a"
]
]
},
{
"id": "2868ef716c960f42",
"type": "inject",
"z": "93772702ba702f70",
"name": "payload = 'some text'",
"props": [
{
"p": "payload"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "some text",
"payloadType": "str",
"x": 280,
"y": 360,
"wires": [
[
"44822ab4c87fce3a"
]
]
},
{
"id": "c8de7779c97be3f6",
"type": "function",
"z": "93772702ba702f70",
"name": "add \"echo\" to received payload and send it back",
"func": "\nmsg.payload = msg.payload.toString()\nmsg.payload = \"echo: \" + msg.payload\n\nreturn msg;",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 640,
"y": 140,
"wires": [
[
"c00764e0854f5a70"
]
]
}
]
When sending msg.reset in order to NOT receive errors msg.payload also needs to be set.
I suspect that since msg.payload != null then msg.reset is ignored and I still receive response from the server.
Maybe fault is on node that is listening and I should try how it all works on our industrial printers but unfortunately I don't have access to them as of now.
Ah OK - indeed a small buglet :-).... It does indeed close the connection.... but then re-establishes it immediately...
What I think should happen - please discuss - is that if ONLY msg.reset is set then it should close the connection and remain closed... If there is also msg.payload then it should close the connection and then re-open and send the new payload.
Does that sound sensible ?
\EDIT\ - Actually looking at the code :-)... the ability to reset the connection has not been released yet... It will be in v4 - but indeed that does have the bug above so will be fixed before release.
1 Like
Hello,
I think more intuitive approach would be like that:
- msg.reset - resets connection (that is disconnecting and connecting to host again), with optional configurable msg.reset_delay.
- msg.close - completely closes connection.
Both scenarios should not care whether msg.payload exists (unless you want it, then you could obviously add something like msg.reset_payload_ignore)
Unfortunately I don't have that much time untill v4 release. Is there any way I could modify existing node? It's a matter of a simple "if" condition so it shouldn't be that hard to modify.
Hi,
So I've tried to copy-paste nodes (with help of the tutorial on website) but I ended up with error in palette manager "MODULE_NOT_FOUND".
Any help or advices? 
I literally only need to add one "if" condition and my flows will be working like well oiled machine.
V4 beta now out. So you can get the fix in there
Hi there!
Unfortunately we would like not to use beta versions. Only stable versions are permitted - my manager insisted on it very much. He agreed on me making slight changes to current tcp nodes.
Could you help me out?
I've tried it previously and I failed with error "MODULE_NOT_FOUND" like I stated in my previous reply.
(Unfortunately since then I had very little time to look into it and probably will still have very little time in future)
You can see the pull request here - Let msg.reset reset Tcp request node connection when in stay connected mode by dceejay · Pull Request #4406 · node-red/node-red · GitHub
Feel free to make the same changes locally.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
