one input precedence over another

[Manglemender]

I've had a quick scratch at this in a State Transition kind of way. (see attachment).

The sequence on the right hand side serves to tell the other two conveyors that it is free to accept a transfer. N.B. There is a big difference between "not busy" and "free". Some years ago a former colleage gave me some code he had written for the conveyor system that accompanied a machine I was commissioning, all was going well until the system experienced a power failure; When power returned, 4 tonnes of polyester film was dumped on the floor because the code looked for the absence of a busy signal rather than an explicitly free signal from the next conveyor. My former colleage is now an IT security consultant.

The sequence on the left of the page is the same for both feed conveyors (C1 and C2). The code for C3 should be executed in between the code for C1 and C2.

Nick

 

[Manglemender]

There is a flaw in the logic as I've described it. For each of the feeding conveyors, the "C3 Free" Transition must include an evaluation that no transfer request is pending for C3.

Nick

 

[Ron Beaufort]

and yet there is more to consider ...

here's another relevant topic for conversation – that hasn't been discussed in this thread yet ...

whenever you're dealing with input signals that are changing state within one or two scans of each other, you can't really count on them to write their ONE or ZERO status into their input bit/boxes as accurately as you might expect them to ...

for example: suppose that we wire TWO digital inputs to the SAME set of contacts on a single momentary pushbutton ... in other words, when we press the button BOTH of the inputs will receive an electrical signal at exactly the same time ...

now common sense would tell us that BOTH of the bits should "fire" – and come ON – at precisely the same time ...

specifically, we'd expect BOTH inputs to either be ON, or BOTH of them to be OFF ... more specifically, since they're "wired together" they should jolly well "stay together" ...

but here's the trick:

when we push the button, SOMETIMES the bit/box for input A will come on BEFORE the bit/box for input B ... and (conversely) SOMETIMES the bit/box for input B will come on BEFORE the bit/box for input A ...

now since this thread is discussing the ControlLogix platform, you might think that the effect that I'm referring to is somehow related to the ControlLogix processor's "asynchronous" scan sequence ...

nope – you'll get the same effect if you try this on a PLC-5 - or an SLC-500 - or on MicroLogix system ...

the effect is primarily due to the facts that:

(1) the input module's input circuits are individual electronic circuits ... in simplest terms, some of them are more "sensitive" or more "responsive" than others – even than others on exactly the same module ...

and ...

(2) the signals from the circuits in the input module happen to be "parsed" or "strobed" into the processor's input bit/boxes at minutely different times ...

so ...

the harsh reality is that IF (that's a big IF) the proper operation of your system actually does rely on knowing PRECISELY (down to ONE SINGLE SOLITARY scan sequence) which one of two inputs comes on FIRST, then you're probably not going to achieve reliable operation from your system ...

the figure below was taken from a ControlLogix processor – and BOTH inputs were wired to exactly the SAME momentary pushbutton (wired Normally-Open) ... after pressing the button 100 times, the data shows the results ...

specifically, both input circuits did come ON at the same time during 94% of the operations ...

but ...

there were five instances where bit/box 0 was driven to a status of ONE while bit/box 1 remained a status of ZERO ... (as shown by the test on the first rung) ...

and ...

there was one instance where bit/box 1 was driven to a status of ONE while bit/box 0 remained a status of ZERO ... (as shown by the test on the second rung) ...

so ...

it's really a random thing as to which of the two bit/boxes will become updated first – even though ELECTRICALLY the inputs are being "powered on" simultaneously ...

summing up ...

if your system truly can not tolerate such a random evaluation of which input is coming on first, then you're going to find some other way, possibly mechanical, to ensure that only one of the inputs can be turned on at a time ...

or ...

put something in your code that will "break the tie" and give priority to one input or to the other ...

I think that Manglemender has already brought that idea up in the discussion ...

.

 

[jdbrandt]

here's another relevant topic for conversation – that hasn't been discussed in this thread yet ...

<snip>

put something in your code that will "break the tie" and give priority to one input or to the other ...

I think that Manglemender has already brought that idea up in the discussion ...

.

Well said, as usual, Ron.
I have seen this in a PLC-2 as well (with obvious other distractions), and proved it in pretty much the same way.
We do, don't we, get into a pretty interesting quandry, when we act as Maslow observed: "When your only tool is a hammer, every problem looks like a nail.". PLCs don't solve every problem (gasp)