To use SBR, Add-Ons or not? (RSLogix 5000)

[Skyl3r]

Hello All,

I'm relatively new to PLC programming, Ladder Logic, Structured Text, SFC, etc. I have roots in Java, C#, PHP and other languages.

I need to do a task that will be calculated exactly the same way potentially hundreds of times in one program. It needs to take some values as input and return a value as output. From a traditional (or traditional to me) standpoint, this is the perfect application for a method or function. It seems the equivalent in RSLogix is Subroutines + Params or Add-on functions.


My plan is this:

Write the SBR or add-on in Structured Text as it seems the easiest and most readable way to complete this function (maybe because I'm used to seeing it.)
Then the other controls guys can reference my SBR or function in their ladder logic.

Is this a good idea or will everyone who may have to debug my code down the road hate me for doing it in Structured Text?
I tend to get that message when researching it.

 

[Operaghost]

If you build the AOI smartly, they shouldn't have any need to see the backing code that you wrote.

OG

 

[kamenges]

Originally posted by Skyl3r:

Is this a good idea or will everyone who may have to debug my code down the road hate me for doing it in Structured Text?
I tend to get that message when researching it.

You're right. This is a hot-button topic. Then again, opinions are like @$$holes...everyone's got one.

My personal opinion is that, if you are writing a dedicated function that you will debug VERY thoroughly and is VERY unlikely to change, you could write the thing in Klingon and no one would know the difference. Users of AB PID functions have been living with this for years. There is no way to see under the hood so people just accept the fact that they can't see what's going on and live with what it is and move on with life. One school of thoght says your AOI would be the same thing. In addition, if the function is really complex enough that structured text is the only reasonable way to approach it, chances are anyone who wouldn't be able to decipher ST would likely not be able to understand what you are doing anyway, making the selection of language a moot point.

Do this as an AOI as opposed to a subroutine. Subroutines have no inherent data encapsulation or any tools to directly analyze specific instances of function. This makes subroutines called with variable data very difficult to troubleshoot. Since AOIs have data encapsulation, when you view a specific instance of an AOI inline in the main body of the program you will be viewing the data that is tied to that specific instance. The exception MIGHT be In/Out parameters. These are passed by reference as opposed to being passed explicitly. I have never looked closely enough at In/Out parameters that are updated in multiple locations in the plc to know if the value is frozen for the AOI instance being viewed or if the values are randomly read and might not be tied to the execution of the instance.

Keith

 

[ganutenator]

You're right. This is a hot-button topic. Then again, opinions are like @$$holes...everyone's got one.

My personal opinion is that, if you are writing a dedicated function that you will debug VERY thoroughly and is VERY unlikely to change, you could write the thing in Klingon and no one would know the difference. Users of AB PID functions have been living with this for years. There is no way to see under the hood so people just accept the fact that they can't see what's going on and live with what it is and move on with life. One school of thoght says your AOI would be the same thing. In addition, if the function is really complex enough that structured text is the only reasonable way to approach it, chances are anyone who wouldn't be able to decipher ST would likely not be able to understand what you are doing anyway, making the selection of language a moot point.

Do this as an AOI as opposed to a subroutine. Subroutines have no inherent data encapsulation or any tools to directly analyze specific instances of function. This makes subroutines called with variable data very difficult to troubleshoot. Since AOIs have data encapsulation, when you view a specific instance of an AOI inline in the main body of the program you will be viewing the data that is tied to that specific instance. The exception MIGHT be In/Out parameters. These are passed by reference as opposed to being passed explicitly. I have never looked closely enough at In/Out parameters that are updated in multiple locations in the plc to know if the value is frozen for the AOI instance being viewed or if the values are randomly read and might not be tied to the execution of the instance.

Keith

Nice instantiation point. Well done.

 

[Skyl3r]

You're right. This is a hot-button topic. Then again, opinions are like @$$holes...everyone's got one.

My personal opinion is that, if you are writing a dedicated function that you will debug VERY thoroughly and is VERY unlikely to change, you could write the thing in Klingon and no one would know the difference. Users of AB PID functions have been living with this for years. There is no way to see under the hood so people just accept the fact that they can't see what's going on and live with what it is and move on with life. One school of thoght says your AOI would be the same thing. In addition, if the function is really complex enough that structured text is the only reasonable way to approach it, chances are anyone who wouldn't be able to decipher ST would likely not be able to understand what you are doing anyway, making the selection of language a moot point.

Do this as an AOI as opposed to a subroutine. Subroutines have no inherent data encapsulation or any tools to directly analyze specific instances of function. This makes subroutines called with variable data very difficult to troubleshoot. Since AOIs have data encapsulation, when you view a specific instance of an AOI inline in the main body of the program you will be viewing the data that is tied to that specific instance. The exception MIGHT be In/Out parameters. These are passed by reference as opposed to being passed explicitly. I have never looked closely enough at In/Out parameters that are updated in multiple locations in the plc to know if the value is frozen for the AOI instance being viewed or if the values are randomly read and might not be tied to the execution of the instance.

Keith

It's not extremely complex, but in Ladder Logic it would be quite a few extra branches on quite a few rungs, so I thought it would be preferable to do it as an SBR or AOI in 15 lines of structured text then to do it as 15 extra branches 100 times on a large amount of different programs.
Thanks for the description as to why I should use AOIs instead of SBRs if anything. That makes pretty good sense.

The other controls guy should be back today so I'll be able to discuss his views on this.
I wanted to get a better general understanding of the implications of using an AOI or SBR before I got into that discussion with him.

 

[kamenges]

Originally posted by Skyl3r:

It's not extremely complex, but in Ladder Logic it would be quite a few extra branches on quite a few rungs, so I thought it would be preferable to do it as an SBR or AOI in 15 lines of structured text then to do it as 15 extra branches 100 times on a large amount of different programs.

This is kind of unrelated to your specific issue but it applies generally. The quote I included is mixing two different things that are only incidentally related. The idea of using a subroutine or an AOI to perform the data analysis function is completely unrelated to whether you write the subroutine or AOI using ST or ladder. The quote kind of has both things mixed together. It seems to infer that you can only go the AOI route if you use ST and, conversely, if you choose ladder the function logic must be included inline in its entirety at each instance.

The reason I bring this up is it tends to muddy discussions when you do that. Each point has its own merits and issues unrelated to the other. Present and discuss them that way. You will tend to be a more effective litigator if you do.

Keith

 

[RET]

Okay, so the one BIG THING that no one has mentioned and that you should know is that when using subroutines in the program and JSR instructions, if you make an incorrect tag reference in a JSR instruction (e.g. try to pass a an incorrect data type (real instead of int), or have too many input parameters than required, or too few), the processor will fault which could mean big problems, ask me how I figured that one out.

Now the real advantage to AOI's, is that it's near impossible for that to happen, as it prompts you for exactly what inputs are needed, and will show a rung error if you input an incorrect tag type.

 

[AshleyParr]

may as well add my two cents,

I hate coming to code and finding SBRs being called to operate equipment (arrrrgh)!! Its hard to trouble shoot, in my experience it never makes sense to anyone who is still around & generally i've not had many good experiences with them.

AOI's or function blocks on the other hand, i love. I'm quite happy using them repeatedly, they offer stable code, repeat-ability & easy troubleshooting.

Although test the nuts out of your AOI before rolling it out. Yes the beauty of an AOI is you mod it in one place and all the others are instantaneously done BUT to modify it once implemented requires a download. Depending on what site it is will limit how often/when you can modify these blocks via a download.

After a rather bad experience, i now put code in an AOI that will not change & anything that may need altering frequently i either write out the code or code the AOI so it can be altered from outside the block.

Ash

 

[JeremyM]

I've written dozens of AOIs for unit conversions, scaling, environment calculations, and so on. They're encapsulated, faster than subroutines, and easily migrated to other projects. I stop short of writing AOIs that are process-specific because they cannot be changed while online.

Sub-routines offer the obvious benefit of functional decomposition of more complex processes, while still being modifiable.

I can't stand seeing spaghetti code, much less ladder spaghetti because the integrator thought that the *** very same process variable *** could only be scaled, tested for alarming, and feed a PID in separate subroutines under multiple aliases, named in unrelated fashion. For some reason, they also tucked the PID instruction inside their own PID AOI, while passing the very same parameters that would have ended up on the rung itself!

 

[daba]

I hate coming to code and finding SBRs being called to operate equipment (arrrrgh)!! Its hard to trouble shoot,

Why are you troubleshooting in the PLC code if the equipment is handled by subroutines.. ?

I am assuming subroutines have been used because there are multiple identical pieces of equipment, so my thought process is "if only one piece of equipment is having troubles, it can't be the code, it has to be the equipment".

When using any method of "iteration" for multiple field devices, whether that be Subroutines or AOIs, you absolutely do not need to look at the PLC code if one device is failing.

Of course, from a troubleshooting perspective, it would be most usefull if an appropriate alarm is generated for the device in question.... loads of possibilities, here's a (possibly incomplete) list of faults you could generate for an auto-valve

"Valve failed to Open in the allotted time"
"Valve failed to Close in the allotted time"
"Valve Open and Closed feedbacks on together"
"Valve slow to open"
"Valve slow to close"
"Valve "Open" feedback lost while driven open"
"Valve "Closed" feedback lost while not driven open"

etc.