I'm finding little consensus on what a higher-level language is for more complex applications for discrete/machine control. Is it C#, C++ and scripting? Are there others in serious play? What can they do that 61131, for example, can't? Does most automation supplier programming software use higher-level languages for some purposes?

 

"More complex applications for discrete/machine control" can cover a lot of different things. It is difficult to give a single answer to a broad question. However, if we narrow the question to one of writing PC programs for non-real time things like typical test systems, data logging, and other cases where you are developing a custom program for one or a very few installations, then we can define the characteristics better.

In this type of application, I would suggest using a language which allows a quick development cycle, easy testing of code, and has extensive and broad library support. For libraries, what is more important than the just number of libraries is whether the libraries cover things that you think might be useful, but may not know how to do in detail. That is, look for things like advanced math, communications, database, etc. libraries. Don't worry as much about the things you are sure you could write yourself if necessary.

My own preferred language is Python. My second preference is C. You can of course use both in one project by calling C libraries from Python, although I would recommend trying to use only language throughout if possible (i.e. doing it in pure Python). C doesn't really lend itself to rapid development, but it meets the other criteria and there is a lot of information available on it. For me, it's a distant second choice, but I have written these types of applications in C.

If you are considering C#, then you should consider Java as well. C# is just Microsoft's proprietary knock-off of Java, so the two have a lot of similarity. Java has been around a while longer though, so it tends to be more stable. That is, you are less likely to have major incompatibilities between different versions.

I'm not a fan of C# or Java for these types of applications though. The problem is that they are not that big of an improvement over C/C++ as compared to more modern languages like Python. You still end up fiddling with a lot of details and writing a lot more lines of code than should be necessary. I would rather write a small program than a big program, so I look for a language that is going to save me some work. That isn't to say that there is no place for Java or C# anywhere, but rather that they are not necessarily the best tool for this sort of job.

Python, Java, C, etc. are general purpose languages. Automation vendors aren't really in that field. They tend to use what is already available. IEC 61131-3 has something called Structured Text (ST). ST is similar to Pascal or Modula-2. It is a classic structured programming language based on 1970s era language design concepts. If you are writing a custom PC application though, you don't really want to consider it. It is such an obscure language that library support is limited, development tools are few, and there is little to no general information about it available on the internet.

Another thing to think about when dealing with any software is that it is very convenient to be able to install as many copies as you want wherever and whenever you want without having to deal with activation codes and without having to convince someone on the other end of the phone that you aren't trying to pirate their software. That includes common third party libraries as well as development systems and run time libraries. Look for licenses that don't restrict you in this way. Most modern general purpose languages are free. The proprietary ones (e.g. C#) are the exception.

 

"I'm finding little consensus..."

Ha ha! You won't find consensus.

"Is it C#, C++ and scripting?"

Scripting almost never. C# is making some inroads, but it's still to young to have much market share. C++ is around. There's a sprinkling of Java. C is far away the most common "real" programming language in the machine control space.

"What can they do that 61131, for example, can't?"

In theory it is possible to do anything with 61131 that C / C++ / C# can do. You might start by writing a C# interpreter in structured text. In practice, C and other general-purpose programming languages are GENERAL PURPOSE, so they can do all kinds of things that 61131 can't. The entire STL comes to mind. Run time type identification in C++, or reflection in Java, are both impossible and utterly unneccessary in 61131. Of course, if all you want to do is control a machine, the general purpose-ness can get in the way without really helping you any.

"Does most automation supplier programming software use higher-level languages for some purposes?"

No. There are some, but it's a long way from most.

-James Ingraham
Sage Automation, Inc.

 

I think that BASIC, VB classic and VBA have been the majority so far. C has been used for an API, but not usually scripting. One advantage over 61131 is access to the Windows OS.

It is difficult to say if VB.NET will continue this tradition, or if something else will become popular. I haven't used them, but Python and Ruby seem to be popular in the PC world.

I would like to see BASIC used more as a scripting language. It has some popularity when extended into a motion control language.

BASIC has also been used on PLC cards as a co-processor, but typically an unstructured version has been implemented. These have been around forever, but are not wildly popular for various reasons. I suspect that Structured Text will make these cards obsolete.

Bill

 

Bill -

Some IEC-61131 software packages can call compiled DLLs, which in turn can have access to the Windows API - haven’t done it but it can be done.

Anyone have any experience in doing this to confirm??

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesign.com
Manufacturing Automation www[.]automationmag.com

 

Michael said: "IEC 61131-3 has something called Structured Text (ST). ST is similar to Pascal or
Modula-2."

Why does everyone say ST is like Pascal? Okay, it uses := for assignment and borrows some syntax. But that's where the similarity ends.

From Wikipedia's page on Pascal: "...build dynamic and recursive data structures such as lists, trees and graphs. Important features included for this were records, enumerations, subranges, dynamically allocated variables with associated pointers, and sets... allows nested procedure definitions to any level of depth, and also allows most kinds of definitions and declarations inside procedures and functions."

Does that sound like structured text? It sure doesn't to me.

"It is a classic structured programming language based on 1970s era language design concepts."

No argument there. Well, maybe a little. I'm not sure structured text is quite up to 1970s level language design.

-James Ingraham
Sage Automation, Inc.

 

I would add to Michael's excellent summary that
what the languages can and can't do is very much
a factor of the compiler/interpreter writers intent and what libraries are available. I would expect the Structured Text implementations to be much more limited in scope and intent while C can do pretty much anything the hardware is capable of. I'm not sure what is available for Python as far as libraries for automation work, but it is much more "high level" than C. Higher level languages are handier if the libraries exist for the platform.

You can do anything in C if you know the hardware. Otherwise you need to be able to write the libraries to extend the language. This might be impossible for a proprietary ST implementation. I hope that made sense.

Regards
cww

 

In reply to James Ingraham: "Programming Industrial Control Systems Using IEC 1131-3" by R.W. Lewis is usually considered to be the canonical book on the standard. In the chapter on Structured Text, the first sentence says "Structured Text or ST is a high level language which has a syntax that on first appearance is very similar to PASCAL".

Yes, I agree that ST doesn't have a lot of the features that Pascal has. However, the ST language designers clearly drew a lot of their inspiration from Pascal (or perhaps more accurately, from Modula-2). If someone understands Pascal, they will understand ST quite easily.

I have programmed with subsets of C. Certain features were sorely missed, but it was still recognisably C.

 

There is now an OPC client library available for Python language, making it usable for many automation scripting tasks.

You can download it from here:
http://openopc.sourceforge.net

 

Very interesting project, Barry!

I thought I would mention the OpenSCADA project (http://www.openscada.org) and their OPC for Java library. It runs natively in Windows and Linux. We use it in our open-source data logger called PlantStreamer (http://www.plantstreamer.com) and the library works very well.

Best Regards,
Andrey Romanenko
Ciengis - Advanced Process Control

 

Michael Griffin, quoting "Programming Industrial Control Systems Using IEC 1131-3" by R.W. Lewis:

"Structured Text... has a syntax that on first appearance is very similar to PASCAL".

"Syntax" and "on first appearance" are the key phrases to me there. What he's saying is that there is a superficial resemblance. Which is what I say.

Thank you; you have, in fact, answered the question of why everybody says ST is "like Pascal." They are misquoting! Much like how Kirk never actually said "Beam me up, Scotty!"

-James Ingraham
Sage Automation, Inc.

 

We are building our entire system with python, and so far we've encountered many advantages and no drawbacks.

We are planning to test and release, hopefully in september, a complete RTU: A python program that runs in any linux-PC and controls a whole plant, using modbus tcp/ip acquisition modules. It will control the plant, log data, send logs via ftp, and alarms via email. After that an HMI will come.

We dont use ladder, modules, IECxxx to build logic to proccess inputs and determine outputs: a simple python program. Easy to understand, easy to debug, easy to maintain...

Dont hesitate, switch to python!

 

I've gone ahead and taken Barry's package, and made what I call a 'textual front end' (classy name for 'badass wrapper') called mod_openopc.

You can download it at http://spinellicreations.com/sc/projects/04_mod_openopc.shtml

The latest version is v.2.1-2 (build #25) and will be posted within the next week. It utilizes OpenOPC version 1.1.6 for super duper killer robust comm. It's in pure Python (2.5), intended for Linux or any of the Unices (BSD anyone?), while your OPC server program (in our case Rockwell RSLinx) sits on a Windows virtual machine (VMWare Server is free, so is Qemu and others).

Basically you setup presets for reads to dump data to MySQL db's at your whim. Then you setup presets for 'recipe' dumps of writes (for example "load all settings for this particular job", click 'enter'). There are also write and read daemons that will sit and watch for file system events, when they occur they will read or write to a PLC or other OPC device immediately. We've passed 30 days without intervention and had no issues, pull something like 400 tags per minute at the moment, but intend to scale up into the thousand + mark in the near future -- we bought enough hardware 'ass end' to run a sick amount of data i/o. Nice thing is, it's also got a built in bridge, so you can take data from a modbus network, or a data highway network, or a 'whatever the heck' network and then message it over to ethernet or modbus or dh or whatever seamlessly.