Technical Article

Applications of Data Structures and Data Types

September 05, 2020 by David Peterson

This article discusses structure data types, structure tags, and various applications of user-defined structures.

One type of data exists only within the scope of a PLC system. However, it might be more appropriate to refer to it as a collection of different data types under a single name, all to perform a specific function. 


Structure Data Types

Inside a PLC, data tags are the addresses and memory storage locations separated into different functions. Inputs and outputs usually consist of boolean tags, which can only support on/off signals. More complex analog signals are floating-point real decimal tags. Calculations and processes often use whole number integers of various sizes.

Aside from these basic data tags, there are very few others required to handle PLC-controlled processes. A few other data types exist, but these usually consist of groupings of these already existing basic data types.


A diagram of types of data structures. Image courtesy of Sri Venkateswara College of Engineering.


One of the more confusing data types is the 'Structure' type tag. It can be incredibly confusing because you can define what it is and when you should use it with every other data type. With structure type tags, they can look entirely different between uses, and those uses can be widely varied. 


Definition of a Structure Tag

A structure tag is a collection of tags under a common name. Those tags do not have the be the same type, making these structures different from array tags. They can be used for related sets of data both internally to the PLC (memory only) or relating to I/O data sets. Finally, they might refer to information passed between networked devices.

This is useful in scenarios when a whole variety of tags related to one part of the process, such as a counter or timer. Let's examine specifically the timer, which always contains a bare minimum of several informational pieces regardless of which type of timer used in the program, or what its purpose might be:


  • A predetermined time, often in ms, which determines how long the timer is supposed to run. This is usually a double integer since a standard integer could only last up to about 65 seconds.
  • A current time which increments as the timer runs. Also usually a double integer.
  • A boolean variable indicates when the current timing process has ended.
  • Some other boolean variables sometimes indicate when the timer is running, or when the timer has not yet completed the timing cycle.


This combination of various data types would all be given the same name; we might call it 'Timer 1'. If we need to reference a specific piece of data or a tag within the timer structure scope such as the boolean indicating the end of the process, we might call it Timer 1.DN. Some PLC programming software suites do not allow direct access to these tags. Instead, they require the programmer to link those internal tags to existing tags of the same data type. So although we may not see each of the individual tags within this structure tag, they are still there.

A few of the other commonly used built-in structure tags are counters, motor drive blocks, math instructions (which contain at least one input and destination tag), and further communication instructions (Ethernet or Modbus read/write, for example).

The final type of structure tag is usually called 'User Defined' structure. This means that the user has a particular block of related information that is not already addressed in the built-in structures' scope. This is not always seen in a program, leading to some programmers who are integrally familiar with user-defined structures, and other programmers who have never seen them before.


Applications of User-Defined Structures

After a PLC programmer has the right circumstances to create their structure tag, it makes perfect sense. Until that time, it can be challenging to imagine how they are created and used.

Imagine a process consisting of 10 identical equipment lines, each with perhaps five proximity switches and driven by a networked VFD. You want to retrieve and store the sensor data and the motor current and frequency from all 10 lines so that you may display the data on an HMI or perform an action with the data at any time.

It would be possible to create 50 boolean tags and 20 integers or decimal tags for the motor data. The problem with this strategy is the sheer number of tags filling the tag database, and if the tags are logically named, they may not appear in the same alphabetical location in the tag listing. Your project organization will be a nightmare.

A relatively simple user-defined structure tag can create instead, containing an array of 10 booleans and two decimals. Perhaps these are called 'prox[1]' through 'prox[10]' and 'Motor_Amps / Hz'. Now the only remaining step is to create 10 of these user-defined structure tags.

The same total number of tags will still exist - you didn't minimize the amount of data. However, for the sake of organization and data manipulation, the structure tags will make life easier. This can simplify processes such as importing and exporting tag lists, displaying data on an HMI, and moving (copying) data from one structure tag to another. If they are of the same type, this is a single move, rather than 12 moves as we would need in our example if they were separate tags.

Structure-type tags are certainly not the most familiar type of data, but they are certainly not uncommon since they are used to construct counters and timers. The ability to create unique structure tags can reduce programming frustration and consolidate data to perform actions using far fewer commands than if we only had access to individual tags.