Cross compiling C to IEC 61131-3

That would seem a bit silly at first glance. Unless you are talking about a C algorithm in one thread you are trying to port apples to oranges because the execution model of IEC61131-3 is not defined. That is to say that there is no set process or thread model for IEC languages, it is left for the vendor to implement which can vary drastically. Maybe there is something to be done with a specific vendor, who knows?

Just curious, but why port the code? Couldn't you just move the C code to another platform with IO?

KEJR
 
> why there is no any C to IEC 61131-3 cross compiler on the automation market?

No one in the control market seems to be interested in reverse
engineering :)

Regards
Armin Steinhoff
 
I do not know the answer, but as a guess it is likely because this spec was largely influenced from Europe where "C" is not popular in the industrial world.
 
B

bob peterson

There is no C to RLL cross compiler because there is no real need and there are a lot of things you could do in C that would be very hard to do in RLL. I am not sure it is even possible.

A lot depends on what your C code is doing. If it is simple control stuff, a competent RLL programmer could probably convert it pretty quick. Most of the work in coding is really not coding so much as figuring out how the miserable machine actually has to work and once that is done, the C code might well be pretty good documentation for creating RLL.

Some of this depends on the skill of the C programmer and how well he documented the code. A lot of C programmers seem to take great delight in writing code that is gibberish.

--
Bob
 
> why there is no any C to IEC 61131-3 cross compiler on the automation market?

It is impossible. To be short: the IL language is a 4GL (i.e. limited to the domain, as well as other IEC 61131-3 languages -- ST, FBD, LD, SFC). The C language is a 3GL.

To understand the problem, try to answer the question, which way to express in IL manipulations with a pointer? for example, to express call a function by a pointer. What about interrupts? Low level access to the peripheral devices?

(really, there are more problems)

BTW, there is the Reflex language, aka "C with processes", a 4GL for the
control domain with C-like syntax. But the known translators produce
C-code and Python-code.
--
Best regards,
Vladimir E. Zyubin
 

> That would seem a bit silly at first glance. Unless you are talking about a C algorithm in one thread you are trying to port apples to oranges because the execution model of IEC61131-3 is not defined. That is to say that there is no set process or thread model for IEC languages, it is left for the vendor to implement which can vary drastically. Maybe there is something to be done with a specific vendor, who knows?

> Just curious, but why port the code?

IMHO ... porting the code makes no sense. A better practice is e.g. to compile the C-code into a shared library (or DLL, shared object) and link dynamically against it. POSIX dlopen, dlsym a.s.o function blocks helps to run that code.

With a fast embedded C compiler you could also compile the C-code at the initialization phase of the application into the memory in order to call it in a "user defined" function block. (possible in DACHSview programming environment
So you get excellent speed and zero porting efforts.

Best Regards
Armin Steinhoff
http://www.steinhoff-automation.com
 
Its not a question that makes sense.

IEC 61131-3 is a specification about programming languages i.e. ST, FBD, SFC, IL and LD. How these get "compiled" depends on the architecture of your processor.

"C" (and variations) also are specifications about programming languages. Again, C source code gets compiled into an executable suitable for a particular processor.

You don't compile C or IEC-61131-3 into another language, you compile them both into processor specific executable files.

Cross compilers compile the same Source code onto multiple hardware platforms. They don't translate between languages.

If you mean "is there a specification for translating C source code into IEC61131 source code code" then NO, that would be as silly as translating C++ into Visual Basic i.e. Theoretically possible but difficult and pointless because languages do different things in different ways, some better than others.

If you mean "Is there a PLC that supports programming in either C or IEC61131" then google is your friend.

And I think we've all seen spaghetti code written in IEC61131 as well :)

Rob
www[.]lymac.co.nz
 
Rob, you are absolutely right.

I have to make the question more clear.

I am wondering, why there is no "source-to-source" compiler from ANSI C to any PLC programming language IEC 61131-3 (IL/LD/FBD/ST/SFC).

Rob wrote:
"that would be as silly as translating C++ into Visual Basic i.e. Theoretically possible but difficult and pointless because languages do different things in different ways, some better than others."

Programming in C is much easier, faster, well suitable for embedded systems AND...it is standardized long time ago (ANSI C89,C99...). PLC programming in C resolves problems with porting software between different PLCs, SBC, PC104 etc., to maintain and replace old systems. As a result, programming in ANSI C (based on set of libraries for specific PLC) and "source-to-source" compiling to specific PLC can improve the quality of PLC programs and save money of industrial investors. But... it may cut the income of PLC makers because of increasing of competition among them. So, may be this the true answer why.

I think, it is really "the way to go" to open boundaries, established by major players on automation market.

So, let's discuss here the technical issues only.

***************************************
Issue#1. "VAR_INPUTs and VAR_OUTPUTs" in PLC programs:
@ they are naturally one bit values and expressible by BOOL type.
***************************************

Issue#2. "IEC 61131-3 spec was largely influenced from Europe where "C" is not popular in the industrial world":

@ there are quite big makers from Europe, who made a C-like(STL)-programmable PLCs:
Siemens, B&R, Beckhoff;
http://forums.mrplc.com/index.php?showtopic=16159&view=findpost&p=79916

http://forums.mrplc.com/index.php?s...e2252fc&showtopic=16159&view=findpost&p=80116
***************************************

Issue#3. "Writing the code in what is best for you is best to develop, but not to have a marketable and servicable product."
Posted 17 March 2009 - 03:09 PM by BobLfoot
http://forums.mrplc.com/index.php?s...e2252fc&showtopic=16159&view=findpost&p=80028

@ the "source-to-source" compiler from ANSI C to any PLC programming language IEC 61131-3 (IL/LD/FBD/ST/SFC) allows efficient developing in C with final output as IL/LD/FBD/ST/SFC-programs. Nothing to be destroyed but resolved.
***************************************

Issue#4. As Vladimir E. Zyubin wrote: "..which way to express in IL manipulations with a pointer? for example, to express call a function by a pointer. What about interrupts? Low level access to the peripheral devices?"

@ pointers are not the magic, they are just pointers. :). Porting C to Java based on switching to indexes, same here, as well (as you know, a lot of systems allow addressing by indexing).
@ interrupts? it is not a part of programming language, not a part of ANSI C at all :) same for "low level access to the peripheral devices".
 
The interesting issue has been resurrected :)

> I am wondering, why there is no "source-to-source" compiler from ANSI C
> to any PLC programming language IEC 61131-3 (IL/LD/FBD/ST/SFC).

1. Well, IEC 61131-3 doesn't specify necessary details that could provide the cross-brand compatibility for graphical languages (so called FxF problem, file exchange format). So, let forget FBD, SFC, LD at all. AFAIK, from the compatibility point of view the less problematic language is IL. So, you are absolutely correct when have mention it as a target language.

2. Look at the facts. ST looks like Pascal, but it is not Pascal. It is not a bad intentions of the IEC 61131-3 team. ST is a 4GL with Pascal-like syntax because of specific features of the domain. The same way C is needed to be prepared to be used as a mean for control algorithm description.

3. I just realise I can not catch what features do you plan to achieve by the hypothetical translator. If you think pure C best fits to create an control algorithm, I can not agree, I think it is a very disputable believe.

> @ pointers are not the magic, they are just pointers. :). Porting C to
> Java based on switching to indexes, same here, as well (as you know, a
> lot of systems allow addressing by indexing).

I suspect IL does not have such a feature.

> @ interrupts? it is not a
> part of programming language, not a part of ANSI C at all :) same for
> "low level access to the peripheral devices".

Alas, it is a part of a control algorithm. In the IEC 61131-3 these things are made by the core systems, and are hidden from the programmer. So, C is needed to be enhanced to provide the features ether by libraries (an issue of incompatibility) or by syntax/semantics (it makes the language to be different from C and possibly means somebody will reinvent the Reflex language :).
--
best regards, Vladimir E. Zyubin

 
I knew this topic wasn't going to die so easily. Now that we're all talking about the right thing i.e. translating from one language to another, we can talk a bit more generally.

A large part of my company's core business is control system upgrades, which by definition is translation of code from one PLC to another, so its something we have more than a passing familiarity with.

We all agree that translating from any language to another is always theoretically possible. We know this is true because ultimately everything gets compiled to a set of processor instructions which can be de-compiled back into a source language. Of course when this happens, information useful to the programmer like comments and symbol names will typically be lost.

Translating form one language to another requires that we apply a set of rules to transform each individual source language statement to the target language statement. The more similar the language, the simpler the transform rules. When the languages perform operation in different ways then the rules become more complex. Creating rules that do something complex like translate C's pointers into COBOL are obviously much harder and much more likely to produce unreadable COBOL code. It's at this point that the whole translation process becomes "silly", that is the resulting code can be compiled but it too complex to be of use to the programmer.

Technically, can converting from c to IEC61131 be done? Yes, of course it can. Is it commercially viable to do this by a generic source code translation tool? Well, that depends on the size of your project. If your project is big enough then its possible that the returns of automating the translation process become economically viable. And yes, there are commercial code translation tools available but they are not a magic solution.

And don't forget to add in that the IEC611 "standard" is anything but standard. Its only perfectly standard for your particular PLC.

Our approach is typically to automate some of the translation process to save the simple and repetitive tasks of identifying and translating the obvious function blocks in a program. (this works because DCS systems are typically very repetitive). Completing the process at a commercially acceptable cost is much better achieved in our typical project size by performing the rest of the process manually.

So, why are there no commercial products for translating C to IEC61131 without manual intervention? Because its too expensive to justify the quality of the results based on the size of the likely market.

Rob
www[.]lymac.co.nz
 
> We all agree that translating from any language to another is always
theoretically possible.<

Theoretically maybe "yes", but practically? Imagine just C2C convertion of the Acrobat Reader Win 7 source code to DOS 6.xx platform?

> ...It's at this point that the whole translation process becomes "silly", that is the resulting code can be compiled but it too complex to be of use to the programmer. <

As far as I understend the idea is to write an algorithm in C and run it (the algorithm) on a Siemens's/ABB's/Allen Bradley's/etc's PLC. That is not silly as a theoretical idea, but in my opinion it will be more simple (less expensive) to introduce C as 6th language of the IEC 61131-3 standard. :)

> Technically, can converting from c to IEC61131 be done? Yes, of course it can.<

It depends on the target code size. It will produce innormously large
code. Another theoretically possible(?) solution assumes an artificial
intelligence module to recognize human logic of the C code :)

> And don't forget to add in that the IEC611 "standard" is anything but standard. Its only perfectly standard for your particular PLC.<

Bravo!

> ...Completing the process at a commercially acceptable cost is much better achieved in our typical project size by performing the rest of the process manually.<

Right, if we speak just about cross-brand porting without changing of the source language. In the case of language changing I believe the only way is manual rewriting of the algorithm.

> So, why are there no commercial products for translating C to IEC61131 without manual intervention? Because its too expensive to justify the quality of the results based on the size of the likely market.<

I'm afraid, performing the correction of IL code generated by the
hypothetical C2IL translator is impossible (practically).

--
Best regards,
Vladimir E. Zyubin
 
Can't you try efb toolkit from schneider ; it's not a general solution but you can develop some c function and integrate it to iec61131 languages.
 
> I knew this topic wasn't going to die so easily. Now that we're all talking about the right thing i.e. translating from one language to another, we can talk a bit more generally.

A large part of my company's core business is control system upgrades, which by definition is translation of code from one PLC to another, so its something we have more than a passing familiarity with.

We all agree that translating from any language to another is always theoretically possible.<

Sorry ... that not the case. It is impossible to translate a recursive algorithm written in C to a ladder logic algorithm e.g. The translation process is in general only possible if both languages are able to support the same class of algorithms.

>We know this is true because ultimately everything gets compiled to a set of processor instructions which can be de-compiled back into a source language.<

No, no ... not every algorithm written in assembler can't be decompiled to ladder logic.

>Of course when this happens, information useful to the programmer like comments and symbol names will typically be lost.

> Translating form one language to another requires that we apply a set of rules to transform each individual source language statement to the target language statement.<

That's impossible because of the fact that the number of possible statements expressed by C e.g. is infinite

>The more similar the language, the simpler the transform rules. When the languages perform operation in different ways then the rules become more complex.<

The next big problem is the sematic expressable by different
programming languages.

>Creating rules that do something complex like translate C's pointers into COBOL are obviously much harder and much more likely to produce unreadable COBOL code. It's at this point that the whole translation process becomes "silly", that is the resulting code can be compiled but it too complex to be of use to the programmer.

> Technically, can converting from c to IEC61131 be done? Yes, of course it can.<

It isn't possible for all languages defined by the IEC61131 standard.

>Is it commercially viable to do this by a generic source code translation tool? Well, that depends on the size of your project. If your project is big enough then its possible that the returns of automating the translation process become economically viable. And yes, there are commercial code translation tools available but they are not a magic solution.

And don't forget to add in that the IEC611 "standard" is anything but standard. Its only perfectly standard for your particular PLC.

Our approach is typically to automate some of the translation process to save the simple and repetitive tasks of identifying and translating the obvious function blocks in a program. (this works because DCS systems are typically very repetitive). Completing the process at a commercially acceptable cost is much better achieved in our typical project size by performing the rest of the process manually.

So, why are there no commercial products for translating C to IEC61131 without manual intervention?<

It isn't why it is simply not possible :)

Best Regards
Armin Steinhoff
 
J

James Ingraham

"We all agree that translating from any language to another is always theoretically possible."

Well, we don't ALL agree. Certainly I don't. While it's true that "ultimately everything gets compiled to a set of processor instructions," there's more to it. For example, certain processor instructions may be specifically hidden in a given language. Here's a simple one: "sleep(1);" How, exactly, are you going to translate that to ladder logic? It doesn't make any SENSE in ladder logic. How about printf? Where is errno? And don't forget that C has a Standard Library. There is absolutely nothing in the IEC 61131 spec that requires a system to have a square root function, much less qsort and bsearch. (BTW, I've implemented bsearch in ladder logic, and it's not too bad. But a C to RLL source translator would hit the bsearch function and have no equivalent. So it would have to know the THEORY behind bsearch, or else have access to the bsearch function source code. Neither is necessarily achievable.)

Let's take a simpler example. Following the JSF C++ standard, exceptions are explicitly disallowed. You cannot possibly convert C++ with exceptions to JSF C++. Even if you create code that boils down to the same processor instructions, any JSF C++ compiler should refuse to generate the code. (There's not actually such a thing as a "JSF C++ compiler" of course, although there are static analysis tools that will check against JSF C++ or MISRA C or whatever.)

"...which can be de-compiled back into a source language."

Well, sort of. This is like a hash; several "inputs" can result in the same "output." So there is no way to UNIQUELY de-compile to a source language. And again, some languages may specifically prohibit certain instructions.

An interesting side-effect of your statement that languages are (eventually) equivalent is that HARDWARE is equivalent. In other words, any modern program could theoretically be ported to run on ENIAC or a Timex Sinclair, even if millions (or trillions) of times slower. There is, of course, the storage problem, for registers, RAM, and mass storage, but it's an interesting thought nonetheless. Could my old TRS-80 run Quake, even at 1 frame per century? I actually don't know the answer to this. I'm curious to hear people's opinions about it.

-James Ingraham
Sage Automation, Inc.
 
James, I think we pretty much agree here. When I said "theoretically" I meant that if you have enough monkeys, enough typewriters and enough time then it can be done in a period less than infinity. And no, the results won't be pretty :)

hmm, sleep(1) translates to something like T_Off(1 Sec) followed by Jump to end of program. The code would get really ugly without a jump instruction and you would have to turn off every rung individually. Yes, you're right - It makes absolutely no sense. I think that was my point as well.

Yes, in principle your T80 can run the equivalent (but obviously not the "same") instructions that make up "Quake" on your PC given enough time - Both are fundamentally Turing Machines. Again, its the enough monkeys, enough time argument. But as pointed out, without hardware equivalence in the peripheral devices (like say a graphics card) the output is not in a form that makes it fun to shoot zombies.

And with that, I'm off to play Call of Duty :p

Rob
 
J

Jeremy Pollard

Silly answer - because there isn't :) it is in no ones interest to provide that capability. Reusable C code that can compile down to structured text may be the only option ... file formats are proprietary!!


Cheers from: Jeremy Pollard, CET The Caring Canuckian!
Crisis, necessity, change
www(.)tsuonline.com

Control Design www(.)controldesignmag.com
Manufacturing Automation www(.)automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579
 
Top