Programming PLC's w C or C++

A frequent question I get from clients is: does anyone make a C or C++ complier (or whatever common HLL programming language is the daily favorite) to run on a PLC. I do not mean the standard IEC1131-3 which seems to have been implemented to limited degree by some vendors. STL as defined is a possible answer, if everyone implemented it.

For example, Omron cx-p 5.0 will support STL in function blocks. However you can not call another function block from inside the block. This is like driving a car with no steering!

I have a coworker who comes from the mainstream software world and he is concerned about such items as software version control, reusability of modules, structures, and good design practices. I can not argue with many of his points as they relate to good software development practices. There are many good software management tools that are simply not available in the PLC world (at least I have not found them readily available).

We are doing a project that will be sold multiple times with some customization being done for each customer. The software is quite complicated and maintaining separate copies of each program is cost prohibitive.

In my opinion ladder logic is, for the most part, a crippled form of p-code assembly language programmed visually. (Lightning rod anyone?) For many applications this is adequate and often the best solution to a problem.

My questions are: Have any of you written programs for PLC’s using standard HLL languages? Who produces these products?

I have a machine that has several options available. I've written the logic (in ladder) to allow for all options and have a single subroutine where they are enabled/disabled. Unfortunately the touch screen isn't as universal and there are 3 or 4 versions of some screens depending. My next step is to make the options enabled/disabled through a hidden locked screen since they wont actually work without the hardware anyway.

I have never used it myself, but I know that GE Fanuc PLCs support subroutines written in C. You need to purchase their "C Programmer's toolkit". That's about the extent of my knowledge on the subject. For more information, contact your GE Fanuc distributor or the GE Fanuc regional Applications Engineer. For New England, the AE is Dave Simoneau.

If you're interested in following up with GE Fanuc, PM me and I'll give you Dave's telephone number.

I agree with what you are saying about ladder logic. However, I will CAUTION you, the cure you are trying to find maybe a lot worse than the problem. Here's a few example of what people tried to do:

Case 1:

A complex program is writting to covert "generic" function block/structured text to ladder logic (multi-platform). The resulting ladder is so huge it won't fit on the PLC anymore and no online editing is available. Startup became hell on earth.

Case 2:

A somewhat clever solution is deviced using Excel to program step transiting than using VB/VBA to translate it ladder code. Again, no online editing and bug aplenty.

Case 3:

IT/PC guys don't understand ladder so they figured out how to access PLC memory using VB and done all higher level function using VB. Result: code impossible/imaccessable to electricans and control guys. won't answer phone call @ 2AM. Problem just dont' get fixed. Also, IT like to PUSH stuff onto PC running VB => zing! BanG! Crash!

I have experienced all the above and more. Sorry if I offended anyone since each solution's have its champions -- feeling are often hurts in the process as well. Some of the best PC programmer make the worst PLC programs.. <putting flame suits on>

I would suggest just document your ladder well using good common sense structure rather than using C/VB/Java/Starbucks ...

Have a look here.
http://www.controlmicrosystems.com/products/prod_scada.html

As harryting told:

Reusability of modules: Copy oldones and re-parameterize inside the block directly by real I/O. Do not use 'structures', help maintenance peoples use XREF-possibility.

That is good design practice in the PLC world. PLC world is different than PC world with C++ and others!

When pointering have used for structured variables, the speed lowering dramatically (even 10 times), startup time grows even 10 times and finally, maintenace gomes impossible for others than programmer itself.

In other hand, use something small, clear and well tested as followed TON-retentive timer for S7:

We,ve recently installed some new machinery controlled by a Sigmatek system DIAS PLC. (A few months ago I'd never heard of them either!)
The programming language they use is a form of C++. As I have lots of experience with ladder logic and none with C++ I find this kind of anoying, but if you're looking for a PLC programmed with C++ you may want to have a look at www.sigmatek.at

We use many different types of PLC's and the one best suited to your type is B&R. Function blocks are programmable in any IEC language as well as C. You can create user libraries with full version controls. I have ten different libraries I use in my projects. I have one project that has the source code for the libraries, then I import only the runtime modules for a real project. That way I have only one place for the source code of my library. Also you can have dynamic memory allocation - deallocation, pointers etc.. in C or their extensions to STL. www.br-automation.com

programming

a P stamp is a form of PLC but its not industrial it is for simple robotics its programable with a form of (basic) easy plug and play instructions you add the start time the stop time and distance but mostly its PLUG AND PLAY

http://bstamp.sourceforge.net/ it can also be used with Linux they are simple but useful in lots of apps

Siemens SCL

You can use Siemens SCL. It's a language like Pascal. You can create Functions and call funtions from other funtions.

Sincerely,
Forgoselo

The P-Stamp is a great little product. However, it does not fit into a company decision to have one world wide vendor with extensive European, Asian and North America operations.

Siemens seems to be ahead of most other large PLC vendors in implementing the various IEC 1131 languages. It has been over ten years since the IEC standard came out and the European companies seem to have best products for this. A full STL implementation as defined in the IEC standard would be very useful.

As Harryting’s reply points out, software products that do not provide debugging and online support using the original source are simply not useful in the PLC world (In fact they are not useful in most programming situations!). Picture trying to debug a VB program at the assembly language level (shudder)! The IT problem is something we all have to face and demonstrate why the IT products and code are a poor solution at the machine level.

Seppoalanen’s solution is an improvement, but now I have a separate copy of each module embedded in every program I produce. How do I manage this code if there are 40 variations on a given module in a single program? My best example was a board sorter with 16 bins. The PLC code had 16 identical blocks of code that required me to manually change a given rung 16 times. The equivalent in C is a single function called 16 times.

The PLC world is different from the land of C++, but there are many software tools available in the PC world that I would love to have.

I firmly believe ladder is the best solution for designs that are relatively short (Say 400-600 rungs). The problem is in life cycle cost management for large projects with thousands of rungs where the lifetime of the code is in decades and there are many people involved in developing and modification of the code.

Would we consider designing a complex machine using tools developed in the 1960’s? Then why do we build complex machines using ladder logic. We must innovate and seek less expensive solutions to stay in business or the world will find a different way that does not involve us...

Sorry for the length of the reply. And, yes I make most of my living writing ladder logic.

I advice you Siemens M7 automation systems. They have OS and work like PC. You can use C/C++ to program a M7 systems. No, I haven't got any experience with them.

Regards,
ceyhan

Frankly I am tending more to writing code that the so called "maintenance guys" DO NOT understand. The exact opposite of Seppoalenen's approach.

Why? Once the a system is past it's final acceptance stage, it either works, or it does not; either there is a bug that is still there OR an I/O device is not working as expected.

If it is a bug then who is actually qualified to fix it? A mainteneance jock on a graveyard shift, or the original programmer (or equivalently qualified individual)? If the system programmer missed the bug then your mythical maintennce jock is likely to make matters worse, not better. (Some of these people are very good, but most are not.)

On the other hand if it is an I/O condition or device doing something unexpected then although mucking around in the logic will eventually uncover the problem...it is MUCH faster and more effective if the logic includes a comprehensive diagnostic messaging in the PLC that announced the exact state of the object in question directly at the HMI level in a simple plain English text string.

Always writing code that is "simple enough for the maintenance guys to understand" is very limiting and in the long run inefficient.

APB said:

Siemens seems to be ahead of most other large PLC vendors in implementing the various IEC 1131 languages.

Click to expand...

WHAT !?

The ONLY Siemens programming language that conforms to IEC 61131-3 is SCL (confroms to Structured Text). All the other programming methods are Siemens-specific and do NOT conform to IEC 61131-3.

Even AB is better than Siemens to implement IEC 61131-3 (in the newer ControlLogix platform that is, not the older PLC5 or SLC500).