ControlLogix

[paraffin power]

Hi
I'd like to create a program which can be called umpteen times but with different parameters, like an FB in Step7.
I currently use separate programs, making use of program tags but something tells me there's other ways.
Hope you can help
Thanks
PP

 

[seppoalanen]

Use separate programs as this far. I have done them over 25 years for quarantee better life to maintenance people. Someone who use better English can tell why I have done that.

 

[Steve Etter]

It sounds to me like you need to use indirect addressing.

If you are not familiar with this, basically you need to create a two register arrays. One array is a storage array where all your different variables will be stored and the other is a common array where the program looks for its "current" variables.

You then create a "pointer" register that will move/copy the appropriate values from the storage array into a common array. Each time a different set of variables is needed, you look at your pointer value, load the variables from storage to the common array and run the application.

This is how you can write and store recipes for batch processes.

Does this help or did I missunderstand your question?

Steve

 

[kamenges]

You can't do an exact match to the Siemens FB calls since there is no such thing as instance data blocks with CLX (there are no data blocks at all). However, you can do something that might be acceptable.
With the S7 you can enter the in, out and stat parameters you need as the devolop your application. In CLX, make up a user defined data type for this function. Include all the dtaa you need for the function. Then use a JSR to this file. You wil have one input and one output parameter. They will both be the same instance of the data type you created when you made your function.

So if I wanted to control a motor, in your main program in CLX:

JSR (Motor_Control, 1, Motor_1, Motor_1)

Motor_Control is tha name of my fictional function
The number 1 tells the JSR that there is one input parameter
Motor_1 is an instance of a user defined data type Motor

Motor contains:

Motor_Forward BOOL
Motor_Reverse BOOL
Desired_Speed INT
Actual_Speed INT
Overload BOOL

This is a pretty simple example but you get the idea.

In the called function you would have at the top:

SBR(Motor_Instance)

and at the bottom:

RET (Motor_Instance)

Motor_Instance being data type Motor.

You could then call the subroutine as many times as you want with different data structures going in at the JSR.

Now to Seppo's point. Thism type of programming can be VERY hard to troubleshoot. Many people who use plcs like the idea that you can look at a piece of logic on the screen and determine it's status. Once you start doing multiple calls to a given subroutine you give up this ability. Now you need to have the logic open as well as a tag window showing the instance structure you are interested in. This can be annoying at best and debilatatingly confusing at worst. Especially when the plant manager is looking over your shoulder because the machine doesn't work.

I now that using separate programs does not allow you make a single change and have it propogate across all your programs. But people who look at your stuff in the future will be much more comfortable if you keep the structure straightforward.

Keith

 

[seppoalanen]

Thanks Keith !

 

[paraffin power]

Thank you all for the replies!
Keith - that is exactly what I was trying to achieve.

 

[Matthias von Zorn]

Debugging

This is why PLCs need better debugging tools, like break points and stepping. Can u imagine trying to debug a C program with the tools a typical PLC has?

 

[kamenges]

There are some plcs that provide tools similar to what Matthias refers to. However, they are of limited practicality in industrial controls, IMHO. With a desktop computer application you can trigger a breakpoint, shut down your process and look at some data with very few ramifications. If you do that with a plc controlling a gantry you may end up with a crane through a wall.
PLCs in general already have a pretty good online data display format. The addition of higer level level programming functions have kind of overstretched the old display capabilities. What they could really use is a triggerable display update. Something like a system bit you could set when you call a subroutine instance you are interested in. The development environment would only update on the pass this bit is set for. That alone would make debugging orders of magnitude easier.

Keith

 

[Tom Jenkins]

kamenges, we do a lot of the type of thing you are referring to. We accomplish this by having a bunch of "debug" bits that we put in various rungs, or subrouting calls, that we may want to disable or enable specifically for de-bugging. It isn't the same as single stepping in C or BASIC, but with a little ingenuity you can do a lot. If you want, you can even put in a timer so that after a while these bits are all reset - eliminates the "Opps, I forgot to clear my debug bits" panic attack on the plane ride home.