Sign in to follow this  
Followers 0
dave

LOGIX5000 JSR / SBR / RET

6 posts in this topic

I'm using Logix5000 v17 with a Compactlogix L32 controller. I want to use a single subroutine with input and return parameters to control a set of 22 identical devices. I understand the principles involved and have created my routine, created a set of local program variables for it and plan to call it repeatedly from my main program using JSR, each time with a different set of controller tags. The subroutine has roughly 18 input tags and 18 output tags of various data types. My question is about input and return parameters and the SBR/RET instructions in the subroutine: Where I have a simple input (for example, a motor overload contact) that is clearly an input parameter and goes in the SBR box. Where I have a simple output device (for example, a solenoid valve) that is clearly an output parameter and goes in the RET box. But, where I have an intermediate math result, or a temporary coil which is latched using a maintaining contact, does that need to go in both SBR and RET lists? Since the subroutine needs to know the last state it left them in, I assume they must be present as input parameters as well as return parameters. In Siemens, there are IN, OUT and IN_OUT parameters for blocks ... here there is only INPUT and RETURN. I have no controller handy nor simulator to test the program at this time. When I enter the same coil bit address in the subroutine's SBR and RET boxes and then do a verify, it flags up a duplicate destructive bit warning. I haven't been able to find a manual or app. note which adequately explains this operation so am hoping one of you resident gurus will be able to fill me in off the top of your head. Thanks in advance for any guidance!

Share this post


Link to post
Share on other sites
well, if I understand your basic question (and I think that I do) then the answer is "yes, you can use a single bit as BOTH an INPUT and as a RETURN parameter for a subroutine call" ... the experimental program shown below demonstrates that the technique can indeed work ... but ... the bigger question becomes "SHOULD you do this?" ... personally I'd answer that one with an emphatic "NO" ... have you given any thought as to how difficult (not to say "impossible") it will be to troubleshoot any particular one of your "22 identical devices" if you write the program to control them this way? ... pity the poor technician (or even you yourself) when trying to figure out why Device X won't operate correctly – when the bits for all of the OTHER devices are constantly and rapidly being flickered on and off as they pass through the logic of your subroutine ... troubleshooting something like this is a nightmare (been there – done that) ... regarding your statement: have you taken a look at the Add-On Instructions avaiable in RSLogix-5000? ... I think that approach might be more along the lines of what you're looking for ... User-Defined Data Types would probably also come in handy ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
What I do in that situation is create a UDT with the store data for each subroutine call Add an input Parameter to the SBR which is used as an index into an array for the call (the array is 22 elements long - one for each call) First Rung COP the array element to local data , last rung COP the local data back into the array

Share this post


Link to post
Share on other sites
Yuck Give me 22 unconditional ladder files every single time. Heck, give me one ladder file with 22 sections (I will even add the page titles). It will be superior in every single aspect. You could have been done writing the program in the time spent researching passing parameters. The execution time will be faster. Bubba will even know what is going on in the middle of the night when he blows up the last good spare output card and has to move one point to a spare at 3 am. What if 18 months from now, I must replace one or more of those devices with one whose behavior needs to be slightly different? Sometimes, we are given way too much tool for the job. Conditional routines or indirect addressing in control of world outputs is a bad idea >99% of the time. This is just my opinion, perhaps your application is one of the <1% that justifies this. Edited by OkiePC

Share this post


Link to post
Share on other sites
Yuck raised to the Yuck Power is more like it. I have a line where the programmers wrote 1 routine to control 30 identical devices and did the subr stuff. AVOID IT IF YOU CAN. Your techs and troubleshooters will love you. I finally at 3am one morning wrote a 31st routine which is never scanned but with setting a couple of variables can show me the state of a single device. If you must use the subroutine approach, please consider writing the Debug breakout system I describe. Maybe you'll save yourself a few hairs.

Share this post


Link to post
Share on other sites
Many thanks to all who answered my plea for advice here. After careful consideration, I decided to go with the majority and just write 22 separate routines. For monitoring/debgging alone it is clearly simpler and the spadework only needs to be done once after all. I spend a lot of time on Siemens Step7 where the prevalence of functions blocks and instance data blocks makes for a more elegant solution, but even then some of the above criticisms apply. Fair enough and thanks again to all.
1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0