What are downsides of bringing process variable (flow rate) into a pid loop via Modbus rather than direct connection
Proposed design has a flow control loop in PLC. Design proposes to read flowrate via serial Modbus. I would normally avoid bringing the input into pid loop via serial connection. Is this common?
1. A problem when just working with a Modbus data value can be the lack of knowing that communications has failed, not realizing that fact and continuing to control based on the last valid value. Sometimes there's a status word, like on a Wireless gateway to indicate a wireless node is off-line, but on a flowmeter? A diagnostics word(s) might alert to an issue within the flowmeter, but what alerts you to a disconnected RS-485 cable?
In your case, the flow meter is likely a slave/server, so if the comm link failsor master/client fails, how do you know that?
A lot of devices (server/slaves and/or master/clients) hold the last received value in a register and keep it there until the next successful comm transaction writes over the last value.
I've tested floating point values at a given interval for three (an arbitrary number) successive identical low order digits which would indicate a stale data value that has not been updated. In real world signal acquisition, low order digits are garbage noise digits that flutter up and down and nobody pays attention to the 3rd, 4th, 5th, and 6th digits to the right of the decimal point, except me, to make sure that they're not identically the same 3 times in a row.
2. A 2nd consideration is the necessity of empirically testing the Modbus comm link to know what its true throughput is. How often does the master/client poll the flowmeter and what is the slave/server response time and how often/quickly can a poll execute without a timeout? Is that polling rate satisfactory for the control loop? You don't really know until you test it. Baud rate is NOT an indication of how quickly the poll/response actually occurs. Just because a serial node can handle bits at 38k doesn't mean the device can respond in a millisecond.
Even so, given the limitations there are lots of drives that get their control setpoints via Modbus.
Thanks. My concerns are similar to what you described:
- Failure modes - ensuring PID loop recognizes/responds to comms failures.
- Response time - how quickly does the process signal update and how does this affect performance of the loop.
I guess both can be overcome if programmed properly. Just not how I would do it.
In general the downside of bringing process variable using a serial connection is people lacking experience with a certain protocol. Serial data to a PLC is used for decades using protocols like Profibus DP, DH+, Controlnet, Devicenet, HART, ASI, Modbus RTU...
The advantage of a serial communication is that the value is more accurate. There are no DA and AD converters. Noise on a signal can be detected. Obviously your communication speed has to be fast enough to ensure the PID controller has accurate data, but normally a PID controller has a scantime . So if you can insure data is refreshed in this time frame, the PID will work fine.
In the case of Modbus RTU communication, if you have a fault in the physical communication connection, you will get a timeout. Simply check that a request is followed by a respond in a certain time. If the connection is OK then a request will be followed by an answer. Fault bit can be used to determine if data is valid. CRC is used to determine if reception of data is OK.
Even with the previous mentioned widely used serial protocols data can freeze on connection error but this should be detected using the communication status word.
Every communication protocol has communication status bits you can use it is just a challenge to find and use them.