PLC written in C++

[HoldenC]

I have been thinking about picking up the P1AM-100 plcs from Automation Direct, and messing around with it.

I took programming languages in college (Python, C++, VB), and I thought it would be interesting to program a PLC that way.

However, I cant seem to find any examples of C++ coding for these units. Does anyone have any experience ?

I would like like simple code that showed how to name I/O, set up timers and counters.

 

[cardosocea]

I know of this guy:
https://community.automationdirect....roller-seadragon-official-v10-release-version
https://www.reddit.com/r/PLC/comments/fwsqli/seadragon_automationdirect_p1ambased_aquarium/

That's how I found out about this product.

Looking up for AutomationDirect on GitHub gets you what you're after.

https://github.com/AutomationDirect

I'm not sure if their libraries are available in the Arduino IDE.

 

[gas]

I'm going to follow this one.

We have a product written in Structured text that calls function blocks written in C++

 

[lfe]

I don't see the sense to use a language created for object-oriented programming (OOP) like C++ or Java in something that doesn't have a class library like a PLC.

By the way I would love to have a PLC with programming based on OOP

Those examples on github from automation direct are written in C, not C++

 

[busarider29]

I have been thinking about picking up the P1AM-100 plcs from Automation Direct, and messing around with it.

I took programming languages in college (Python, C++, VB), and I thought it would be interesting to program a PLC that way.

However, I cant seem to find any examples of C++ coding for these units. Does anyone have any experience ?

I would like like simple code that showed how to name I/O, set up timers and counters.

Beckhoff PLC's can be coded using C++ language specifically if you choose. Of course they can be programmed in IEC-61131 "Structured Text" too, which with your textual based language background, you could pick up in no time. You don't need physical hardware and can program, run and debug the "virtual" PLC right on your local machine. One of the many benefits of the Beckhoff platform.

If you prefer to start with real physical hardware to play with and that's inexpensive, I would recommend a Barth Mini PLC. They can be programmed using the C language in the Arduino IDE. You can also program them using the graphical language in miCon-L.

 

[ndzied1]

CoDeSys does offer some object oriented features.

https://help.codesys.com/webapp/_cds_f_object_oriented_programming;product=codesys;version=3.5.16.0

 

[Peter Nachtwey]

What is the point of writing code in C++ or C?
I/we write code in C and C++ to do embedded programming for motion controllers. The purpose is to provide routines in firmware that can be called by the user. The problem I have with programming in any language is how the code is debugged. C or C++ can be debugged easily when using VS-Code or Visual Studio but these debuggers don't run on embedded systems/firmware.


What should really scare any body doing this is what happens when a C or C++ pointer goes bad?


ST doesn't allow pointers and should sacrifice a little efficiency for checking array indexes to make sure they don't index off the ends of an array.



So why?

 

[busarider29]

What is the point of writing code in C++ or C?

Familiarity I suppose. It's the same reason why LD programmers pretty much always use LD. They like it and are familiar with it. Past that, I don't know.

I/we write code in C and C++ to do embedded programming for motion controllers. The purpose is to provide routines in firmware that can be called by the user. The problem I have with programming in any language is how the code is debugged. C or C++ can be debugged easily when using VS-Code or Visual Studio but these debuggers don't run on embedded systems/firmware.

I suppose it depends on the PLC platform used and the programming software(??). Because TwinCAT uses Visual Studio as it's IDE and programming environment, the C++ PLC code is easily debugged in the programming environment. Set some break-points and debug away. I've never used C++ programming in TwinCAT, but that is my assumption. I know you can set break points and debug a ST program in TwinCAT (I do it all the time), so I'm sure it's just the same in a C++ PLC program. I don't know of any other PLC platforms that allow programming in C++, so that is why I'm only mentioning TwinCAT (Beckhoff).

What should really scare any body doing this is what happens when a C or C++ pointer goes bad?

I don't have an answer for this. I'm sure TwinCAT C/C++ has mechanisms that allow some things and don't allow others that are 'normal' in standard C++. Or easy answer: avoid using pointers if possible.

ST doesn't allow pointers and should sacrifice a little efficiency for checking array indexes to make sure they don't index off the ends of an array.

https://infosys.beckhoff.com/englis...3/tcplccontrol/html/TcPlcCtrl_POINTER.htm&id=

 

[janner_10]

If you get hit by a bus tomorrow, some poor guy is going have to wade through this sh!tshow and try and maintain it. Why do that?

 

[drbitboy]

If you get hit by a bus tomorrow, some poor guy is going have to wade through this sh!tshow and try and maintain it. Why do that?

If they were going to be hit by a bus tomorrow, why would they care about this?


jes' sayin'

 

[Peter Nachtwey]

I suppose it depends on the PLC platform used and the programming software(??). Because TwinCAT uses Visual Studio as it's IDE and programming environment, the C++ PLC code is easily debugged in the programming environment. Set some break-points and debug away.

And what happens when you hit a break point? Does the whole machine stop or does it run open loop?

This is a problem when debugging anything that moves.

I've never used C++ programming in TwinCAT, but that is my assumption. I know you can set break points and debug a ST program in TwinCAT (I do it all the time), so I'm sure it's just the same in a C++ PLC program.

Yes, it can be don't but it isn't always safe when things are moving or when a burner can be left on etc. What makes sure the outputs are in a safe state?

I don't have an answer for this. I'm sure TwinCAT C/C++ has mechanisms that allow some things and don't allow others that are 'normal' in standard C++. Or easy answer: avoid using pointers if possible.

What about array indexes going past the end or beginning of an array?

 

[busarider29]

And what happens when you hit a break point? Does the whole machine stop or does it run open loop?

This is a problem when debugging anything that moves.

The program stops, set outputs stay high or low. If something is in motion, it will potentially stay in motion. The current line of code where the breakpoint is set is highlighted in yellow, then you can step though/over it.
Setting a break point in the PLC program

Yes, it can be done but it isn't always safe when things are moving or when a burner can be left on etc. What makes sure the outputs are in a safe state?

Setting break-points in a PLC program (TwinCAT) can be done and that debugging tool is available to the developer to use if he/she wishes. It's up to the developer to ensure everything is safe before setting break points, but that should go without having to be said. It's no different then making online edits, forcing outputs, etc. It's up to the developer to make sure its safe before doing these things. The TwinCAT Debugging documentation on setting Break Points is also very explicit about this:

https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_c/1028235531.html&id=

I sometimes use break-points when debugging, but its always within one of two scenarios:

1. 95% of the time when using Break Points, I only use them when debugging a fresh program or algorithm (function, function block, etc) on my laptop. Recall, because it's TwinCAT, I can run a PLC runtime on my laptop without the need for physical PLC hardware. So setting break-points in this scenario has 0% potential of hurting anything or anyone!

2. The remaining 5% of the time, I only use break-points in a real PLC that is controlling a machine when the machine is down and not in use, and I have full reign to that machine. Still, I rarely use break points on a live machine.

What about array indexes going past the end or beginning of an array?

Can't say. I avoid using pointers. I can try it out on my laptop and report back though. I suppose you could too

 

[Peter Nachtwey]

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.


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. This was a pain in the a$$. Over 20 years ago we developed the means of simulating the motion in software. What is nice about that is that when I am debugging code and hit a break point, EVERYTHING stops. The simulation does not keep going. I can restarted the program and the simulation will keep running from where it left off.


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.


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.


Wait, there is more! We check all array indexing to make sure array index do not go outside the array. Yes, this eats a few clock cycles but that is what more CPU power is for.


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

 

[Lyndon A]

C or C++ can be debugged easily when using VS-Code or Visual Studio but these debuggers don't run on embedded systems/firmware.

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. It went very well and I'd recommend the same tool stack to anyone doing something similar.

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.

 

[busarider29]

If you get hit by a bus tomorrow, some poor guy is going have to wade through this sh!tshow and try and maintain it. Why do that?

Here comes the LD crowd - "It MUST be written in LD because (insert a myriad of excuses [cough...cough], I mean reasons here)"


For the sake of not getting too off topic (Can a PLC program be written in C++?), I prefer not to get into the why's of using one language over the other in PLC's. Besides, I've been down that rabbit hole more than once on this forum.