Sign in to follow this  
Followers 0
Shiner

subroutines

8 posts in this topic

If you use subroutines, say one is for automatic mode, and one is for manual mode, using a JSR to access each that is exclusive to each, I am curious about a few things. If each mode needs to energize the same contact, if I am scanning the auto mode and trying to turn on O:0.0/1, and it is also in the manual program will that be a conflict or because I am not jumping to it should it not be scanned. Or would I need to turn on separate B3s with the statments and AND them in a scanning ladder to the output in question. Or is there another way that I am unaware of. Micrologix 1400 serA

Share this post


Link to post
Share on other sites
You can use duplicate OTE instructions in separate subroutines, just remember the rule that the last one scanned wins. Since only one sub is going to be scanned, then you can get away with this. Problems can arise when you switch modes. Suppose you are running along in auto and you have 6 outputs energized to run motors. Then you suddenly switch to manual mode and stop scanning the auto subroutine. In your manual subroutine, suppose you have those same outputs but you are using the output addresses to seal around momentary pushbuttons. Since the output addresses already contain "1"s, those rungs will be true and stay sealed in. If you choose to use this method, you will have to be extra careful how you deal with the transition between modes. I prefer not to have real world outputs in conditional subroutines at all. I have had to deal with programs written that way and I have not seen any advantage to this. I suppose if you were hurting for scan time and/or memory in a complex system, then it could be beneficial, but it's not the best practice in my opinion. Edited by OkiePC

Share this post


Link to post
Share on other sites
i can see how that would happen, would it then be beneficial to have simple truth statements like I had said in a scanning routine, with anded B3 contacts that are exclusive to each subroutine being the statement in that routine, and the truths that trigger the B3s in each subroutine would then not interfere as you have described

Share this post


Link to post
Share on other sites
It's not necessary but it is absolutely maddening to try to troubleshoot them, because you have to watch the program state and whatever you want to look at simultaneously.

Share this post


Link to post
Share on other sites
I agree with Paul! It's given that a program should function, but ease of troubleshooting is just as important. I've inherited several machines that have very unorthidox programming that drives me crazy. If the machine stops running it usually takes me 15-30 minutes just to find the logic that might be the problem. And trying to find out which logic is running and which coil is controlling the physical output is another mind bending task. Placing all system outputs in a continously scanned subroutine with one branch of logic for automode and a branch for not automode (manual) is a simple way to avoid this problem. Any other technique is fine as long as it is easy to understand and consistent throughout the program. Just my $.02 opinion. Edited by noxcuses

Share this post


Link to post
Share on other sites
I would like to hear more opinions on this, it seems there are many ways to skin this cat, and there has been no established methodology when it comes to programming. Each teacher has his or her way, and each programmer the same, and they may or may not be similar, but while this is not a new science, there still seems to be a great debate on many of the ways to "properly' do things.

Share this post


Link to post
Share on other sites
Shiner, Personally I never have a real world output in the entire program file more than one time. (never/ever) Personally I hate it when I have to try & troubleshoot another persons program that uses conditional JSR instructions. It can become very confusing to say the least. My opinion is that the additional subroutines are helpful to organize the various tasks into logical groups. For example; Routine 2=Main, Routine 3=analog input scaling,Routine 4=discrete input timers, Routine 5=HMI, and so on. Yes, the use of conditional routines can shave a few mili-seconds of scan time. If you are worried about scan time, you are using the wrong processor for the job. I'm sure we have all tried to get Corvette performance from a Malibu before. The "Atta Boy" for saving $500 on the cheaper hardware you may get from the boss will be long forgotten while the maintenance staff are still cussing & throwing tools & swearing they will never ever get another of these blasted machines! I prefer to have all subroutines scanned all the time, except for special cases. If I need to control a sol coil (or motor coil) in manual mode as well as auto, I use a parallel rung branch with auto on top & manual on bottom, output on the right. See simple example below. While at first glance the rung looks complicated, once you get used to the flow it is easier than looking for a binary bit that is in a far away place. Of course binary (B3) bits are necessary in a lot of cases. Best practice is to keep them close by the output when possible, not in a conditional subroutine for sure. That is my $0.02

Share this post


Link to post
Share on other sites
Couldn't have phrased it better myself.

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