I have a system running; redeployed some node changes and a sequencer and the initial getter node in the flow reached state "stopped". Now injecting a message results in an error complaining that the node is in state stopped. What can be done to get the stopped nodes back to "active"?
so you have a Modbus-Getter node that has some configuration
and then you introduced a Modbus-Sequencer node that uses the same Config as the Getter ?
if yes .. then i guess that would break the config of the Getter since this is the purpose of the Sequencer .. to dynamically change the config but without sharing your flow its hard to tell.
Is this Modbus TCP or Serial ?
If TCP .. Can you create a totally new Config (add new modbus-client) for the one used in Sequencer ?
or better include the Read that you are doing with the Getter, in msg.sequences so the read is done by the Sequencer instead.
I just want to know if there's something that can be done in a flow to address the state of a modbus node that has become "stopped" - then I could consider implementing a response via a status node.
- for example, when the received status is "stopped", send the message required to restart the node. Meanwhile, the "stopped" nodes have been returned to "active" after a subsequent deployment that changed a couple modbus nodes.
I don't understand your assertion that modbus-flex-sequencer is to "dynamically change the config".
That node accepts one server, just like the getter, read, and write nodes. Right now, I'm directly encoding in the sequencer node a series of disjoint reads, rather than encoding msg.sequences to send to the sequencer node.
The single modbus getter I mentioned appears early in the flow, to read a single system configuration register; flow continues to the sequencer node upon success (so when there's a modbus error I get one error from the one getter node rather than many errors from the series of reads in the sequencer node). Since I had seen a read quietly fail, stopping a flow, I use a trigger to repeat the read until it succeeds, as discussed in this Steve Cope video starting about 4:20: Using the Node-red Trigger Node - YouTube.
[
{
"id": "2b2027fc14cd6102",
"type": "change",
"z": "fe2c538af62e54a6",
"name": "Set Reading true",
"rules": [
{
"t": "set",
"p": "reading",
"pt": "flow",
"to": "true",
"tot": "bool"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 870,
"y": 60,
"wires": [
[
"486b4963a32f6dc4"
]
]
},
{
"id": "486b4963a32f6dc4",
"type": "trigger",
"z": "fe2c538af62e54a6",
"name": "Trigger every 5 s",
"op1": "1",
"op2": "1",
"op1type": "str",
"op2type": "str",
"duration": "-5",
"extend": false,
"overrideDelay": false,
"units": "s",
"reset": "",
"bytopic": "all",
"topic": "topic",
"outputs": 1,
"x": 1110,
"y": 60,
"wires": [
[
"8c5f3a28b5f422e8"
]
]
},
{
"id": "8c5f3a28b5f422e8",
"type": "modbus-getter",
"z": "fe2c538af62e54a6",
"name": "Read System Config",
"showStatusActivities": true,
"showErrors": true,
"logIOActivities": false,
"unitid": "",
"dataType": "HoldingRegister",
"adr": "1018",
"quantity": "1",
"server": "628fb65d.a65618",
"useIOFile": false,
"ioFile": "",
"useIOForPayload": false,
"emptyMsgOnFail": false,
"keepMsgProperties": false,
"x": 1380,
"y": 60,
"wires": [
,
[
"842da3dac06b03a7",
"02bf6c1f701e8beb",
"218d377ced69a918"
]
]
},
{
"id": "02bf6c1f701e8beb",
"type": "change",
"z": "fe2c538af62e54a6",
"name": "",
"rules": [
{
"t": "set",
"p": "reset",
"pt": "msg",
"to": "true",
"tot": "bool"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 1120,
"y": 120,
"wires": [
[
"486b4963a32f6dc4"
]
]
},
{
"id": "842da3dac06b03a7",
"type": "function",
"z": "fe2c538af62e54a6",
"name": "Read System Config",
"func": "if (typeof msg.values !== 'undefined') {\n msg.payload = msg.values[0];\n} \nelse {\n msg.payload = null;\n}\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": ,
"x": 1220,
"y": 200,
"wires": [
[
"a2b54feaf0fecaa8"
]
]
},
{
"id": "628fb65d.a65618",
"type": "modbus-client",
"name": "Trumpf Truconvert System Control",
"clienttype": "tcp",
"bufferCommands": true,
"stateLogEnabled": true,
"queueLogEnabled": true,
"failureLogEnabled": true,
"tcpHost": "10.40.6.38",
"tcpPort": "502",
"tcpType": "DEFAULT",
"serialPort": "/dev/ttyUSB",
"serialType": "RTU-BUFFERD",
"serialBaudrate": "9600",
"serialDatabits": "8",
"serialStopbits": "1",
"serialParity": "none",
"serialConnectionDelay": "100",
"serialAsciiResponseStartDelimiter": "0x3A",
"unit_id": 1,
"commandDelay": 200,
"clientTimeout": 1000,
"reconnectOnTimeout": true,
"reconnectTimeout": 2000,
"parallelUnitIdsAllowed": false
}
]
The "Read System Config" node is one of the nodes that showed status "stopped" earlier. While in that state, all reads unsurprisingly produced a modbus error.
On the notion of using a status node, I see that status nodes configured to monitor individual modbus nodes fire when the configured server status changes, not only when the node monitored is triggered. That this would happen is predicable too by the status display under a node - my connect node, sequencers, getter and flex-write all go from showing "active" to "queueing" simultaneously when the flow triggered periodically to read a set of modbus registers is running, while the handful of write nodes (but not the flex-write) in subflows on the same editor tab show only "active". Consequently, where I monitor sequencers, I have flow variables indicating which one is active to stop the status flow for inactive sequencers.
i must have misinterpreted your original question ..
i have now run a Modbus Slave simulator and attached a Status node on your Modbus Getter.
When the device is online and i trigger a Read, the msg.status.text changes that i see are
connected, queueing, reading done, active.
When the device is offline and i trigger a Read i get a failure and the reconnect kicks in.
failure, reconnecting after 2000 msec., timeout, initialize, reconnecting after 2000 msec ..
I neither case did i see a state "stopped". When does that happen ?
But besides that .. what do you want to do when the device is offline / stopped / failed to reply ?
In my project for example, instead of using a Status node to re-trigger a read, I do my reads every x seconds and have the Modbus nodes set to produce an "Empty msg on Modbus fail"
and then handle it by settings the failed reply's payload to null (as i see you try to do in your function node)
if it was a successful read I just send the value
if (msg.payload == "" || msg.hasOwnProperty('error')) {
msg.payload = null;
}
else {
msg.payload = msg.payload[0];
}
return msg;
Test Flow
[{"id":"842da3dac06b03a7","type":"function","z":"7bdde9e9b6e1d37d","name":"Read System Config","func":"if (msg.payload == \"\" || msg.hasOwnProperty('error')) {\n msg.payload = null;\n}\nelse {\n msg.payload = msg.payload[0];\n}\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":350,"y":520,"wires":[["67b20ca16098f323"]]},{"id":"5bcc20071e8a1ef8","type":"inject","z":"7bdde9e9b6e1d37d","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":220,"y":380,"wires":[["d816410827ad688b"]]},{"id":"67b20ca16098f323","type":"debug","z":"7bdde9e9b6e1d37d","name":"debug 37","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":560,"y":520,"wires":[]},{"id":"5e73b141c292a3ce","type":"debug","z":"7bdde9e9b6e1d37d","name":"debug 38","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":780,"y":320,"wires":[]},{"id":"49a195ae72e090ad","type":"modbus-flex-getter","z":"7bdde9e9b6e1d37d","name":"","showStatusActivities":true,"showErrors":true,"showWarnings":true,"logIOActivities":false,"server":"628fb65d.a65618","useIOFile":false,"ioFile":"","useIOForPayload":false,"emptyMsgOnFail":true,"keepMsgProperties":false,"delayOnStart":false,"startDelayTime":"","x":580,"y":380,"wires":[["5e73b141c292a3ce","842da3dac06b03a7"],[]]},{"id":"d816410827ad688b","type":"function","z":"7bdde9e9b6e1d37d","name":"1018","func":"msg.payload = {\n 'fc': 3,\n 'unitid': 1,\n 'address': 1018,\n 'quantity': 1\n}\n\nreturn msg","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":370,"y":380,"wires":[["49a195ae72e090ad"]]},{"id":"628fb65d.a65618","type":"modbus-client","name":"Trumpf Truconvert System Control","clienttype":"tcp","bufferCommands":true,"stateLogEnabled":true,"queueLogEnabled":true,"failureLogEnabled":true,"tcpHost":"10.40.6.38","tcpPort":"502","tcpType":"DEFAULT","serialPort":"/dev/ttyUSB","serialType":"RTU-BUFFERD","serialBaudrate":"9600","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","serialAsciiResponseStartDelimiter":"0x3A","unit_id":"1","commandDelay":"200","clientTimeout":"1000","reconnectOnTimeout":false,"reconnectTimeout":"2000","parallelUnitIdsAllowed":false}]
maybe this "Empty msg on Modbus fail" is something you can implement in your bigger flow and helps simplify things instead on relying on the Status nodes.
I don't know just how the read and sequencer nodes became "stopped", except that it happened as a consequence of deploying Modified Nodes where some of the modifications involved modbus-write and modbus-flex-write nodes; the deploy happened while the flow was running, doing periodic modbus reads from the same server as the writes use.
Thanks for the reminder about "Empty msg on Modbus fail" - heretofore I've been assuming errors are thrown, but I understand that to get catchable errors one needs to have set DEBUG=contribModbus*; it'll be better not to rely on nodered configuration since it'll eventually be running on other systems than the one I am developing on.
The status nodes monitoring sequence nodes currently aren't being used to detect errors, just the completion of operations. I suppose I can instead rely upon the order of read operations in the sequence and just branch off the response to the last one to continue the flow.
may i ask what version of node-red-contrib-modbus nodes you are using ?
I found some Github issues that could be related to what you are seeing with the "stopped" state
( source1, source2 ) apparently this is fixed and the error handled properly in newer versions of Modbus
thanks for your continued attention. I am using node-red-contrib-modbus 5.23.2, on Nodered v3.0.2.
try the latest modbus 5.25.0 .. maybe the developers fixed something related to your issue (changelog)
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
