Input scan v/s Direct use of Inputs address

While framing the logic we normally use first input scan and store
it on input registers and then use those register data in subsequent logic.

Of course the processor scaning sequence is first input scan- program scan and then result to output registers. Can somebody tells me what all are the disadvantages of using direct input addresses in the logic instead of storing it in registers and consuming more memory space ?

Regards.

Saroj.

Faster Scan Time

huh?

shahn4,

I, for one, would like to see the reasonong behind your assertion that moving the input data to a holding location and then using the holding address in subsequent ladder logic will result in faster scan time.

saroj sarangi,

The primary reason is for when you want to use the same logic on another machine where the I/O addresses might be different. You need only modify the rungs that move the module data to the holding address.

Saroj Sarangi,

Most PLC's go through the scanning of inputs and setting of outputs in a similar sequence. Scan inputs, solve logic, and set outputs.

However in the Control Logix it is done a little differently.

Input data transfers to the controller asynchronous to the logic scan. The controller transfers output data at the end of each and every program scan. So, an input could change state anywhere throughout the program scan.

If you want input data to remain constant throughout one scan, make a copy of the input data at the beginning of the scan and use the copy throughout the scan.

Kim

In addition to Steve's suggestion, you can use your "mapping" routine to also "filter" your signals. These "filters" can be added at any time . . .

At my workplace, i use bit mapping so i can easily perform a change-over. A simple key switch and swap of a harting connector can change 50 I/O. What was once a proximity swith in program A is now a optic sensor in program B. Very versitile and allows for more machine capability.

Mark

Another advantage - Simulation

Another common use for internal inputs is simulation.

Some PLC brands do no let you write to the input image table, but will, of course, let you write to an internal register.

So if you were to disable your mapping routine, and enable your simulation logic {--|Valve|------(TMR)---(Opwn_LS) }, you can test your logic and HMI (to the limits of the simulation, at least).

You don't even need to have the real I/O modules (or any I/O modules) in your rack (or even much of a rack). You can be testing in a small test bed while the panel is being wired in the shop, or is in use by production on the floor.

Hi Steve,
"I, for one, would like to see the reasonong behind your assertion that moving the input data to a holding location and then using the holding address in subsequent ladder logic will result in faster scan time."

I have understanding (or misunderstanding) that in case of direct I/O addressing, the plc scan the I/O whenever it encounters one.

However, when the data is stored in plc internal registers rather than direct I/O addressing, it's access time for internal register is faster. Which in turns speeds the scan time.

I have understanding (or misunderstanding) that in case of direct I/O addressing, the plc scan the I/O whenever it encounters one.

Click to expand...

I'm not aware of any PLCs that work that way. Many PLCs include an 'Immediate update' instruction in their function set in case you want the most recent data before making a decision. Too frequent use of that instruction imposes a severe speed penalty on your program execution time.

However, when the data is stored in plc internal registers rather than direct I/O addressing, it's access time for internal register is faster. Which in turns speeds the scan time.

Click to expand...

I doubt if that is true. The PLCs with which I am familiar have an area of their memory assigned to data from input modules, another area for data to ouput modules, another area for internal bits, still another area for internal data registers. There is no reason why access time should be different for one area compared to another.

Field devices are going to be recorded into the Input table in any case (in any PLC). Input table memory is dedicated (in any PLC). To then take that information and move it into a word only increases scan time. It takes time to move data from one location to another. That increases scan time.

Even if reading internal registers can happen faster than reading the actual input bit, the information has to be transferred from the actual input bit to an internal register... that takes time.

However, I will say, it seems to me that there is a certain amount of overhead in trying to read a particular bit in a word from the Input table. But then, the same situation exists when trying to read a particular bit from a register.

Since some PLC's are capable of doing an immediate read... it must be the case that the input data is available in real-time. (Of course, that is true in only some modules in the structure. In TI, immediate reads are allowed in the base station only. The base station does not rely on communication between stations.)

In that case, if the input data is logged into a register at the top of the ladder, then later code, designed to look at that register, might be latent. That is, the real-time value of the input might have changed since it was recorded into the register.

While it might be the case that register data is more accessible (faster), I don't think that recording all input data into a set of registers makes the data more immediate.

Field devices are going to be recorded into the Input table in any case (in any PLC). Input table memory is dedicated (in any PLC). To then take that information and move it into a word only increases scan time. It takes time to move data from one location to another. That increases scan time.

Click to expand...

Yes, but realistically we would only be looking at a few instructions. For instance, in the S7 world, a word instruction only takes 80 nanoseconds (for an S7-400). I could load/transfer 100 words to a virtual IO map and only increase my scan by 16 microseconds, which is hardly a make or break decision.

On the other hand, mapping the IO can give incredible advantages during development (I can map the IO to local memory and use canned functions). Or, perhaps the IO addresses change from machine to machine, in which case I would rather change the code in one place rather than a thousand places.

My vote is for IO mapping, regardless of how trivial it might be at the moment.

The only notable exception to Steve Bailey's I/O update description a few posts back. The AB SLC5 plc has a significant amount of overhead associated with M data access but about standard data transfer rate. That is to say it take about the same amount of time to read 100 words as one bit. OK, maybe I embelished that a bit, but not much. So in that case it is always better to read you M data in as a block and use internal registers.

Keith

I/O mapping is all about structure.

When you develop a sequence of logic you MUST follow a structure.

If you don't, chances increase to end up with spagheti code.

Raltime, almost-Realtime semi-Realtime ... well, when you will understand that you will also have your own educated-opinion on the subject.

I personaly always use I/O mapping in a way. Not all the I/Os but certainly ALL the ones being subject to a change in there logic program.

When I make a change and I do online, I always map some I/Os to test the logic in parallel.

After ready a post from Terry I also added watchdogs in parallel to them new rungs.

So I use the mapping to test.

I also always use this technique when my program is base on a serie of Karnaugh maps and LL converted Grafcet.

Makes life easyer.

Do I ear them keepers coming. Who opened the door?

Pierre is correct. I/O mapping has a lot advantages but DOCUMENT the system well. I really dont like being called out to work on a system and then have to track down an input that got mapped to a register that does something to an internal coil that gets mapped to another register and then "magically" shows up in the output image table.

RANT WARNING
Since I spend more maintaining systems and not designing new systems I have become a firm believer in the KISS method. I want to see code where the programmer spent less time trying to show somebody how smart he is and more time trying to make the code readable to mere mortals...

Sorry, got bit in the butt last night when apparently Einstein, Newton, and Pascal all got together and wrote a PLC-2 program. I mean give me a break is the two milliseconds you saved gonna kill you on process where the lag time is measured in minutes... #$^^#@&*#!