Do PLC's run compiled code?

lostcontrol

Lifetime Supporting Member
Join Date
May 2009
Location
NeverSayNever
Posts
1,071
I was having a discussion recently & my comment mentioned 'the compiler', being RSlogix, Step 7, CX-programmer etc.
The other person mentioned "PLC's don't run compiled code", which I did not argue with, rather let it rest to think about.

My impression was that the s/w is a GUI, that takes the instructions & converts them to machine code, specific for the CPU it is running on.

Or does the code as it is written go direct to the PLC? :confused:
 
Ok, so when downloading or performing online edits, the code is 'compiled' then committed?
I think the other person's thoughts were that compiled code is an .exe file..
 
Are you referring to the ladder program or to the Plc software that processes the ladder program?

I'm asking to get you to think about what software the processor is actually executing and what it is doing behind the scenes.


Whether you think of it this way or not, ladder logic is a high level language. People on the forum will argue this point, but whether a language is high level or not has nothing, zero, zip, nada, to do with its complexity. Level has to do with its degree of abstraction from the process. Consider the seemingly lowly XIC instruction for examining the status of a single bit. XIC gives the programmer a single instruction while behind the scenes it constructs a binary mask, ANDS the mask with a memory word, then tests for nonzero. Or the OTE, an if-then-else instruction that can set or clear just one bit in a word on a processor that writes 32 bits at a time, not one bit at a time, without disturbing any of the other bits in the word. (Work that one out, it's not hard but it will show that OTE is getting up there in language level.) A CTU or TON does even more behind the scenes work for you.

Somehow those ladder instructions have to be executed at the CPUs machine level. A compiler is a program that converts code written in one language to another. So what would you call it if the graphical or mnemonic ladder is converted to a list of numeric op codes that is downloaded to the PLC to be interpreted by the software of the PLC? Isn't that compiling?

And just what is an interpreter? It's a piece of compiled software that compiles op codes at run time. The interpreter only hides the compile step with a slight of hand and it has to do it over and over each time the same code executes, but that doesn't change what it is doing.

So your friend can split hairs and argue over semantics but at the end of the day machine language is what the processor speaks, and your program must be reduced to that for anything to happen. Somewhere at the bottom it is all compiled, no matter what the PLC brand is or what strategy the manufacturer uses, or whether the code is compiled by the development software before download or by the PLC firmware at runtime.
 
Last edited:
Ok, so when downloading or performing online edits, the code is 'compiled' then committed?
I think the other person's thoughts were that compiled code is an .exe file..
I don't know for sure but if I were designing the compiler for Rockwell I would compile the code rung by rung. To execute the code in each rung I would start with a linked list of pointers to the rungs. This would allow one to down load a new replacement rung and by just changing the pointer to the new rung code one can execute a new rung. The code for each rung doesn't need to be in any logical order because of the linked list makes sure the rungs get executed in order.

For Siemens I bet the code is compiled by OB, FC and FB and not by network. It seems that one must replace the whole FC or FB. There may be a linked list but I bet there is an array of pointers to FC, and FBs because there is a limit to how many one can have.
 
I was told Omron used to run machine code - probably still do. The machine code is generated by the software. Omron guy may confirm or deny.
 
CX Programmer definitely does a compile before the program is downloaded to the PLC and a de-compile when code is extracted from a PLC. The current versions of Omron PLCs do have a memory area reserved to store comments so that de-compiled code is commented.
Running interpreted code in a PLC makes no sense at all. It would be much slower and take up more memory to load the source code into the PLC and interpret it there.
 
I don't know for sure but if I were designing the compiler for Rockwell I would compile the code rung by rung. To execute the code in each rung I would start with a linked list of pointers to the rungs. This would allow one to down load a new replacement rung and by just changing the pointer to the new rung code one can execute a new rung. The code for each rung doesn't need to be in any logical order because of the linked list makes sure the rungs get executed in order.

That's how I've always assumed they did it. Also, complex instructions are like dlls and called by the compiled program.
 
A compiler generates machine code for the target microprocessor from application source code. It may generate assembly source instead but that's just a step in the process. The end result is a block of machine code that represents the entire application. This code executes without support from the complier at run time.

An interpreter executes concurrently with the application code. It is a program that processes the application source and executes pre-existing modules of machine code based on the instructions and operands in the source file. At no time does an executable block of code exist in memory that represents the entire application in machine code. The interpreter may store the application in a format that is easier to process than the human readable source. This is sometimes called tokenized code.

At least, that's how I think of the differences.

It's quite possible to use either approach in a PLC. However, I agree with Peter's comment that compiled code should generally perform better.

As far as libraries go, there is certainly more than one viable method for including standard blocks of code but I expect it is simpler than DLLs and more like C libraries.
 
Last edited:
So your friend can split hairs and argue over semantics but at the end of the day machine language is what the processor speaks, and your program must be reduced to that for anything to happen. Somewhere at the bottom it is all compiled, no matter what the PLC brand is or what strategy the manufacturer uses, or whether the code is compiled by the development software before download or by the PLC firmware at runtime.
The 'friend' does sometimes split hairs when comparing PLC brands, so this is a valid statement.

Thanks for all the replies, I had no idea on what actually happens when the PLC software (interpreter) transfers the code to the PLC, but had kinda thought that it compiled it to some fashion of machine code.
 
Split hairs, talk about compiling, split hairs, it's time for a beer :whistle:

All code run on a microprocessor (including a PLC) is compiled(it has to be turned into something the CPU understands).

The differences in types code is this,

assembly code is machine (CPU) specific code using mnemonics that translates exactly to the exact bits, byte, or word (whatever the instruction size is)of the instruction/data code for the processor and can be done without a compiler using hardware and switches to load a ram or prom, though usually is done with a compiler.

such as:

Mov A,E

(move the 8 bits in the E register to the A register), which for a 8080 processor would compile to 7B hex

A High level language (compiled code also) is a a human readable (in most cases) program that is turned into specific compiled code for each "instruction" in the source code. such as

Copy a to b

which depending on your choice of compiler, may be either turned into machine code that directly does almost what the assembly code did (although with some added overhead), basically it adds a pre-compiled generic routine maybe named copy (or calls it from a pre-compiled set of routines called say a DLL) that uses a pointer(either a CPU register, a place on the stack, a direct memory address, an index into a memory address, etc for either a and/or b) to the variable called a and stores it into the variable called b

All things equal, it is all compiled code, just the way it is compiled and run is different.

The fastest most compact code is assembly code (usually), but it is extremely hard to write complex algorithms in assembly and takes an intimate knowledge of the specific processors instruction set, registers and timing, so compilers were designed that made the code easier for people to read and understand. the trade off is larger slower running programs (look up hello world in assembly them c then visual basic)

Interpreted programs on the other hand are programs that run programs :)whistle:) whether they scan the text file, or tokenized version of the text file) but again there is a compiled program running in the background that you may call a "runtime" using Microsoft's name for it. Tokenized interpreted programs are faster than raw text interpreted files because the interpreter does not have to "Read" as much of the file to make a decision on what to do next, but both are much slower than the "compiled:whistle:" code of the previous two examples

so yes your plc has to compile the code to run it(unless it is using a runtime), but the more instructions and data types your PLC has the larger the code base gets and the larger the program gets due to code overhead. and in some cases the slower code execution becomes. that is why even with your faster PC today running in the ghz, it is still not 1000 times faster than the old 8086 originally was (8 mhz)

The closest to Assembly is Siemens Statement logic, It closely matches assembly statements for the processor, the furthest from it is structured text which has to be compiled just like statement logic has to be compiled.

Yes there are optimizing compilers, but as long as it is human readable form, with direct, indirect, and indexed variables of different bit/bite/word widths and types then the compiler has to add overhead to handle each situation without crashing........

I have not talked to the person(s) who have written the compiler for RSLogix 5000, or Step7, but I would bet there is a runtime (exe and dll's for a simile)using a tokenized code the displayed source code you see on the screen. that would logically be the fastest way to handle complex algorithms with the lowest overhead and highest speed.

Anyone out there who helped develop say RSlogix 5000 step in and tell me different.
 
For Step 7, inspection of the code on my PC, the code on the memory card and the code in the work memory of the CPU shows it to be all the same (MC7) - my inference is that it is interpreted.
 
Furthe to what LD has said. I've always believed that S5 and S7 were interpreted. High level languages Step7 compile to MC7 code (Step5 to MC5).

Inside the CPU there is a ROM chip that contains a translation for each MC7 (MC5) instruction into the native op codes for the CPU chip. MC7 (MC5) is analagous to RISC in that there are only a limited number of instructions.

In this way PLC processors can be developed that use different chip sets internally while keeping the developement platform unchanged.

Nick
 
I don't think the S7 puts an op code translator on a ROM chip. It may or may not use a translator, but if it does it is downloaded to the PLC with the program. That was the feature that was exploited by the Stuxnet virus, enabling the PLC to be infected from an infected computer while remaining invisible from the user program.
 

Similar Topics

Hello..I am new to Plc.I have Mitsubishi Melsec Fx3Ga-40MR PLC controlling a machine for packing powder.Currently the Plc has issue which power...
Replies
3
Views
164
I have an issue with Power Flex 525 during running processing, the VFD stopped suddenly while the PLC and VFD connection ok, VFD does not have any...
Replies
1
Views
139
Hello everyone!!, I may be asking a newbie question, but I want to be sure of that. Can I run a PLC program directly from the SD card? I mean, I...
Replies
2
Views
198
I'm in possession of an Allen Bradley, Micro 820, 2080-LC20-20QBB that's password protected and currently in run mode. The PLC was shipped to me...
Replies
1
Views
973
I have an Allen Bradley, Micro 820, 2080-LC20-20QBB that is password protected and is set in run mode. The plc was sent to me with a password that...
Replies
0
Views
606
Back
Top Bottom