Ignition has many powerful and useful features that can be utilized for making screens with dynamic animations and control. Some of these features are custom screen properties, parameterized templates, and expression building. This blog will explore how to create a screen that allows the user to navigate easily between configuration settings for similar devices.

Using Dropdown Lists

One object that can be very useful and intuitive to implement is the dropdown list component. The dropdown list comes with a built-in, two-column dataset where one column displays a label and the other corresponds to a selected value.

Figure 1: Station Selector Dataset

This is useful because a more detailed description is displayed to the user while something as simple as an integer can be set to a parameter in the background. For example, in situations where the system has individual stations that use similar equipment, it is likely that the only thing differentiating these units from a software perspective would be the number assigned to that station. Since the value and label are independent from each other, the developer can use any label they want (such as a number or a relative position) to convey the station’s identity to the user.

Modular Tag Structure

Figure 2: Example Tag Setup

In the above tag structure, each station has many sub-devices with the same underlying tag structure. If each station has four devices, then each will have its own integer and double value with two devices sharing a float value. For example, Device 1 would correspond to Int1, Double1, and SmallFloat (Devices 1 and 2 share SmallFloat, while 3 and 4 share BigFloat).

Device Configuration Example

Figure 3: Calibration Screen Initial

In this example, I set up a calibration screen with two dropdown lists. One of the dropdown lists is used to set the selected station (see figure 1 for the dataset configuration and figure 2 for the tag structure). The second dropdown list is used to select a device within that station. The Device Selector dataset can be set up in a very similar fashion to the Station Selector with the biggest difference being that it needs to have an extra column added to account for the float values’ tag-paths.

Figure 4: Device Sector Dataset

Indirect Tag Mapping

After the dropdown lists were configured, I used indirect tag bindings to map the selected integers and double values to their respective IO fields.

Figure 5: Indirect Tag Mapping

In this dynamic mapping, the tag-path is automatically set to the correct double by taking the selected value of the station and device selectors. An almost identical indirect tag expression can be used to set the integer field to the correct tag. The only difference between the two being that I replaced Double with Int.

Accessing Custom Dataset Values

As unfortunate as it is, we cannot use indirect tagging to access the custom column that we added to the device selector. Fortunately, with a few extra steps, we can still use that value to point the float input/output field to the correct tag in our tag browser. The first step to achieving this is to create a string custom property on the screen that will hold the tag path for our float IO field. A screen’s custom properties can be accessed by right-clicking the screen and selecting the Custom Properties item under the Customizers menu.

Figure 6: Custom Properties Location

Figure 7: Custom Property Setup

The next step is to create a property binding on that string parameter so that it accesses the FloatName column that has been configured on the Device Selector dropdown.

Figure 8: Expression Setup

Once that expression is set up, we can implement an indirect tag for the float IO field.

Now, the screen will update its values to the correct tags as the user shifts between the different stations and devices. This dynamic tag pathing is just one example of how Ignition can be a flexible and powerful SCADA solution.

Learn more about DMC’s Ignition capabilities.

The post Using Dropdowns to Set Tag-Paths in Ignition appeared first on DMC, Inc..

In most applications, Ignition uses industrial Ethernet to connect and communicate to field devices. This may not be possible if the devices are isolated in a way that it makes it impossible to connect over a network. However, there are other methods to set-up communication between the main Ignition server and field devices which I will outline below.

Message Queuing Telemetry Transport (MQTT)

One such method involves using the MQTT protocol. MQTT stands for Message Queuing Telemetry Transport and works by using a publish subscribe based messaging procedure. During this procedure, one device publishes a string to the topic as a second device takes that string and parses it into useful information. What is nice about Ignition’s implementation is that the string and tag parsing is done for us by Ignition’s MQTT modules. Therefore, once these modules have been set up through Ignition’s gateway, the rest of the implementation should be straightforward.

Process

In a full implementation, the central gateway can communicate with any number of edge devices. For this demo, I am using a central gateway on my computer and an edge gateway on a raspberry pi. In addition to the standard Ignition modules, the MQTT distributor and the MQTT engine modules should be added to the central gateway. All edge gateways should have the MQTT transmission module added.

Modules can be added to a gateway by going to the configure tab of the gateway, clicking the modules page on the system group, and selecting the desired mod1 file to upload. These files can be acquired from the inductive automation website.

Configuring MQTT Engine

Once the MQTT Engine module has been added to the desired gateway, it can be configured by clicking on the settings item of the MQTT engine group on the configure tab. This will bring up a page that has three separate tabs: general, servers, and namespaces. Located on the general settings page is an input field for the primary host ID. For this implementation I set this as TestMQTT, but it can be set to anything. This value will be used again when configuring the MQTT transmission module on the Ignition edge gateway.

Next, under the miscellaneous section of the page, I unchecked the boxes labeled block node commands and block device commands. This will allow access for the main gateway to write to the tags that are being shared by the Edge gateway. After that I navigated to the servers tab. There should be a default server set up.  This will be the server we use for our implementation.

When you click the edit button, it will bring up the connection settings for this server. Under URL, type in the address and port of the MQTT distributer either in the form of tcp://mydomain.com:1883, for tcp connections, or ssl://mydomain.com:8883, for ssl connections (1883 and 8883 are the default ports for Ignition’s TCP and SSL connections). Since the MQTT distributor and MQTT engine are on the same gateway, you can use localhost as the domain. TCP is the default server type on the distributor, so I used that type of connection during this process.

The last tab is the namespaces tab, which you can leave at the default values. If you want your engine to subscribe to topics published by third party devices, this is where you would configure those connections. The MQTT disturber can also be set up from the configure tab of the gateway’s home page, but the default values should work fine for this implementation.

Setting up the MQTT Transmission Module

After the MQTT engine has been configured on the main Ignition gateway, it is time to set-up the MQTT transmission module on the Ignition edge gateway. As before, this is done through the MQTT modules settings page under the configuration tab. This settings page has 5 tabs: general, servers, sets, transmitters, and records. First, select the servers tab and set the URL to point towards the main Ignition gateway in the form of tcp://[ip address of gateway computer]:1883.

Next, set the server to default. Under the sets tab, press the edit button for the default set and set the primary host id to the same host id used in the configuration for the MQTT Engine.

Create Edge Tags

After the default set has been configured appropriately, it is time to create the edge tags. To do this, launch the designer from the Ignition edge gateway. In the designer’s tag browser, under all providers -> edge, there will be a folder called Edge Nodes that will have been auto generated by the MQTT Transmission module. Create folders using this structure: Edge Nodes -> Group folder -> Edge Node Folder -> Device Folder. For this implementation, I named these folders Group 1, Edge Node 1, and Device 1.

In this device folder above, I added a few UDTs with memory tags to be mapped to the MQTT Engine on the main gateway. This folder can contain a variety of tag types, UDTs, and lower level folders as well. All of which would be mapped to the MQTT Engine on the main gateway.

Verifying the Connection 

Once this is completed, the transmitter is started by setting the refresh tag in the MQTT Transmission -> Transmission Control folder to true. After this tag is set (it will automatically reset itself), the connection can be verified from the edge gateway by going to the server’s tab of the MQTT Transmission settings. If everything is working properly, connected in the tab servers tab should be “1 of 1”. If it doesn’t, check your port and firewall settings to verify it allows incoming data transmission.  

Once it has been confirmed that the transmitter is connected, the tags that were created in the device folder should be visible to the main Ignition gateway. This can be checked by opening a designer for the main gateway project. In the designer’s tag browser, navigate to the folder All Providers ->  MQTT Engine. The folder structure that was created in the edge project should be replicated here (as well as tags from other MQTT Transmission modules connected to this engine).

Learn more about DMC’s Ignition Expertise and contact us with any inquiries.

The post MQTT Ignition Communication with an Edge Gateway appeared first on DMC, Inc..

The DMC boot loader has three important features that help improve its use. The first of which is it has an onboard micro USB port. This port allows for serial communication with a CPU via a USB to micro USB cord (like you would use to charge a phone).

The second important feature of the boot loader is that it has onboard reset and boot buttons. This allows for the user to easily put their MCU into boot loading mode by resetting the MCU while pressing the bootloader button.

The third feature of this board that is important is the five-pin connector. This connector is how the bootloader communicates with the target MCU.

For most DMC embedded projects, there is a standard 5 pin header that is compatible with the boot loader’s connector. Through this mounting, we can send and receive the serial data, as well as reset and put the board into boot loading mode. Even if a board doesn’t have a compatible mount, you can manually connect the boot loader’s TX, RX, boot, ground, and reset pins to the appropriate locations on the target board to achieve the same functionality.

This tool is one example of many internal initiatives DMC has undertaken to be more efficient and profitable.

Learn more about DMC's Embedded Development and Programming Solutions. Contact us for additional information.

The post DMC’s Custom Bootloader appeared first on DMC, Inc..

It is important to note that this implementation will not work with basic panels!

Exporting and Importing Files

Siemens HMI’s have built-in functions for importing and exporting files that are relatively easy to implement. Both functions are triggered by events that are named ExportDataRecords and ImportDataRecords, which are built-in Siemens functions. The events can trigger on a large variety of actions, but for this example, I had them trigger on HMI button presses. 

These events can be set by going to a component’s properties and clicking on the events tab (shown below). 

Component Properties on the HMI interface

Sample Configuration for ExportDataRecords

Sample Configuration for ImportDataRecords

For both importing and exporting data records, the input that specifies the desired pathing is the filename input. This parameter is the system path to the file in the form of a string. The string containing the import variable, and the string containing the export variable can be set using the same built-in HMI event function called OpenFileBrowser. Note that for this implementation, the export path and the import will need to be held in separate variables.

Sample Configuration for OpenFileBrowser

This event lets the user navigate to a desired folder/file and save the computer pathing of that file to the tag passed into the Path input. In this application, a specific file is used for importing recipes, and a folder is specified for exporting recipes. To do this, toggle the file input of the open file browser event.

When this parameter is set to true, the file browser will return a path to a file, when it is false it will return the path to a folder. When this field is set to true, you can also mask the browser to only show specific file extensions such as .csv or .ap by using the mask field. This can be useful for ignoring irrelevant files.

The event that exports recipes needs a file pathing to export, and since our file browsing event is grabbing a folder pathing, some basic scripting is needed to create an export file path we can use. The script below concatenates the folder pathing we got from the file browser with a name tag I created for the current recipe. This script should be triggered on the value change of either the folder path or the recipe name.

Sub ExportPathing()

    HmiRuntime.SmartTags("sExportPath") = _
        HmiRuntime.SmartTags("sExportPathFolder") & _
        HmiRuntime.SmartTags("dbRecipes_udtCurrentRecipe_sRecipeName") & _
        ".csv"

End Sub

Sub ExportPathing()

    HmiRuntime.SmartTags("sExportPath") = _
        HmiRuntime.SmartTags("sExportPathFolder") & _
        HmiRuntime.SmartTags("dbRecipes_udtCurrentRecipe_sRecipeName") & _
        ".csv"

End Sub

Once the correct path is specified for importing and exporting, the import and export event are ready to be triggered. By using the tips outlined for importing and exporting recipes, you should be able to specify computer locations for importing and exporting recipes easily. I hope this will help in your future endeavors.

Learn more about DMC’s HMI and SCADA Expertise and our partnership with Siemens.

The post Dynamically Specifying the Folder for Importing & Exporting Siemens HMI Recipes appeared first on DMC, Inc..

Reduce this inconsistency by using a built-in hardware interrupt associated with high-speed counters. Reduce the variance due to a program’s scan time by passing a reference point to the high-speed counter and peripherally writing to the desired output bit.

This tutorial demonstrates how to set up a high-speed counter interrupt, peripherally write to the desired output, and set its reference point in the PLC.

Setting up the High-Speed Counter Interrupt

1. To set up a reference interrupt for a high-speed counter, go to the device configuration of the PLC. From there, navigate to the high-speed counters tab and select the desired counter.
   
   
    

   

2. From here, select event configuration and check the box for Generate interrupt for counter value equals reference value event. Checking this box will autogenerate an event name and priority.
   
   
    

   

3. To specify the OB that this interrupt will call, press the button that contains the … on the far right of the configuration window. Pressing this button will open a dropdown that allows the programmer to either select a preprogrammed interrupt or to create a new one specifically for this event by using the add new button located on the bottom right of the drop-down.
   
   

   

Peripherally Writing to an Output in the Interrupt

The code used in the interrupt is not all that complicated in this specific instance, but there are a few things that you should keep in mind when implementing it.

The main functionality is in network one, and all it does is write the output bit low if it is already high. The important thing to note with this section of code is how the bit is written low. To peripherally write to that output, the tag needs to be followed by .

Following the tag with will immediately write the output bit low instead of waiting until the creation of the process image. This is how the variability due to the scan time is eliminated. The output is immediately written low when the condition is met, instead of waiting the variable amount of time from when the condition is met in the program, and the scan reaches the point in which it writes to the outputs.

The second thing to note in this interrupt is contained within the second network. Note that in this network, a global bit is set high. The reason that this is necessary is that depending on when this interrupt is triggered, logic in the main code may overwrite the peripheral write.

To avoid this, the output is buffered by this global bit. Whenever the output would be written, it is preceded by a normally closed gate tied to this global variable. This ensures that if this interrupt is triggered, there is no way the output can be written high unless the status bit is written low again.

One last important thing to note is that this status bit is only written high during this interrupt. The main program writes it low again when it has been high for a quarter of a second.

This is more time than is needed but it ensures that the main logic reaches the point where it would have written this output low by itself. 

Setting the Reference Point for the High-Speed Counter

Now that the interrupt has been configured, the reference point for the interrupt must be set in the main program. This is done by using the CTRL_HSC function block.

For this implementation, there are three crucial inputs.

1. The first is the HSC input. Pass the hardware ID to this input to connect this block to the desired counter. The IDs for the high-speed counters can be found in PLC Tags > System Constants.
    
2. The next input of importance is the NEW_RV input. This is the value the counter will use as a reference to trigger the interrupt. It is important to note that this input is a Dint data type, so some conversions may be necessary. In this situation, the stop position was being tracked in mm as a real. To convert it the desired position it was first divided by a pre-calculated mm per count, and the result of that was converted into a Dint. This Dint value can then be passed to the NEW_RV input of the CTRL_HSC block.
   
   
    

   

3. The last input of importance for this application is the RV input. This is a Boolean input that sets the counter’s reference value whenever it is set to high. The program can constantly be updating the reference value passed to this block, but that value will only be set if this RV input is high.

Conclusion

This tutorial is not an overly complicated example of how to use a high-speed counter’s reference interrupt, but it shows some key details and methods needed to write to PLC outputs peripherally. I hope that the information presented here will be helpful in your future endeavors.

Learn more about DMC’s Siemens S7 PLC Programming services. Or, contact us to get started on a project today.

The post Using a High-Speed Counter’s Hardware Interrupt to Peripherally Write to an Output on a Siemens 1200 PLC appeared first on DMC, Inc..