Midweek PLC Musings

Thinking about a General Motor Logic Block.

So last week we looked at abstraction, and I thought it might be helpful to abstract out something that is common to a lot of PLC applications. A simple single speed motor control block that has most of the functionality you would expect in say eighty percent of the situations you come across. That way it should not be too hard of a task to add the specific feature(s) that you just can not live without.

Remember we spoke last week about some of the good reasons why we would want to develop our own function blocks. As you might see from the following, it's worth it to put in some time to develop your own, since as it turns out, there is hardly anyone else who would build it like you would. And that is the point, the thing should to be useful to you, for it to make sense to invest the time.

One of the first things to include in our set of features is the ability to start and stop the motor from HMI issued commands. Then, quite often you would want to run the motor based on logic from the automatic portion of your control system. I’d call that a run request, a single bit that when on, makes the motor run. It is advantageous to have a ready signal that can be used if an HMI is involved, to allow the operator, or for that matter an interlocked process, to know that the motor is ready to run. Of course we need to have an input for the overload trip signal, because that always has the bad effect on the motor not being able to run. And we need an output signal that finally controls the motor contactor coil. And one item we always have to include is the emergency stop, which usually is hardwired and has nothing to do with the PLC control system - except that these days we are usually connected to an HMI - and so we should let the HMI know when someone pops the ESD. And there is one final, sort of a status variable that is useful, especially if the whole design is not fully detailed out: An enumerated variable, a number that can represent all sorts of information if an HMI of some sort is used. See that last minute addition of the ESD signal, it would simply add one more number to the status information (1 = Ready, 2 = Running, 3 = Tripped, 4 = ESD , etc.)

So that is the very basics, but why stop there since we are starting with a blank slate. Might as well include some more of the features we often build into the motor control logic. How about protecting the motor from willful start/stop cycling? That is easily done if we include a configuration for minimum run-time. This would take the form of a configuration bit to turn the feature on, and a numeric input for the actual number of seconds minimum run time. And how about a permission signal that we often have to contend with. Might as well include that so we can tell the motor logic that it is ok to start the motor. If we do that we should also include an interlock signal, that we could drive from a connected process the possibly needs to stop the motor when something bad happens in the process.

With todays networked electronic overloads we could likely include a whole bunch more - like motor current, voltage, power and predicted time to an overload trip. But lets keep it simple for our first example, and leave that for some future exercise. I would like to include a counter to track the number of times the motor was started, because that is useful to evaluate the contactor condition. And we should also track the motor run time, because that will give us a hint about the requirements of lubrication and bearing life.

So there you have it. The basic requirements are outlined. Now we just have to give our features some good names and order them from boolean to double integer and floating point so we can declare our function block parameters, and build the actual function block logic. Till next time. Tell me if there are some other features that you would consider important enough to add.