This looks awfully complex - and possibly not necessary. The loops are certainly not recommended. What is this doing? Perhaps you could share this part of the flow?
The flow then goes to the getter.
The switch node receives the payload from the getter and sends the flow on where msg.trip is equal to 1.
The next function node then process the data and makes another request object.
const obj = {}
const fields = msg.fields
msg.payload.data.forEach((data, index) => {
if(fields[index].field == "PID effect") {
obj[fields[index].field] = data
return
}
obj[fields[index].field] = Number(calculateFromRawValueMA(data).toFixed(1))
})
msg.influxObj.Temperature = obj
msg.fields = context.get("Holding")
msg.payload = {
'fc': 3,
'unitid': 1,
'address': 0,
'quantity': msg.fields.length
}
msg.trip = 2
return msg;
function calculateFromRawValueMA(mA) {
// 4-20mA signal
// -50 to 150 range
const PvHigh = 150 // Process value high
const PvLow = -50 // Process value low
const Ihigh = 20000 // mA high
const Ilow = 4000 // mA low
const I = parseInt(mA) // Amp/Process value
const Pv = (PvHigh - PvLow)/(Ihigh - Ilow)*(I-Ilow)+PvLow // Process value
return Pv
}
Then the flow goes to a 100ms delay to the getter.
This repeats itself until the end, where all the data is formatted pr influxdb standard and sent to influx.
The reason for the number of loops is requesting between different modbus functions and some of them because of several thousands difference in modbus addresses in the same modbus function...
if that makes any sense.
Before I can suggest any architectural change, I need to ask, are you using modbus as a means of sharing data between different node-red instances?
Based on your opening statement:
I have a server with a modbus-contrib-flex-getter that reads from another server Modbus-contrib-flex-server
It looks like that is the case. And if this is purely for node-red to node-red communication, there are far better ways to achieve this. Please appreciate that I don't have all of your details or end goal so it might be totally necessary. Please clarify.
I am using node-red as a modbus client in this example. But that's for testing purposes only.
My device uses node-red, flex-server.
As a communication protocol the requirement is modbus TCP/IP.
In a production environment some form of modbus client is used. Not Node-red.
As far as I know, it is not normal (or possible) to make requests across different function codes in one request.
I could make multiple requests at the same time. That is, not waiting for one request to finish before I make another one. In that way I would not need a loop like I'm using now.
I thought that a loop was the way to go. Would you rather make request at the same time?
Like requesting a data block in the holding register from address 1000 - 1080.
And at the same time request some coils from 500 - 550.
And some Input register from 0 - 60.
The modbus contrib flex getter takes care of this for me?
I had my Node-red editor open when the error occurred today.
The error is:
"Error: read ECONNRESET". This is outputed by the flex-server node.
I have an error Catch node attached to the flex-server, but the error was not catched by the Catch node.
For the client node-red to be able to get responses from modbus requests I had to redeploy the node-red where the flex-server resides.
Everything else works. Just the flex-server that doesn't respond.
yes the Modbus Flex Getter node should be able to queue the reads with its internal queue as far as you have the option enabled in Modbus Config to do so
It's not a network problem. I reach the linux machine fine. As I said, when I redeploy node-red the modbus flex-server start responding. If there was a network problem I could not have reached the node-red editor.
Maybe this github issue is related to what you see with ECONNRESET
but as usual the issue was autoclosed with no apparent fix ..
There is also a separate server node .. Modbus Flex Server by the same developer. This node also seems to suffer by the same issue not recovering after a socket error. There is a suggested fix though if you want to fork the repo and try it yourself.
Looks like I’m not alone after all.
I’ve seen this type of error mentioned in older posts where the creator provided a fix.
I thought this bug had already been resolved by now.
I remember also them fixing something related but i think it was for the Read nodes not reconnecting ?
I wish someone with the experience in programming could contribute to these nodes, since Modbus is still widely used in industrial applications .. hint hint
