Ken Roach said:
...your only options are to delete those modules, and the logic associated with them, from your project in order to test it. Hopefully that logic is fairly self-contained in routines that operate those communications modules.
This is a classic example of where Buffering the I/O for the modules could be used...
(This is not for your benefit Ken!)
Buffering Input data is a technique in which the logic references a copy of the input data from the module-defined data type.
Buffering Output data is a technique in which logic modifies a copy of the output data from the module-defined data type.
We can copy parts of a module-defined data type to and from single atomic tags, such as a DINT for a 32 bit SLOT, or we can copy an entire module-defined data type structure to and from a user-defined similar structure.
That's just a synopisis. I'm not going to go all into the topic of Buffering I/O.
For the example in this thread...
In the project, let's say we have Buffered an Input module in Slot 12 (last) of the distributed I/O 13 slot chassis as follows...
Using a CPS instruction (Copy Synchronous)
Source:
Dist_IO_01:I.Slot[12].Data (DINT within module-defined data type)
Dest:
Buffer_In_Slot_12 (DINT user-defined within Controller Tags)
Anywhere in the project's logic that we need to reference theses Input tags, we do so by referencing the Buffer Input tags and not the module-defined tags. Likewise we can do the same for Output data, but I want to keep this example simple and as short as possible. So I'm just focusing on one Input module in one slot that will "dissapear".
For the original configuration of a distributed I/O 13 slot chassis under the communications module, the module-defined tags will include up to the
I.Slot[12].Data DINT member (0-12 slots). However, when we change the distributed I/O chassis size to a 10 slot chassis, it will now only include up to the
I.Slot[9].Data DINT member (0-9 slots). This will make the reference to
Dist_IO_01:I.Slot[12].Data in the CPS instruction invalid.
In this case, we can simply create a placeholder or substitute user-defined tag of a similar description so as to retain a reference to what the original module-defined tag was...
Actual module-defined memeber:
Dist_IO_01:I.Slot[12].Data DINT
User-defined reference placeholder:
ph_Dist_IO_01_ISlot12Data DINT
Now when the project is verified the CPS will have valid operands and will execute when running by copying blank data from the reference placeholder tag into the Buffer tag. Likewise for Output data, a CPS would copy the Buffer tag data to the user-defined reference placeholder tag.
Depending on how many members within a module-defined data type that you have chosen to interact with seperately, you would still only have to create a few tags and modify a few copy instructions. If an entire module-defined data type structure is being copied to or form, then this is further simplified down to a couple of tags and edits.
This may help to simplify the process of adding and removing actual modules and will, more importantly, allow you to keep the existing logic which is referencing, and/or looking to modify, the I/O data for the modules you wish to remove.
Regards,
George
