You can also insert a composite into a module. Composite blocks are user-defined blocks that represent a group of function blocks or Sequential Function Chart (SFC) steps. Composite block execution is synchronous with other function blocks in the module.
Composite blocks can be linked or embedded. The main differences between linking and embedding blocks are in storing the algorithm data and updating the data after the block is created. When you link to a composite block, it remains linked to the library composite template it was created from. The system updates the linked block when you modify the structure of the original template. Linked data is stored in the source block; the linked block stores the location of the source block and displays a representation of its template. The parameters in a linked block can be unique for that block.
When you embed a block, the block does not change if you modify the source block. Embedded blocks become separate, standalone blocks. You can edit the structure of an embedded block, and the original composite block remains unchanged.
The modular approach to configuration makes troubleshooting easier and reuse of the modules possible. This approach also avoids the complications of creating one large program to perform the control strategies for each controller and the difficulty of defining and accessing the control data based on the physical location.
Sometimes implementing a control strategy in a composite block works as well as it would in a module. Some of the factors that determine whether you should use a module or a composite block include:
Scan Rate — When a control strategy needs to run at a different rate than the module that contains it and that rate is not a multiple of the module's scan rate, you must put the strategy into its own module. Scan rate is a property of a module, and a composite block can have a scan rate multiplier that executes it only on certain scans, but it does not have its own scan rate.
Efficiency — There is more overhead associated with a module than with a composite block. Therefore, the module uses more memory than a composite block. If you have a choice that does not seem illogical in your control philosophy, use a composite block. (An illogical choice might be if you are controlling all of your motors with a module, and you select one particular motor control and put it in a composite block.) Try to be consistent with your approach.
Function — A composite block works like a subroutine that is called by the containing module. You can call the composite from different modules and pass it different parameters, but it cannot run by itself. A module is more like a standalone program that can be invoked from within another module.
Control Language — If you need to intermix different control languages within a single module, use one composite block for each language.
Logic — You logically divide your system for troubleshooting and maintenance purposes so that you can isolate problems and limit the module to specific equipment. If you find your modules getting large and complex with many composite blocks, you might want to break the modules into separate modules that make sense logically.
Alarms — If you want to place the object you are defining into the library for reusing, and you want to save the alarms that you have defined with the object, you must use a module because the alarms are not stored with the composite in the database.