Curt,

I'm building up an automation library based on C at my company for a linux/xenomai based commercial controller. So there are functions in my library that take care of task creation, time functions, IO access, error messaging, HMI, etc. Not quite Arduino simple, but a few steps removed from a nice clean user friendly package. Its not an open source project, but I'm just demonstrating that the simplified automation approach doesn't have to take on the IEC61131 model or ladder model.

I think I tend to agree with M. Griffin these days in that the key to this kind of project is in commodity PC platform tied over ethernet (or perhaps EtherCat in the future). We differ in opinion that the IO access should be deterministic and fast, but that is OK, each of us has different target applications for this type of thing. I'd like to find out that with a dedicated ethernet port, standard ethernet driver, and the PREEMPT_RT patch that you can obtain 1-2ms ethernet polling but I don't even have time to test this type of thing!

I stick to my guns that if a user is presented with an automation environment based on a *simplified* RTOS that they will develop nicer programs for complex machines. There is a reason that *most* motion controllers and Robot controllers are based roughly on C/Basic kinds of text languages and multithreaded environments.

If you are flicking a few valves on a timer and displaying a few error lights, by all means buy a small PLC.

KEJR

 

Good day, Armin!

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

Why? It is just typical 4GL (4th generation lang, problem-oriented) with its own strong syntax and semantics (at least for every separate implementation). And I see no problem to express the language in BNF or in the form of syntax diagrams.

(I agreed the high/low classification has no much sense in the case)

--
Best regards,
Vladimir E. Zyubin

 

Hello Vladimir,

and how would you define the extensive semantics with a simple BNF ?

Regards
Armin

 

@Ken: "I'm building up an automation library based on C at my company for a linux/xenomai based commercial controller."

My company had it's own library in C on QNX about 15 years ago. We moved it forward from QNX4 to QNX6, and added support for various things over the years (like Modbus/TCP and EtherNet/IP). There were a lot of really cool features that we're proud of. I actually got the whole thing to compile on Linux with two problems; (1) the screens were of course not possible to port, and (2) I had empty functions to replace the QNX message passing functions. The screens weren't too bad; we could have rebuilt them easily enough. The message passing is also solvable. In the end, we stopped any and all work on either QNX or Linux. Our customers weren't interested. They didn't like C. They wanted Allen-Bradley. So we just gave up on it.

"I stick to my guns that if a user is presented with an automation environment based on a *simplified* RTOS that they will develop nicer programs for complex machines."

Maybe we weren't simple enough. Maybe our machines weren't complex enough. Whatever the case, we found the exact opposite. Our users didn't want it.

"There is a reason that *most* motion controllers and Robot controllers are based roughly on C/Basic kinds of text languages and multithreaded environments."

What robot and motion controllers are you talking about? I've never heard of a such a thing. Well, Basic, sort of. Certainly not C. Fanuc, Kuka, Motoman, and ABB all fall WAY short of the functionality of C. If we've left them out, I don't see how we can say "most" robot controllers. As for motion controllers, Delta Tau & Galil sure don't fit this bill. And I've never seen any of these be true multi-threaded environments.

Name me any robot or motion controller that has an equivalent to qsort & bsearch, much less a dictionary / collections framework.

-James Ingraham
Sage Automation, Inc.

 

@Ken: "One should not assume that PLCs users can accept slow rates."

I guess properly one shouldn't assume anything about anything. But if someone says "PLC" to me without mentioning that they need high speed I'm going to assume we're talking in the 5-10ms range.

"my Mitsubishi Q series PLCs run scans of 0.7ms regularly and reliably on many modestly complicated machines."

Pretty cool. Of course, my prox switches and photo-eyes aren't that fast, even the DC ones. And my servo control is independent of the PLC logic. Sure, my servo my be in position for 5ms before I react to it, but that very rarely bothers me.

"You do have to buy the "high speed" input modules which allow programmable filtering down to 0.1ms."

Again, few of my sensors will work this fast, and very few of my applications would care. I have to stop a box on the conveyor; 1ms or 50ms just doesn't matter.

"The bottom line is that today with hall effect switches and valves that spool in under 5ms that there is a significant advantage to higher speed processing and IO cards."

Three points.
(1) I've never used a hall effect switch for anything, ever. It's all proxes, photo-eyes, limit switches, etc.
(2) So the valve spools in under 5ms. That just starts the air flow. It will take a while for the actual cylinder I'm firing to move. In some cases, I've got cylinders that move for tens of SECONDS. Do I really care if the valve spool moved in 5ms instead of 50?
(3) Okay, we've got your fast inputs and fast valves. How does this give me a "significant advantage?" My machines usually do something like six cycles per MINUTE. And even if I shave some milliseconds off here and there, all that means is that I'll outstrip the machine feeding me by that much more.

"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"

True enough. I've been particularly bad about being off-topic lately. FWIW, I think ladder logic is neither high nor low, and that the whole high / low thing is pretty passe. I might call it a Domain Specific Language (DSL) if I just wanted to throw around buzzwords to sound knowledgeable.

BTW Ken, I'd actually really like to talk to you about your experience with Mitsubishi PLCs and what you're doing with them. If you don't mind, drop me a line or call me. My e-mail address is jamesi with the domain sagerobot.com. Our phone number is on our website at www.sagerobot.com, where you can also take a look at the machines I'm talking about.

-James Ingraham
Sage Automation, Inc.

 

:: M Griffin Wrote: "Typical run of the mill PLCs are not deterministic or real time in any way, shape or form."

I was flamed by a very experienced engineer years ago for saying just that. Two facts cannot be avoided:

1. It is theoretically possible to determine the worst case response in most PLC's, it is not easy however. For any given state, one could add up the execution time for each instruction that is being scanned and add the published overhead to arrive at an expected scan time.

2. As a practical matter, many PLC's keep track of the typical and worst case scan time in operation. These numbers should be fairly accurate if the program is tested comprehensively.

PLC's may not respond anyway near as fast as an interrupt to a dedicated CPU or microcontroller, but they are deterministic devices.

Bill Sturm

 

In reply to Ken E: There is nothing about the Modbus/TCP protocol that specifies or limits polling rates. The protocol simply doesn't deal with that type of question. A request is simply "give me 'x' number of coils starting at coil 'y'" and a response is "here's your coils". If the client and server can go faster, then the polling cycle is faster. The limits are strictly the limits of the hardware at each end. If you had a master that wouldn't let you run it faster than 5 msec, that's strictly a speed governor that the vendor decided to put in either because of some limitation of the client (master), or possibly because faster polling rates may trigger bugs in their servers (slaves).

 

In reply to James Ingraham: A lot of the "MRS" switches used on cylinders these days are actually hall effect sensors. That includes many of the 2 wire ones (which is why they don't work with high impedance inputs).

As for 6 cycles per minute not being fast, that's actually fairly typical for a lot of assembly operations. There's only so fast a lot of physical processes can go (welding, turning, pressing, staking, heating, nut driving, etc.).

 

Hi Ken

> I'm building up an automation library based on C at my company for a linux/xenomai based commercial controller. So there are functions in my library that take care of task creation, time functions, IO access, error messaging, HMI, etc. Not quite Arduino simple, but a few steps removed from a nice clean user friendly package. Its not an open source project, but I'm just demonstrating that the simplified automation approach doesn't have to take on the IEC61131 model or ladder model. <

I quite agree, there are many problems that would be more easily handled outside the ladder paradigm. But, that paradigm also has merit for a great many applications.

> I think I tend to agree with M. Griffin these days in that the key to this kind of project is in commodity PC platform tied over ethernet (or perhaps EtherCat in the future). We differ in opinion that the IO access should be deterministic and fast, but that is OK, each of us has different target applications for this type of thing. I'd like to find out that with a dedicated ethernet port, standard ethernet driver, and the PREEMPT_RT patch that you can obtain 1-2ms ethernet polling but I don't even have time to test this type of thing! <

I have no argument there either, where it makes sense. That is, where remote IO and the cost associated with it are a fit. But consider that an awful lot of PLCs go in a box with local I/O and "home run" wiring, and that "all in one" units are quite popular, something with local IO capability would fit more applications. And at least a few local I/O for panel devices is really handy. Nothing precludes having a 1 slot rack if all IO is to be remote. The speed issue is a trade off. You'll notice the cards I designed would be high speed cards. But, the only thing you have to do to make the great majority of PLC applications fail in bizarre and extremely hard to troubleshoot ways, is to try to run them fast. Trying to get fast edges and high rep rates down a wire in raceway or conduit will not only give you extreme problems with signal integrity like ringing and reflections, it would couple to other circuits readily. Anyone who survived wirewrap backplanes knows that a wire stops acting like a wire above a few kHz or with corresponding rise and fall times. Twisted pairs or coax for logic signals is going to go no place with the unwashed masses. It's easy nowadays to make the PLC go faster, but common wiring practice won't support it. That's why high speed inputs, etc. are a specialty item.

> I stick to my guns that if a user is presented with an automation environment based on a *simplified* RTOS that they will develop nicer programs for complex machines. There is a reason that *most* motion controllers and Robot controllers are based roughly on C/Basic kinds of text languages and multithreaded environments. <
>
I think the idea would be, if possible, to free the user from having to know it's an RTOS or OS or firmware executive. That's why people buy PLCs.

> If you are flicking a few valves on a timer and displaying a few error lights, by all means buy a small PLC. <

But if you need anything more an SBC like the BeagleBoard would become cheaper very quickly.

Regards
cww

 

Hello Armin

TA> and how would you define the extensive semantics with a simple BNF ?

No way, I am sure you know BNF defines syntax, not semantics. I just would like to hear, what do you mean when say LD is not a formal language.

--
Best regards,
Zyubin

 

>> @Ken: "I'm building up an automation library based on C at my company for a linux/xenomai based commercial controller." <<

> My company had it's own library in C on QNX about 15 years ago. We moved it forward from QNX4 to QNX6, and added support for various things over the years (like Modbus/TCP and EtherNet/IP). There were a lot of really cool features that we're proud of. <
Only what's visible on the screen is interesting for the customer ... no one is asking for QNX. Also the way they are programming their applications is important. Eclipse for C/C++ has no change ... for that reason we have developed a function block based programming tool which allows to program all aspects of real-time or control applications. The RTOS is not visible for the developer....

> I actually got the whole thing to compile on Linux with two problems; (1) the screens were of course not possible to port, and (2) I had empty functions to replace the QNX message passing functions. The screens weren't too bad; we could have rebuilt them easily enough. The message passing is also solvable. <

We are using the messaging passing middle ware 0MQ ( www.zeromq.org ) in order to replace the message passing functions of QNX

> In the end, we stopped any and all work on either QNX or Linux. Our customers weren't interested. They didn't like C. <

IMHO ... they didn't like the nitty gritty details of QNX and C ...

> They wanted Allen-Bradley. So we just gave up on it. <

>> "I stick to my guns that if a user is presented with an automation environment based on a *simplified* RTOS that they will develop nicer programs for complex machines." <<

> Maybe we weren't simple enough. <

No, the RTOS must not be simplified ... it must be invisible for the end users and developers of control applications.

> Maybe our machines weren't complex enough. Whatever the case, we found the exact opposite. Our users didn't want it. <

>> "There is a reason that *most* motion controllers and Robot controllers are based roughly on C/Basic kinds of text languages and multithreaded environments." <<

> What robot and motion controllers are you talking about? <

Have a look to Baldor e.g. But their Basic code is just used to the communicate over Ethernet Powerlink with a QNX application programmed with DACHSview.

Regards
Armin Steinhoff

 

Moin all,

FYI
The IEC 61131-3 committee currently works on the third edition. I am a German member (65B/WG7.)

The IEC 61131-3 edition 3 will include object orientation and many small improvements. Nevertheless the ed. 2 base will be the same. 5 programming languages - function block diagram, instruction list, ladder diagram, sequential function chart, structured text (in alphabetical order.) Other programming languages (C, Basic, or whatever) are still allowed (since the very first release!)

What do these OO-features look like?

Function blocks (not to be confused with function block diagrams as function blocks are used in all languages) may have additional member functions and may constitute a class hierarchy. There are provisions for polymorphism and inheritance. Additionally pure classes are defined like function blocks including member functions but without inputs and outputs. For those who care: No, this all does not require garbage collectors.

This future standard is in a rather advanced state, maybe very near to the final state. Next international meeting in march. We expect to have a committee draft for voting in a few month. International voting will take some time. We expect the new 3rd release end of the year or early next year. But please keep in mind that it will take some more time for the implementers to upgrade their software.

Just in case someone would like to contact me
friedrich <dot> haase <at> 61131 <dot> com

Best regards
Friedrich Haase

 

@James Ingraham

That's too bad about your QNX/linux work beign let go. In selling machines/contract work you do have to bend to customer needs. I understand this.

OK, I take it back, *most* was too strong a word, and they aren't all as nice as C for sure. How many are programmed in ladder though? I've only used Epson Robots and they have a RTOS and a language based roughly on attributes of C and Visual Basic. I have been told that Denso has a multitasking system with a text language, although it is not as Basic or C like as the Epson (which is why I haven't tried them). I believe Adept has a text based language with multitasking. Delta Tau has also offered text based languages and allowed for multiple "tasks" although it wasn't a tradition RTOS under the hood. The down side to the traditional Delta Tau systems is that their "PLCs" did not have function calls and their array support left a lot to be desired. The latest Delta Tau Power PMAC *is* a linux box with Xenomai RTOS that you can program your application in using the Xenomai pthreads skin.


KEJR

 

@ James Ingraham again:

We have machines running at 300PPM doing many operations in this time using discrete IO operations and motion. Time is everything. Semiconductor folks also have this issue, which is why I think they tend to use their own controls or high end PLCs. Our keyence photo eyes can catch 30-50us events, usually a small part flying by fast. Yes, we do stretch the off time to 2ms or so just to make sure our PLC catches it.

KEJR

 

In many ways ladder is a high level language.

It is optimized for doing the kinds of general purpose control that are the predominant control problems encountered in industrial control problems.

It isolates the user from any operating system, and provides a graphical means of entry and debug that is very intuitive to those who have worked with electrical circuits. By its nature, it is essentially a massively parallel system. Which is good because a lot of control problems involve a lot of things happening in parallel.

OTOH, there are control problems that involve data manipulation and sequential control that it is less well suited to.

--
Bob

 

> FYI The IEC 61131-3 committee currently works on the third edition. I am a German member (65B/WG7.)

> The IEC 61131-3 edition 3 will include object orientation and many small improvements. Nevertheless the ed. 2 base will be the same. 5 programming languages - function block diagram, instruction list, ladder diagram, sequential function chart, structured text (in alphabetical order.) Other programming languages (C, Basic, or whatever) are still allowed (since the very first release!)

> What do these OO-features look like?

> Function blocks (not to be confused with function block diagrams as function blocks are used in all languages) may have additional member functions and may constitute a class hierarchy. There are provisions for polymorphism and inheritance. Additionally pure classes are defined like function blocks including member functions but without inputs and outputs. <

Seems not to be an exciting innovation as long as the operational model of IEC 61131-3 doesn't support distributed systems and is based on processing by polling.

Do you really believe that anyone who knows LD does also know what "class hierarchy, polymorphism or inheritance" means ?

I'm not convinced ...

Regards
Armin Steinhoff

 

What sometimes is lost in figuring if a scan time is "quick enough" is how much movement happens between scans and the accuracy of positioning needed.

As an example, I worked on a system in my first job that was basically a DCS that tried to do logic as well. It scanned all the PID loops that were configured 4 times a second which, for those loops, were very quick. However, we had no way of scanning digital bits any faster either and our conveyor was running at 6"/sec. Our positioning accuracy required was 0.5" which could not be accomplished. We ended up going to a fast to slow speed in advance of the stopping spot to make the positioning requirement.

Is this unreasonably slow for today, it sure is. Are we pushing equipment to go faster yet, of course we are. Now we are approaching the limits of 60Hz. I/O and needc <b><i>sic - moderator</i></b> to go to DC and include the time delay in things like filling an impulse line with 30 PSI air and similar equipment needs.

One other item I ran into concerning Modbus serial. I had a set of level transmitters communicating via RS-485 using Modbus to a PLC card. The card's configuration defaulted to 1 stop bit while the transmitters only operated with 2 stop bits. Both met the Modbus standard but were incompatible; the number of stop bits were not specified in the standard. We were able to reconfigure the PLC card but finding out why we didn't talk was frustrating - actually we did get some garbage data into the card but it certainly didn't match what we expected.

Vendors can set their "standard" with a number of specific details not well documented. A 5 mS update may be just that.

Russ K.
Phoenix, AZ USA