Multithreaded C++ into function blocks - PLCOpen

EinarM

Member
Join Date
Mar 2016
Location
Iceland
Posts
5
Hi there
I'm an embedded software engineer mostly programming C/C++ in Linux and have very little knowledge of the PLC environment.
Recently my attention was diverted towards integrating C/C++ (Linux software) into PLC and then presumably as a function block which is supported with something called PLCOpen. Is that right ?

How is multithread support in PLC in general ? and/or with the these function blocks or what ever might become instead when integrating/porting C/C++ code into PLC.

The current situation is purely embedded Linux environment with open-source 3rd party userland that our code relies heavily on. How feasible is to port such environment over to PLC (given that the system supports it) ?

I've been looking into B&R Automation Studio 4 and having a hard time to establish concrete feeling on how difficult/easy it is to port the code.

Hope anyone can give me a slight insight into this.
Kind regards
Einar
 
Hi Einar and welcome to the forum.

Unfortunately you have misunderstood the concept of PLCs.
A PLC is not a MCU. It obviously has a processor inside it, but you don't flash it directly.
PLCs have specialized software that you use to program them with, using various languages e.g. ladder logic, function blocks, structured text to name a few.
I only know of one PLC (there are probably more) that you can program using C#/C++, but only through Visual Studio, so you will not be able to port your Linux code.
Programming PLCs is very different from programming embedded devices. It's alot simpler, but takes a while to get used to, if your not familiar with it.

Click the "Learn PLCS" link on the top of the page to get a quick intro.
 
Depending on your application you may have some PLC type options. For instance Mitsubishi has C controller that can be used, there are also mobile controllers that have a C variant.

Typically you would have to port your C code to Structured Text to run in a PLC.

Why do you require a PLC?
 
I just reread your question, and realized that I misunderstood it.
It's too late to delete my post, so please just disregard it.
 
A stab at the portability part

Hello Einar
Very interesting questions and several of them in there too. I will take a stab at the portability part.

1. Most PLC platforms rely heavily on lower layers and stacks to control I/O, access file systems, interface with comms. buses...etc. This inherently limits the ability to have full definition of some of the features of the ports and comms. network interfaces. So, one approach to answer your question would be to detail the exact features you currently implement or are looking to implement. For example, a colleague came across a situation once where the frame header over a comms. network needed to be 2 Words(32 bits) long instead of 1 Word (16 bits). In the PLC platform, this was handled by the communication stack which we had no access to. The only workaround was to 're-create' the function of the stack with direct access to the sockets, which took more time and R&D . This was a Codesys based controller and we were fortunate that there were libraries available to access the socket directly and sufficient functions in those libraries to emulate the operation of the protocol that had to be 're-created'. To answer your question, portability of code that handles these kind of features (per example above) would be difficult as the socket access functions would rely on the platform chosen. Still possible but difficult.

2. The sequence of operation on your current program may be influenced by the tools and functionality of the current platform. You refer to multi-threading which in theory is utilized by newer PLC platforms today but often at the lower levels in the processor runtime. Some functions made available in the IDE’s or the programming platforms may not be invokable in parallel/simultaneously by multiple processes (The term ‘may not’ is used as I prefer not to over- generalize without identifying the exact functions and platform). There are multiple cores in many newer PLC and simultaneous access is possible, again, loosely said, depending on type of function. There will likely be variances on the new platform that may redefine the flow of the program on the new platform. This is highly likely. In this sense, portability can be a challenge too.

In summary, despite the gloom about portability in my two points above, depending on the features and complexity, it is still possible but may take more time. When you move from an embedded environment to a PLC platform, some control of the end product is relinquished. This may be ok and may even reduce complexity on your program as long as your core features and functions are met by the new platform.

In either case (complex or simple) the best approach would probably be to clarify the desired sequence of operation ( even if it is high level) and then look into possible PLC platform implementations- down to specific features, libraries and functions. Doing this up front will reduce surprises down the line.
 
Hi there and thank you for your feedback.

To shortly describe why I'm looking into PLC is just because there is a potential shift in our company to switch over entirely to PLC hardware and then utilize the C/C++ support in it.

The innovation in my company is split between PLC and Embedded C/C++. The PLC part is Allen Bradley, Omron, Siemens and more. For the embedded part we manufacture our own CPU board used in our machines. That board as a SoC, Ethernet, USB, CAN and other standard computer peripherals. Running on that hardware we have a software framework that I would have to port over to a PLC hardware.

I'm trying to establish a solid knowledge foundation of the scope for such porting job before I actually start to do anything at all.

From your responses I understand the porting job could be difficult because we would have to change and modify a lot that has to do with I/O, Memory and such. Does that basically mean we would have a totally different hardware abstraction layer (HAL) ?
I mentioned that our userland is open-source 3rd party libraries a long with the Linux kernel that constitutes our HAL. I guess that would change alot ?

I'm still not seeing if multithreading is supported if we move C/C++ code over to a PLC hardware. Will that be a true multithread support or scanned polling like PLC operates ?

For the experienced PLC developer, is this a viable solution at all ?

kind regards
EinarM
 
I have done a couple if simular tasks over the years replacing quite complex pc solutions with a plc.
Some c functions I read and rewrote manually to stl (Siemens plc language) others I just tried to understand the purpose and wrote plc logic that did the same thing
.
So it's indeed possible however if there are very computer heavy algorithms with a lot of data involved then you might have a problem.

Regarding multithreading if you only have one processor core the code is never parallell right?

The plc have very predictable scan times and timed interrupts.

When we needed very fast processing of analog inputs we choose a national instruments plc instead of Siemens all other projects worked with Siemens plcs
 
Hi Bratt and thank you for your input.

Regarding multithreading matters then I'm really asking if there is this conventional context switching in PLC or is it a single loop where each task/thread is scanned/probed if it needs attention.
I'm not so worried about pure parallelism but rather the multithread support for a C/C++ code that has been ported.
What I mean by ported is using PLC vendor compiler to compile C/C++ code to run on a PLC hardware. As I understand it, it would be compiled into a so called "function block" that runs in the PLC context or am I wrong ?
If my assumption is correct would that function block then be executed in some sort of main PLC loop or is it running as a separate task ?

Thanks for your support in advance
EinarM
 
I can only speak for Siemens.
Siemens has a special range of embedded controllers which can run compiled code and regular plc code simular to what you ask for.
I have not used this I have manually ported the code or functionality to regular plc code for regular Siemens plc

ODK includes an application wizard and a class library for simple programming in Microsoft Visual Studio. The program running outside WinAC is developed with Visual C# – or with Visual Basic or Visual C# for Windows applications – and generated as DLL or Real-Time DLL. The DLL is called with the help of three systemfunctions (SFC 65001, 65002, 65003).
The C program can be executed in three different ways:

Synchronously, that is, processed as part of the PLC cycle

Asynchronously, that is, started by the PLC program and terminated in the background

Continuously, that is, processed parallel to the PLC program

More info here

There is also a newer version for the 1500 series called 1500-odk which runs on a pc or a special pc version of the 1500 controller
 
I'm not so worried about pure parallelism but rather the multithread support for a C/C++ code that has been ported.
What I mean by ported is using PLC vendor compiler to compile C/C++ code to run on a PLC hardware. As I understand it, it would be compiled into a so called "function block" that runs in the PLC context or am I wrong ?

New PLCs can run logic in multiple separate tasks, those can be setup on timed intervals or driven based on events. In most cases, the C/C++ could would have to be re-written using Structured Text language (see IEC 61131-3). So yes you have some "multithread" ability, however I'm sure this isn't apples to oranges.

Function blocks are just objects of code that an be instantiated and called in the PLC logic, not much different then defining a sub Main() in C/C++ then making function calls within.

Depending on how complex your C/C++ code is, it may or may not be that easy to convert to Structured Text.

I highly recommned reviewing the Mitsubishi C/C++ PLC controller manual:

http://dl.mitsubishielectric.com/dl/fa/document/catalog/sol/ccpu/l08211eng/l08211enga.pdf

Using a product like this might be your easiest bet, note that generally speaking you don't see much C/C++ discussions along with PLC discussions. You probably won't find much information on this setup.

EDIT: Additional Links

Brochure
https://us.mitsubishielectric.com/fa/en/support/technical-support/knowledge-base/getdocument/?docid=3E26SJWH3ZZR-38-1656
 
Last edited:
......
Hope anyone can give me a slight insight into this.
Kind regards
Einar
How can you expect a valid answer? We don't know that the application is.
Many applications can be done in a PLC but many applications can not, at least not without a specialized card that goes in the PLC rack.

What are you trying to do? What is you application?
 
Our application is a software framework comprised of Linux, assembly, C/C++ modules, HTML, Bash and Lua scripts. This framework is then used by others within our company to develop the end product.

What I'm trying to get a head start of by posting on this forum, is how feasible it would be to move this software platform of ours over to a PLC hardware.

The reason I'm asking is because there are some ideas that PLC should be our future hardware and in order to unify the HMI's we should "port" the software platform over to PLC. First candidate is PLC from B&R.
What I've heard is that PLC supports C/C++ which is fine but I have serious doubt that a comprehensive framework as our would be so easily ported.

I mean f.e. can I port the Lua interpretor and have Lua scripts running in function blocks ? I know the assembler and low level C code would have to be written again.

Kind regards and thank you again for your input
Einar
 
It seems to me you are trying to get a taxi to be a race car.

PLC is born and bread for 2 very specific tasks:
  • I/O based control of industrial devices
  • Communications to/from industrial devices

Throw in as well that the hardware is generally more rugged than office grade equipment and generally a specific model will be available for a longer lifetime then office grade equipment which changes model numbers and availabilitiies yearly or more frequently.

THE question is what are the perceived benefits to your company of moving to a PLC platform?

If someone can't tell you that then you really should go back and ask them the improvements or changes they are expecting and see if they line up with the features and strengths of a PLC platform.

I hate to quash ideas right out of the gate but I can't see a benefit to it.
 
Our application is a software framework comprised of Linux, assembly, C/C++ modules, HTML, Bash and Lua scripts. This framework is then used by others within our company to develop the end product.

What I'm trying to get a head start of by posting on this forum, is how feasible it would be to move this software platform of ours over to a PLC hardware.

The answer is that this is not very feasible for anything resembling a traditional PLC. I'm not saying it's 100% guaranteed impossible, but, seriously, it isn't a path you want to start going down.

what you MIGHT be able to do, however, is use a PC based PLC platform. Some vendors have "soft" plc's that are programmed similarly to traditional PLCs, but also have Windows running. There is usually some kind of virtualization concept so that a windows BSOD doesn't crash your PLC as well. Therefore, traditional C programming can be done on the windows side, and then communicate to the PLC side as needed. However, this isn't all that different from simply having separate PC and PLC, unless you really need to save space in your system.
 

Similar Topics

Good morning crew! Ok my logic works but I am missing something. When the start button is pushed it should like the red light for 4sec then shut...
Replies
13
Views
344
Please see attached file. I need this program in Function Block form but I am totally lost on this. Any help would be appreciated. Thanks!
Replies
8
Views
255
The idea here is to provide for a brief rapid influx of message codes while preventing sequentially repeating the same message. i.e. if two...
Replies
22
Views
427
Howdy, I am currently struggling with an array of values that I want to re-arrange in a programmatic way. My program is a mix of ladder and STX...
Replies
6
Views
365
Hello all, I am trying to set PLC clock using DATE function. When DATE function is enabled, I can see A351 to A354 change to the register...
Replies
3
Views
361
Back
Top Bottom