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?

要查看或添加评论,请登录

Hugo Ahrens的更多文章

  • Midweek PLC Musings

    Midweek PLC Musings

    There was some commentary about function block programming and its suitability for the application at hand. It might be…

  • Midweek PLC Musings

    Midweek PLC Musings

    Last week I regaled you with the ever lasting impact of ladder logic. Turns out I’m not done with that topic, because…

  • Midweek PLC Musings

    Midweek PLC Musings

    In Support of Ladder Logic Not that ladder logic needs my support specifically to keep it alive. It’s doing quite well…

    4 条评论
  • Midweek PLC Musings

    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…

  • Midweek PLC Musings

    Midweek PLC Musings

    Abstraction in Art and the Art of PLC Programming What is it about abstract art that gets so many people unsure…

  • Midweek PLC Musings

    Midweek PLC Musings

    Alternating Logic What are we talking about when confronted with the requirement to discuss something that requires…

  • Midweek PLC Musings

    Midweek PLC Musings

    Back To The Simple Toggle You would think that a simple toggle bit instruction would be one of the simplest items to…

  • Midweek PLC Musings

    Midweek PLC Musings

    Truth And Fake News Those of us still using Ladder Logic during some part of our day have a great advantage over the…

    2 条评论
  • Midweek PLC Musings

    Midweek PLC Musings

    Calling a Spade a Shovel In the technical world we live in there is no faster way to discount your trade value - than…

  • Midweek PLC Musings

    Midweek PLC Musings

    Programmers Notebooks, what are they for? No they are not a design tool. They are a memory aid and progress reference.

社区洞察

其他会员也浏览了