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)

The post How to Create a Configurable Routine Using Application Code Manager appeared first on DMC, Inc..

At first glance, using ACM can seem daunting or tedious when adding one object at a time to build your database, but I’m here to present you with a way to quickly import/export multiple object instances at once using Excel.

With most projects, the customer or integrator will provide an I/O list containing names, descriptions, alarm setpoints, and more. This list has a lot of key information that is usually entered manually in Studio 5000 or via the HMI. This can take a lot of time and introduce typos and mistakes. 

ACM takes this data and enters all of it into .l5x and .ACD files, allowing one to begin programming actual logic quickly. The steps below will instruct you how to streamline your object instantiation and start actual logic programming.

The Process

Once you have the initial project created with your controller, rack, and I/O, you can start assigning instances.

To help move things along, add one instance of every object that you will use for the project. This builds the necessary examples and tabs in the ACM Excel file.

Once your object first instances have been inserted in the project, right click the controller, and select the Export option.

Select the complete project radio button, and then click Export and Open button. 

After a few moments, a Windows save dialog will open and ask you to save the export into a location of your choosing. Click Save and proceed.

Once finished, an ACM Excel file will open, ready to be modified with the rest of your object instances.

Please note that some of these example objects have many columns of data that can be configured, but I will be focusing on the main data inputs that are usually necessary for every type of project. The example below will go through analog inputs. This process can be used for all object types and instances.

Legend –

• Name – Tag name of the object instance that will be imported into the Studio5000 program.
• Task and Program – Studio5000 task and program that the object will be inserted into.
• Description – Object description that will be used for HMI display, alarm messages, and anything else description related.
• P_Cfg_PVEUMax – The maximum engineering value.
• P_Cfg_PVEUMin – The minimum engineering value.
• P_Cfg_PVEU – Engineering units for the instrument.
• P_Cfg_InpRawMax – the maximum raw input scale, in this case 20mA. This depends on how the input/output card has been configured.
• P_Cfg_InRawMin – the minimum raw input scale, in this case 4mA. This depends on how the input/output card has been configured.
• P_Cfg_HiHiLim – High High alarm limit.
• P_Cfg_HiLim – High alarm limit.
• P_Cfg_LoLim – Low alarm limit.
• P_Cfg_LoLoLim – Low Low alarm limit.
• P_Inp_PV_Address – I/O Assignment. This is the tag for the actual input/output card and channel number. There will be no need to map I/O in Studio5000 after ACM creates the .acd file.

With your I/O list, you can now simply copy and paste the information into the ACM format. This can include alarm setpoints, descriptions, instance names, engineering units, raw units, and anything else that needs and can be configured ahead of time.

Once you have filled out the Excel sheet, you can import the sheet back into ACM. Right click the controller in the class view and select Import.

Select Replace – Overwrite project, navigate to the Excel file you have just updated, and click Import.

After the import finishes, you can expand the object class and see the newly imported object instances. At this point you are ready to generate the initial .ACD file from ACM.

Now, right click on the controller and select Generate Controller.

A popup will appear. Select where you would like to save the .l5x and .ACD files, then click Generate.

Once the generation finishes, you will have a Studio5000 program file that already has all instances created along with their tags. At this point, all that is left is to do is project specific programming like sequences, shutdowns, and anything else required. 

As you can see, using Excel with ACM can quickly streamline projects of any size and help integrators complete projects in record time.

Learn more about DMC's Rockwell Automation partnership and contact us today for your next project!

The post Streamline Rockwell’s Application Code Manager with Excel appeared first on DMC, Inc..