ControlLogix: Online - Green Bars

[SoftwareJanitor]

Is it true that you don't get the green True/False bars in "Online" mode on every element type? For example, the GTEQ or NEQ block: it doesn't turn these blocks green if they're true?

Or is there some option I need to turn ON?

 

[Ron Beaufort]

IF I understand your question - then yes, you are correct ...

specifically, you do not get the "green on the screen" highlights when some types of instructions are TRUE ...

for example: the comparison-type instructions such as GRT and LES ...

and – going further - (you're not going to like this) ...

SOME of the "green on the screen" highlights that DO appear, do NOT actually represent TRUE (or represent "power flow" as some folks like to express it)...

for example, consider an ONS (One Shot) instruction ... this will appear "green on the screen" once it has already been "fired" ... specifically, an ONS which is highlighted in green is NOT actually TRUE ... indeed - it is FALSE ... it is highlighted "green on the screen" not because it is a TRUE condition – but rather because there is a ONE stored in its status bit/box ...

side note: the OSR and ONS instructions in the RSLogix500 systems (SLC, MicroLogix, etc.) typically do not turn green under any circumstances ...

so – could we possibly nail things down to the one-size-fits-all statement that "a ONE stored in a bit/box always represents a TRUE condition?" ... no – unfortunately it's not nearly as simple as "ONE always means TRUE – ZERO always means FALSE" ...

consider an XIO (Examine If Open) instruction ... this will show "green on the screen" highlights whenever its bit/box contains the value of ZERO (not ONE) ...

now take a deep breath – and consider the following facts ...

the ControlLogix processor is typically scanning the ladder logic "code" at something like 400 to 600 times per second ... now ask yourself this: how fast do you think that your computer screen (running RSLogix/Studio5000) can possibly be updated? ... the obvious answer is nowhere even remotely close to the rate of the processor's scan rate ... and even if the screen could somehow miraculously be updated just as fast as the processor is scanning – your human eye could not possibly interpret the actual real-time TRUE/FALSE signals as anything other than a meaningless blur ...

so ... here's what that means in brutally simple terms ...

you can NOT really trust the "green on the screen" indications when you are working on "beyond beginner" problems ...

the fact of the matter is that the "green on the screen" indications are placed on your computer screen by the SOFTWARE (RSLogix/Studio5000) ... specifically, those indications are NOT placed there by the PROCESSOR which is scanning the code ...

going further ...

the "green on the screen" indications are an attempt to help field technicians troubleshoot fairly simple problems such as "the pump won't run" at 3:00 o'clock in the morning ...

"Look, Bubba, the float switch is green – so it must be OK. But the limit switch ain't green – so maybe THAT'S what's holding us out." ...

the truth of the matter is that there are MANY (MANY!) situations where the "green on the screen" indications are worse-than-worthless for troubleshooting purposes ...

the following link gives one simple example – and a quick easy testing method that you might find extremely useful when debugging beyond-beginner type problems in the future ... you might want to try this little one-rung demonstration on your own equipment ...

http://www.plctalk.net/qanda/showthread.php?p=438423&postcount=11

I hope that what I have written proves helpful to you ... I offer it with the best of intentions ...

 

[SoftwareJanitor]

Ron Beaufort:

Thanks for your thorough and meticulous reply! Yeah ... I was just wondering why the comparative blocks weren't lighting up. Seemed like those should be.

So I guess the Green Bars in Ladder Logic may not be as great a feature as many of its proponents would have you believe (inconsistently implemented)...

 

[daba]

Just to complete a small part of the picture, Ron linked to his post showing the difference between RSLogix500 and RSLogix5000 highlighting of the "first-scan" status bits.....

There are 6 "system" bits that are maintained by Logix5000 processors, 4 of them are arithmetic status bits.

S:FS - "First Scan" bit. This bit is set by the processor on the first actual processing scan. Every Program in every Task has it's own S:FS status bit.

S:MINOR - A minor fault exists in the processor. Minor faults do not stop the scan, so this bit can be used to trigger code to determine which fault exists.

The next four status "flags" are typically maintained by arithmetic instructions, so can be inspected in code immediately after they have been executed. If you want to know whether an instruction affects the S:x flags, look in the instruction "Help".

S:Z - The result of the last instruction that affects the arithmetic status flags produced a Zero result.

S:N - The result of the last instruction that affects the arithmetic status flags produced a Negative result.

S:V - The result of the last instruction that affects the arithmetic status flags resulted in an Overflow.

S:C - The result of the last instruction that affects the arithmetic status flags resulted in a Carry.

The RSLogix programming software makes no attempt to "green- highlight" any instructions with any of these 6 bits as operands, on the basis that many of them will be changing too fast for GUI highlighting to be of any use.

Some people might say it's an inconsistency between the two platforms. I say it is perfectly valid to exclude them, considering the arithmetic flags could be changing every few microseconds. Typically RSLinx is updating tag values at about 0.5 second intervals.