PLC Programming Language

Can we programme a PLC in C or assembly? if not then what is the reason.

Why would you want to?


Manufacturers have gone to great extents to develop programming software that, for the most part, is relatively easy to use.


I don't see any reason to reinvent the wheel!

Maria Javaid said:

Can we programme a PLC in C or assembly? if not then what is the reason.

Click to expand...

I think some PLCs have that option (Siemens?) but I can't tell you any more since I never had a need to use it...
I've seen it only once and that was a REALLY BAD example. System was written in C by someone else and another guy was commissioning it... Poor guy!!!

Most brands of PLC have some kind of co-processor that will allow programming in a "high level" language like C or BASIC. They are normally used when some very specific code with high level math functions are used or if communcations with a serial device that requires ASCII strings are needed.

Programming in assembly would be redundant, since the ladder logic or other PLC code is generally compiled before execution.

PLCs were not designed as general purpose computers. They were designed for industrial control and for logic readily understood by plant electricians used to ladder diagrams for electrical schematics. In Europe, because electricians were not initially seen as candidates for programming, languages like sequential function chart and so on became popular early on.

If you want a general purpose compute and need to program in C or such, use an industrial PC and remote I/O.

Siemens provide the M7-300 and M7-400 range which allows you to use the Borland C/C++ compiler to generate code.

Hello Simon (and others);
The M7 platform did not produce code for the PLC processor; you could create and run C applications that would executre in parrallel with the processor logic.
Siemens also offered a Java-based compiler that would produce machine code for their S7-400 PLCs, and eventually for other platforms (Allen-Bradley amongst others).
Both the Java compilers and the M7 platforms were abandonned a few years ago for lack of interest in the market.
Hope this helps,
Daniel Chartier

Thanks for that update Daniel.

CoDesys used in Wago PLCs uses a script type code.

Mitsubishi A Series processors prior to the AnA series used to be able to run sub routines written in 8086 assembler. This was useful for programmes using complex maths (ie PID) and these routines were referred to as "micro's". This procedure became unnecessary when more powerful maths instructions were made available and I have not seen it used in years.
Andybr

Why would you want to use a low level language to program a PLC?

Seriously. I'm not being sarcastic. Ladder is a high level language because it takes care of all of the bit masking and shifting to extract the status of a single bit from a word, and/or that single bit with other bits, and then create an if-then-else statement all in a single instruction.

It really depends on what the PLC manufacturer (or in some cases third-party software developers) have provided. For example Rockwell ControlLogix family and higher-end PLC-5s (5/80 and above?) have a "Structured Text" language which is syntactically a mish-mash of BASIC and C syntax. Siemens "STL" language is essentially assembly. GE offers a C programming package add-on (at least they do/did for LogicMaster 90 software).

There are plenty of reasons to use a low-level language. The only low-level language I'm personally familiar with is Siemen's STL, and I've used it for creating "roll-your-own" blocks (for example, I created a purpose-built timer FC block which took a shift number as an input. Using one of these timers, I could keep track of how long the equipent was in auto per shift. I use another timer for how long the machine is idle per shift, etc... Now, with nice simple, clean ladder logic that makes use of my STL-built timers, I have a DB block keeping track of how much time during each production shift the machine was in any particular condition (Auto, Idle, Fault, Changeover, etc.)) Siemens doesn't support indirect addressing in ladder - you have to use STL (low-level) for that.

ogimoj said:

.... Siemens "STL" language is essentially assembly......

Click to expand...

I dont know where you get that from...

I use STL and I have done VB, VBA, C++, bla bla ...and I would not compare the two.

But that's me...

That's exactly what I was saying - STL is like assembly and not like a high-level language (VB, C, etc). Assembly and STL are low level languages where you deal directly with the accumulator and address/memory registers.

The lower level the language the less removed it is from the machine code that the processor uses. The level of the language has absolutely nothing to do with the mnemonics used for the instruction. STL is hardly a low level language. If you were to run STL, or IL, or ladder for that matter thru a compiler that gave you an assembly language output file like a C compiler does, you would find that what you thought was a single low level instruciton generated several lines of assembly code.

(Also don't confuse a function library with a low or high level language. Technically, C is a lower level language, just a step above assembly but with a fantastically large library).


http://en.wikipedia.org/wiki/Low-level_programming_language

In computer science, a low-level programming language is a language that provides little or no abstraction from a computer's microprocessor. The word "low" does not imply that the language is inferior to high-level programming languages but rather refers to the small or nonexistent amount of abstraction between the language and machine language; because of this, low-level languages are sometimes described as being "close to the hardware."

Click to expand...

Take just an IO address for example. A common mistake is to confuse the IO address as referenced in a PLC program for the exact physical hardware address of the IO point. It is not. It is an abstraction of a memory location where the IO status was last saved by a part of the program that you didn't even have to write - it was all done for you by the compiler. It doesn't even resemble the actual memory address as it would be rendered in machine code, rather it is abstracted to something that is easier for us carbon based life forms to remember and work with. To top it off, you are probably working with a bit address more often than not. But your processor does not work with bits. It works with words (probably 32 bit.) That means that to determine the state of that single bit the compiler must generate code for the processor to exectue which includes a mask, an AND operation, and a comparrison, and two possible jumps based on the comparrison result. All of that is represented by a single abstraction, a simple mnemonic, that is incorrectly confused for the level of the language.

We could get into how most PLC languages are interpreted instead of compiled as well and what that really means for how many levels of abstraction there are between the language and the processor, but there is no need to beat a dead horse.

Yes, you're absolutely right. True assembly language has a one-to-one correlation between any particular mnemonic and the machine language opcode that it represents on whichever microprocessor you're dealing with. I guess what I was trying to imply is that STL is syntactically as close to assembly as you'll find for off-the shelf PLC programming packages (at least ones that I'm familiar with). If one really wanted to program a controller in pure assembly, then why bother with the overhead of a PLC? Grab your favorite microcontroller, some flash, whatever I/O interfacing circuitry is appropriate, etc. and go