High-level programming language for PLC

  • Thread starter Oleg Gudovannyy
  • Start date
O

Thread Starter

Oleg Gudovannyy

Hi, all!

Please, inform me about using high-level programming languages for PLC. It's true? Who is vendor? Which industries?

Thank in advance, Oleg.
 
J

James Ingraham

"Please, inform me about using high-level programming languages for PLC. It's true?"

Depends on what you mean. Does C count? In that case, B&R, Siemens, and GE have PLC cards that can run C. Heck, even Allen-Bradley can do it, with an add-on card from a third-party vendor. Several companies used to have BASIC modules as well, although we can again argue whether that's high level by today's standards.

Is there a PLC in which you can freely mix-and-match traditional languages like relay ladder logic with modern high level languages like Java, C#, Python, Ruby, etc.? Not that I'm aware of. Anything that can handle that kind of stuff is really a PC with some PLC functionality, not the other way around.

"Which industries?"

There's no industry that uses predominately PLCs that also uses even a significant fraction of high level languages.

-James Ingraham
Sage Automation, Inc.
 
In reply to James Ingraham:

Do all of those PLCs run "scanned" C? That is to say are these C programming languages like structured text in that they are expected to return every scan? I only mention this in the case that the original poster wants more of a traditional multithreaded system with procedural programming in a high level language. To my knowledge there aren't any traditional PLCs that can do this, at least in realtime speeds.

We are now using Delta Tau PowerPMAC system which is not a traditional PLC but it does include a hard realtime OS, motion control, and digital/analog IO. They have is set up so that you can have multithreaded apps with their program model, or you can write your own with Posix threading routines (Linux scheduler or Xenomai realtime kernel). Although it has taken me longer to set up this system, the next machine we do will benefit from code development since you can create your own C fles and they are just text files that get compiled (as opposed to cutting and pasting text into a ladder or SFC "block" in a PLC editor).

KEJR
 
J
Motorola's products, the now-discontinued MOSCAD and the current RTU product ACE3600, can have both ladder logic and C at the same time... I do this regularly. Of course, this is an RTU, not a PLC.

jackD
 
C

curt wuollet

C isn't really a HLL, but it's an absolutely excellent choice for writing to hardware for drivers and well suited for PLC work. Mostly because it's not a HLL.

RLL _is_ a high level language, not because relays are particularly sophisticated, but because it is generally written with graphical symbolic elements that can generate whole subroutines and abstract their underlying function. But like most high level languages, you can only do what is built in, whereas C can do nearly anything the hardware is capable of. It is generally used as a portable assembler with hardware. just one level above the machine language. It's about the lowest level that can be reasonable common across architectures.

Regards
cww
 
Hi,

I have seen already ~15 years ago a PC board as PLC slot card for using High-level programming languages for a PLC.
The PC had just synchronized access to the process data of the PLC. It was an old Siemens S5 PLC ...

Regards

Armin Steinhoff

http://www.steinhoff-automation.com
 
D

David Farris

Not sure if it qualifies as a "High Level Language", but the IEC61131-3 standard is supported by many RTU/Hybrid PLCs and offers both graphical languages and text based languages similar to C. I find that some task are better suited for one language over another. The 1131 environment allows me to perform the required task in the language that best fits the need. I especially like the ability to define my own data types and structures of those data types, much like classes in higher level languages.

David
 
I tend to think of high level code as a language with the ability to have rich function calls, libraries, and data structures. Although C is very close to hardware I think it qualifies. Its definitely not a RAD language though. When you are doing high performance work RTOS class work, C (and to a lesser extent, properly programmed C++) is kind of the common denominator.

Again, I'd like to state that there is a differentiation between procedural programmed multithreaded environment and IEC61131 on a PLC. As far as I know all vendors of PLCs that have IEC61131 are basically compiled front ends for their scanned instruction list code. You still have the inherent issue of "programming like ladder" even though it is another language. Certainly with structured text math and some logic is easier, but other than that it is programmed like ladder in that you can't block in a function call. That is to say they expect you to scan through any ST code and return from it or else the watchdog trips. I laugh when I see ST examples in a help file and it is just a long winded version of ladder... What’s the point? In my work with PLCs I tend to use ST for calculating things and for complex logic statements. Other than that ladder (with function block calls) is better for discrete sequencing work. Give me C/C++ anyday though....

KEJR
 
> I tend to think of high level code as a language with the ability to have rich function calls, libraries, and data structures. Although C is very close to hardware I think it qualifies. Its definitely not a RAD language though. When you are doing high performance work RTOS class work, C (and to a lesser extent, properly programmed C++) is kind of the common denominator.
>
> Again, I'd like to state that there is a differentiation between procedural programmed multithreaded environment<

You mean event oriented processing ?

> and IEC61131 on a PLC. As far as I know all vendors of PLCs that have IEC61131 are basically compiled front ends for their scanned instruction list code. You still have the inherent issue of "programming like ladder" even though it is another language. Certainly with structured text math and some logic is easier, but other than that it is programmed like ladder in that you can't block in a function call. That is to say they expect you to scan through any ST code and return from it or else the watchdog trips. I laugh when I see ST examples in a help file and it is just a long winded version of ladder... <

You laugh because of processing by polling ?

> What’s the point? In my work with PLCs I tend to use ST for calculating things and for complex logic statements. Other than that ladder (with function block calls) is better for discrete sequencing work. Give me C/C++ anyday though....

IMHO ... your point is not related to a high level language. The differentiation is polling vs. event oriented processing (with blocking operation)

Regards
Armin Steinhoff
 
Armin,

No, I don't mean event processing. I said a multithreaded environment with a procedural language, such as C with pthreads or proprietary RTOS. So I would say that my argument is Multithreaded vs. Scanned processing.

My original point to the original poster is that to not expect a PLC [at least to my knowledge] with "A high level language" to act like a multithreaded environment, its more like a scanned based PLC with other languages included. It's a big difference from someone who comes from a computing background and wants to get into control projects.

I laugh at the Structured text examples because they tell you that they have a nice high level language and then the prime example in how to use it is to make it into a wordy version of ladder programming. Then when you read further into the documentation and manuals there are hints that "structured text is good for calculations" and really, that is all I find it good for.

KEJR
 
If you're looking for a PLC-like package that can be programmed with conventional computer languages then I believe that Advantech has versions of their Adam-5000 and APAX-5000 which can do this.

As Curt Wuollet said however, ladder logic *is* a high level language, and is higher level than C, C++, Java, C#, etc.

If what you really want to do is to write programs in (for example) C to control a machine, then look at 32 bit single board computers or mini-ITX PCs running Linux. These come in various form factors and you can use a solid state drive to avoid having moving parts. For I/O, use Ethernet I/O with Modbus/TCP.

There's no point in using a PLC-like package if you are not going to use the vendor's own ladder programming tools. You're paying a premium and accepting the vendor lock-in on the hardware in order to get a package that runs ladder out of the box. If you're not going to make use of that, then there's no point to using it.
 
> If you're looking for a PLC-like package that can be programmed with conventional computer languages then I believe that Advantech has versions of their Adam-5000 and APAX-5000 which can do this.

> As Curt Wuollet said however, ladder logic *is* a high level language, and is higher level than C, C++, Java, C#, etc. <

Ladder logic is based on a graphical representation of expressions of the boolean algebra. Each expression represents a rule.

Such sets of rules is only able to express a restricted set of algorithm. That means its level isn't higher than C, C++, Java or C# ...
it is a low level rule based scheme of boolean expressions.

Regards
Armin Steinhoff
 
In reply to M. Griffin,

> If what you really want to do is to write programs in (for
> example) C to control a machine, then look at 32 bit single
> board computers or mini-ITX PCs running Linux.

I think we have been here before. ;) The PLC hardware is very attractive [to some] from an IO and form factor perspective. I think a lot of people feel more comfortable with a shrink wrap package and support network from their vendors.

The other problem with this (you might elaborate since you know more about modbus than me) is that some modbus TCP devices seem to expect a 5ms polling rate. This is just not fast enough for high speed work in fast assembly, robotics, and/or semiconductor production.

So lets look at what we are talking about for a high speed machine controller:

- Linux with RTOS (or PREEMPT_RT) for high speed and deterministic work

- Dedicated ethernet for IO work. This probably wants to be a realtime driver running in a high priority task.

- Second ethernet (and/or USB/serial) for programming and conventional networking.

- Special and/or customized distribution which does the read only filesystem stuff.

- (ideally) Motion control network and drivers for interface to servos (EtherCAT???).

I think all of these can be had and work well, but the average Joe is going to have a hard time setting up all of these components, test them, and support them on the job while building machines at the same time.

Don't get me wrong, I would love to see all of this come together and thrive as a community. Maybe there is a market for this, a sort of multitasking linux based "Arduino" of the automation world where all of the pieces are put together in a nice format that has been pre-tested and the low level drudgery already dealt with. Maybe the business model is the support contracts for the people who need the help but can't hire someone full time and/or custom additions to the software.

So until that time comes I'll be using purchased hardware/software since I have limited time to develop these things.

KEJR
 
Armin Steinhoff said: "Ladder logic is based on a graphical representation of expressions of the boolean algebra. (...) Such sets of rules is only able to express a restricted set of algorithm. That means its level isn't higher than C, C++, Java or C#"

No, that's why ladder *is* a higher level language. It incorporates assumptions about the problem domain into the language itself, so that you don't have to deal with them explicitly. That is why a ladder (or IL) program requires much less code than an equivalent C program. On the other hand, once you step outside of the domain that ladder (and IL) was designed for, you will find many problems impossible to solve with ladder (or IL).

The "low level language" versus "high level language" debate is really a 1960s era concept when people were debating the merits of Fortran versus assembler. Today it's really a multi-dimensional issue with some languages being better suited to some applications than others. You have to pick the right tool for the job which is why it's impossible to give a definite recommendation in response to the original question.
 
C

curt wuollet

I think when you add in comms, PID loops, shift registers, drum sequencers, etc. you're up a level since these would have to be constructed from primitives it C. But, it's certainly debatable. There is also that it is somewhat application specific to control. These are high level functions. For example, Progress and most 4GLs are pretty specific to reporting from databases. 5GLs are almost exclusively database tools, QBE, etc.

Regards
cww
 
C

curt wuollet

That's interesting, since an "arduino" approach to Linux control is easily doable. All that is needed is a suitable PLC form factor platform (which I've designed, sans packaging, which would be spendy in low quantity), a group or community to write an "automation language" like Arduino's Sketch, and a push. The only problem I see is that the target audience is quite small and extremely hidebound and Ludditic, so it would be hard to achieve the "viral" phenomena that Arduino did. Still, It's a goal I have been working towards. MAT was aimed at the software end, but turned out different. An automation language that just hides the nasty details like Sketch would fit well on top of a PLC like engine analogous to the simple loop used in Sketch. In fact, the original simple PLC I wrote and the _intent_ of what became MAT, was pretty close to that. Simple, small, and above all, letting you concentrate on the logic, not the execution. It's not much of a technical challenge, it's an acceptance challenge. As even you expressed, there's not much pioneering spirit in our ranks. If there were pent up aspirations to do Open Automation, and an audience willing to invest a bit of time and try it, it could be a real option very quickly. Without those, it will take years.

Regards
cww
 
In reply to Ken E: Look at the context of the original question. Someone wanted to program PLC-type hardware using a "high level language" (presumably he meant something like C). No performance specs were stated. Typical run of the mill PLCs are not deterministic or real time in any way, shape or form. Scan times for the typical PLCs actually running in factories today are in 10s of milliseconds, and that rate can vary from scan to scan by 10%, 50%, 100% or more. Many PLCs have default watchdog timers set to 300 msec, and users rarely change them. Now evaluate the answer I gave within that context. If the user has some special requirements beyond that, then he needs to state them.

To deal with some of your other points:

>The PLC hardware is very attractive [to
>some] from an IO and form factor
>perspective. I think a lot of people
>feel more comfortable with a shrink wrap
>package and support network from their
>vendors.

The big problem you have when looking to program that sort of hardware in C (or Java, or whatever) is that PLC type hardware which will allow this tends to be niche products with very little market share. Long term availability of hardware is a problem, making repair and replacement difficult. If you are going down that road, you should try to stick with hardware that is less specialized so that you can find some sort of compatible replacement 5 years from now. Small form factor PCs probably fit that the best. Yes, this would require more configuration and installation work, but on the other hand they would require much less work than redoing the entire application from scratch because the original niche hardware is no longer available.

>The other problem with this (...)
>is that some modbus TCP devices seem
>to expect a 5ms polling rate.

That's a combination of two things - low cost microprocessors have limited CPU power and so can only process messages so fast. The other is that basic laws of physics such as capacitance limit how fast the transistors in the I/O will react (given the noise suppression capacitors installed), how fast a typical off the shelf proximity sensor will switch, or how fast a pneumatic valve spool will shift. All industrial I/O makes similar trade-offs with regards to price, performance, expandability, etc. The TCP stack itself is rarely the bottleneck.

You will find by the way that a lot of process industry hardware will poll at a 300 msec rate. There is nothing in the protocol which dictates that, it's just what customer demand in that market seems to be looking for.

>This is just not fast enough for
>high speed work in fast assembly,
>robotics, and/or semiconductor
>production.

If's fast enough for most people and it's as fast or faster than the I/O cards in most PLCs. Products are designed to fit markets and the examples you gave are all niche applications. They might happen to be the niche that you are familiar with, but they're not mass market I/O.

One thing you have to keep in mind in applications is whether you can poll I/O one at a time in series or in all together in parallel. Some bus systems require each I/O module to update in sequence, which means that if you have multiple modules the update times for each are additive. Other bus systems allow you to update all the modules in parallel, so the overall update time is no longer than the slowest module. Since 100 mbit Ethernet is like a firehose compared to the amount of I/O data going through it the network bandwidth capacity isn't going to be the bottleneck unless you have an exceptionally large system with everything on one network.

Another problem is that some protocols have very small maximum message sizes which means that larger I/O blocks may take multiple message cycles to update. Some protocols try to get around that by just sending data that changes, but in high speed applications *most* of the data is going to change very rapidly unless you happen to be lucky enough to be able segment your I/O just right. That means the "just send the updates" algorithm will fall over because you have to send more updates than will fit in a single message anyway.

So, when we're talking about speed, you can't look at just the specs for individual modules. You have to look at how the system will behave as a whole.

>So lets look at what we are talking
>about for a high speed machine
>controller:

You're making a very big assumptions when you state that he wants a high speed real time controller. Your laundry list doesn't match what he asked for. He asked for a PLC that can be programmed using a language that he is familiar with. Typical PLCs are not real time and they're not high speed. There may be some which are, but they're not controlling the bulk of the machines that are running in factories today.

Somebody who can actually make use of a real-time controller with microsecond response times isn't going to be posting questions here about whether he can find PLC hardware that he can program in Java. He's going to already know the answers because he has enough experience to know what is available.

Let's look at the Siemens S7-22x PLC. It's not their most recent or most expensive product, but I have the specs handy and they sold *lots* of them. One floating point divide operation takes 0.3 to 0.36 milliseconds. A square root operation takes 0.725 to 0.8 milliseconds. Typical word operations take 0.03 to 0.05 milliseconds. A timer takes 0.06 milliseconds. Now do a bunch of those and then the I/O operations bottlenecks don't look so slow after all. Boolean operations are much faster, but look up "Amdahl's law" if you want to see why faster boolean execution times are not really that important.

You can no doubt find faster PLCs. You can also find slower PLCs. The fact is though that for 99% of the market PLCs became fast enough 15 or 20 years ago so that speed was no longer a meaningful issue in typical applications. The biggest speed boost that most people saw was when the starting using multiple cheaper (and nominally slower) PLCs to replace centralised PLC systems. What people want today is features, price, and being in stock at their local distributor. What I would like to see most today isn't more speed, it's an easier ability integrate PLCs into the overall plant rather than sitting in isolation.

What you consider to be "high speed" I consider to be a niche that sits between general purpose PLC compatible I/O and data acquisition boards that operate in the megahertz. That's a pretty narrow niche that might be important to the people who are in it, but it's not that important to the market as a whole.
 
On M Griffin's:
TA> The "low level language" versus "high level language" debate is
TA> really a 1960s era concept when people were debating the merits of
TA> Fortran versus assembler. Today it's really a multi-dimensional
TA> issue with some languages being better suited to some applications
TA> than others.

it seems we try to give an answer on incorrect questions. But answer is strongly depended on the application.

The searching language could be some of the IEC languages
or LabVIEW
or C
or Java
or MSRS
or something else

and the main question is not "high" or "low", but fit or not fit the application requirements.

--
Best regards,
Vladimir E. Zyubin
 
>> Armin Steinhoff said: "Ladder logic is based on a graphical representation of expressions of the boolean algebra. (...) Such sets of rules is only able to express a restricted set of algorithm. That means its level isn't higher than C, C++, Java or C#" <<

> M Griffin said: "No, that's why ladder *is* a higher level language." <

Ladder logic is from the view of computing science and formal languages not a formal language and not at all a high level language.

It is simple a graphical displayed scheme for the the computing of sequence of rules ...

Regards
Armin
 
In reply to M. Griffin:

One should not assume that PLCs users can accept slow rates. Maybe that was true 20 years ago, but my Mitsubishi Q series PLCs run scans of 0.7ms regularly and reliably on many modestly complicated machines. You do have to buy the "high speed" input modules which allow programmable filtering down to 0.1ms. The bottom line is that today with hall effect switches and valves that spool in under 5ms (tested with o-scope with high performance SMC valves) that there is a significant advantage to higher speed processing and IO cards.

My question regarding Modbus was not so much the transistor level delays (although that needs to be tested) but whether or not the 5ms polling rate of modbus TCP is a standard or just something a lot of vendors have as default. One Master I used could not be set up to poll any faster than 5ms.

So saying that someone can put together a simple linux system with IO, depending on what you are doing that is not such a simple statement. The answer could lie anywhere in between our two approaches depending on what the person needs.

As to the original poster, we probably scared them right off this forum with our endless debate about what high level language is and whether or not he/she needs a RTOS :eek:)

KEJR
 
Top