What language to choose for my brand PLC?

Serhioromano

Member
Join Date
Sep 2015
Location
Kazakhstan
Posts
57
I am developing a PLC. The IDE for my PLC will be VS Code. I want my PLC to support IEC-61131-3 but only one language with is ST. Actually I already have a VS Code extension published for ST support. My PLC will be based on board like Raspberry PI but that will be Оrange PI.

Of course, I'll have to compile or better say analyze ST code and convert it to another language. Of course, if I would flash CPU and make my PLC based on Atmel chips for Arduino, I would have no other options but convert my ST code to C/C++ and then compile it to BIN file to download to CPU.

But my PLC is Linux based, I can use any language I want. So I am thinking would it be much simpler to convert ST program to Python for example or even Nodejs. Then I'll have no need for code compilation.

What do you think? Do you think Python will be good? What language would run with minimal resources and with industrial-grade stability?
 
No offense, but I would say that if you're asking that question in here, you're probably in over your head.


As far as I know, you'd need to start with a realtime OS (not just basic linux), and then see what it allows from there.
 
As far as I know, you'd need to start with a realtime OS (not just basic linux), and then see what it allows from there.

Pardon me? Most of the contemporary PLCs like WAGO PFC200 for example and lot of others are based on Linux. I do not see any problem with that. I can SSH PLC, install mosquito there or other applications and then use them.

Quick Google search and I find this

“The PREEMPT_RT patch (aka the -rt patch or RT patch) makes Linux into a real-time system,” said Steven Rostedt, a Linux kernel developer at Red Hat and maintainer of the stable version of the real-time Linux kernel patch.
 
How about latching on to this project:
Open source PLC

I like the OpenPLC project. But unfortunately, their runtime is deeply bounded to IDE. And one of my main purposes is to be able to use any text-based IDE like VS Code, Atom, Eclipse, IntelliJ and others.

Also, I have some features that I cannot reveal now, that will not allow using OpenPLC. Besides their ST implementation is quite limited as they tend toward graphical languages like LD. I want to make not only full ST implementation but even implement ST-Ext. Those are extended language features that are not in the IEC-61131-3 standard.
 
If you want industry grade stability you are probably going to want to convert to binary and not convert your language into another one before it eventually gets compiled. That sounds inefficient and error prone if you ask me.

You are going to need experience in writing programming languages and in writing compilers before you can start this project.
 
Pardon me? Most of the contemporary PLCs like WAGO PFC200 for example and lot of others are based on Linux. I do not see any problem with that. I can SSH PLC, install mosquito there or other applications and then use them.

Quick Google search and I find this

“The PREEMPT_RT patch (aka the -rt patch or RT patch) makes Linux into a real-time system,” said Steven Rostedt, a Linux kernel developer at Red Hat and maintainer of the stable version of the real-time Linux kernel patch.
I guess what I was trying to say is that this is a forum primarily for USERS of PLCs, not developers/designers. I'm not saying no one will be able to help you, but I think the number of users here knowledgeable in embedded system design and the performance trade offs between different PC languages would be pretty minimal.



If linux has a simple compile flag to make it hard real time that you plan to use, then I guess I retract my objection.
 
Will the compiled ST code be able to load during runtime, and without initializing the memory used by the previously compiled ST code ?
If not, then will not be a real "PLC" in my view.

Historically, this was not always possible, but today it is a must-have.
 
Serhioromano, what a cool sounding project. You mentioned that you have some features you can't share yet.. Is this an open source project, masters thesis or do you have a private team?

Compiling ST into executable code is trivial, at least compared to the other tasks involved in making a PLC. If you have just the one hardware ambition in the Orange Pi (pi4?), you could choose to compile straight from ST to linux executable binaries for your architecture. Sure, Raspbian uses armel, but maybe you want arm64 for performance, and just use a different distribution. It sounds like you are going to be using a preempt patch anyway, so may as well go all in.

If you're not going to compile to binary yourself, you may as well pick your favourite programming language. I think your code will run fast enough in most languages, and designing the PLC features is going to be your tougher hurdle. As already mentioned, these features are a must these days: online changes, online monitoring, communications to IO, communications to visualisation, communications to business systems.

If it is opensource I will be interested in following the repository when you are ready to link it.
 
This will be a long struggle. If you aren't familiar with compiler writing you may get frustrated.

I started an ST compiler a long time ago. I bought the full specification and used winflex and winbison to generate parse tree. My code generator only generated a pseudo assembly language. It got stalled because we switched CPUs so generating machine code would not work on all products. ST has many intrinsic functions, about 500. Most of these function are extremely simple like converting an INT to a DINT. You don't want to call a function for that but sign extending an INT does require emitting a machine code. I should generate Intel 386 code just for the heck of it and be done even though it wouldn't work on our motion controller.

My ST compiler will probably never get done before I retire which is too bad.

Python is not a solution because it is interpreted byte code and slow compared to machine code.

A lot of work is required to generate machine code. Most of the code is easy to generate but some jumps require relative offsets that must be patched ( ORed ) in after the first pass is done.

I would consider using Scintilla as the HMI because then the compiler can be integrated in with the editor. This makes things like high lighting syntax and spelling errors easier.

If you want to implement something quick then try Forth. There are lots of topics about that.
 
I guess what I was trying to say is that this is a forum primarily for USERS of PLCs, not developers/designers. I'm not saying no one will be able to help you, but I think the number of users here knowledgeable in embedded system design and the performance trade offs between different PC languages would be pretty minimal.
If linux has a simple compile flag to make it hard real time that you plan to use, then I guess I retract my objection.

I see. But again, how hard it should be. And if you think about real time every OS is real time and just different hardness. Better readt this. еhis is opinion I stand on.

https://www.linuxfoundation.org/blog/2013/03/intro-to-real-time-linux-for-embedded-developers/

Also 90% of PLC tasks are not time-critical. I mean that critical time task is when it starts killing people if delivered not on time.

Will the compiled ST code be able to load during runtime, and without initializing the memory used by the previously compiled ST code ?
If not, then will not be a real "PLC" in my view.

You are right, it will not be a real PLC. And I do not care much about loading during runtime. As I have mentioned 90% of PLC tasks do not care about this feature. So I leave those features to PLC developers and I create PLC for tsks that are not critical to hot reloads.

Serhioromano, what a cool sounding project. You mentioned that you have some features you can't share yet.. Is this an open source project, masters thesis or do you have a private team?

Compiling ST into executable code is trivial, at least compared to the other tasks involved in making a PLC. If you have just the one hardware ambition in the Orange Pi (pi4?), you could choose to compile straight from ST to linux executable binaries for your architecture. Sure, Raspbian uses armel, but maybe you want arm64 for performance, and just use a different distribution. It sounds like you are going to be using a preempt patch anyway, so may as well go all in.

If you're not going to compile to binary yourself, you may as well pick your favourite programming language. I think your code will run fast enough in most languages, and designing the PLC features is going to be your tougher hurdle. As already mentioned, these features are a must these days: online changes, online monitoring, communications to IO, communications to visualisation, communications to business systems.

If it is opensource I will be interested in following the repository when you are ready to link it.

That is why I want to convert to Phyton or something like this. I'll make it CPU(hardware) agnostic. It there is a Linux, it should work. I do not plan that PLC will have onboard I\O just CPU and all I\O will be connected. This means that I do not need even PLC configuration, you can write a program and upload to any PLC (I plan to produce or theoretically any Linux plc with Modbus TCP\RTU interfaces) because I\O will be connected through ST code, not through configuration, it means it will be universal.

Right now I have only one open repo. This is an extension for VS Code that allows code with ST. It is not yet fully featured just the start, but it is the most complete, most downloaded ST Extension for VS Code to date.

https://github.com/Serhioromano/vscode-st

So, my IDE will be public repos. And converter too, but I have not started it yet, as you can see I try to grasp clear picture where to go.

You can follow me on GitHub and you will be notified when I create a new repo.

This will be a long struggle. If you aren't familiar with compiler writing you may get frustrated.

I started an ST compiler a long time ago. I bought the full specification and used winflex and winbison to generate parse tree. My code generator only generated a pseudo assembly language. It got stalled because we switched CPUs so generating machine code would not work on all products. ST has many intrinsic functions, about 500. Most of these function are extremely simple like converting an INT to a DINT. You don't want to call a function for that but sign extending an INT does require emitting a machine code. I should generate Intel 386 code just for the heck of it and be done even though it wouldn't work on our motion controller.

My ST compiler will probably never get done before I retire which is too bad.

Python is not a solution because it is interpreted byte code and slow compared to machine code.

A lot of work is required to generate machine code. Most of the code is easy to generate but some jumps require relative offsets that must be patched ( ORed ) in after the first pass is done.

I would consider using Scintilla as the HMI because then the compiler can be integrated in with the editor. This makes things like high lighting syntax and spelling errors easier.

If you want to implement something quick then try Forth. There are lots of topics about that.

I perfectly understand. Fortunately, I know ST pretty much well. My 320 pages book to learn ST, right now in the publishing process. еhat is why I want to convert it to something like Phyton. Then Phyton will make all errors of compilation and I do not need to do that. Slower? Yes but my PLC will run on big CPU machines like XEON, i7 and such. So I can sacrifice little bit of performance.
 
Tabs: drbitboy is a PC programmer, who is team spaces. I suspect you use tabs to indent your code somewhere, rather than spaces.


This WILL be the last post about tabs vs spaces in this thread.
 

Similar Topics

So, I'm new to the PLC world (fresh graduate) and at my job I've been pretty much only helping out the other programmers with simpler tasks while...
Replies
1
Views
582
Hello, I was wondering if anyone could let me know how to change the audit trail messages language on Factory Talk ME. I am currently working...
Replies
0
Views
427
Good morning, I have a project coming up that will require my HMI runtime to toggle from English to Spanish via selector switch. What is the...
Replies
0
Views
432
So I am sure many of you have run into this problem over the years. I know I have.... The customer has a machine that was built outside the...
Replies
14
Views
2,527
Hi All! Anyone seen this before (See JPG)? It looks like assembly language. Is there a module I am missing to view this properly or something?
Replies
28
Views
6,778
Back
Top Bottom