Programming Style

One quick reason comes to mind is that if an input or output were to change address you could just change the mapping from the real I/O to the integer bit and the rest of the code would be unaffected. Also in the days of the PLC-2 I/O was asynchronous so it was standard to map I/O to internal bits so that inputs could be scanned first and outputs scanned at the end.

I myself don't like that style of programming. It can make it difficult to follow. The only reason I can think of is in the case the input/output module was changed to a different slot in a newer machine or update, they might have thought this is easier. It might have been before the days of global search and replace. Today it would sort of be like aliasing on the newer platforms.

Another possible reason is that at one time they were somehow masking inputs or outputs and just carried this programming style throughout.

We actually have this as one of our programming standards.

Reason for using this method is for simulations. The code can be developed using modular styles with the IO attached at a later date (once that is determined).

Another reason is for communications. If you have all your data compacted into a memory area, then the communications is more efficient.

Input and Output mapping is often done to allow the same core program to run with multiple revisions of the actual I/O. Sometimes the programmer does not know how the machine is going to be wired, or what the states of sensor will be etc...

Once completed, any changes to the I/O can be handled by simply editing the mapping logic. I like the practice as long as it is consolidated into one or two ladder files and an organized manner. It also makes it easier to have one all inclusive program and then edit just the input and output maps to accomodate options that are not installed.

It also avoids issues that some platforms (like Controllogix) may have in which the states of real inputs or outputs may change during the scan.

Paul

It also avoids issues that some platforms (like Controllogix) may have in which the states of real inputs or outputs may change during the scan.

Click to expand...

I am not sure I follow this. Are you saying here that by mapping the I/O you can simulate logix 500 scanning method on a control logix platform? I would like to hear in detail how that works. I never understood why AB made the control logix scan process asynchronous.

The asynchronous nature allowed the logic scan and the I/O scan to be accomplished in parallel by 2 processors each designed for precisely that function - thus more speed. Update for slower I/O (which doesn't need the constant update) could also be seperated from high speed update I/O thus optimizing the flow. The side effect was the 'change in the middle of the scan' effect.

The copy that OkiePC alludes to accomplishes essentially the same thing that aiki202 noted. Copy real inputs to internal memory at the start of the scan. Update internal memory for outputs during the scan. Then at the end of the scan copy the internal memory to the real outputs.

Dohhhh!!!! I get it now. Quite simple realy! Thanks!!

BOWRIDER said:

Dohhhh!!!! I get it now. Quite simple realy! Thanks!!

Click to expand...

Simple method, beggining of Main Routine copy all physical inputs to a mapped register---use register values for process---> End of Main routine copy the value of mapped registers to the physical Outputs.
Works like a charm!

This was quite a while ago for me but I think the PLC5 did an I/O update at the end of a parallel branch of an SFC. So even with the PLC5 it was possible to get multiple I/O updates per plc scan if the SFC was constructed in a specific way. With the Classics (5/12, 5/15, 5/25, ect) I don't think there was a way to inhibit this.

Keith

kamenges said:

This was quite a while ago for me but I think the PLC5 did an I/O update at the end of a parallel branch of an SFC. So even with the PLC5 it was possible to get multiple I/O updates per plc scan if the SFC was constructed in a specific way. With the Classics (5/12, 5/15, 5/25, ect) I don't think there was a way to inhibit this.

Keith

Click to expand...

The enhanced PLC5s have 16 Master Control Programs.( If you wanted to use them)
You can chose to update the I/O before each MCP. See pic, just uncheck the skip I/O update.

Thanks to all who replied. LJBMatt, your response about PLC-2 I/O being asynchronous makes sense. This was the type of info I thought I might not be aware of. It is before my programming days, but I think the early 90's is when the PLC-5 would have been first installed instead of a PLC-2 or upgraded from a PLC-2. Those doing the ladder code were most likely PLC 2 savvy.

I would say for reuse.It is fine if you comment and organize it, rather than like some "programmers" do and leave it scattered around with no sense.

Now though, being able to search and replace in the PLC and HMI, life is good.

The evolution of the AB scan method:

PLC-2 had a synchronous scan but it occurred between program scans - while the I/O was updated the program was not being scanned

PLC-3 had a totally asynchronous scan - I/O was updated independently of the program scan and it was possible for an input to change state in the middle of a scan causing many hours to be spent wondering how the machine could run fine for a month then suddenly crash...

PLC-5 combined the two methods - the I/O scan was asynchronous but the state of the I/O was buffered and only updated between program scans so that I/O was "frozen" throughout the scan.

Another reason for using Integer addresses was because they appeared on the screen and in printouts in File:Word/Bit format instead of I/O or Binary addresses appearing as B3/23, etc. This made it possible to come up with many different schemes for organizing addresses in a logical fashion, N7:10 bits controlled one valve or motor, N7:20 bits were for the next valve, etc. Crude methods compared to today, but that's all they had then.

I have also seen this used because of confusion between the octal IO addressing, 0-7 & 10-17, and the 0-15 used internally.