Just a question - I/O Mapping to Integer files

sparky64

Member
Join Date
May 2003
Location
Newcastle upon Tyne
Posts
127
Some of our PLCs' have code written so that the I/O files are mapped unconditionally into integer files, and the bits or words of the integer file are used in the code, instead of the actual inputs or outputs. Can anyone tell me why do the programmers do this, because it becomes a pain to fault find on, especially if the documentation is not what it should be.

Thanks
Sparky
 
Sometimes its not the programmers choice. I've had customers that actually require it as part of their controls specification that real I/O be mapped to internals and that internals are to be used in programming. The last time I ran into this was at a Delphi plant in Saginaw MI on a disk brake caliper assembly machine. It was a Modicon application and they stated that if they lose an input or output the eletrician just has to go to the one rung where the real I/O point is mapped and make a change to use a spare.
 
Last edited:
There are lots of reasons.
One may be that the OEM has many 'similar' machines, so writing the entire program referencing identical integer file points means that the core logic never changes. They merely connect up the actual physical I/O to the 'mimic' points in the program.

One example of this could even be as simple as where a manufacturer makes a machine with all pushbutton control, and an upgrade that has touchscreen control. By mapping to internal points, either set of 'physical' inputs can be used.

Another reason could be when someone is developing a program, without any idea what the physical I/O layout will be (actually, that's pretty common, believe it or not). Again, once the logic is complete, the I/O can be mapped later on.

Then there is the case where I/O points are going to be shown on an HMI. In some cases, HMI's cannot directly read all I/O points, but even when they can, it is more efficient (communications wise) to group data together into blocks that can be read at one time.

One more reason, is that with more and more asynchronous scan PLC's showing up, is that sometimes it is important to make a scan-invariant copy of the input table, and sometimes even a scan-invariant copy of the output table in order to simulate PLC's with a synchronous I/O scan.

Just a few reasons off the top of my head, there are many more.
 
well... i'm using this method quite often, because of simulation purposes... 1) build architecture which allows to switch between various inputs or outputs 2) simply invert bit tag to set mode of real ai,ao,di,do,tm/ virtual ai,ao,... and still let whole functionality unharmed - this also helps me if somebody need to try immediately different settings of gas/ oxygene for burners etc.

(and yes rdrast, to cross them easily too)

and there may be another 'historical' reason (more like custom) - some platform i/o cards in past wasn't able to send data fast enough for cpu or if they was, it ate so much cpu time - so the trick on 'small application' is: not to communicate so hastly with i/o - today, cpu's doing this behind user code
 

Similar Topics

I have the impression I used to have the answer for this question, but I dont remember. I am copying the input data from a 1734 IB8 Safety module...
Replies
5
Views
1,216
Hi all, I'm using a Micrologix 1400 PLC. I have 8 physical DI's, 4 DO, 4 AI's that will be radio transmitted to a DCS Master. The DCS is a Bailey...
Replies
8
Views
9,204
Hey all! Before I jump in I just want to say this community is amazing! I haven't been at this whole Controls thing very long and this forum has...
Replies
8
Views
5,518
Can you guys explain to me how a 1747-SDN is mapped to work with an SLC 5/04. On the pictures I posted, the number 1 shows the address N72:0/0 to...
Replies
9
Views
2,799
I'm been deciphering a program for a press here. I've gotten most of it deciphered using the manual to understand the instructions (first mitsu...
Replies
0
Views
1
Back
Top Bottom