Makers Blog Archive

Coding Diary: How to make your own PLCnext Store application

PLCnext Team 12 July 2019 min. read
294 views 0 comments
Coding Diary

In 10 episodes we show how to code an app for PLCnext Technology and deploy it via the PLCnext Store. Peek into the coder’s diary where he tells all about building the “MQTT on paho” app that’s already available at the PLCnext Store.

All code examples to these instructions are available at GitHub.

Schedule for 10 days of coding

Already online:

playlist with all videos in one frame is available here.

Day-by-day videos

Duration: 5m:13s

Please accept marketing-cookies to watch this video.

On Day 1, we look a bit deeper into the MQTT protocol and how it would fit into the PLCnext Technology system architecture. This is important to find the best kind of component to program for our C++ application because each of the three kinds has its advantages for different purposes. After that we consider how to use the Eclipse paho MQTT client as an open source library for our application.

Duration: 10m:50s

Please accept marketing-cookies to watch this video.

On Day 2, we pull the open source code of the Eclipse™ paho project from its GitHub repository to our host machine running on Linux Debian. We will do that for both the C and C++ library, as explained on Day 1.
For that we set up a task in Visual Studio Code, so we can later on build the app for different target controllers. After that, we check that the code is working fine on our PLC by deploying a sample application from the paho library to our PLC and running it with the public MQTT broker at

Duration: 8m:07s

Please accept marketing-cookies to watch this video.

On Day 3, we create a Function Extension component for PLCnext Technology based on the paho MQTT client we pulled from the Eclipse paho project’s GitHub repository on Day 2. To do that, we use a template installed by the PLCnext CLI that’s part of the toolchain provided by Phoenix Contact free of charge. The PLCnext CLI will create the C++ code for our PLCnext component, and after that, all the intermediate and configuration files for this project.
But from here on we proceed without the help of the PLCnext CLI and set up a task in Visual Studio Code to deploy the code to the PLC manually, start the component in the Shared Object library and create the Automation Component Framework (ACF) config file. Finally, we check our code with a simple debug message.

Duration: 06m:07s

Please accept marketing-cookies to watch this video.

On Day 4, we convert the PLM component that was generated by the PLCnext CLI by default to a pure Automation Component Framework (ACF) component that doesn’t depend on the real-time context. It’s also a nice way to revisit and distinguish the different types of C++ programs for the PLCnext Runtime System that are explained in the preliminary video. For that we strip our code down to what’s necessary for an ACF component, and rebuild our barebone code to see if all still works fine. And if it does we can call it a day – because we have already made good progress on our project, and we have earned a nice summer’s day at the beach before things get serious (again).

Duration: 12m:19s

Please accept marketing-cookies to watch this video.

On Day 5, we turn our project into an RSC Service and publish that service via the Service Manager to make it available to other components on the PLCnext Control. We use CMake to link the RSC Service to the paho MQTT client library. To understand the methods that our RSC Service will expose, we refer to the paho MQTT client documentation that you can find in the Eclipse paho documentation.
This episode will take a while so better prepare yourself with a cold or hot drink and some sweets.

Duration: 03m:28s

Please accept marketing-cookies to watch this video.

On Day 6, we won’t be looking at any code. Instead of that we will just look at some of the more interesting design elements that were used when completing the MQTT client for PLCnext Control.
We’re not finished yet, there’s a second task to do before we can use the component in our PLCnext Control. But cheer up – the hardest parts are already done, and today we will be home early.

Duration: 06m:10s

Please accept marketing-cookies to watch this video.

On Day 7, we create a new RSC client component to provide a crucial functionality to our MQTT client for industrial automation purposes: sending and receiving data through the Global Data Space (GDS) of the PLCnext Technology.
For this we explain how the MqttGdsConnector component is made – source code is available at GitHub.

Duration: 03m:04s

Please accept marketing-cookies to watch this video.

On Day 8, we add a Worker Thread to the MqttGdsConnector component that we created last time. That is because, unlike programs running on PLCnext Technology, a component cannot be scheduled on a cyclic ESM task. For this we explain what to put into the MqttGdsConnector component code, and where to do it. All source code is available at GitHub.
So that’s a quite short lesson today! Once you know how to let the WorkerThread do all the boring, repetetive work for you, you’re free to go and hang out with friends…
Assumed you’re interested in using WorkerThreads elsewhere in PLCnext programming, you might take a look at this C++ example in our GitHub CppExamples project, too.

Duration: 05m:07s

Please accept marketing-cookies to watch this video.

On Day 9, we set up a JSON file based on an example schema for configuration of all MQTT related communication in our MqttGdsConnector component. There’s much to specify in our chatty component: What GDS variables are we reading? What topics are we publishing to, and on which MQTT Broker? And conversely, which topics have we subscribed to? And where do we write that incoming message data in the Global Data Space?
A JSON file is a convenient way to put settings into our code, and so we provide a suitable JSON schema and an example that uses two Open Source projects:
JSON parser and a JSON validator. All the MQTT and GDS variable settings may change on occasion, so we better avoid a hard-coded path and name for the JSON file in our C++ code, and use another nice feature of our ACF configuration file. When we tell the PLCnext Runtime to create an instance of our component we can also pass in the path to a “settings” file and its name, which now would be those of our user configuration JSON file. Users could change this setting to point to whatever settings file they like in whatever location they want on the PLC.
All source code is available at GitHub.

Duration: 08m:07s

Please accept marketing-cookies to watch this video.

On Day 10, we package our two components – the MqttClient RSC service and the MqttGdsConnector that uses the service – into a single Function Extension app. To deploy this app via the PLCnext Store, there are some further steps to go but you will see how convenient this way is for both the contributor and the user.
We walk you through the entire process of preparing, packaging, uploading the app, and afterwards installing the app like users will do, directly from the PLCnext Store to their PLC.

All-in-one playlist

Once started, the videos in this playlist will play one after the other.
To choose a specific video in the playlist, do this:

  • Click on the video to activate the YouTube embedding frame
  • Click on the “list” icon at the upper edge (see picture)
  • From the pop-up list, select a video
  • Close the list at the “X” in the upper-right corner
Find the playlist icon

You can also use YouTube to switch to fullscreen mode, show subtitles, or change the resolution.

Duration: 1h:09m


The Makers Blog shows applications and user stories of community members that are not tested or reviewed by Phoenix Contact. Use them at your own risk.


Please login/register to comment


Leave a Reply

Never miss a new article
Sign up for the newsletter
Never miss news about PLCnext Technology
Get interesting content via newsletter four times a year
Receive exclusive information before all other users