Midweek PLC Musings
Last week I developed some general thoughts about what you would include in a typical single speed motor control function block (FB, what Rockwell calls an AOI), if you were inclined to make one. This time I’ll finish the preparation by going through the boring process of actually building such a function block from scratch. With this I’ll walk you through three stages:
- Stage 1, coming up with the proper, meaningful tag names (which become the labels to which we attach the input and output signals of the FB).
- Stage 2, sorting the order in which the tags will be declared as FB parameters. Because getting the order right affects the size, efficiency and final look of the FB we produce.
- Stage 3, finally writing the ladder logic code that performs the FB actions.
From last week’s effort, remember these are the items we came up with:
Start and stop the motor from HMI, Run request, Ready to run, Overload trip, Contactor coil output, Emergency stop, Enumerated variable, (1 = Ready, 2 = Running, 3 = Tripped, 4 = ESD , etc.), Enable minimum run-time, Minimum run time, Permission signal, Interlock signal, and Start counter
So let's address the turning of these requirements into properly named parameters that can be used with our new function block: Remember that the instance of the FB will be named by an appropriate tag name, something like CM123 - and the names we come up with will appear after the dot separating the main tag name from the FB parameter. So the permission signal for instance will be CM123.Perm. It is best to start the sub-tag name with the group then the function That way if there are multiple signals that belong together they are more easily identified. In this way the HMI signals become: HMI_Start and HMI_Stop
The equipment ready signal that indicates an MCC based starter is ready, becomes: Ready
The normal overload trip input is simply called: OL_Trip
The output to the starter or contactor coil could be called Run or On or Energize. But I like short: Out
?The input where the ESD signal is connected is best simply called by that label: ESD
We came up with an enumerated variable for the purpose of letting other processes (including possibly an HMI or Scada) know what is going on with the motor. Since this covers pretty well all the possible states the motor can be in, let’s call it: State
Then we want to be able to turn on and off the minimum run-time: Cfg_MinRun
To be able to alter the actual minimum run time we should make provision to enter the number of seconds for the timer preset (notice I choose a tagname that includes the units to remind us what they are, later when we come to use the FB): Cfg_MinSec
Now we need to make the permission signal useful, by allowing it to be used or not: Cfg_Perm
And then we need the input for the actual permission signal: Perm
Similarly we must make the interlock signal able to be used or not: Cfg_Intrlk
And again we need an input for the actual interlock signal: Intrlk
And finally we need a storage spot and possibly an output for the number of times the motor has started: Start_Cnt
Of course we can argue at length about the above decisions, to use the underscore or not, to spell the names out more completely or not, to choose different names altogether. These decisions are influenced by my experience, yours is likely to be different. I like the tag names to be reasonably short, and contain a good reminder of what they are all about if there turns out to be a lot of time before I reuse a function block (so I don’t have to pen the logic to remind myself about what the signal is all about).
Now we come to Stage 2, where we format the tags we defined above into a table format that is suitable for entering into the FB set of parameters. This will require some sorting and deciding on data types, but it is really no big deal:
TagName Usage DataType Req. Vis. Description
HMI_Start Input BOOL No No HMI Start input
HMI_Stop Input BOOL No No HMI Start input
OL_Trip Input BOOL Yes Yes Overload Trip input (norm. low)
ESD Input BOOL Yes Yes Wired ESD input (norm. high)
Cfg_Perm Input BOOL Yes Yes Config for permission signal
Perm Input BOOL Yes Yes Permission signal (1=Permission)
Cfg_Intrlk Input BOOL Yes Yes Config for interlock signal
Intrlk Input BOOL Yes Yes Interlock signal (1=Interlock normal)
Cfg_MinRun Input BOOL Yes Yes Config for min. runtime = 1
Out Output BOOL Yes Yes Output to starter coil
Cfg_MinSec Input DINT Yes Yes Seconds of min runtime
State Output DINT No Yes Motor (1=Rdy, 2=Run, 3=OL..)
Start_Cnt Output DINT Yes Yes Number of times motor started
<<Sorry about this messy formatting! LinkedIn does not know about tabs or importing a table. Argh!>>
A few comments on this table might be in order. You’ll notice I have listed all the inputs first. In this way the input signals into the FB will be shown in that order on the left side of the FB symbol. Also, all the booleans are sorted first. In this way they are more efficiently handled by the AOI. Some people would keep all the config items together, but that comes down to your preference. By laying out all the parameters that are handed into and out of the AOI in a table first, you can control how the function block looks, and work out the most suitable layout.
Now we are finally ready for Stage 3, the actual programming of the FB. I hope I don’t have to show you how to do that. In case you have never built a FB, just find the "Add-On Instructions" folder in the processor organizer pane, right click on it and click on "New Add-On Instruction". Then choose the name and decide if you want the new instruction to be used in ladder logic and/or function block (I suggest to make it for both). And now it’s simply a matter of adding your ladder logic code. Now you can insert the new FB just like any other of the built in instructions!
Did I miss anything?