Same "ONESHOT" in Multiple Locations

[Lancie1]

OSR (One Shot Rising)
.
.
.
Description
The OSR is a conditional input instruction that triggers an event to occur one time. Use the OSR when an event must start based on the change of state of the rung from false to true, as triggered by a pushbutton. An example would be to use the OSR to freeze rapidly displayed LED values.
.
.
.
You must enter a bit address for the OSR. Use either a binary file or integer file address. The bit address you use must be unique. Do not use it elsewhere in the program.

The address assigned to the OSR instruction is not the one-shot address referenced by your program, nor does it indicate the state of the OSR instruction. This address allows the OSR instruction to remember its previous rung state.

Warning! Do not place input conditions after the OSR instruction in a rung when using a Fixed or SLC 5/01 controller. Unexpected operation may occur.

The SLC 5/02, 5/03, 5/04, 5/05 and MicroLogix controllers allow you to use one OSR instruction per output in a rung. With the Fixed and SLC 5/01 processors you can only use one OSR per rung, regardless of the number of outputs. OSRs cannot occur within branches when using the Fixed and 5/01 controllers.

Operation

When the rung conditions preceding the OSR instruction go from false-to-true, the OSR instruction is true for one scan. After one scan is complete, the OSR instruction becomes false, even if the rung conditions preceding it remain true. The OSR instruction becomes true again if the rung conditions preceding it transition from false-to-true.

Rockwell Software 2000

 

[Ron Beaufort]

from the "more than you wanted to know" department ... part 1 ...

Greetings skyfox ...



since your original question has already been correctly answered (more than once) this response will certainly fall under the heading of “overkill” ... be that as it may, it appears that there is still some amount of misconception about how the ONS instruction works its magic ... for those who aren’t already tired of the subject, here are some nuts-and-bolts details from Monday afternoon of the PLC “Bootcamp” class ...



first of all, let’s work through a step-by-step analysis of what the ONS instruction does during NORMAL operation in a CLX (ControlLogix) application ... let’s use the following simple example:

(1) suppose that Switch_0 has been turned “OFF” out in the field for a long time ...

(2) the bit/box for Switch_0 thus contains a 0 ...

(3) now suppose that the CLX processor begins its next pass through the ladder logic ...

(4) the XIC instruction for Switch_0 tells the processor to “go look for a 1” in the bit/box for Switch_0 ...

(5) the processor does NOT find a 1 – and so the XIC is evaluated as “FALSE” ...

(6) now the processor comes to the ONS with “FALSE” logic ...

(7) whenever the ONS is executed with “FALSE” logic, “FALSE” logic flows downstream from the ONS ... (translation: no “fire” this time) ... AND the processor also resets the ONS bit/box to a 0 status ... (translation: it “reloads” the ONS) ...

(8) now the processor comes to the ADD instruction with “FALSE” logic ...

(9) whenever the ADD instruction is executed with “FALSE” logic, the processor does NOT increase the value in the Destination ... (translation: the value of Data_1 remains unchanged) ...

(10) and around and around we go – until something changes ...



(11) now suppose that someone turns Switch_0 “ON” out in the field ...

(12) the bit/box for Switch_0 now contains a 1 ...

(13) now suppose that the CLX processor begins its next pass through the ladder logic ...

(14) the XIC instruction for Switch_0 tells the processor to “go look for a 1” in the bit/box for Switch_0 ...

(15) the processor DOES find a 1 – and so the XIC is evaluated as “TRUE” ...

(16) now the processor comes to the ONS with “TRUE” logic ...

(17) whenever the ONS is executed with “TRUE” logic, the processor first checks the status of the ONS bit/box ... (translation: it needs to see if the ONS has already been “fired”) ...

(18) in this case, the processor finds a 0 in the ONS bit/box ... (translation: since it found a 0, the processor now knows that the ONS has NOT already been fired) ...

(19) whenever the processor executes the ONS with “TRUE” logic – AND the ONS bit/box contains a 0 – “TRUE” logic flows downstream from the ONS ... (translation: the ONS was “loaded” and now it gets “fired”) ... AND the processor sets the value of the ONS bit/box to a 1 ... (translation: the processor marks the ONS as “fired”) ...

(20) now the processor comes to the ADD instruction with “TRUE” logic ...

(21) whenever the ADD instruction is executed with “TRUE” logic, the processor DOES increase the value in the Destination ... (translation: the value of Data_1 is increased by 1) ...



(22) now suppose that Switch_0 stays “ON” out in the field during the next pass ...

(23) the bit/box for Switch_0 still contains a 1 ...

(24) now suppose that the CLX processor begins its next pass through the ladder logic ...

(25) the XIC instruction for Switch_0 tells the processor to “go look for a 1” in the bit/box for Switch_0 ...

(26) the processor DOES find a 1 – and so the XIC is evaluated as “TRUE” ...

(27) now the processor comes to the ONS with “TRUE” logic ...

(28) whenever the ONS is executed with “TRUE” logic, the processor first checks the status of the ONS bit/box ... (translation: it needs to see if the ONS has already been “fired”) ...

(29) in this case, the processor finds a 1 in the ONS bit/box ... (translation: since it found a 1, the processor now knows that the ONS has ALREADY been fired) ...

(30) whenever the processor executes the ONS with “TRUE” logic – AND the ONS bit/box contains a 1 – “FALSE” logic flows downstream from the ONS ... (translation: this time the ONS does NOT get “fired”) ... AND the processor sets the value of the ONS bit/box to a 1 ... (translation: the processor marks the ONS as “fired”) ...

(31) now the processor comes to the ADD instruction with “FALSE” logic ...

(32) whenever the ADD instruction is executed with “FALSE” logic, the processor does NOT increase the value in the Destination ... (translation: the value of Data_1 remains unchanged) ...

side trip: I’m amazed at how much “text” it takes to explain this ... I cover it in every class and it only takes a few minutes to nail everything down ... but MAN it sure looks like a lot of “stuff” when you type it all out ...

summation: under NORMAL operating conditions, we have three possible outcomes for the ONS ...

(33) “FALSE” logic comes in – and “FALSE” logic goes out – and the status bit/box gets marked with a 0 ... (no fire) ...

(34) “TRUE” logic comes in – the bit/box contains a 0 – “TRUE” logic goes out – and the status bit/box gets marked with a 1 ... (fires) ...

(35) “TRUE” logic comes in – the bit/box already contains a 1 – “FALSE” logic goes out – and the status bit/box stays marked with a 1 ... (already fired) ...



well, it doesn’t sound so bad after all when you say it that way does it? ...



now that we’ve got the NORMAL operation nuts-and-bolts behind us, let’s take a look at the first question that skyfox asked in Post #1 ...

continued in next post ...

 

[Ron Beaufort]

part 2 ...

For an example: Logic in the same subroutine (AB LOGIX Platform)

RUNG#0 MOMENTARY_SWITCH_1-------[ONS1]-----------LIGHT_1_ON(LATCH)

RUNG#33 MOMENTARY_SWITCH_1------[ONS1]-----------LIGHT_5_ON(UNLATCH)

Is this Legal?

(too) simple answer: yes, it’s legal ... going further, you probably don’t really want to do it that way ...



let’s go through it step-by-step ...



(36) suppose that MOMENTARY_SWITCH_1 has been turned “OFF” out in the field for a long time ...

(37) the bit/box for MOMENTARY_SWITCH_1 thus contains a 0 ...

(38) now suppose that the CLX processor begins its next pass through the ladder logic ...

(39) on Rung #0, the XIC instruction for MOMENTARY_SWITCH_1 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_1 ...

(40) the processor does NOT find a 1 – and so the XIC is evaluated as “FALSE” ...

(41) now the processor comes to the ONS with “FALSE” logic ...

(42) whenever the ONS is executed with “FALSE” logic, “FALSE” logic flows downstream from the ONS ... (translation: no “fire” this time) ... AND the processor also resets the ONS bit/box to a 0 status ... (translation: it “reloads” the ONS) ...

(43) now the processor comes to the OTL (Latch) instruction with “FALSE” logic ...

(44) whenever the OTL instruction is executed with “FALSE” logic, the processor takes NO action ... (translation: the status of LIGHT_1 remains unchanged) ...

(45) on Rung #33, the XIC instruction for MOMENTARY_SWITCH_1 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_1 ...

(46) the processor does NOT find a 1 – and so the XIC is evaluated as “FALSE” ...

(47) now the processor comes to the ONS with “FALSE” logic ...

(48) whenever the ONS is executed with “FALSE” logic, “FALSE” logic flows downstream from the ONS ... (translation: no “fire” this time) ... AND the processor also resets the ONS bit/box to a 0 status ... (translation: it “reloads” the ONS) ...

(49) now the processor comes to the OTU (Unlatch) instruction with “FALSE” logic ...

(50) whenever the OTU instruction is executed with “FALSE” logic, the processor takes NO action ... (translation: the status of LIGHT_5 remains unchanged) ...

(51) and around and around we go – until something changes ...



(52) now suppose that someone turns MOMENTARY_SWITCH_1 “ON” out in the field ...

(53) the bit/box for MOMENTARY_SWITCH_1 now contains a 1 ...

(54) now suppose that the CLX processor begins its next pass through the ladder logic ...

(55) on Rung #0, the XIC instruction for MOMENTARY_SWITCH_1 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_1 ...

(56) the processor DOES find a 1 – and so the XIC is evaluated as “TRUE” ...

(57) now the processor comes to the ONS with “TRUE” logic ...

(58) whenever the ONS is executed with “TRUE” logic, the processor first checks the status of the ONS bit/box ... (translation: it needs to see if the ONS has already been “fired”) ...

(59) in this case, the processor finds a 0 in the ONS bit/box ... (translation: since it found a 0, the processor now knows that the ONS has NOT already been fired) ...

(60) whenever the processor executes the ONS with “TRUE” logic – AND the ONS bit/box contains a 0 – “TRUE” logic flows downstream from the ONS ... (translation: the ONS was “loaded” and now it gets “fired”) ... AND the processor sets the value of the ONS bit/box to a 1 ... (translation: the processor marks the ONS as “fired”) ...

(61) now the processor comes to the OTL (Latch) instruction with “TRUE” logic ...

(62) whenever the OTL instruction is executed with “TRUE” logic, the processor “goes and writes a 1” into the bit/box for LIGHT_1 ... (translation: the processor sets the status of LIGHT_1 to a 1) ...



(now comes the tricky part, so stay on your toes) ...



(63) on Rung #33, the XIC instruction for MOMENTARY_SWITCH_1 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_1 ...

(64) the processor DOES find a 1 – and so the XIC is evaluated as “TRUE” ...

(65) now the processor comes to the ONS with “TRUE” logic ...

(66) whenever the ONS is executed with “TRUE” logic, the processor first checks the status of the ONS bit/box ... (translation: it needs to see if the ONS has already been “fired”) ...

(67) in this case, the processor DOES find a 1 in the ONS bit/box ... (oops! the 1 that the processor finds is the same 1 that it just wrote into the ONS bit/box back on Rung #0 ... and so ... since it found a 1, the processor is convinced - rightly or wrongly - that this ONS has ALREADY been fired) ... and moving right along ...

(68) whenever the processor executes the ONS with “TRUE” logic – AND the ONS bit/box contains a 1 – “FALSE” logic flows downstream from the ONS ... (translation: the ONS on Rung #33 does NOT get “fired”) ... AND the processor sets the value of the ONS bit/box to a 1 ... (translation: the processor marks the ONS as “fired”) ... and continuing even further along ...

(69) now the processor comes to the OTU instruction with “FALSE” logic ...

(70) whenever the OTU instruction is executed with “FALSE” logic, the processor takes NO action ... so ... if you’re planning for your program to take some type of “unlatching” action down there on Rung #33 when MOMENTARY_SWITCH_1 comes ON, don’t get your hopes up ...



and that’s why (almost) everyone is telling you to use a separate status bit/box for each and every ONS ... personally, I’m really at a complete loss to imagine even ONE example of where “reusing” a status bit for multiple ONS instructions would be a good idea ... of course I’m always open for suggestions if anyone can come up with one ...

continued in next post ...

 

[Ron Beaufort]

part 3 ...

now let’s tackle the second scenario from the original post by skyfox ...

RUNG#0 MOMENTARY_SWITCH_44-------[ONS1]-----------LIGHT_1_ON[L]

RUNG#33 MOMENTARY_SWITCH_17------[ONS1]-----------LIGHT_5_ON[L]

Is this possible or is it a no-no.

it’s a definite no-no ... this one can be even more confusing - since you have two separate switches this time ... but let’s go through it – at least part way ...



(71) suppose that MOMENTARY_SWITCH_44 has been turned “OFF” out in the field for a long time ...

(72) the bit/box for MOMENTARY_SWITCH_44 thus contains a 0 ...

(73) also suppose that MOMENTARY_SWITCH_17 has been turned “OFF” out in the field for a long time ...

(74) the bit/box for MOMENTARY_SWITCH_17 thus contains a 0 ...

(75) now suppose that the CLX processor begins its next pass through the ladder logic ...

(76) on Rung #0, the XIC instruction for MOMENTARY_SWITCH_44 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_44 ...

(77) the processor does NOT find a 1 – and so the XIC is evaluated as “FALSE” ...

(78) now the processor comes to the ONS with “FALSE” logic ...

(79) whenever the ONS is executed with “FALSE” logic, “FALSE” logic flows downstream from the ONS ... (translation: no “fire” this time) ... AND the processor also resets the ONS bit/box to a 0 status ... (translation: it “reloads” the ONS) ...

(80) now the processor comes to the OTL (Latch) instruction with “FALSE” logic ...

(81) whenever the OTL instruction is executed with “FALSE” logic, the processor takes NO action ... (translation: the status of LIGHT_1 remains unchanged) ...

(82) on Rung #33, the XIC instruction for MOMENTARY_SWITCH_17 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_17 ...

(83) the processor does NOT find a 1 – and so the XIC is evaluated as “FALSE” ...

(84) now the processor comes to the ONS with “FALSE” logic ...

(85) whenever the ONS is executed with “FALSE” logic, “FALSE” logic flows downstream from the ONS ... (translation: no “fire” this time) ... AND the processor also resets the ONS bit/box to a 0 status ... (translation: it “reloads” the ONS) ...

(86) now the processor comes to the OTL (Latch) instruction with “FALSE” logic ...

(87) whenever the OTL instruction is executed with “FALSE” logic, the processor takes NO action ... (translation: the status of LIGHT_5 remains unchanged) ...

(88) and around and around we go – until something changes ...



(89) now suppose that someone turns MOMENTARY_SWITCH_44 “ON” out in the field ...

(90) the bit/box for MOMENTARY_SWITCH_44 now contains a 1 ...

(91) suppose that MOMENTARY_SWITCH_17 still remains “OFF” out in the field ...

(92) the bit/box for MOMENTARY_SWITCH_17 still contains a 0 ...

(93) now suppose that the CLX processor begins its next pass through the ladder logic ...

(94) on Rung #0, the XIC instruction for MOMENTARY_SWITCH_44 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_44 ...

(95) the processor DOES find a 1 – and so the XIC is evaluated as “TRUE” ...

(96) now the processor comes to the ONS with “TRUE” logic ...

(97) whenever the ONS is executed with “TRUE” logic, the processor first checks the status of the ONS bit/box ... (translation: it needs to see if the ONS has already been “fired”) ...

(98) in this case, the processor finds a 0 in the ONS bit/box ... (translation: since it found a 0, the processor now knows that the ONS has NOT already been fired) ...

(99) whenever the processor executes the ONS with “TRUE” logic – AND the ONS bit/box contains a 0 – “TRUE” logic flows downstream from the ONS ... (translation: the ONS was “loaded” and now it gets “fired”) ... AND the processor sets the value of the ONS bit/box to a 1 ... (translation: the processor marks the ONS as “fired”) ...

(100) now the processor comes to the OTL (Latch) instruction with “TRUE” logic ...

(101) whenever the OTL instruction is executed with “TRUE” logic, the processor “goes and writes a 1” into the bit/box for LIGHT_1 ... (translation: the processor sets the status of LIGHT_1 to a 1) ...



(now here’s a VERY tricky part) ...



(102) on Rung #33, the XIC instruction for MOMENTARY_SWITCH_17 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_17 ...

(103) the processor does NOT find a 1 – and so the XIC is evaluated as “FALSE” ...

(104) now the processor comes to the ONS with “FALSE” logic ...

(105) whenever the ONS is executed with “FALSE” logic, “FALSE” logic flows downstream from the ONS ... (translation: no “fire” this time) ... AND the processor also resets the ONS bit/box to a 0 status ... OOOPS! ... (translation: it “reloads” the ONS) ...

(106) now the processor comes to the OTL (Latch) instruction with “FALSE” logic ...

(107) whenever the OTL instruction is executed with “FALSE” logic, the processor takes NO action ... (translation: the status of LIGHT_5 remains unchanged) ...

(108) and now we go around again – with the same switch conditions ... specifically, MOMENTARY_SWITCH_44 is “ON” out in the field ... MOMENTARY_SWITCH_17 is “OFF” out in the field ...



(109) suppose that MOMENTARY_SWITCH_44 is still “ON” out in the field ...

(110) the bit/box for MOMENTARY_SWITCH_44 still contains a 1 ...

(111) suppose that MOMENTARY_SWITCH_17 still remains “OFF” out in the field ...

(112) the bit/box for MOMENTARY_SWITCH_17 still contains a 0 ...

(113) now suppose that the CLX processor begins its next pass through the ladder logic ...

(114) on Rung #0, the XIC instruction for MOMENTARY_SWITCH_44 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_44 ...

(115) the processor DOES find a 1 – and so the XIC is evaluated as “TRUE” ...

(116) now the processor comes to the ONS with “TRUE” logic ...

(117) whenever the ONS is executed with “TRUE” logic, the processor first checks the status of the ONS bit/box ... (translation: it needs to see if the ONS has already been “fired”) ...

(118) in this case, the processor finds a 0 in the ONS bit/box ... (translation: since it found a 0, the processor now knows – or at least it THINKS! - that the ONS has NOT already been fired) ... (IMPORTANT! notice that the status of the ONS has been “hijacked” by that other ONS instruction down on Rung #33) ...

(119) whenever the processor executes the ONS with “TRUE” logic – AND the ONS bit/box contains a 0 – “TRUE” logic flows downstream from the ONS ... (translation: the ONS was “loaded” and now it gets “fired” – AGAIN!) ... AND the processor sets the value of the ONS bit/box to a 1 ... (translation: the processor marks the ONS as “fired”) ...

(120) now the processor comes to the OTL (Latch) instruction with “TRUE” logic ...

(121) whenever the OTL instruction is executed with “TRUE” logic, the processor “goes and writes a 1” into the bit/box for LIGHT_1 ... (translation: the processor sets the status of LIGHT_1 to a 1) – AGAIN! ...



(again - here’s the same VERY tricky part) ...



(122) on Rung #33, the XIC instruction for MOMENTARY_SWITCH_17 tells the processor to “go look for a 1” in the bit/box for MOMENTARY_SWITCH_17 ...

(123) the processor does NOT find a 1 – and so the XIC is evaluated as “FALSE” ...

(124) now the processor comes to the ONS with “FALSE” logic ...

(125) whenever the ONS is executed with “FALSE” logic, “FALSE” logic flows downstream from the ONS ... (translation: no “fire” this time) ... AND the processor also resets the ONS bit/box to a 0 status ... OOOPS! ... (translation: it “reloads” the ONS – AGAIN!) ...

(126) now the processor comes to the OTL (Latch) instruction with “FALSE” logic ...

(127) whenever the OTL instruction is executed with “FALSE” logic, the processor takes NO action ... (translation: the status of LIGHT_5 remains unchanged) ...

(128) and now we go around again ...

(129) so in this setup, the logic of Rung #0 will be executed (with “TRUE” logic) over and over again on each and every scan – REGARDLESS of the presence of the ONS instruction ...



and that’s enough for now ... anyone who wants to work through the “what if?” conditions with the other switch positions is welcome to my nightmare ...



going further ... when you finally get a chance to try this out on a working processor, I’d suggest that you set up something EXACTLY like the example that my distinguished colleague MikeB suggested in Post #7 ... you’ll find that the ADD instructions will make it a LOT easier to see what’s going on than the OTL and OTU instructions that you used in your original post ...



and now on to the next post where the SERIOUS fun begins ....

 

[Ron Beaufort]

part 4 ... conclusion ...

disclaimer: the discussion which follows is intended SOLELY for the Allen-Bradley ControlLogix platform ... specifically, it does NOT directly apply to the Allen-Bradley PLC-5 or SLC-500 platforms ... more specifically, the processor’s scan sequence is DIFFERENT for the ControlLogix platform ...



here we have a simple “test” program – based on the excellent example given by MikeB back in Post #7 ...

what we haven’t mentioned so far in this discussion, is that with the ControlLogix platform, there is a definite possibility for the logic of Rung #1 to be executed “TRUE” once in awhile – even though the logic of Rung #1 might (on the same pass) remain “FALSE” ...



specifically, if you flip Switch_0 on and off repeatedly, sooner or later there will come a time that the ONS on Rung #1 will indeed “fire” and increase the value of Data_2 – even though the ONS on Rung #0 will NOT “fire” ...



witness (in the picture) that I had to flip the switch 13 times before Rung #1 executed its copy of the ONS “TRUE” just once ... on each previous flip of the switch, only the logic of Rung #0 was able to execute its copy of the same “reused” ONS ... and it’s a totally RANDOM thing ... the next experiment (made under exactly the same conditions) might take only one flip – or it might take hundreds ... who knows? ...



secret handshake: remember that (unlike the PLC-5 and SLC-500 platforms) the ControlLogix processor does NOT have its “Update of the Input Image Table” defined at a specific point in the processor’s scan sequence ...



specifically, you don’t know at exactly what point in the rung-by-rung execution any change in the “on” or “off” status of the field inputs is going to suddenly be reflected in the processor’s tag listing ... so ... what that means is that all of that step-by-step analysis that we did in my previous post was based on NORMAL operation of the ControlLogix ... now we’ve turned a corner and must consider that “normal” is a relative thing ...



suggested subjects for further research (if you’re interested in the fine points) would include: RPI (Requested Packet Interval) and COS (Change of State) ... both of these topics pertain to the setup and configuration of the input module being used ... also consider that the closer the two rungs are physically located together, the smaller the “window of opportunity” for this type of mischief to occur ... placing the rungs further apart, of course, gives the input module more of a chance to change the status of the switch’s input bit/box - and therefore makes it more likely to affect the operation of the “reused” ONS instructions in ways that are unexpected and almost certain to be unpleasant ...



on the sunny side of things: these are the types of “debug” problems that make programming such an interesting enterprise ...



finally ... do NOT reuse your ONS status bits ... it’s as simple as that ... if you do, you’re just asking for trouble ...



disclaimer: obviously these posts have involved a LOT of Copying-and-Pasting ... I apologize for any errors – but right now I’m just too tired to proofread it again ... hope this helps ...

 

[skyfox]

WOW!

A hearty THAK YOU TO ALL!

It's amazing what one can learn (Or knew very little) about a simple instruction. Ron, Thank you for the detailed and methodical explanations. It wasn't overkill at all. Once again, I am very thankfull for the knowledge I gained from you and all the rest of you that took the time to respond and explain.

Much appreciated.

Best Regards to all!

 

[optimus2861]

Just as a followup to Ron's last post, on a bit of a tangent. Note that area where Ron says the processor has a "window of opportunity" to change a field input in the middle of a program scan. This is because the ControlLogix processor updates I/O asynchronous to program scan. That sort of thing can be an awful bug to track down if it causes your program to behave loopy once every 10,000th scan or so. I had it happen to me once, and as a result have forever sworn off directly referencing an input tag in a program except in one location, where the input is "mapped" into an appropriate device tag name. The rest of the program uses that mapped tag, which won't change for the duration of the scan:

XIC Local:1:I: Data.0 OTE Switch_0

XIC Switch_0 ...

It's true that you lose the ability to directly force on/off the tag Switch_0 (since it's no longer an alias to the input), but you do gain the ability to quickly change the point Switch_0 is referencing (say your electrician wired it to the wrong point, or you were given the wrong information), or change its NC/NO status on the fly (say the input is a NC contact instead of NO - now all your logic in the aliased program is backward. In the mapped program, flip the one contact and the rest of your program is good to go).