We are looking at potentially replacing our aging VFDs. Currently we are using VFDs that get a digital output to turn on/off and multiple digital outputs to determine frequency output.
As we are researching possible Modbus TCP/IP replacements, we are hearing from multiple representatives that they have experienced issues with large amounts of Modbus TCP/IP devices.
Since our current strategy operates about 75 VFDs, has anyone experienced communication issues (or other types of issues) through Modbus with this many devices? If so, how did you handle the situation?
If it helps, we wouldn’t be sending signals to the VFD every few seconds. Shortest time would be around 1 minute between turning it on then turning it off.
We will be running on an EPIC using PAC control. The command to each VFD will vary but a single VFD may happen twice within a minute (then a longer delay of 10 minutes).
As an example, we would turn on a motor using the VFD for 30 seconds then turn it off. The next cycle may be 10 or more minutes later for that specific VFD. The next command to a different VFD would probably be 30 seconds later or longer. The chance more than 2-3 needing to be turned on/off at the same exact time would be vary rare. In this case separate charts would be issuing the command.
Checking for faults may be done more often, but we expect that to be done on a regular basis not faster than is recommended by the equipment manufacturer.
I personally prefer running field wiring to VFDs for control as it is easier for technicians to troubleshoot and allows different brands/models of VFDs to be installed without having to change programming, but I understand the desire to use Modbus as well for lower upfront costs.
If you are not familiar with Opto’s Modbus kit, it operates synchronously which means you will only be talking to one device at a time per chart. With the slow update rates you are looking at this shouldn’t be a problem. There are ways to use a single chart and communicate async over TCP (with the exception of OpenOutgoingCommunication which is always synchronous), but you won’t be able to use the Opto kit as-is. To summarize, if you want to talk to all the VFDs and use a single chart, it will not be much faster than if you were using Modbus RTU without significant extra work since you will only be performing a request/response with a single VFD at a time.
You will want to have a way of handling devices that are offline so that you are not trying to poll/push data to them causing a delay in your entire communication loop. Use the SendCommunicationHandleCommand to set the set.to and the set.to open.o options to as low values as your network/devices can handle. This will speed things up when a device goes offline.
We had a conversation with a vendor today who is telling us that the very best VFD for our application is one made by Allen Bradley that communicates using EtherNet/IP. I’ve seen some documentation on Opto’s website about setting up PAC I/O so that an AB PLC can communicate with it using EtherNet/IP, but is it possible to communicate with an EtherNet/IP device via PAC Control or NodeRED?
If there is a requirement for Ethernet/IP scanner support, you would need to use Codesys and the Ethernet/IP scanner SL module. Then you can add the powerflex VFD eds files to control them.
I tend to communicate with most VFDs with modbus. I have used both modbus tcp and rs485. As far as maintainability is concerned, I think modbus communication simplifies things and is more maintainable than running a minimum of 4 wires (start/stop, an AO speed setpoint, a common for the start stop and analog common) . You will often times need an interposing relay for the start/stop signal as well. If you want feed back you will need a few more wires as well.
The key is to have easy to read and maintain code for the particular model of VFD. In Codesys, I have a function block for each model of VFD and just instantiate a new instance for each physical VFD in the plant. By using modbus you are transferring physical complexity to programming complexity.
I have never seen any issues with with TCP devices but a VFD is one of the noisiest devices in most plants. Perhaps a grounded shielded high quality Ethernet cabling can mitigate most of the issues.
I also tend to lean towards modbus rs485 and have 8 VFDs on one chain and they seem to work well.
On another note, if you lose communication the VFD is going to stay at the last state. This may be desirable or not depending on the application. I usally have a safety plc connected to the safety contacts of the vfd for ESTOP and interlocking purposes.
The Codesys with Ethernet/IP with eds files method that @greichert mentioned is probably the most professional way to do this, but we monitor (not control) our PowerFlex 525 VFDs with 2-wire Modbus RTU and it works great. More here. Eventually we might send stop/start signals via Modbus.
Grabbing the data via Node-RED to InfluxDB & Grafana gives us tons of info that is usually locked inside crytpic codes / screens.
Long answer:
Depends on the baud rate of each port.
Depends on the poll time of each device.
Depends on how frequently you are writing to each node.
Depends on the time out you set for a non-response from each node.
Depends on the commands / payload you are needing for each node.
Depends on how you setup your chart in PAC Control.
For 9600 baud are are looking around 1.04 milliseconds per character or around 960 bytes per second.
Im sure @philip has a better real world answer for how many per port you might want to consider.
Don’t forget the EPIC serial port can only go into the first 4 slots and so you can only have a max of 4 cards.
You could put some USB to serial ports in, but they would share the USB port bandwidth, so keep that in mind.
The RS-485 standard allows 32 unit loads. Most RS-485 transceivers are fractional load - you will need to check your device for this information. For the common 1/8 load devices, you could have 256 devices on one RS-485 bus without using any repeaters, though you can only address 247 according to the modbus standard.
Now - is it reasonable or practical to have that many devices on a single RS-485 bus? - probably not, as a single malfunctioning device can take down the entire bus. It is better to have multiple busses with less devices - if you have a four port card - take advantage of it. I don’t think I have ever used a RS-485 bus with more than about 40 devices on it - it worked fine though and could probably run more, but if something fails, I wouldn’t want to try to find the failure.
Based on what I was told, Powerflex 525 can have up to 31 devices can be linked together. So I would think that since each port can handle multiple devices daisy chained together, the CSERI-4 could handle this without diving too much into specifics that I don’t have available. I’ll pass this information along.
Running VFDs on modbus RTU simplifies installation and lowers the up-front costs (sometimes significantly), but I disagree that is simplifies maintainability in the majority of cases.
What happens when a start/stop or analog signal wire is damaged verses what happens when the modbus comm cable is damaged? (Of course nobody knows nothing when trying to locate it)
How many devices are going to be affected?
Who has the skills to troubleshoot the field I/O verses the modbus network?
How long will it take that skillset to arrive on site?
When a VFD needs to be replaced with a new model- will the electrician be able to do it without the help of the controls engineer?
I’m not saying running the VFDs with modbus alone is wrong - it just needs to be done with some care and understanding and knowledge of the risks.
Another thing with modbus TCP specifically is security. If an attacker gets into your control network, they can perform writes directly to the modbus enabled drive bypassing the control system.
For all the downsides of Modbus, I tend to like it more than Ethernet/IP because of the simplicity of Modbus and for most things only minimal gains are made with Ethernet/IP. If you are really into the Rockwell environment it might be a good choice. I tend to stick with Modbus and Ethercat.
