PLC written in C++

[Peter Nachtwey]

I finished a large project for an STM32 embedded processor last year programmed in C++ using Visual Studio 2019 with the Visual GDB debugger plugin.

GDB, yuk but at least you had a debugger.

It went very well and I'd recommend the same tool stack to anyone doing something similar.

I wouldn't. There are nice interfaces to the GDB debugger that make GDB tolerable.

As for the why? People are usually most productive in the language/development system that they're most familiar with. VS is probably overkill for most PLC projects though.

I find that moving from one language to the next is pretty easy. It is the debugging tools that are critical and that is implementation dependent not language dependent.

 

[ojz0r]

As for the why? People are usually most productive in the language/development system that they're most familiar with. VS is probably overkill for most PLC projects though.

Its not always about the rate you write lines of code, factors like maintainability and troubleshooting by clients are usually higher priority than spitting out code as fast as you can.

 

[busarider29]

This is where are solution is superior.
We use ST in steps or states for our motion control. We don't have break points for the user. We have done two things to make debugging easier for the customer and for us/me and here is why.

In my respectful opinion, it is not a "superior solution" in terms of the RMC Tools ST debugging tools, nor is it easier. For instance, what do I have to do if I want to step through each line of ST code in a RMC Tools program? Well, in order for me to do that, I would have to add a separate step for each line, actually block, of code, then set some variable in order for the program to go to the next step (block of code). So if I have say 30 blocks of ST code I want to step through, well then I need 30 steps in my RMC Tools program. Then, once I've debugged it all, I need to go back and delete all those "debugging" steps and consolidate the ST code into a lesser number of steps. That is not what I call "easier" debugging. Unless I've been missing some debugging feature in RMC Tools this whole time, that is how it would have to be done. Furthermore as stated, I cannot (that I know of) step through each line of ST code, line by line, like I would be able to if given the functionality of adding break points at each line of code. That is not what I consider "superior" debugging. There are work-arounds to having steps for each block of code. One is to use a CASE statement. But even then, you still cannot step through each line, line by line. You need the functionality of setting break points for that, which of course RMC Tools does not have.

Break points are a law suit waiting to happen. If an actuator is moving with 50% output and a break point is reached, the output will still be set at 50% and crash into the end if there is one. Originally we used electronic simulators and they would do just that.

Yep, that's what's going to happen if you set a break point at the wrong time, in the wrong place! How is this any different than forcing outputs on/off, online edits, etc?? One could cause the same machine crashes using those common PLC functionalities, could they not??

The ability to set break points in TwinCAT is just another debugger tool. The PLC developer can use it, or they can leave it. It's not really essential but it is another option, and who doesn't appreciate having more options?? It does however make it easier at times to debug, depending of course on the complexity of the programming task. My advice is to use break points with caution, and mitigate using the tool on a live, working machine. Just my opinion.

For the customer, and us, we added what we call an event log. It will log EVERYTHING or just what you want it to log at the motion controller scan rate. We can also set conditions so that the graphing and log will stop recording when an event is triggered showing what happened before and what happened after. This is like the old time data analyzers.
NO PLCs have this function. This feature is good for capturing rare events that happen every few days so you don't want to watch the machine all the time.

"No PLCs have this function".

I'm going to respectfully disagree again because its just not a correct statement. The Beckhoff PLCs do indeed have this very same functionality. I know because we use it everyday. It's called TwinCAT Analytics Logger. I can log every single variable and/or piece of data in the PLC, or just what I want, cycle-synchronous, each data point time-stamped down to the single digit nS on some data (over-sampling terminals for example). The logger can be set on a ring buffer set to whatever time I specify. Recorded data can be saved to a local drive or pushed out to the cloud. The only limitation to data capacity and how much it can record is the data storage capacity of the drive/cloud.

Using the TwinCAT Scope, we too can set conditions so that the logging and graphing will stop when an event/s is triggered. We use this tool all the time for that very reason, so that we can view events that happened before the triggered event. In our case, a part that failed in a testing machine. When the part under test fails, we can then look at the data and graph to determine why the part failed and look at the data trends over a period of days, and sometimes weeks. We can go as far back in time as we want really, since we record it all to the cloud. I also use the Scope Tool for debugging a PLC program. Again, another tool to be used for PLC program debugging!!

Another neat feature is to graph computed data on a plot but what is common is to plot the the step the machine is on in the plot so one can see when a transition is made from one step to another. Then one can look at the time in the plot and go to the event log and see what caused it.

I'll have to remember to use that feature, as far as plotting the step. That could be useful. I usually just search through the event log.

The language one programs in is not as important as the available debugging tools.

Yet you don't appear to have as many debugging tools as what's available in TwinCAT, yet claim RMC Tools is 'superior' in debugging tools? Did I miss something somewhere?

 

[Peter Nachtwey]

In my respectful opinion, it is not a "superior solution" in terms of the RMC Tools ST debugging tools, nor is it easier. For instance, what do I have to do if I want to step through each line of ST code in a RMC Tools program?

Stepping through code is like hitting a break point after each instruction. This is dangerous when debugging motion programs because the outputs are still on.

Well, in order for me to do that, I would have to add a separate step for each line, actually block, of code, then set some variable in order for the program to go to the next step (block of code). So if I have say 30 blocks of ST code I want to step through, well then I need 30 steps in my RMC Tools program.

Or you could look in the event log to see what happened.

Then, once I've debugged it all, I need to go back and delete all those "debugging" steps and consolidate the ST code into a lesser number of steps. That is not what I call "easier" debugging.

Again, if you want you can see everything in the event log. I usually don't so if I am only interested in a couple of variables I do use LOG_EVENT to log a few variables. I do this so the event log doesn't get clutter with stuff I don't want to see.

Unless I've been missing some debugging feature in RMC Tools this whole time, that is how it would have to be done.

Look at the even log. Right click and you can see all the options.

Furthermore as stated, I cannot (that I know of) step through each line of ST code, line by line, like I would be able to if given the functionality of adding break points at each line of code.

Single stepping is not allowed for safety reasons.

That is not what I consider "superior" debugging. There are work-arounds to having steps for each block of code. One is to use a CASE statement. But even then, you still cannot step through each line, line by line. You need the functionality of setting break points for that, which of course RMC Tools does not have.

Superior debugging should be safe first. How can a PLC check for safety conditions if it is stopped at a break point?
You are comparing industrial debugging with debugging using Visual Studio or similar.
Again, look at the event log options. All commands and results of calculations can be seen there in addition to when the programs move from step to step. Also, you can plot data using the plot manager.

Yep, that's what's going to happen if you set a break point at the wrong time, in the wrong place!

That doesn't bother you?

How is this any different than forcing outputs on/off, online edits, etc?? One could cause the same machine crashes using those common PLC functionalities, could they not??

It is easier to keep track of just one output. Hitting a break point freezes everything. The two are not the same.

The ability to set break points in TwinCAT is just another debugger tool. The PLC developer can use it, or they can leave it. It's not really essential but it is another option, and who doesn't appreciate having more options??

I wonder how many people use break points while actually running? If you want options then program in C or C++.

"No PLCs have this function".
I'm going to respectfully disagree again because its just not a correct statement. The Beckhoff PLCs do indeed have this very same functionality. I know because we use it everyday. It's called TwinCAT Analytics Logger. I can log every single variable and/or piece of data in the PLC, or just what I want, cycle-synchronous, each data point time-stamped down to the single digit nS on some data (over-sampling terminals for example). The logger can be set on a ring buffer set to whatever time I specify. Recorded data can be saved to a local drive or pushed out to the cloud. The only limitation to data capacity and how much it can record is the data storage capacity of the drive/cloud.

Using the TwinCAT Scope, we too can set conditions so that the logging and graphing will stop when an event/s is triggered. We use this tool all the time for that very reason, so that we can view events that happened before the triggered event. In our case, a part that failed in a testing machine. When the part under test fails, we can then look at the data and graph to determine why the part failed and look at the data trends over a period of days, and sometimes weeks. We can go as far back in time as we want really, since we record it all to the cloud. I also use the Scope Tool for debugging a PLC program. Again, another tool to be used for PLC program debugging!!

I'll have to remember to use that feature, as far as plotting the step. That could be useful. I usually just search through the event log.

You can plot I/O and the results of calculations too.

Yet you don't appear to have as many debugging tools as what's available in TwinCAT, yet claim RMC Tools is 'superior' in debugging tools? Did I miss something somewhere?

We only seem to be missing the break points but that is on purpose.

You need to look at the event log options.

 

[TurpoUrpo]

Stepping through code is like hitting a break point after each instruction. This is dangerous when debugging motion programs because the outputs are still on.

Or you could look in the event log to see what happened.

Again, if you want you can see everything in the event log. I usually don't so if I am only interested in a couple of variables I do use LOG_EVENT to log a few variables. I do this so the event log doesn't get clutter with stuff I don't want to see.

Look at the even log. Right click and you can see all the options.

Single stepping is not allowed for safety reasons.

Superior debugging should be safe first. How can a PLC check for safety conditions if it is stopped at a break point?
You are comparing industrial debugging with debugging using Visual Studio or similar.
Again, look at the event log options. All commands and results of calculations can be seen there in addition to when the programs move from step to step. Also, you can plot data using the plot manager.

That doesn't bother you?

It is easier to keep track of just one output. Hitting a break point freezes everything. The two are not the same.

I wonder how many people use break points while actually running? If you want options then program in C or C++.

"No PLCs have this function".
I'm going to respectfully disagree again because its just not a correct statement. The Beckhoff PLCs do indeed have this very same functionality. I know because we use it everyday. It's called TwinCAT Analytics Logger. I can log every single variable and/or piece of data in the PLC, or just what I want, cycle-synchronous, each data point time-stamped down to the single digit nS on some data (over-sampling terminals for example). The logger can be set on a ring buffer set to whatever time I specify. Recorded data can be saved to a local drive or pushed out to the cloud. The only limitation to data capacity and how much it can record is the data storage capacity of the drive/cloud.

Using the TwinCAT Scope, we too can set conditions so that the logging and graphing will stop when an event/s is triggered. We use this tool all the time for that very reason, so that we can view events that happened before the triggered event. In our case, a part that failed in a testing machine. When the part under test fails, we can then look at the data and graph to determine why the part failed and look at the data trends over a period of days, and sometimes weeks. We can go as far back in time as we want really, since we record it all to the cloud. I also use the Scope Tool for debugging a PLC program. Again, another tool to be used for PLC program debugging!!

You can plot I/O and the results of calculations too.

We only seem to be missing the break points but that is on purpose.

You need to look at the event log options.

I develop mainly with tc3 now. I see breakpoints to be very useful. Of course you need to know what you are doing, but those are 99,999% of time used only in simulation and not during hw runtime. To be honest, I would need to check what is the status of outputs when breakpoint is reached within live system as its quite long time ago that I used one live (with machine we were developing, not during production).

I have not used RMC tools so don't know the abilities of it for simulation, is there some and if there are, why would not breakpoints be possibility during simulation?

 

[OysterMan]

Ive heard about Comfile Moacon PLCs made by a company in northern Virginia. They look pretty nifty to play around with. The trouble is that you will pretty much never see them used at most factories. I could only see it being used for specialty applications.
http://comfiletech.com/pages/embedded-controller/moacon.html
ARM was bought up by nvidia so this may become more widespread in the future. Ive been thinking about picking one up just for fun..

 

[drbitboy]

Ive heard about Comfile Moacon PLCs made by a company in northern Virginia. They look pretty nifty to play around with....

wow, here is something from that page:

The API is concise and simple. The following sample shows how to toggle a digital output every 100 milliseconds.

[COLOR=#0000e1][B]void[/B][/COLOR] cmain[COLOR=#808030]([/COLOR][COLOR=#0000e1][B]void[/B][/COLOR][COLOR=#808030])[/COLOR] 
{
    portInit[COLOR=#808030]([/COLOR][COLOR=#0080c0]1[/COLOR][COLOR=#808030],[/COLOR][COLOR=#0080c0]0[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// initialize port 1 for output[/COLOR]
    [COLOR=#0000e1][B]while[/B][/COLOR][COLOR=#808030]([/COLOR][COLOR=#0080c0]1[/COLOR][COLOR=#808030])[/COLOR]           [COLOR=#32aa32]// loop forever[/COLOR]
    {
        portOn[COLOR=#808030]([/COLOR][COLOR=#0080c0]12[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// Pin 12 on[/COLOR]
        delay[COLOR=#808030]([/COLOR][COLOR=#0080c0]100[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// wait 100 milliseconds[/COLOR]
        portOff[COLOR=#808030]([/COLOR][COLOR=#0080c0]12[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]    [COLOR=#32aa32]// Pin 12 off[/COLOR]
        delay[COLOR=#808030]([/COLOR][COLOR=#0080c0]100[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// wait 100 milliseconds[/COLOR]
     }
}

Concise? yes.


Powerful? yes.


Simple? ... uhhh, with the programmer defining the continuous scan loop, and free to put delays in it? How is that interrupted e.g. to go back to program mode? Where is the watchdog timeout?


This is the definition of a technical debt generator; like @OysterMan said, specialty applications only.


"Some assembly required "

 

[Peter Nachtwey]

I have not used RMC tools so don't know the abilities of it for simulation, is there some and if there are, why would not breakpoints be possibility during simulation?

This would be safe since we disable all outputs in simulate mode. Now what would you expect to see? Just variables?


Also, single stepping requires modify the code. What it does is that it removes the byte or word at the the next instruction or line of code and replaces it with a break point instruction. When going to the next opcode or line it must replace the break point instruction with the old opcode and then save the next opcode and place a break point there.


That is doable but it is much easier to do on a PC than an embedded processor. Basically all the code to do that would need to be added to the firmware or at least downloaded to free ram some place because the debugger must work on the target.

 

[gas]

I’m 77 and have been around maintenance for a few years. I also had a tool and die shop that designed and built small machines for the secondary plastic industry. I now teach maintenance folks.


Everyone here, except Ron of course, has missed why they get paid. The ONLY reason you exist in any commercial enterprise is to put money in someone’s pocket. The customer doesn’t care how efficient the designer, machinist, programmer is. He wants a reliable stream of cash from that machine. He is not happy when he has to wait for someone to come and get his money streaming again.


I told my employees and students “manufacturing is like bowling….if you miss that spare that opportunity is gone forever.”


If you have to use a clunkly, old fashioned program but the maintenance folks can read it then put in the extra time and do it. Always remember…It’s all about the money!
I do understand that this is not possible all the time. But customers are not happy when they miss 4 or 5 shifts at hundreds or more an hour.

 

[alive15]

Well said gas, well said. Do whichever option is easier for your maintenance team to solve in the future or for someone to work on it.

 

[janner_10]

Well said gas, well said. Do whichever option is easier for your maintenance team to solve in the future or for someone to work on it.

Yes bUt wOt aBot tHe lAdDER Crowd!!1111

 

[cardosocea]

wow, here is something from that page:

The API is concise and simple. The following sample shows how to toggle a digital output every 100 milliseconds.Concise? yes.

Powerful? yes.

Simple? ... uhhh, with the programmer defining the continuous scan loop, and free to put delays in it? How is that interrupted e.g. to go back to program mode? Where is the watchdog timeout?

This is the definition of a technical debt generator; like @OysterMan said, specialty applications only.
​

This is an Arduino effectively... I'm sure a bunch of the other functions are blocking too, which would catch a lot of people that only ever programmed a PLC. I wouldn't call a platform that sells its functionality with an example of a timing done on a delay (which most likely is just a while loop counting sheep in the background) powerful. I get what they are trying to convey, but if they're to be taken seriously in the controls industry this is a mistake by them.

The ONLY reason you exist in any commercial enterprise is to put money in someone’s pocket. The customer doesn’t care how efficient the designer, machinist, programmer is. He wants a reliable stream of cash from that machine. He is not happy when he has to wait for someone to come and get his money streaming again.

I think you're missing a layer on your own perspective. You're applying this to the end user of the machine, but the supplier of the machine is also in business to put money in his pocket and faster and better development tools enable him to save an awful lot on engineering and testing (which can either be a commercial advantage or translated into higher profit).
Yeah, the guy buying a machine doesn't care so much that you developed it with OOP and with fancy troubleshooting tools, but the supplier of said machine will definitely be looking into those tools to save him a buck or keep him in business against competitors.​

 

[OysterMan]

c programming is like riding a motorcycle, RSLogix is like driving a camper van. lol

 

[Peter Nachtwey]

wow, here is something from that page:

The API is concise and simple. The following sample shows how to toggle a digital output every 100 milliseconds.

[COLOR=#0000e1][B]void[/B][/COLOR] cmain[COLOR=#808030]([/COLOR][COLOR=#0000e1][B]void[/B][/COLOR][COLOR=#808030])[/COLOR] 
{
    portInit[COLOR=#808030]([/COLOR][COLOR=#0080c0]1[/COLOR][COLOR=#808030],[/COLOR][COLOR=#0080c0]0[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// initialize port 1 for output[/COLOR]
    [COLOR=#0000e1][B]while[/B][/COLOR][COLOR=#808030]([/COLOR][COLOR=#0080c0]1[/COLOR][COLOR=#808030])[/COLOR]           [COLOR=#32aa32]// loop forever[/COLOR]
    {
        portOn[COLOR=#808030]([/COLOR][COLOR=#0080c0]12[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// Pin 12 on[/COLOR]
        delay[COLOR=#808030]([/COLOR][COLOR=#0080c0]100[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// wait 100 milliseconds[/COLOR]
        portOff[COLOR=#808030]([/COLOR][COLOR=#0080c0]12[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]    [COLOR=#32aa32]// Pin 12 off[/COLOR]
        delay[COLOR=#808030]([/COLOR][COLOR=#0080c0]100[/COLOR][COLOR=#808030])[/COLOR][COLOR=#32aa32];[/COLOR]     [COLOR=#32aa32]// wait 100 milliseconds[/COLOR]
     }
}

Concise? yes.


Powerful? yes.


Simple? ... uhhh, with the programmer defining the continuous scan loop, and free to put delays in it? How is that interrupted e.g. to go back to program mode? Where is the watchdog timeout?


This is the definition of a technical debt generator; like @OysterMan said, specialty applications only.


"Some assembly required "

I would have jumped on that too. However, I looked further and saw it was Linux based so the delay shouldn't be a hard loop. I gave it a pass. It would be better to say the system is multitasking if it is. If not then you complaint is valid.


The problem I have with the code is that it claims to turn the output on then delay 100 ms. It should say delay AT LEAST 100 ms due to overhead. Eventually all the extra delays from the over head pileup.


It would be better to schedule the task to run every 100 ms based off a 100 ms timer or counting 10 10 interrupts.





We use RT Linux in our systems. I wouldn't call it a PLC. I wouldn't call the Moacon a PLC either. However, that Moacon might fit right in with some of the systems we do.


The article didn't say if it used RT Linux.