This article will demonstrate how to build a library object for Application Code Manager (ACM). We will touch on instantiating AOIs using a library object in addition to adding optional logic to the code based on the object’s configuration.
Utilizing ACM and configurable library objects allow you to streamline development by deterministically generating the code you need based on easy to modify configurations. This saves time, reduces mistakes, and enforces approved coding standards. While this blog illustrates the use of a few specific AOIs, the concept can be extended to any objects in your development library.
Planning the Routines and Programs
The first step is to define the routines and programs within the library to organize the logic being generated. For this example, the alarm logic is organized in routines within the MainLogic program, which is dedicated to alarms and other control logic such as sequences. The MainProgram is used to organize and generate AOIs for devices, such as transmitters, into related routines. Both program names are intended to be placeholders and will be modified via parameter substitution in ACM.
In this example, Analog Objects are configured with LoLo, Lo, Hi, and HiHi status thresholds. The Lo and Hi thresholds generate alarms, while LoLo and HiHi generate shutdown conditions. Alarm handling is contained within a dedicated Alarm routine, and shutdown handling is contained within a dedicated Shutdown routine, as illustrated in the figure below.
Next, we’ll need to define the routine for our devices. For demonstration purposes, this routine will house the AOIs for processing and scaling the input data from either in-chassis IO or from a Turck IO block.
For this example, we will use the name “myRoutine” so that we can later modify it via parameter substitution in ACM.
Programming the Routines
We will create an analog input routine consisting of two AOIs, AOI_TurckAnalogInputProcessing and AOI_AnalogInput.
Analog Input Routine
The Analog Input routine will be structured to be fully configurable and allow the use with Turck I/O or without. This will be handled with configurable ACM parameters that will be explained later in the article.
The Turck Analog Input Processing AOI is intended to be used with a BLCEN-8M12LT-4AI-VI-4A-VI. This AOI will combine the two Bytes which make up the analog input raw value, which will then be passed into iInRaw tag of the AOI AOI_AnalogInput via configurable ACM parameters. If Turck I/O was not being used ACM will not generate the Turck logic and will insert the user’s preferred I/O tag into iInRaw of the AOI_AnalogInput AOI.
Alarms Routine
The Alarms routine will be used to configure alarm logic automatically if the AnalogInput is configured to have the corresponding Alarm(s). What does this mean? We will only generate Hi or Lo alarm logic if the input is configured to use them in ACM. In this example, we will use simple alarm bits with a global reset.
Notice that the naming convention “C0000_myAnalog” matches the generic name of the AOI_AnalogInput that was added in the Analog Input Routine. This is done so we can use the parameter substitution feature in ACM to replace this text when generating code.
Shutdowns Routine
Similar to the Alarms routine, HiHi and LoLo shutdowns will be added to the Shutdowns routine if the analog input is configured to use them.
Building the Library Object with Library Designer
From here, we’ll work within Rockwell’s Library Designer Plugin and configure the required text substitutions, parameters, and deterministic logic creation.
Access the Library Designer plugin by right clicking the top of your controller organizer tree.
Once in Library Designer, navigate to “myRoutine” to get ready to apply conditional expressions that will handle logic creation.
In Library Designer, you can set up instantiation rules per rung, per ladder branch, and even down to logic components like contacts and coiles. Here, we will be applying a rule for a rung containing the Turck AOI. Select the rung by clicking it. A green box will appear indicating that the rung has been selected.
Update the condition to control the creation of the logic. By default, the library will have the field filled in with “Always.”
This means that no matter what, this logic will always be created during the code generation process. For our example, we will only instantiate this logic if the configured IO is coming from a Turck IO device, which will be set using the parameter “bTurckIO.”
This new parameter is added to the parameters section of our library object.
With that rule configured, the Turck AOI will only be included if the device is configured as a Turck IO point, while the Analog Input AOI will always be included when we instantiate one. We will leave the condition set to “Always” for the AOI_AnalogInput so that it will always be added for every input we configure.
Next, we will use the same concept for the Alarms and Shutdowns routines. Just like the Turck object, we will create parameters to define if an alarm should exist.
In the Alarms routine, we will apply a conditional parameter for both the Hi and Lo alarm rungs.
We will apply the same concept to the Shutdowns routine as well. These parameters are shown below.
To demonstrate an additional option, we will add a conditional statement on the Alarms and Shutdown routines themselves. Just like choosing to instantiate rungs and small pieces of logic, you can choose to optionally create routines as well. Here, if no alarms or shutdowns are enabled, we will not create the respective routine.
For Alarms we will require the following ACM parameters bAlarmLEnable (Low Alarm Enabled) or bAlarmHEnable (High Alarm Enabled) to be true.
For Shutdowns we will require the following ACM parameters bAlarmHHEnable (High High Alarm Enabled), bAlarmLLEnable (Low Low Alarm Enabled), or bAlarmOREnable (Out of Range Alarm Enabled) to be true.
From here, we can jump to the Application Code Manager and see how we can enter values into the parameters to affect what is created with the logic during code generation.
Application Code Manager Code Generation
To continue with our demonstration, let’s add an Analog Input instance within ACM. For the first instance, we’ll configure it to require the Turck I/O without any alarms. To do so, we’ll need to concentrate on the following fields.
- Name – This field specifies the device name and is used to generate the corresponding PLC tag name.
- sRoutineName – This field defines and creates the routine that the device will be instantiated in.
- bTurkIO – This field is used to enable or disable the creation of Turck IO logic.
- AI_ADDRESS – This field is used to assign the I/O tag to the AnalogInput AOI. In this example we use “TIT_100.iInRaw” so that it can be referenced by the Turck AOI output.
Next, we’ll create an Analog Input instance that does not use Turck IO but has all its alarms enabled. For now, I will put a placeholder into the AI_Address that can be configured later once I/O is configured in the project. Additional fields for alarm configuration will be used in this example.
- bAlarmHHEnable – This field specifies if the High High alarm is enabled or disabled for the device.
- bAlarmHEnable – This field specifies if the High alarm is enabled or disabled for the device.
- bAlarmLEnable – This field specifies if the Low alarm is enabled or disabled for the device.
- bAlarmLLEnable – This field specifies if the Low Low alarm is enabled or disabled for the device.
- bAlarmOREnable – This field specifies if the Out of Range alarm is enabled or disabled for the device.
Now we’re ready to use ACM to generate our code. To do so, right click on the controller in ACM and click Generate Controller.
When the pop‑up dialog box appears, select Create ACD, enter the desired file name, select whether to overwrite the existing ACD file, and define the file path.
After you generate the .ACD file from ACM you will see that the following routines and programs have been created.
If we open the AnalogInputs routine, we will now see the two instances, TIT_100 and PIT_100 that were configured in ACM.
You’ll see that the Turck Interface created only for the TIT_100 object based on the parameters we set. Note that PIT_100 was instantiated without the Turck AOI based on its parameterization.
Now, let’s look at the newly generated Alarms and Shutdowns routines. In this example, alarms were only created for PIT_100 as TIT_100 was not configured to use them.
Conclusion
While this demonstration was simple in nature, it illustrates the benefits that can be derived by creating your own library objects and utilizing ACM to autogenerate a significant portion of your PLC logic.
These concepts can be extended to create much more advanced programs and routines based on configurable parameters. For very large projects, or for OEMs with very similar systems, this can significantly streamline the development process.
Here at DMC, we leverage ACM as a powerful tool to accelerate development timelines, improve code standardization, and quickly modify projects to account for changing requirements.
For more information on Application Code Manager, read our other articles:
- Streamline Rockwell’s Application Code Manager with Excel
- Importing and Customizing a Library with Application Code Manager
- How to Use Application Code Manager (ACM) with PlantPAx Distributed Control System (DCS)
Ready to take your manufacturing automation project to the next level? Contact us today to learn more about DMC’s solutions and how we can help you achieve your goals.