This is Part II of a two-part series. Read Part I.
The original variable frequency drives (VFDs) used control via Remote I/O. Although it was current technology at the time of the original SLC 500 processor, by the year 2000 that technology, while still around, was being replaced by newer, more robust network protocols. Physical wires were used to enable the drive, and passing a 0 to the drive to the speed-reference parameter in the drive acted as an “off” command to the drive. By current standards, this was not very safe, but it was very common back then. For our purposes, our people would drop the main power to the entire control system to render the system safe for cleaning purposes.
Safe Torque Off (STO) is a key feature for us. STO renders the output circuit of the drive incapable of passing power to the output terminals of the drive. By tying the e-stop relay output to the STO input of the drive, one can safely disable the drive from passing any current out of the device. This now allows our people to press an e-stop or open an inspection lid and know that any motion of the blender is rendered safe until the safety device is closed and the reset button is pressed on the safety circuit.
The ENETR module seems like a simple thing where one can use rotary switches to set the device address in the private network of 192.168.1.xxx. However, for us, this provides for the electrician to set this at time of installation and our controls person has immediate connection to the drive at power up without having to use the keypad to enter an address. If, as in our case, you have the programmable-logic-controller (PLC) application from the previous control system, then you can have the PLC automatically download the configuration into the drive from the parameters saved in the PLC application. This can save tremendous time in the commissioning phase of a controls upgrade.
Most manufacturers will have a similar version of these features on their variable frequency drives, but it is the added features in my favorite drive that are of even greater value.
The drive we commonly use comes, out of the box, with built-in commissioning profiles. At any time during the commissioning process, a wizard can be activated that will pre-load a set of parameters that are specifically selected by the manufacturer to best create the operation of the listed profiles. For example, there is a wizard for an induction fan. Another profile sets up a start point for commissioning a centrifugal pump. These common sets of parameters aren’t intended to be the final solution to your application, but they give you a good starting point from which you can fine tune your solution.
Another feature that has recently shown up in my favorite drive is a feature called DeviceLogix. This technology allows for devices to execute simple control functions independent of the central processor. The DeviceLogix editor can be used to develop code in either function block or ladder. In order to use the run-time code, one must configure device parameters. These parameters map physical I/O to DeviceLogix inputs and outputs.
Using this technology allows for decisions to happen at the device level. These decisions, not needing a central processor, are a quick and local response to an input without the performance and activation lag inherent with network and backplane interactions. It isn’t much of a stretch to imagine that DeviceLogix can be used to sense a broken communications link with the central processor and command the drive to a pre-defined state. Depending on the device where the DeviceLogix is located, this could mean either a continuation of controlled process or a shutdown of that process, depending on the application. The user manual for my VFD suggests that one example of this device-level decision could be in a mixing process where stopping the mixer could result in a huge cost.
Another example of where DeviceLogix might be of use is simple control where a PLC isn’t needed at all. Imagine a simple conveying system where a lead sensor on each conveyor sensor turns on that particular conveyor section. When the next sensor is made, the first section turns off and the next section turns on. This could all be done with the local I/O board in one of the drives functioning as the master and commanding the other motors in the system.
In my situation, I would not have noticed this new feature had I not had an upgrade program stretch out as far as it has. Luckily, this was evolution within the current model, but it could easily have been a situation where a new model would have to be bought to get the same function.
Automation evolution moves at an incredible rate, and it is important that we try and stay on top of those emails and white papers that our suppliers send us. Some of them can lead to wonderful discoveries and time-saving measures.
