digital inputs and status bits

[Skidood]

I'm losing it...I accidentally posted this in a existing thread thinking I was starting a new thread. Time to put me out to pasture.

Instead of just using the actual inputs from the digital input card in your program, why do some programmers implement a ladder designed specifically to "converting" each of the physical inputs such as limit switches into status bits?

ie...If input "X" is "on", turn bit Bx ON.

TY

 

[plvlce]

Two primary reasons

1)If the PLC updates its I/O asynchronously this prevents inputs from changing state mid-scan.

2) Ease of later revision. If you have to move to a different input later (eg because the input goes bad) then you only have to make the change in one place, instead of hunting down every spot in the program that the input is checked.

 

[drbitboy]

[whoops, plvlce beat me to it]

Are you talking about an Input Map pattern cf. here?

If yes, there have been recent threads discussing this; some likely reason are the following:

• Flexibility - it's easy to replace a failed input channel with a spare, at the cost of only one changed character in the easy-to-find input map and re-landing some wires. Without the input map:
  • If the input tag is used in the main code of the program, then you have to find it, which is not a big deal if there is a cross-reference tool, but might need to be changed in several places
  • If the input module is treated as an INT, then it might be harder to fix.
• Validate data where it won't foul up program flow - any input handling, like a debounce, can be placed out of the way in the input map, and not clutter the main program
• Separation of concerns - in A-B ControlLogix/CompactLogix, the input scan runs asynchronously with the program scan and at a potentially higher priority. So an input map ensures a consisten mapped input bit during any single scan. Without the input map:
  • a reference to an input channel tag at the start of a program scan could yield a different value than one later in the same scan.

Those are just a few reasons.

 

[Skidood]

Yes to the input mapping, drbitboy..

OK thanks so much. Micrologix is not asynchronous, right?

 

[parky]

As Brian stated, one other reason (especially in the past), it was easy to simulate the code, before simulators were readily availlable, most PLC's you could not write to inputs so by mapping them (including outputs) but either remove the call to those blocks or not write them you could use just a rack & CPU without I/O & write simulation code to simulate real I/O for example:
Open a valve to add water to a tank, using the mapped bits/words the simulation code would be
AND 1_Sec_Clock AND V001_Open INC Tank_Weight
AND 1_Sec_Clock AND V002_Open DEC Tank_Weight.
When program has been tested, remove calls or delete the simulation code & re-introduce the I/O mapping.
So many PLC's would not run if I/O was not there or it was not possible to write to inputs.
Even with modern simulation programs I find it easier to write the extra temporary code than write it in the simulator, many are not very good or do not support analogues etc.

 

[KuulKuum]

Another thread that has some more info.
http://www.plctalk.net/qanda/showthread.php?t=74002
Posts by DamianInRochester are some good examples

 

[drbitboy]

OK thanks so much. Micrologix is not asynchronous, right?

Yes, I am fairly certain of that, but there may still be exceptions (e.g. messaging).