Newbie question about "properly" writing a ladder

[JZerb 2]

So, i have been reading some downloadable PDF's, online literature, and watching plenty of YouTube videos to try and teach myself RSLogix 500 in the recent months.  I was finally able to take a stab at programming something at work this week, and it actually all worked in the end!  But i have a few questions regardless, because in my eyes just because something works doesn't always mean i did it properly; or more or less if i did it the 'safe, proper' way.  Hopefully i can get some answers to my questions here.  

Firstly.  If you have a rung in say SBR4 that sets a Latched bit on an Output, and that Latched bit is needed for something to happen earlier on in the program, in say SBR2; is that ok?  I know the PLC is constantly scanning through the ladder and very quickly, so i assume its going fast enough for it to not matter but i just want to be sure.  

Secondly.  Screenshot of the section of ladder that i have a question about is attached.  Ill explain what has to happen as best i can.  hold a mom pushbutton (forward SS) and  lift goes up, it hits a NC prox switch (PRS422) and then at that point the LIFT_FWD function temporarily gets knocked out until the invert motor inverts a drum, at which point the drum is either inverted or upright in order for the lift to continue on its path.  as i said, the way i have it written works, but i just want to make sure thats the way it should be done.  i assume that different people do things different ways, but i would like to know if im on the right path to properly learning and executing this, or if i should be doing it a different way.  thank you

 

Edited 20 Sep 2016 by JZerb

[panic mode 246]

about first: that is ok

about second: i see LIFT_FWD but not LIFT_REV so cant help much but... are you aware of difference between OTE and OTL/OTU on powerup? you can use OTE to seal-in output and behave 'like' latch but it is not exactly the same, on powerup any OTE is reset while OTL/OTU are left in the last state. just make sure that your logic works for all scenarios as intended - even if there is a power loss. 

[kaiser_will 65]

You do have a latching bit, B3:1/0, that has an output O:0/2, with both being a function of each other.  Having 2 elements a function of each other can make for a chasing-your-tail situation.

I also prefer to use one shots with latching/unlatching bits.  From the code example, this is a SLC or Micro, I assume.  One-shots will afford you better code debugging ability, in my opinion.  Most of us have had to debug bouncing logic, and one-shots will make your life easier, in my opinion.

Lastly, rung descriptions.  I encourage everyone to document their code to help the next guy that comes along.

Edited 19 Sep 2016 by kaiser_will

[Michael Lloyd 85]

Quote

I also prefer to use one shots with latching/unlatching bits. 

Second this. If the trigger contact is a button I generally have a one shot between it and the latch. Mosts of the time you don't want to run the risk of an operator sticking a sharpened matchstick or whatever in the button to hold it on all the time. With a one shot, they can do that, but one shot prevents the latch from being held on. I've seen quarters, sticks, you name it, used like this. 

When you write a program you have to write it with the understanding that an operator will often "test" things. I wrote a high pressure tube trailer loading program a number of years ago. Basically it controlled the loading of ethane into high pressure tubes and used a scale to control how much was loaded in each tube. There were 5 buttons on the panel. Four were intentionally spaced so that they couldn't be pushed at the same time. The panel shop did that. I didn't ask for it. They had prior experience. The project went online and worked fine. A few months afterward the operator called- "Hey man, we need you to come fix the program. It doesn't work right. When we push all of the buttons at the same time it does weird stuff"  

After a pause I asked- how in the he** are you pushing all 5 buttons at the same time????

"It was hard, I had to get the other operator to come help me".

Why did you do that??? 

"We wanted to see what it would do"

So I ended up writing code so if they did that nothing would happen AND the screen would pop up- DON'T DO THAT!!

True story

Edited 19 Sep 2016 by Michael Lloyd

[Armadillo852 25]

5 hours ago, Michael Lloyd said:

When you write a program you have to write it with the understanding that an operator will often "test" things. I wrote a high pressure tube trailer loading program a number of years ago. Basically it controlled the loading of ethane into high pressure tubes and used a scale to control how much was loaded in each tube. There were 5 buttons on the panel. Four were intentionally spaced so that they couldn't be pushed at the same time. The panel shop did that. I didn't ask for it. They had prior experience. The project went online and worked fine. A few months afterward the operator called- "Hey man, we need you to come fix the program. It doesn't work right. When we push all of the buttons at the same time it does weird stuff"  

After a pause I asked- how in the he** are you pushing all 5 buttons at the same time????

"It was hard, I had to get the other operator to come help me".

Why did you do that??? 

"We wanted to see what it would do"

So I ended up writing code so if they did that nothing would happen AND the screen would pop up- DON'T DO THAT!!

True story

 

I am glad you wrote this. I am a Senior Field Service Technician, former Controls Engineer, but didn't like the whole desk thing. I tell my Controls Engineer this all the time. What if.... The standard answer I get is why would they do that. To which I respond, the better question is why we allowed them to do it!!!!

People are people, and will do if we let them. If you think I'm wrong, add a counter and a button on the HMI that says "Do Not Touch." See how many times a day it gets pressed. Then you will see why you have to protect so many things.

[kaiser_will 65]

Forgive me for the crudeness, but it comes in handy.  "Do you know why a Dog licks his balls?"  Because he can.

Always design so that operators can't.  Always.

[JZerb 2]

On 9/19/2016 at 1:06 AM, panic mode said:

about first: that is ok

about second: i see LIFT_FWD but not LIFT_REV so cant help much but... are you aware of difference between OTE and OTL/OTU on powerup? you can use OTE to seal-in output and behave 'like' latch but it is not exactly the same, on powerup any OTE is reset while OTL/OTU are left in the last state. just make sure that your logic works for all scenarios as intended - even if there is a power loss. 

i added the REV section of the ladder above.  Thank you all in here that have given advice.  its much appreciated.  

 

and yes, i have seen in our systems where they are programmed if say someone hits the Estop button a certain number of times...the machine will cease to work until a phone call is made.  im trying to learn and program the best i can for any and all situations that an operator may "put" a machine into.  

[JZerb 2]

so.  two more things to make sure i understand properly here.  i modified the _REV_  ladders that i had written so that its just one rung now to set the output for LIFT_REV.  I assume thats the way to do things(?), as you can see in the first picture the LIFT_REV output could be set at the end of either of those rungs, so i figured to make it less confusing i wrote it so that there was only one rung to follow in order to see how the LIFT_REV OTE was set.  

Secondly.  The Slue Brake section of the program i have screen shotted here as well.  I know things get read from top to bottom in the program, so im assuming it is ok to have that XIO bit B3:3/0 being turned on and off by an OTE thats in the rung below it?  is there a better way to do it if this isnt it?  

[pop29684 14]

Your idea to combine the logic of rungs 9 and 10 is a good idea but not just for the reason you stated (clarity). As written in the first screen shot (separate rungs controlling the same output), the conditional control of rung 10 (second rung) will always overwrite the conditional control of  the previous rung 9 (first rung). Imagine that the conditions of rung 9 are true. The result is that the output of rung 9 will be turned "ON". Now imagine that the conditions of rung 10 are false. The result is that the output of rung 10 (same output just turned "ON" by rung 9) is immediately turned "OFF". The final state of the output will be "OFF" because that was the last operation performed on the output. This behavior is normal and must always be taken into account when using OTE instructions.

Look carefully at the combined logic in the single rung - rung 10. You have taken two parallel ("OR") conditions and created a series ("AND") condition. Do you see it? The only difference between the rungs in the first screen shot is the N.C. condition of B3:1/1 ("AT_INVERT_HEIGHT_REV") or the two conditions of either N.O. I:0/13 ("LOW_LIMIT_INVERTED") or N.C. I:0/16 ("LOAD_POSITION"). To preserve the original conditions you must move both of the two conditions [either N.O. I:0/13 ("LOW_LIMIT_INVERTED") or N.C. I:0/16 ("LOAD_POSITION")] in parallel with the condition of B3:1/1 ("AT_INVERT_HEIGHT_REV").

Finally, you should be okay using the N.C. contact B3:3/0 ahead of the OTE control of B3:3/0. This does not normally cause any issues.

[JZerb 2]

when i combined the two rungs from the first picture i also changed how the program was going to function a bit, which is why they dont match exactly as you pointed out.  its functioning as it should as of now so hopefully i will be good.  thanks for the insight! the more i learn the better here, i just want to make sure im writing things properly in the end like i said; not JUST getting them to function 

[Richviper44 0]

Just another tip......

I have always learned NOT to have a physical input drive a output but drive a internal bit and Proxies / switches should always be debounced with a timer as these can cause grief and strange acting logic which is also very difficult to troubleshoot.

 

[JZerb 2]

On 9/23/2016 at 9:39 AM, Richviper44 said:

Just another tip......

I have always learned NOT to have a physical input drive a output but drive a internal bit and Proxies / switches should always be debounced with a timer as these can cause grief and strange acting logic which is also very difficult to troubleshoot.

 

It's funny you say that because as I was writing this I was looking at other ladders that have been written by experienced programmers for my company in the past and it seemed as if it was done  it the way you described. I just wasn't sure if there was a rhyme or reason for doing it one way or another. 

[panic mode 246]

it is fine to have guidelines, it is harder to have rules that apply to all cases, as usual, the best case is probably some middle-ground where developer decides what is suitable for the job. for example:

- all input cards already have some sort of conditioning (hardware and/or software).

- timers are scarce resources on some plcs. 

[Richviper44 0]

18 hours ago, JZerb said:

It's funny you say that because as I was writing this I was looking at other ladders that have been written by experienced programmers for my company in the past and it seemed as if it was done  it the way you described. I just wasn't sure if there was a rhyme or reason for doing it one way or another. 

In the early days of programming yes its true memory was scarce and so were timers in memory.  Now that is not really the case.

I was taught to write PLC code by many high level programmers and they always wrote code as if it were in very specific steps and one step was not allowed to affect a previous step as this could cause dangerous actions.  A good example was on a press that I had to service once.....   A 4000lb ram would move via a hydraulic valve and was programmed to stop when it hit a prox.  If the prox flickered or the ram drifted out of position the ram would continue moving.  I was taught every machine and its motions were a sequence.  So in a step of this sequence is the prox is on.... Next step de-activate the valve.  Since the first step was completed it cannot happen again compared to the same prox driving the valve in the same rung would or could re-initiate the valve output.......

 

[JZerb 2]

dragging this one up from a few months ago, laid out two sample ladders and was curious as to which way was the more 'proper' way to get it done.  

in the make believe scenario the machine is picking something up and flipping it over and then continuing to lift the piece that it has flipped over up into the air.  should i write the ladder so that the OTE for the Machine Forward is just triggered by either of the OTE B3 bits that you see on the first two rungs?  or should the OTE for Machine Forward be triggered by something like a NEQ function that would be looking at the entire B3:0 word, and this i could just continue to write rungs that were for different machine conditions that could be met but would all still allow the end result of the motor running and thus the machine going forward.   

 

[kcox1980 2]

You're off to a good start to learning PLC's. The fact that you're even a little concerned about doing things the right way and seeking help from outside sources puts you way ahead of the curve.