Subroutines and latching

[mrowen]

I'm married, so by default, I take critisism EXTREMELY well. LOL.
Thanks you very much for your (and everyone's) time.

Okay, I'll follow your lettering here and try to defend/embarass myself.

1:
Okay, enough said, The B's have it.

2:
R6:3/EN is actually for the purpose of the final unfinished routine which is now finished. Since I am using an 1000 model with RS500, I can not use a one shot falling to detect switch going off. The last rung of my main was my way around this. In the finished shutdown subroutine, when all conditions are met, the last thing I do is Unlatch R6:3/EN from within the subroutine.

3:
I actually have stripped and changed all anotations for the purpose of posting. My copy is over documented.

4:
A:
The start up timer is set by two conditions. It will help to realize that something is actually happening with certain outputs are off. Like 3 way valves. In this case, "switch-1" (actually a sensor and not to be confused with the main ON switch) is already on going into this routine. Once it turns off, the timer is set to continue doing what it is doing for another 1.5 secs. Then start up is complete and the routine is ended. Now I thought that was all good. Now it is after midnight, I have rewired the unit and now I see exactly what you are saying. My startup mode only works once. Will have to fix that.
B:
Yes, this is a highly desirable effect. However, I do need to address fault issues such as this switch not being made in a reasonable amount of time. Several little safetys have to be added.

Subroutine 7, Ouch, I swear it really works!!! With the exception of failing to udate on the first scan, and Rung 1 haveing no value, it actually works ok. I think rung 1 is just the remnants of me trying to create a simple loop in the code. Just didn't realize I completely skirted it. I am still struggling with this scan then update thing. I just don't completely get it. Now with timers and loops, well, makes me want to open a beer. Will look closely at this.


Rung 2, again it helps to remember that outputs in the off state are doing things.

File 8, It was not complete. I have since made it complete. Well it works anyway. I had a problem with the one shot. You are not allowed to parrallel the one shots coil to someother condition. I ended up just using it to get things going. Really didn't like that approach.

Again, thank you very much for this help. As for taking time to master, doesn't everything. I strongly committed to demoing this thing sometime next week. Looks like its gonna be a long weekend.


RSDORAN:

Just saw your post. I guess the main reason I have tried to do this with routines is simply so I can follow it. Basically, you've got a start squence thats kinda like Half of a full loop. Then you have a run sequence that is the full loop. Then you have a shut down sequence that again is half cycling several times in a flip flop mode, until conditions are met. For me, trying to put all that into one ladder on lad2 would honestly be near impossible. I still get hung up on simple loops.

But in the spirit of trying to do this right, and learn how to handle larger programs, I'm gonna try to get it all on the main.

 

[rsdoran]

Personally I think you are looking at this wrong. As shown now you have 2 outputs to work with that either half loop or loop using your terms. I assume loop means runs continuous and half loop means something like cycles once or just cycle thru a part of the complete cycle.

I think you are making this harder for you. Simple fact, 2 outputs with 3 inputs to create conditions. I still believe you could follow the basic guidelines and create this program in one LAD file with just a few rungs being used. Its common for there to be 2 or more ways for a machine to be operated...ie manual mode, jog mode, automatic with variances in any of those depending on the machine.

Maybe if you took a look at Terry and Allen's start guide to programming:http://www.patchn.com/b4programming.htm This may help in some way.

You may have more experience programming than I do because of your backround in Fortran/Pascal but I think you may have gotten some misconceptions on plcs in general and the way the scan works.

Using Terry's idea of BE THE COMPUTER, step back and look at it again. Dont concern yourself with scan time at this point, you dont have anything showing that would be scan intensive. Start basic and develop from there, it may be less complicated than you think.

 

[msinclair]

mrowen:

I don't have much to add - Allen covered it very thoroughly.

I think that is pretty much what I got except for actually placing the outputs in the main. Seems to complicate it. Now I would have a maze of Subroutine contacts leading to each output. Then if I wanted to see what was wrong with the output, I'd have to follow this maze on the main, and then go into a sub. Still not clear on why I would want to do this.

To some degree you are right - the code is potentially longer if you do it this way. Where it gives you a huge advantage is in troubleshooting. In your case, if everyone is trained to KNOW that the three routines are guaranteed to be mutually exclusive (see Allen's comments), then it isn't too bad. If someone (consultant / future programmer / etc) were to walk into your plant without that knowledge, and wanted to find out "Why is this output really on?", they would have a bear of a time figuring out which (of three rungs) actually was controlling the real-world output. (At least until they figured out the subroutine structure / sequence).

Now as Ron said - your code is not very extensive, so it probably is not the end of the world here, but if this is being expanded (or used as a template for other programs), the debug / commissioning savings will likely be worth the more ordered structure.

Marc

 

[msinclair]

But in the spirit of trying to do this right, and learn how to handle larger programs, I'm gonna try to get it all on the main.

I just noticed this comment. Putting everything in the Main ladder is often not the best way to handle larger programs. Breaking it down into either sequences and/or machine parts can make the code much more readable.

What I think Ron was suggesting was that your code was not very extensive, and would be a candidate to run in one Ladder routine (Main) because of this .

What I was suggesting was that the double coils could be eliminated if the "double-coiled" outputs were placed in Main (or in their own ladder routine, or . . .) There are lots of ways to do this - you just have to pick one that makes sense.

Marc

 

[mrowen]

I hate to say it, but I'm having a lot of fun.

Okay, trying now to write one file. Mostly because, three days ago, I wouldn't have stood a chance. Now armed with enough info to hurt myself, I gonna try. This is the fetal position of the code. There are several additions and routines/modes that need to be added.

So my current attempt is basically to have these outputs on the main. Each output will be fed by 3 parallel branches. Each branch being enabled by Mode. Mode will be determined at the top based on Primary ON/OFF switch transition and state.

I know that I'm still thinking the same way. I want isolation, I need isolation or my little brain will simply melt down.

I am hoping that once I get it going, I will be able to see lots of unneeded redunancy and perhaps begin to break it down.

One thing I never liked was a program that was a reduced prime truth table. No doubt the fastest running program (that mattered alot in my past programing experience) but it is nearly impossible to understand the logic without having the full table and understanding the reduced version. Does that make any sense.

Okay, back to the fun.