Do PLCs run a common intermediate language under the hood?

[surferb]

I speculate that PLCs translate the language from programmers (e.g Ladder Logic, SFCs, Structured Text) into a common intermediate language, similar to Java or .NET bytecode. I'm curious about a vendor-agnostic response (e.g. AB, Siemens, Mitsubishi, etc).

Is there any reference to this or are there knowledgeable folks here?

 

[I_Automation]

Going back to the days of the Text Editor / Compiler program sets for machine language each CPU has it's own code it processes. A 8088 program was very different from a 68000 program.


The core machine language of a PLC would have to be for the CPU used in it and wouldn't even be recognizable to another CPU. Even if 2 different PLC's used the same CPU the hardware on one motherboard would be incompatible with the other.

 

[Peter Nachtwey]

Early Modicon 984's used AMD bit slice processors to emulate a PDP-11 for speed. There were 4 bit slice processors, each handling 16 bits of a 16 bit word so the PDP-11 instruction set was an intermediate code.

Today the PLCs should just compile down to their native machine code for speed.

 

[surferb]

The point of my question is whether the resulting code would be the same on a given PLC from equivalent programming in Ladder Logic versus SFCs. When we say "native", this is still run on top of another application, right? We still need to be able to make "online changes" without restarting.

Today the PLCs should just compile down to their native machine code for speed.

 

[TheWaterboy]

I would think that would be up to the compiler and could even change with FW revision improvements. If the complier recognized the SFC code as one of it's kin, it would make sense for the compiler to have optimized bytecode just for that instruction ready to go whereas ladder gives little hint on its intentions so could only be optimized for space and not speed.

FBD and PlantPax instructions are very likely done with preoptimized code blocks the complier just inserts variables into allowing fast compilation and execution at the cost of memory footprint.

 

[I_Automation]

The point of my question is whether the resulting code would be the same on a given PLC from equivalent programming in Ladder Logic versus SFCs.

I read that wrong, sorry. Speed reading is nice but sometimes it bites you in the A**.



To answer that - YES. Sometimes.


In Siemens projects you can select to view a block as ladder or text if the routine has all the instructions used supported in ladder, some show as a mix of ladder & text.


In Mitsubishi you can choose to view either way as all commands are ladder supported.


For those the compiled code sent to the PLC is the same whether it was created in ladder or text, it's the programming software that's creating how it's viewed.

 

[surferb]

Thx!!!

 

[parky]

It will depend on the platform, I know of a couple that use the "PLC" code (regardless of ladder STL or FBD) actually use an interpreter, the code you write is converted into a hex number, the interpreter uses that to run the program in it's native Machine code, a little bit like basic was some years ago.
I know that because I worked with a guy who did some for a well known manufacturer, I will not name them as it was something I should not have known about, the idea was that rather than compile it into an exe for on-line modifications it certainly gave an edge for large changes.
Again, regardless if it is compiled to run directly or interpreted, the code produced in LAD,STL,ST or FBD will produce roughly the same code in this case.
A good example of this is S7 classic, when you configure a rung say compare two values for greater than, the conversion to STL shows conditional jump that you do not see in Ladder.

 

[JesperMP]

I can only speak for Siemens.

In the older generation S7-300/400, the programming software generated a code called MC7 (Machine Code for S7) which was almost identical to the statement list programming language. Because of that, you could always upload from the PLC to the programming software and have it displayed as STL (*). Comments and symbols where not loaded in the CPU, memory was limited and expensive.
I believe that the MC7 code was actually an interpreted language (despite the 'machine code' part of MC7), and S7-300 and S7-400 actually had quite different processors. Since the MC7 code was interpreted, this was transparent to the programmer.

*: And if the STL code conform to the rules for displaying as FBD or LAD, then the STL code could be switched to FBD and/or LAD.

In the newer S7-1200/1500 I am quite certain that the code is compiled to something very close to the machine code. When loading the code on the CPU, both debug information and a copy of the source code is loaded as well (since nowadays memory is cheap). Because of that you can upload the program and get both code, comments and symbols.

 

[parky]

Yes Jesper, S5 was the same it was called MC5, this enabled the whole project to be downloaded even in run mode. There was a way of setting the MC5 (& Presumably MC7) code in DW & processing those to run the instruction, i.e. could have self modifying code very dangerous, did a trial once not for the faint hearted.

 

[Manglemender]

Yes Jesper, S5 was the same it was called MC5, this enabled the whole project to be downloaded even in run mode. There was a way of setting the MC5 (& Presumably MC7) code in DW & processing those to run the instruction, i.e. could have self modifying code very dangerous, did a trial once not for the faint hearted.

Yes. You could actually read and write directly in the memory of the CPU so if you knew an offset start address for a block you could edit it.

This was commonly used to hide the contents of a block in S5: In the edititor you would write Jump Unconditional = Label followed by a blank line and then the Jump Label followed by the rest of the code. After downloading the block you would then edit the memory and replace the blank line (NOP 0) instruction with a Block End (BE) instruction.

When viewed in the editor, nothing was displayed beyond the BE instruction.

I've also come accross direct memory manipulation used for some HMI stuff in S5.

Nick

 

[parky]

That is correct, that is how Siemens protected their blocks, so all you could see was JU=M001
BE
Put NOP in place of the jump & replace BE with *** (Segment end) & it opened it up.
Siemens stated that their code was compiled but that was just to put people off, however, there were some instructions that I could not find in the manuals, but an ex Siemens engineer said these were ones that were not officially released.

 

[surferb]

This is awesome - exactly what I was looking for. Thanks all!!!

 

[theColonel26]

I suspect the answer is yes, they use a some form of byte code, CLR. I have no evidence of this though other than the knowledge that to hot reload natively compiled code is a lot more complicated than hot reloading an Immediate Language.

I especially think Rockwell PLCs use an IL because of the way they allow online editing at the rung level.

Codesys allows online edits too, but, it compiles chunks of the application first. Then does a partial download in between scans.
I suspect it still uses a IL, but I suppose I could be wrong.


I don't think you will find any official information about this, since all PLC Vendors are super paranoid and propriety.





Side note: for the anyone that thinks PLC code is complied to a single monolithic native application and that they have no operating system... You are absolutely wrong. They all have OSes, even if the are Single Task RTOS. Something has to provide services to the user application...

 

[parky]

I agree with the Colonel, however, as programs now are more structured it is probably easier to compile small chunks i.e. subroutines. I know Mitsubishi do use an interpreter as such, the download is limited to 500 bytes. That's why Siemens was so good especially in the S5 days, all blocks were stored in memory just like a hard disk i.e. a FAT table, the block being downloaded on-line was put into spare ram, at some point in the tidy up & other internal routines the original block allocation was deleted & the location of the updated block was added in the table, originally you had to at some point compress the memory as the original blocks were not removed so filled up the ram, later versions did an automatic compression i.e. remove the redundant blocks of code.