Duplicate Destructive Outputs in Allen Bradley Micro800 PLC? Last Rung Wins = FALSE

[@TimWilborne]

Thanks for watching! If you are looking for the complete Connected Components Workbench PLC Training series, visit twcontrols.com/micro800-connected-components-workbench-lessons

[@eischristchurch485]

I just have started learning PLCs and automation and glad that I found your videos. Happy to say your are my very first PLC tutor. Keep doing great work I am following all your videos. Good luck from New Zealand

[@TimWilborne]

Thank you!

[@dwightbelyeu577]

I've been programming plc's for twelve years and i missed that! I knew that when I slipped up and used the same output in two places sometimes it would flicker but I didn't know why.

[@TimWilborne]

It happens, here is a recent video I did and I didn't catch it until I was editing! kzbin.info/www/bejne/qqqknaqQa6iFj5o

[@aldozixicivi3740]

I agree with you only to some extent. It depends on the brand. Some vendors say that the last rung win (automation direci is one of this brand).In any case, your is a very good demostration.

[@TimWilborne]

Automation Direct says it, but this exercise works in them as well. It is a test question in one major brand's certification. It doesn't make it true either :)

[@kevinziegler3963]

Last rung wins = TRUE. In the example you provided, every iteration where the green light was on, rung 2 wrote a 1/true/"checked" value to the green light variable. Every iteration where the green light was off rung 2 wrote a 0/false/"unchecked" value to the green light variable. Since rung 2 is the last rung to change the value of the green light variable, the plc sends this value to the output. This can be further confirmed by reversing the two rungs of code. Now switch 1 controls the final value of the green light variable. The green and red buttons have no control over the final value of the green light variable. The big take away for me is you have to consider all preceding rungs of code that can change the value of any item on the rung of code you are evaluating. Only then can you determine the final value of that rung.

[@TimWilborne]

I haven't watched this video in a while but isn't that what I said 😕⁉️

[@kevinziegler3963]

I found your final statement that the PLC wins to be confusing. It's probably just me but after showing that the last rung does win your final statement contradicts it. I feel this is a very important topic and want to thank you for taking the time to make this and your other videos. If you feel this is misleading or you don't agree with it, then please remove my comments.

[@TimWilborne]

@@kevinziegler3963 I'd never delete a good constructive conversation! I think you have to understand the context of this video. There are programmers that believe that if there is a second OTE of the same address, then the second one will overwrite anything that the first one does since "outputs" aren't updated until the end of the scan. So when I switched switch 1 in rung 0 on, you saw that the light came on. They will insist that the only thing that can turn the light on is the green button until they go through this exercise.

[@Lil2012angle]

Thank you Tim for talking about this subject, I know it has been a couple of years since anyone talked about this subject. With your example I can understand it completely, I have a code to open and close a garage door, when open or close the door the green light should turn on but the green light turn on just on the second rung which is the last rung that uses the same output, I’m still confused about it and need to think how to improve the code so this condition will not happen, I truly believe it depends solely on the programmer logic. You are very helpful with the videos you have posted thank you.

[@LogixWorkshops]

Love it, I follow the rule of one myself. Nice little fight subject for sure..

[@TimWilborne]

Thanks for watching!

[@MrJohnd1221]

This is very good, however its kinda deceptive that it is allowed in the program in the first place. Would this also be the same for function block and structed text as well?

[@TimWilborne]

Absolutely John, you can replicate this in Function Blocks and Structured Text of CCW. This is much more common than you initially think. I like doing it with outputs because it gives you that surprising indication of a light turning on, but think about an integer or a real value. It isn't uncommon to have multiple MOV instructions with the same destination. In those situations you must understand program flow as well to determine which one "wins".

[@GuyFromJupiter]

It's really not deceptive at all that it's allowed. I can't imagine a reason you would want to do it with OTEs for physical outputs, but I could imagine doing it for internal bits for some reason. I've done something similar with MOV and COP functions before to make a converted PLC 5 program work with Control Logix. The reason for doing this is a bit complicated, but essentially I had to copy data from an INT array into a DINT array for an FBC function to work, then move the result into another INT. Instead of creating unique tags for each instance of having to do this I just used 1 array of DINTs to copy data into repeatedly throughout the program, which made my life easier and doesn't waste memory (not really a big issue on Control Logix, but still good practice). In retrospect it probably would have been easier for me if I had just created an AOI to do it all with one instruction, but what I did certainly worked. You really have to understand how a program flows when you want to modify a tag's value multiple times throughout a program, but there are certainly valid reasons to do it.

[@rixpanapasa8977]

ahhhhhhh now i get it lol...nice explanation tim. just a suggestion tim can your mouse pointer be seen so we can see what you selecting or pointing at? thanks again tim.

[@TimWilborne]

Yes I forgot to check it in this video. Sorry about that.

[@usoroekwereessiet4397]

I encountered similar problem yesterday when I was practicing something on RSlogix 5000. In my own case the last rung won. I was surprised because I wasn't familiar with the concept of duplicate destructive outputs. So when I saw this video I had to take out a moment to watch it. But I'm surprised both rungs turned on the output in your own case. I don't know if it is software dependent stuff as you are using Connected component workbench (just saying).

[@TimWilborne]

I have a video coming on your problem. It has to do with the difference between synchronous scan and asynchronous scan.

[@usoroekwereessiet4397]

@@TimWilborne I look forward to it Tim. Thanks.

[@dhh488]

I gotta get the fundamentals down. This is a good lesson for that, so thanks Tim.

[@TimWilborne]

You are welcome!

[@tektonelec4695]

Great video Tim!! Although using an ote more than once can be predictably figured out with an understanding of how a pic operates would you say it’s a good rule of thumb not to use an ote as an ote more than once in a program??? Your example was great to follow for an understanding of this but I would think using an ote more than once in a larger program can become complicated especially if you have to troubleshoot it.

[@TimWilborne]

Yes, I would say that is a good rule of thumb.

[@GuyFromJupiter]

Yeah, if you run into a situation where you need to use an OTE on the same bit multiple times it would probably be better to use OTL and OTU functions instead. Just be careful if you do that though, because if you aren't careful or don't understand exactly how a program flows then it can cause a real headache when you have to troubleshoot it.

[@MyTato2010]

is the CCW software free and if it is not how much is it and where would i find it

[@TimWilborne]

Yes Maciek, it is free. See link below. twcontrols.com/lessons/where-can-i-download-allen-bradleys-connected-components-workbench-for-the-micro800

[@richardh568]

Tim: I really appreciate the video. I pretty well understand the which rung wins concept, but the title of the video was about duplicate destructive bits which I have encountered twice in my project for school. I found ways around the issue, but still don't completely understand it. I had two different rungs referring to the same OTE, and got warnings about duplicate destructive bits. Can you please explain what's causing the issue and how to avoid it even though I need for two different sections of code to be able to set it . It's not like I'm addressing the OTE's at the same time. BTW....in both cases, they were warnings, not errors. Do you think the program would have worked properly anyway ? Yo

[@TimWilborne]

Hi Richard. Which rung wins and duplicate destructive bits are the same thing. This example shows that the outcome of your two OTEs wouldn't be as expected. You would use branches and a single OTE to fix it.

[@richardh568]

@@TimWilborne Tim: Thanks for the reply. The weird things is, I did use branches. One OTE is in one branch, and the other is in another. Both should never be called in one cycle. But, the software still complains about having two in the same program. Since it's only a warning, I just wondered if the program would work correctly. I'm getting some strange results, but not sure if it's related to this issue. Thanks....

[@TimWilborne]

@@richardh568 If they are branched then there would only be one OTE. And define called. That is a term used with subroutines.

[@richardh568]

@@TimWilborne Thanks....

[@jacobbutler2498]

Thanks for all of this great content! That said, I understand what you've explained. However, is the moral of the story that this should not be done? I understand that the PLC will do it, and it is not ileagal in that respect, but it is considered poor practice, correct?

[@TimWilborne]

It would be considered a poor practice, but I think the more important moral of the story is don't abide by programming "rules" that are in place because of a lack of understanding of how PLC programs execute. I put this one in the same category as "an Examine if Closed" contact should be considered a normally open contact. It simply isn't true.

[@ryancastillo7240]

Is there online tutoriam

[@TimWilborne]

Check out this lesson series. www.theautomationstore.com/ccw-micro800-training/

[@diverbob8]

If the last rung doesn't win, then it isn't that last rung in the scan....

[@TimWilborne]

Not quite Robert. No rung wins. A PLC will scan code in a methodical order and come out with a predictable outcome every time. The last run influences the outcome, but it doesn't win. There are two points of this lesson, one to show that the "last run wins" rule is false. The other is this is a great exercise in understanding how a PLC scans. Once people grasp how a PLC scans, this exercise is easily understood.

[@diverbob8]

Just messing with you Tim, sorry for the transgression. As you know, they scan so fast, that they fight each other with messy results. When I started out with PLC 2s, the scan rate was slower and the IO updates were exactly predictable. Input Logic Ouput, so the last scanned output did win consistantly, but the results were obviouly still messy. When I write a rung, I always scan to see if there are any conflicts, which after hacking on the same program for 10 years, there sometimes are. On top of that, there are two processors (one for safety applications) and they have to work together. This makes for some real troubleshooting fun like when there is a fire and some of each system burns up and you still need to get critical infrastructure functions completed. Cheers!

[@diverbob8]

Have had all this transpire, the simple solution to all this, when you actually need two rungs, like one for jog or manual maintenance and another for an automatic sequence, is just ot put them in different routines and only scan one at a time.