Same Output On Different Rungs?

OK, I thought I was gettin' pretty good at this. But, today I had to hook up to a PLC on one of our machines and found something that I thought you could not do...the same outputs located in 2 different spots. The only condition to make the rungs true were integer file bits (a different bit on the 2 different rungs). But, the outputs were exactly the same. As a matter of fact, there were a total of 7 outputs like this. They were outputs for a TTL output card on an Allen-Bradley 5/03 processor. Also, each pair were located inside of Jump/Label instructions. The machine has been operating fine like this for nearly 6 years, so I know it doesn't cause any problems. Someone help me out here and explain this. I must be missing something that I should already know.

Yes AB unlike Modicon will let you use an output more than once.
I think the idea is to use it in different sub-routines.
I'm not an expert on AB perhaps someone can explain what happens when you use the same output twice in the same routine i.e. does it act on the last state it sees?

Roy

All A-B PLCs scan the user code from top to bottom, as do the majority of other PLCs.

An output instruction eg. OTE --( )-- is just an instruction to the processor to write the current logic state of the rung to the memory address specified, and it will do that as and when it encounters each instruction.

If an output bit is used multiple times, then it could be written on, off, off, on, etc. several times during one processor scan.

A-B PLC5's have "Synchronous I/O". That means the Output Image data-table is written out to the output modules between logic scans, and in this case, the "last one wins" rule will apply.

However, some A-B PLCs, for example the PLC5/250 (Pyramid Integrator), and the ControlLogix series, have "Asynchronous I/O", where the outputs are transferred to the output modules at a time that is not synchronised to the logic scan at all. In this case, the "last one wins" rule cannot apply, and the state of the output will be determined by which rung was execuited last, not the last rung in the program.

However, that said, digging deeper into your post, you said the outputs in question were N-file bits, which of course are not outputs at all, just memory locations.

I imagine that at some point the N-file data is copied to the O-file to set the state of the TTL outputs.

If this data transfer only occurs once in the scan, then the physical output data will not be going on and off, but will be set only once.

The source data may have changed many times during the logic scan, but the output file data will be static.

And then I read that you have several JMP/LBL instructions in the program, and I can also imagine that the programmer may have organised this code so that only one of the sections of code is executed, thereby enabling only one write of the output data.

This could have been done to reduce scan time, for example, but using JMPs and LBLs to do this is, in my opinion, sloppy programming. There are better ways to organise code execution.

".....The only condition to make the rungs true were integer file bits."

What daba said was dead-on. Just pointing out that the integers noted were conditions not the outputs in question.

OG

The use of JMP/LBL or subroutines to execute different code controlling the same outputs can be effective if VERY CAREFULLY DOCUMENTED.

The tricky part, unless every section controls ALL THE SAME OUTPUTS aand at least one section is always active, is the transition from one section controlling code to another.

The outputs on the transition must be left in an appropriate state. If a section/subroutine were controlling an output then that section is disabled, unless controlled by another section the outputs would retain their last controlled state, even if it were just an OTE.

I agree with what bernie has said, however, it's the "controlled carefully" bit that worries me.

When I started in PLC control systems, way back in 1984, I was mentored by a time-served programmer.

He gave me several pieces of advice, one of which was "avoid making your code position-dependant". His idea was that any code you enter into the PLC should work properly, no matter where you place it.

Of course, back then, PLCs were much less sophisticated than they are now, and very often had only one user-program area. Even if they did have subroutines, placement of rungs within the file should not be position-conscious.

He also taught me that a program should have ONLY ONE reference to a physical output, for obvious reasons, and he disliked the use of JMP/LBL constructions, pretty much like I still do today.

He also positively detested the A-B MCR instruction, another sentiment I wholly agree with. When I look at a rung of logic that has a true path of conditional instructions, I want to see the output true also, and not have to go hunting round trying to find JMP's, MCR's, etc., that could interfere with the logic I am viewing.

By avoiding the sort of convoluted code that can ensue from switching bits of it in and out, I have always felt comfortable leaving my code at clients' sites, knowing that they can cause less damage when they come to modify it.

Worth about $0.02 I reckon.

Greetings shoelesscraig ...

something in the wording of your original post makes me think that you might find my series of YouTube videos helpful ... these are easily available from the Sample Lessons page on my website (no registration or information required) ... if you're interested, I strongly recommend that you watch them all IN ORDER – but (based on the questions you've already asked) pay particular attention to the part that runs from 4:40 through 6:12 in Video #7 ... that part covers OTE instructions executed with TRUE logic, OTE instructions executed with FALSE logic, and OTE instructions which aren't executed at all (as in JMP/LBL arrangements) ...

I must be missing something that I should already know.

Click to expand...

believe me, you are NOT alone ... even beyond all of the excellent (and accurate) advice already posted by my distinguished colleagues, there is often a fundamental flaw in the way that many people look at the operation of a PLC ... one of the most common mistakes is thinking of an OTE instruction as an "OUTPUT" ... once you understand the basic concepts of what an OTE instruction IS - and (just as important) what it is NOT – then a lot of otherwise confusing things will generally fall into place ...

I hope this helps ...

to be or not to be is definately the question.

i quite often use scratchpad bits to an ote or coil, and then re use them, some times hundreds of times depending on the program. it depends on the programming method you use. i saw a german written CIP program where each file was a sequence STEP conditionally called, with the outputs duplicated in every one, but they were conditionally called files, depending on the step. i thought it was quite well written, and i think thats the key to it.

From a structured programming standpoint, using physical outputs more than once in a program are bad practice. For that matter using jmp instructions (jsr is a much better option). In general, except in very small systems, I reference all physical I/O in one file (area) of the program. This makes trouble shooting by others much easier.

I've seen plenty of poorly written code run quite happily over the years. I'm just glad I wasn't there at the original debug period.

First off, to the OP shoelesscraig. If you can post the program in question, I would be happy to explain any parts you are having trouble with. Regardless of if you agree that it is written poorly or not, it's still a good idea to understand how it works.

I have one guiding principle for PLC programming that works for me. "Everything should be made as simple as possible, but not simpler" That line is attributed to Albert Einstein, there is some question as to if he actually said it, but I still like it.

Most of the "rules of thumb" I have seen in this and other threads, I have broken at one time or another. That is the nature of "rules of thumb", they aren't hard laws after all. When I do something a little different and break a "rule of thumb", I don't do it to show off. I do it because the problem at hand calls for a different approach to come up with a simpler solution.

Roy Matson said:

Yes AB unlike Modicon will let you use an output more than once.

Click to expand...

You can with Modicon as well, at least with Momentum's and Quantum's using Proworx. You just have to enable it. I used the feature recently when makingh major changes, having the two versions in different sub routines.