I’m working on streamlining VFD control at plant. Currently, the VFDs are set up for hard wiring, where each control point is connected to a OPTO22 card, connected to a Groov Epic PLC. What I would like to do is control the VFDs in the plant with Node Red’s Modbus TCP nodes.
Currently, I am not having issues with VFD parameters, or setting up the nodes. What I’m wondering is if it would be possible to control the plant with the TCP nodes. There are approximately 80 VFDs in the plant (100 total Modbus devices - sensors, controllers, vfds, etc). I am reading about 15 data points from each drive, and would have to write about 2-4 points per drive. The plant is set up with 1 gb switches handling the communications.
What would be the best way to set up the Node Red/Network to make this happen?
What sort of ‘control’ is required for the 80 VFDs?
Node-RED can only do ‘control’ slowly and is not synchronous, so as far as tight control loops go, its not the right tool for the job. This is in response to your comment about reading 15 points and writing 4 points.
I’m sure you have done the math, but that’s 1200 tags being read and 320 tags written (not counting your extra 20 devices with their tags). Whats not mentioned is how often all those tags need to be read/write.
Sounds like you are using analog input cards for some other control aspects? Are you using PAC Control or Codesys on the EPIC?
How many EPIC processors are you using? If all those tags are to one instance of Node-RED on one EPIC, see point 1 about the speed and control requirements. If they are spread over a few different controllers are there any synchronization requirements? If so, how tight is the timing?
One other thing to consider is when a VFD is replaced with a new version or different brand you will inevitably need to update the logic as well. With field IO, the VFD guy commissions the drive and you’re done.
I always have customers wanting to use communication to control the drive (due to low first cost) and I usually talk them out of it - there are cases where it is appropriate though.
Philip’s comment is very valid. Complexity increases when doing everything through comms, and it can make on-site troubleshooting more difficult. This is especially true if you have technicians that prefer multimeters to laptops.
I have done Modbus integration for 8 or so different VFD suppliers and they are all different. We use an in-house Modbus server built in C++ (shell access), so I have no familiarity with the challenges of getting this working with Node-RED. I can vouch that if done correctly, Modbus control can be very reliable though.
I have (2) recommendations if you go the Modbus route:
First, if it is critical that you stop a drive immediately, I suggest still wiring up an input on the VFD’s for an enable. That way you can immediately drop this signal and the VFD will stop. If wired through IO, you could also trigger this output through a watchdog on the PR1.
Second, I highly suggest configuring the fieldbus timeout/fault parameters on your VFD’s. If there is an interruption between the PR1 and VFD, you want the drive to stop.
For most VFDs the ‘control’ is: Start forward, Start Reverse, speed reference, VFD reset. In terms of tight control loops, most of the plant processes are slow, meaning they don’t have to stop or start on a dime (within milliseconds), but obviously, the tighter the better. I write to the drive on the order of, I would say, minutes. The only condition that would require speed would be an e-stop.
For the current set up, I am using PAC Control Pro on the EPIC, there are 5 total EPIC processors with their own card configurations. The control engine in PAC Control Pro is loaded onto one EPIC which runs the whole plant. I am considering switching to a DCS, but I have received advice that it would likely not have much effect on the performance.
I have been doing all the VFD commissioning for the plant currently. However, it is a good point, that in the future all fixes will be more difficult over Ethernet.
Sounds like a switch from Node-RED Modbus to PAC Control Modbus toolkit is the best option here.
No need for the slower Node-RED to be in a system like you have.
