The Arduino Opta PLC is compatible with the Schneider Electric Modicon M171 and M172 series
As a DigiKey application engineer, I have the pleasure of working with a wide variety of hardware and software. My tasks include responding directly to customer inquiries on this technical forum as well as proactive writing about topics of future interest to DigiKey customers. Occasionally, I encounter surprising results such as the compatibility between the Arduino Opta and the Schneider Electric Modicon M171 and M172 Programmable Logic Controllers (PLC).
This engineering brief explores the software commonalities between the Arduino PLC IDE for the Opta and the Schneider Electric EcoStructure Machine Expert – HVAC for the Modicon M171 and 172. We will see that the IDEs share a common structure allowing IEC 61131-3 Program Organizational Units (POUs) to be shared across platforms. The synergy allows the programmer to easily transition between devices such as the Opta WiFi and devices such as Modicon TM172PDG28RI pictured in Figure 1.
Figure 1: Picture of the Arduino Opta WiFi and a Schneider Modicon M172 with integral display. The respective IDEs share a common structure allowing cross-family sharing of POUs (software components).
What is an IEC61131-3 Program Organizational Unit (POU)?
The IEC 61131-3 standard defines common PLC programming languages including Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST), Instruction List (IL), and Sequential Function Chart (SFC). This standard also describes how the programs are organized. These Program Organizational Units (POUs) are the building blocks for a PLC project. They consist of programs, function blocks, and User Defined Function Blocks (UDFBs).
Tech Tip: The term “program” requires additional explanation in the context of the IEC 61131-3 standard. In one case we are describing the totality of the software installed on the PLC. This is likely composed of many individual POUs. In another instance we are describing a specific type of POU. It’s relatively easy to determine the difference by looking for contextual clues. For example, all of the components in Figure 2 are used to create the PLC’s program. This program is composed of individual POUs such as a the programs prgCtrl and prgComms.
Figure 2: Block diagram showing the namespace for IEC 61131-3 software. The three types of POUs are seen on the right-hand side including programs, functions, and user defined function blocks.
Built-in vs user provided functions
All modern PLC development tools contain predefined functions. We can expect to find a variety of graphical blocks for LD and FBD with text-based counterparts for those programmers who prefer to write in ST. Examples include timers, counters, and trigonometric functions.
The PLC programmer stitches together a PLC application by using these built in functions along with POUs of their own design. In Figure 2 we see that the user has written two programs including prgCtrl and prgComms. As part of a hierarchical design process, these programs then instantiate a variety of user written function blocks and functions. In total, there are seven POUs on Figure 2.
Tech Tip: The User Defined Function Block (UDFB) and the user function are closely related POUs. The difference is that the UDFB contains memory and will return different valued depending on the state (past interactions) whereas a function will always return the same value for a given set of inputs.
What is the purpose of user written functions and function blocks?
Each PLC manufacturer provides a solid foundation of built-in functions applicable to a wide variety of PLC applications. However, it is up to the user to code POUs for their given application. For example, the programmer may construct a function to calculate total gallons for a given tank diameter and liquid height. The programmer may also construct a UDFB to encapsulate the operations of a three-phase motor starter / contactor. A UDFB with its associated memory is required to track the state of the physical mechanism.
In all cases, the functions and UDFBs are the programmer’s intellectual property. When properly written they form a library for commonly encountered control problems. This allows an experienced PLC programmer to quickly assemble an application by leveraging a body of well written and tested POUs.
Tech Tip: PLC programmers can benefit from the language used by Object Oriented Programming (OOP). While the IEC 61131-3 is not written with OOP functionality, the PLC programmer can adopt OOP principles. For example, the three-phase motor starter is a physical device that a PLC may control and monitor. With careful software design, the programmer can encapsulate the functionality of the motor starter into a single UDFB. The object then serves as an abstraction of the real world. The PLC programmer collects these objects into a library speeding up the programming process while simultaneously providing a common structure facilitating technician troubleshooting and allowing fast future modifications.
What software components may be shared between the Opta and the Modicon?
Now that we have a solid understanding of the IEC 61131-3 POUs, we can identify what can and cannot be shared between the Arduino Opta and the Schneider M171 /172. As a simple statement, the user written POUs may be shared including programs, functions and UDFBs. As implied in Figure 2, we must use a consistent naming scheme with the global variables. This is essential as the global variables are the link between the figure 2 left-hand hardware dependency and the right-hand hardware independence.
Please note that a full compatibility test for all types and situations has not been conducted. However, as will be demonstrated, there is good reason to believe most POUs will transfer. A significant clue is the overlap between the Opta’s and M171/ M172’s built-in functions. The TON is an example of a built-in POU that is common to both suites. Consequently, a user program or UFDB that incorporates a timer is expected to be portable.
Tech Tip: The Schneider Electric term “Modicon” refers to a large collection of PLCs ranging from the Pico TM221C16R to the powerhouse TM262M35MESS8T. The name also encompasses a series of controllers designed for commercial machines known as the Modicon M171/M172 series. This commonality with the Arduino Opta is limited to the M171/172 series.
Why are global variable essential for portable programs?
Students of computer science are instructed to avoid global variables. This is excellent advice as global variables can complicate the program. They are also notoriously difficult to troubleshoot especially when a program spans many pages or when a program is spread across multiple .h and .cpp files.
Global variables are unavoidable in the IEC 61131-3 environment. Even the simplest program for the Opta of 171/172 where a single pushbutton is used to control a single output pin requires two global variables. The is true as the screw terminal I/O are mapped to global variables that are then accessible by any program (little POU) in the PLC code structure.
Looking back to Figure 2, we recognize that a greater PLC program is composed of a hardware dependent configuration (left-hand side) and collection of hardware independent POUs (right-hand side) that includes built-in POUs along with those written by the user. As suggested in Figure 2, the two sides of the PLC program communicate through these global variables.
This is a question of mapping hardware to specific variable names. The Opta and M171/M172 perform this using the mechanism show in Figure 3. For example, we see that the Opta inputs I1 and I2 are mapped to gxPB1 and gxPB2 respectively. Likewise, we see that the M172 DIL1 and DIL2 inputs are also mapped to gxPB1 and gxPB2.
This is an essential consideration that bears repeating. We can have different hardware but common global variable names. These common names are essential for portable POUs such a prgCtrl or prgComms. This strategy is an abstraction layer that provide the figure 2 right-hand POUs a common interface.
Tech Tip: Use of Hungarian notation is highly recommended for PLC programming in a tag-based environment such as featured in this engineering brief. With this notation we prefix each variable with the data type such as “x” for Boolean. We also include the “g” prefix to indicate that a variable is global in scope. It has been my experience as an educator that these little details can save considerable development and troubleshooting time as the PLC programmer must explicitly consider the scope and type of each variable. It’s very easy to see things that don’t belong. Please see PLCopen Coding Guidelines for additional suggests for PLC programming.
Figure 3: Hardware specific mapping to global variables for gxPB1 and gxPB2 for Arduino (top) and Schneider (bottom).
How are the POUs transferred across platforms?
Let’s start by building a simple POU such as prgCtrl shown in Figure 4. This is a very simple program that monitors two pushbuttons. The panel lamp will turn on if gxPB2 is pressed and gxPB1 has been active for at least 1 second. In this example we have hard coded the one second delay into a TON timer. Recall that the Opta’s timers tick at the 1 ms rate. When the programmed Time (PT) is set to 1000 we have a 1 second delay.
Once this program is constructed and tested, we can export it to a library. To do so we right click on the POU and select “Export to library.” This will create a *.plclib file at a location of your choosing. Note that many POUs including programs, function and function blocks may be placed into a common a *.plclib file. This is highly desirable as your POUs are highly portable.
Once a library file is created you can use it for your next Opta project. To import a POU, select “Import objects” and then select the desired POU(s) from the library. This is a very easy process with identification of POU version and the ability to add or overwrite existing POUs in you project tree.
Figure 4: Arduino Opta implementation of the shared prgCtrl POU.
Opta and Modicon cross functionality
The Opta and the M171/M172 appear to be built on a common platform. For example, a close inspection of Figure 4 (Arduino) and Figure 5 (Schneider) shows a common program tree. We also see the same element in the prgCtrl POU.
These are in fact the same POU! The library process, internal to a given environment, is the same as the process across platforms.
In this example, prgCtrl was written in the Arduino PLC IDE, passed to a library, and then imported into the Schneider Electric EcoStructure Machine Expert – HVAC. Please try for yourself as the featured POU (library) may be downloaded here:
POUDemo.plclib (2.1 KB)
Figure 5: Modicon M172 implementation of the shared prgCtrol POU.
What are the implications of the cross-platform compatibility?
Personally, I see this as a delightful synergy. It’s one thing to say that a PLC may be programmed in all IEC 61131-3 languages. It’s another story when the individual POUs may be transferred fully intact across multiple platforms. There is great potential for the community to build and share a library of POUs. The large number of related devices provides incentive for community involvement as it is no longer hardware specific. In some respects, this is like programming in C as we now have an effective abstraction layer providing the highly desirable hardware independence.
This is beneficial from an education standpoint. As I have previously argued, Arduino has a nearly two-decade track record for setting the standard in microcontroller development. Arduino is well known across higher education to technicians, technologists, and engineers with a healthy inclusion of electrical and mechanical oriented students.
Recall that the Opta is uniquely poised to leverage this existing microcontroller user base as it may be programmed from the traditional Arduino IDE as well as the new Arduino PLC IDE with all the IEC 61131-3 languages. From an education standpoint, this flexibility provides multiple entry points into PLC programming. It also facilitates parallel coding assignments allowing students to explore the strengths and challenges of the various languages IEC 61131-3 languages alongside the traditional Arduino IDE.
With this discovered interoperability, all those education benefits and goodwill are immediately transferred to Schneider Modicon M171 and M172 products.
Returning to the fundamental POU building blocks, I envision a community of educators and other vested partners building and maintaining libraries of POUs for specific applications. As previously mentioned, many of these could take the form of OOP like objects to interface with and control the PLC connect hardware. There is great potential to lower the accessibility threshold and therefore increase PLC programming to a larger pool of programmers.
Please share your comments, questions, and concerns regarding PLC programming and education. Also, there may be other, yet to be identified PLCs, that share this common interface. Thank you in advance for expanding the list.
Best wishes,
APDahlen
Return to the Industrial Control and Automation Index
About the author
Aaron Dahlen, LCDR USCG (Ret.), serves as an application engineer at DigiKey. He has a unique electronics and automation foundation built over a 27-year military career as a technician and engineer which was further enhanced by 12 years of teaching (interwoven). With an MSEE degree from Minnesota State University, Mankato, Dahlen has taught in an ABET accredited EE program, served as the program coordinator for an EET program, and taught component-level repair to military electronics technicians. Dahlen has returned to his Northern Minnesota home and thoroughly enjoys researching and writing articles such as this. LinkedIn | Aaron Dahlen - Application Engineer - DigiKey