Sign in to follow this  
Followers 0
Navyguy

RSLogix Lite - Sub-Routines

6 posts in this topic

Good Day All

It has been a while since I have done any serious programming with PLCs; having said that I feel pretty comfortable with the older AB series of PLC.  I am currently working with some apprentices and I have given them the task of programming the classic “Alternating Pump” scenario.  I think we all know the scenario…

The premise is Pump A is activated and will run for a max 15 minutes or until max pressure / level reached.  Pump B is activated on the next call for low pressure / level or when Pump A runs for 15 minutes; Pump B will run for 15 minutes max.

Pump A will then be recalled and run until level / pressure reached or will continue to run for 15 minutes; Pump A continues to run and Pump B will start (after a total of 45 minutes single run time) until pressure / level reached.  Note that this could be the opposite order based on what pump was called first in the alternating cycle.

If there is a call from the "extra low" level / pressure at any point, then both pumps run until the level / pressure is reached and then the alternating cycle is returned to normal.

The alternating pump, and timers, the calls and recalls, etc is all pretty straight forward from my perspective.  Where I am struggling with is a I want to add conditional sub-routines to this to teach the apprentices how to keep the program(s) organized and ultimately to learn in larger programs to reduce scan time and memory resources.  I acknowledge that this small program; it is unlikely it would be necessary to use sub-routines, but I am interested in teaching the good programming principles.

What I have tried to do is create several sub-routines essentially calling them Pump_1, Pump_2, Pump 1_2.  The issue I am having is I cannot get the pump to turn off in the sub-routine when the program exits early (reaches maintain level before timer expires as an example, or where it is switched from Auto to Hand) the OTE remains true.  I am able to use move bits to reset the .acc bits on the timers and counters and I have use B3 bits to keep the “real world” OTE in the main program, but obviously I am missing something here very simple.

I have not taught the apprentices the One-Shot instruction, but I am not sure if this is where I need to go, and I am not a proponent of the OTL, OTU instructions (perhaps I should be?).

I understand that the instructions in the JSR will stay in their last state upon exiting, but I, for some reason, can’t figure out how to change the condition of the OTE (either real world of B3) in the sub-routine before exiting.  I have done a fair amount of research and am wondering if it is an issue with the AB RSlogix Lite that I am using with the apprentices.

I appreciate you taking the time to read my very long first post and offering any suggestions.

Cheers

John

Share this post


Link to post
Share on other sites

I would move the pump control OTE instructions to the main routine or a subroutine that's unconditionally run. Each other subroutine would have an "output bit" that turns on when it wants the pump to run. The "output bits" would then be paralleled to control the pump's main OTE. Put a conditional branch for each subroutine's "output bit" so that IF Subroutine1 is active AND Subroutine1's "output bit" is on, THEN run the pump. Repeat for the other subroutines.

Edited to add:

You need to make sure that the subroutine runs at least one scan before allowing it to control the pump, otherwise the pump's OTE could be on for a scan, which would cause problems. For all those reasons, I tend to NOT use conditional subroutines except in very rare situations and generally for functions that can complete in one scan of the subroutine. In my experience, conditional subroutines are an effective way to get 2AM phone calls...

Edited by Joe E.

Share this post


Link to post
Share on other sites

Hi Joe E.

Thanks for your response.

I have read a lot regarding opinions on conditional / unconditional sub-routines.  Perhaps it is my inexperience, but I do find it interesting that there is a trend to put in unconditional sub-routines just for the purposes of organizing the code (which I agree it can be easier to look at things); but if the sub-routines run all the time or every time, there is no savings on PLC resources, which to me is the fundamental reason for having sub-routines in the first place.

I am going to try to use some unconditional sub-routines to get this going, but it does seem illogical to call for sub-routines that are not required in the overall scope of things.

Can you confirm that this is a limitation of the software?

Cheers

John

Share this post


Link to post
Share on other sites

Skipping a subroutine for basic pump control would save milliseconds or microseconds on program scan time. If this much scan time matters for a MicroLogix project, you’re using the wrong platform. Program organization is a fundamental reason for subroutines.

There are situations where conditional routines are the logical choice. An example that comes to mind is call a subroutine at completion of a message to process data received in that message. A subroutine can also be called from a timed interrupt or a condition interrupt. A registration sensor on a packaging machine could trigger a subroutine for tracking position. I have used a subroutine triggered by PLC fault to move data to HMI registers for diagnostic information on why the PLC was crashing.

I understand wanting to not execute useless code but I wouldn’t recommend it for normal operating. I recall only one time skipping a subroutine because it didn’t matter. When a HMI recipe select screen was opened, I ONS JSR'd to a subroutine that repopulated 48 recipe name strings. I did hate to execute that every scan because only the previously selected one might have changed. That’s just populating strings. I wouldn’t do it for output controls.

Edited by 5618

Share this post


Link to post
Share on other sites

If you've ever had to scroll through a few hundred rungs of code to find what you're looking for, you'll understand the value of subroutines for organization. We have 3 production lines that bond steel and aluminum strip. The first two are well-divided into subroutines that are meaningfully named according to specific pieces of equipment on the line. The 3rd is subdivided but not as much or as well. Most of the code is in LAD 2 (it's a PLC-5). It's really a pain to find what you're looking for, especially if you don't know ahead of time how the programmer commented things so you can search for it. I've been here long enough that I know a few search terms to use to find what I'm looking for, but someone who hasn't seen the machine before will be in for a tough time.

On our bonding lines, there is code that tracks defects in the strip that was written by a contractor. He used a LOT of conditional subroutines and nested loops. When it works, it works, but occasionally it glitches and freezes up. Because of the conditional subroutines and nested loops, it's been impossible to find the problem. I once spent 2 days straight mapping out the subroutine calls and loops, trying to at least figure out the program flow, but still couldn't isolate the problem. If you value your time, and the time of the people who are on-call after hours, sacrifice the "ideal" efficiency of the code to make it easier to troubleshoot. Those few milliseconds you save don't really matter when the line goes down and it's not making product while your technicians are trying to figure it out. Write code defensively, to avoid 2AM phone calls when something weird happens and the technician sees the spaghetti logic and gets stuck. Even if the spaghetti logic is completely unrelated to the problem, your phone will still be ringing.

Share this post


Link to post
Share on other sites

Thanks Guys, appreciate your responses.

I acknowledge that on this small program, the scan time issue is not relevant (think I mentioned that initially).  Again looking at "best practices" and code organization and thought this would be a simple one for the apprentices.  I will just focus on a different scenario, perhaps a Pack, Clean, Maintain that has three distinct functions that can be conditional with a selector switch or something.

Cheers

John

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