In reply to Curt Wuollet: Expectations were supposed to be address by the IEC and compatibility was supposed to be addressed by PLCOpen. The problem that customers have in attempting to set the agenda is that they can only buy what is available for sale. This means that they can tilt the balance, but only a small bit at a time.

The real battle at this time though is not the language details, but the network "bus" that connects the CPU to the I/O, drives, MMI, and other devices. This is taking the central place in the scheme of things that the PLC "rack" once held. Whoever controls the bus, controls the industry. This is why all the various industry alliances are all vying to call themselves "open" while actually opening nothing.

If the major automation users that you mention want to influence things, then what they need to do is to get together and insist that they won't use a new Ethernet based network that isn't genuinely open. They should also make it clear that being open doesn't mean just tacking the word "open" onto the name of a private club. They could then pick one common genuinely open bus (or one for simple general I/O, and one for motion control and safety) and make it a requirement for all of their purchases.

Once the bus has been pried open, customers have more leverage to influence language standards because they aren't locked in by their installed hardware base.

 

In reply to Michael Griffin:

Regardless of the bus and hardware architecture, how can you have a piece of equipment with perfect IO but having software that weighs down the programmer? People will eventually go to home grown or community grown solutions if the industry doesn't supply a structured programming solution that begins to approach the power of C/C++ with a RTOS, and IEC 61131 is not cutting it (IEC is still based on a traditional PLC scan which makes doing sequence programming in structured text useless if you have to wait on IO, etc).

Case and Point, I develop using Epson RC+ with their robots and I can make changes, write, and rewrite code all day very quickly using their language (misture of VB and C like syntax). Their environment is a dedicated simplified (to the user) RTOS with up to 32 tasks executing at a 2ms clock. I'm running not only the robot but a sub-processing machine that has 7 simultaneously executing stations operating on parts that are in a rotary turntable. Doing the equivalent code using IEC 61131 would be a nightmare, but people do it because in some applications there isn't anything much better short of developing your own controller, which has maintenance nightmares.

If I could have Epson-like software in a PLC like package with a high speed backplane and flexible IO including high performance motion, I would buy it in a heartbeat and not look back! Why has nobody done this yet? Does the industry really think that the users are too stupid to use RTOS like features with structured programming in a PLC package?

I personally believe that Dealing with tasks, Mutual exclusions (MUTEX), and variable scope are much easier to understand than trying to debug a problem with a complicated ladder structure of similar complexity. I think that some people are just used to dealing with ladder problems and are putting up with it. Someone in the industry just needs the guts to do something completely different and trust that users will start to use it if it is available.

Currently I am using the Epson products (for robot machines) and Mitsubishi PLCs running IEC-Developer, programming mainly in ladder (non robot machines). The mitsu platform I use ladder function blocks to abstract common routines into libraries I have written. There is so much potential there, but it is fairly untapped.

My $0.02

~Ken

 

Moin Mr. Emmons,
moin all,

FYI, the IEC 61131-3 also includes Sequential Function Chart (SFC) in a textual form for the ST language (and all others). Usually SFC is regarded as the 5th IEC 61131 language by its own. Nevertheless, the standard clearly says that SFC is a "common element" of the other 4 languages. And it also tells how SFC in ST (or IL or...) should work.

This textual form of the SFC is rarely implemented. But it indeed can make sequential programming in ST much easier. http://www.61131.com to try out yourself.

Best regards,
Friedrich Haase

Ingenieurbüro Dr. Friedrich Haase Consulting - Automatisierungstechnik web http://www.61131.com/

 

In reply to Ken Emmons Jr.: IEC 61131-3 does have a "structured text" (ST) language. The syntax is more similar to Pascal rather than C, but the ST language is there. I am not aware of any direct support in the ST language for multi-threading, but there isn't any reason why it couldn't be added (there are many examples of this in other computer programming languages). I suspect though that most ST implementations simply compile the ST to IL (instruction list) and the typical PLC is NOT a real-time platform.

The real problem with IEC 61131-3 is that it doesn't define things closely enough to produce a worthwhile standard. As noted previously in this discussion, just about any PLC can call itself "IEC compliant". PLCOpen has tried to deal with this via "compliance levels", but there are so many of these levels and options that it didn't really solve anything.

My point about the network I/O "bus" was that with the traditional PLC, the software, CPU, and I/O have been inextricably linked together. A genuinely open "bus" would separate the software and CPU from the I/O, allowing options such as you desire to exist. While at present it is theoretically possible to build such an open system, the market is so fragmented with proprietary (or pseudo-proprietary) network systems that is it difficult for systems such as you describe to exist outside of niche markets.

 

In response to Michael Griffin:

I have used Structured Text before, and have not found anyone who really supports it natively in a high performance round robin RTOS like fashion, as you suggested. Most replies from automation vendors are something like this:

"Structured text is great for doing calculations."

Then I ask: "What happens when you wait on an input in a while loop"

"Well, it depends; if you wait long enough, you'll trip the watchdog timer".

Which, as you know, means the structured text language must complete any while loops in one scan time.

So really, to me, the IEC specification dances around implementation because it does not want to break the pre-existing infrastructure of the PLC, which is natively executing the manufacturer's instructions, and everything is compiled down from that. I think Rockwell is the exception where their compiler actually will generate better code than an old ladder Instruction languages, but they really don't support multithreading in the RTOS fashion.

While I still don't agree that the bus architecture is key to improving the software design, I do believe that a truly open bus can open doors to the future. Having a high performance open bus (that you don't have to pay ridiculous money for the specs) *could* potentially allow a startup company to solve the software issues by implementing a magic black box with a few communication ports and some kick@$$ software. Maybe this is the future.

~Ken

 

I think what you up against is what PLCs are made for. The intent was and is to provide a simple way to implement a large percentage of industrial control tasks. And they do that fairly well. Not as well as in the past, but they do cover a lot of the scope of industrial control where you need mostly logic, mediocre analog, and very limited networking. Most are reasonably approachable and usable by those who are not programmers as such, but use the programmability as a means toward the end of making something happen.

From a sophisticated computer engineering viewpoint they are Pathetic Little Computers and anything that can be done with them can be done far more elegantly, efficiently and in volume, inexpensively with a custom design and software written for the purpose. That is what a lot of embedded computing is about.

If one had the access, you could certainly throw away the firmware and software that make the microprocessor and assorted logic a PLC and run whatever pleases you that the available resources permit. In fact you can now buy "bare" PLCs where you can roll your own system software. Some look like a PC as far as programming is concerned and they would seem ideal for what you are talking about. They do tend to be pretty spendy compared to most PLCs but are also usually far more powerful to accommodate an actual OS or RTOS rather than a small runtime executive. I have kept an eye on these as potential containers for a Linux PLC.

But far from the software weighing the programmer down on commercial offerings, I think it's much the other way around. The majority of people who do things with PLCs seem to _like_ RLL and adamantly resist any change.

It's a very pragmatic way of doing things and has several practical advantages that most proposed replacements simply don't. This is coming from someone who would much rather write C to solve certain problems and would love to have the facilities of an OS (Linux) at my beck and call. I can, and have, controlled machines both ways and find them somewhat complimentary. Anything I can do with say, a Micrologix standalone is probably not a candidate for anything else as a practical matter.

A large PLC system that requires coprocessors and a lot of auxiliary equipment probably is. A sorting conveyor system may be done either way. If it requires a dozen serial bar code readers and an interface to enterprise software, PC control will probably be a lot cheaper and easier. Many systems now include a PC anyway. These would obviously warrant a look at doing the whole thing with the PC.

Anything with lots of analog or video or networking or computation is really outside the PLC scope and gets far more expensive and the performance is really abysmal compared to using a PC or other general class computer. And I am familiar with several large systems where the PLC paradigm was stretched and abused to the point where all the practical advantages were lost.

The cost of using PLCs beyond their no-brainer scope can be astonishing and it would almost certainly be cheaper and easier to do with other computers and more appropriate software. And in many cases it would be as easy to diagnose, repair, and expand. A really large PLC program with vast portions written in IL and spread among several processors is often more complex and inscrutable than a well structured C program to do the same job on a single large processor. PLCs are great where they are at their best. Outside that envelope there really is no comparable packaged product (DCS excepted)

My choice would be PC control with Linux with the soft realtime and scheduling enhancements and cooperating processes. It's a very good choice and you can do multithreading and scale to meet any conceivable need. But, run of the mill, mostly logic applications will be done with RLL for the foreseeable future.

Regards
cww

 

Thx Curt ... interesting insight...

Cheers from: Jeremy Pollard, CET The Caring Canuckian!

 

I'd like to disagree with Ken Stewart's statement that "we are talking about the process used to discuss standardising the programming languages used to program PLCs."

Why? I mean, not that it's unimportant, but I thought the question was what the standard should HAVE, not how to get there. In that vein, here's my wish list for PLC programming software:

1) Hiding the data model is far and away the most productive improvement PLCs have made. In other words, I no longer deal with register 40336 or N7:12. I just create an integer and go on with my life. Most modern high-end PLCs offer a hybrid approach, although some are still stuck in the dark ages. Siemens Step-7 comes to mind as an example that hasn't moved forward. RSLogix 5000 is a "pure" solution.


2) User defined data-types (UDT) is critical, including UDTs that contain UDTs, and arrays of UDTs that contain UDTs that contain arrays of UDTs.... you get the picture. Again, RSLogix 5000 gets this right. Modicon Concept tried but failed. Step-7 makes you think it will do it, but then you run into problems...


3) Array index by variable. Another critical feature. In Step-7, you can declare an array but it is useless; there's no way to say MyArray[MyInt]. Again, RSLogix does it right. Except that I'd also like to be able to say MyArray[2*MyInt+1].


4) Scoped variables. Nobody gets this one quite perfect, at least that I'm aware of. Step-7 allows me to have function-local variables, including typed input, output, and input/output parameters. But there is no way to scope variables to a SET of functions. In RSLogix 5000, you have global scope and "program" scope, allowing related functions to share variables, and those variables are hidden from functions in other “programs.” However, Logix has no concept of function-local, and doesn't typecheck input and output parameters. (The latest release of Logix adds some of this functionality, but if you use it you limit the use of the routine compared to "normal" routines.)


5) Calling functions/subroutines from functions/subroutines. Logix almost gets this right; you can call any routine from any routine, to any depth. You can even do recursion. But because of the aforementioned lack of function-local memory, recursion gets even weirder than normal. Step-7 will let you call a function from inside a function, but you can't pass a function-local value as a parameter, which is a SEVERE limitation, including preventing recursion. (Of course, recursion prevention is probably a good thing in general, but why the artificial limits?)


6) Automatic type conversion. Step-7 is absolutely EVIL in this regard. Why is a WORD different from and INT? Why can't I pass an INT to a FLOAT parameter? Logix (and C and Java and...) have no trouble with this concept.


7) Scheculed / periodic tasks. Haven't had a problem with this one in a while. Step-7 and Logix both have it, at least. It would be nice to formally declare it a requirement. The days of "one big ladder diagram" are over... or at least should be.


8) Conveniance functions. Akin to the C standard library, perhaps. Virtually all PLCs have math functions like square root and cosine, and of course motion functions have started to become de riguer. But where are hash tables? Dictionaries / maps? Sorted sets? Bounded queues and stacks? Quick sort / binary search? Logging? Time-stamping? Time/Date calculations?


9) Strings should be first class citizens, including functions for ASCII serial read/write communication. Most modern systems deal with strings, some far more elegantly than others. Logix comes close, but doesn't allow string literals in ladder. Plus, you have to declare a string type for each maximum size you want, which requires a download. That's not “first-class citizen” in my book.

-James Ingraham
Sage Automation, Inc.

 

Except for being compiled, A C implementation with good libraries and a "smart" IDE that let you mouse things into place and hid the glue code would answer all these and more. And I submit that it could be made easier to use than Step 7. Sounds like a 4GL for automation. Since the RLL "language" contains a very small number of tokens, this sort of thing should be very doable. :^) Place the token graphically, parse the tokens and generate the code. Simple. You could use all the native data types and I could write straight to the machine and skip all the GUI nonsense. Sounds like a plan. I'm only half joking, what folks can't seem to realize is that with Open tools and systems you _can_ do something like this. It's not even extraordinary, More like a college CS project. So, why labor with tools you don't like? Because you are wedded to proprietary hardware. Change platforms and the possibilities are endless. How do we get people to do it?

Regards
cww

 

I guess interest has waned in this topic, but I'd like to bring my 9-point list back up because I'm curious as to what other people think about my "requirements."

Did you think, "Man, this guy obviously hasn't seen XYZ's software, the most common in the world. It's like he's living in a cave!"

Or maybe, "Dictionary functions in a PLC? What good will that do? The reason we program in ladder is that our maintenance techs can understand it. I start throwing red-black tree-based sorted containers in there, and they won't understand a thing!"

I'm particularly interested in hearing about the use of arrays, especially looping through an array. I've write most of my code this way, and sometimes my customers will insist I rewrite it and unroll the loop.

Any Logix programmers missing the days of PLC/5?

Any Unity programmers wishing they could go back to ModSoft?

Any Step-7 programmers that share my feeling that Step-7 is a German plot to set the US manufacturing industry back by 30 years?

-James Ingraham
Sage Automation, Inc.

 

James - you are a computer geek right?? Great list and most have been missing for some time ..
Some I would agree with and others would be a non-event for most developers.

Not to say that the features wouldn’t be useful, just that most wouldn’t use them. RSLogix, Step 7 and Concept are ALL IEC-61131 based/compliant. Yet they are so different.. thus my argument that 61131 should not be a standard as such.

I am preparing a tutorial for the ISA conference on IEC-61131, and need some feedback re the use of the word (or inference) 'standard' as it applies to the IEC-61131 'standard'.

Please respond on the list or to me personally - either works for me. Thx in advance

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

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

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

 

To Jeremy Pollard:

Jeremy Pollard >Not to say that the features wouldn’t be useful, just that most wouldn’t use them. RSLogix, Step 7 and Concept are ALL IEC-61131 based/compliant. Yet they are so different.. thus my argument that 61131 should not be a standard as such.<

And it is the case for ALL brands.. and have a look at CoDeSys (Smart Software Solutions GmbH - http://www.3s-software.com/) It seems to me, their invention activity (free fly of creation) isn't limited by any rules or conception. Very interesting software, but it is very hard to say it is compliant (in common sense) with the IEC 61131-3 standard.

Jeremy Pollard >I am preparing a tutorial for the ISA conference on IEC-61131, and need some feedback re the use of the word (or inference) 'standard' as it applies to the IEC-61131 'standard'.<

In my opinion, we need to divide the standard on 5 parts and exclude any mention about PLC from the title and text (because of the misleading connotations).

--
Best regards,
zyubin

 

In reply to James Ingraham: I will address each of your original points in turn below.

On Friday 15 June 2007 22:08:25 The AList wrote:
<clip>
> 1) Hiding the data model is far and away the most productive
> improvement PLCs have made. In other words, I no longer deal
> with register 40336 or N7:12. I just create an integer and go on
> with my life. Most modern high-end PLCs offer a hybrid approach,
> although some are still stuck in the dark ages. Siemens Step-7
> comes to mind as an example that hasn't moved forward. RSLogix
> 5000 is a "pure" solution.

What you are describing is "symbolic addressing". Siemens Step-7 does this for most variables (although not all). A well written S7-300/400 program should have most data local to each function block (FB). You just create the variable, define the type, and let the Step-7 software decide where to put it. The exceptions are mainly timers and counters, which are global resources. "M" memory should only be used as sparingly as possible for global variables.

This might not be exactly what you want, but Step-7 (and the S7-300/400) certainly has hanged in this respect from Step-5 and the S5.

> 2) User defined data-types (UDT) is critical, including UDTs
> that contain UDTs, and arrays of UDTs that contain UDTs that
> contain arrays of UDTs.... you get the picture. Again, RSLogix
> 5000 gets this right. Modicon Concept tried but failed. Step-7
> makes you think it will do it, but then you run into problems...

Your description of your problems with Step-7 are a bit vague. I've used blocks of UDTs with Step-7 to store structured data.

> 3) Array index by variable. Another critical feature. In
> Step-7, you can declare an array but it is useless; there's no
> way to say MyArray[MyInt]. Again, RSLogix does it right. Except
> that I'd also like to be able to say MyArray[2*MyInt+1].

With Step-7 for the S7-300/400, you have to use pointers. They do make this very difficult, so you are best off to write an FC to wrap up and hide all the pointer handling. The S7-200 is completely different and comes with simple and useable indirect addressing instructions.

> 4) Scoped variables. Nobody gets this one quite perfect, at
> least that I'm aware of. Step-7 allows me to have function-local
> variables, including typed input, output, and input/output
> parameters. But there is no way to scope variables to a SET of
> functions. In RSLogix 5000, you have global scope and "program"
> scope, allowing related functions to share variables, and those
> variables are hidden from functions in other “programs.”
> However, Logix has no concept of function-local, and doesn't
> typecheck input and output parameters. (The latest release of
> Logix adds some of this functionality, but if you use it you
> limit the use of the routine compared to "normal" routines.)

The only sort of variable scoping that would do what you want and be understandable would be nested scoping. Most PLCs though don't support the concept of nested subroutines.

> 5) Calling functions/subroutines from functions/subroutines.
> Logix almost gets this right; you can call any routine from any
> routine, to any depth. You can even do recursion. But because
> of the aforementioned lack of function-local memory, recursion
> gets even weirder than normal. Step-7 will let you call a
> function from inside a function, but you can't pass a
> function-local value as a parameter, which is a SEVERE
> limitation, including preventing recursion. (Of course,
> recursion prevention is probably a good thing in general, but why
> the artificial limits?)

I very much doubt that you can call "to any depth", even when doing recursion. Your PLC will be using a call stack, and there will be a maximum depth to the call stack even if it isn't documented. There will be either some arbitrary limit, or the PLC will crash when the top of the stack runs into something else.

The Siemens S5 had a call depth of I believe somewhere between 7 and 10. I never ran into that limit in practise. I imagine the S7-300/400
also has a set limit, although it may be deeper.

Recursion is one of those concepts that is taught in computer science as the "elegant" way of solving many problems. And indeed, there are
problems for which a recursive solution works the best. However, in most practical software people avoid recursive algorithms because the
dangers and limitations.

> 6) Automatic type conversion. Step-7 is absolutely EVIL in this
> regard. Why is a WORD different from and INT? Why can't I pass
> an INT to a FLOAT parameter? Logix (and C and Java and...) have
> no trouble with this concept.

There are three trains of thought with regards to variable typing. There is weak typing, strong typing, and dynamic typing. Each has it's proponents, and each has its benefits and downfalls. The people who created the S7 evidently liked strong typing.

As for "why is a WORD different from and INT?". Well a WORD *is* different from an INT. A WORD is an unsigned basic unit of memory, while an INT is a signed integer number. Some people had the same attitude when they were writing 'C' or 'C++' programs, and their successors ended up painfully debugging the those same programs when
they were ported to a different architecture where the word, integer, and pointer sizes were different. The 32 bit to 64 bit x86 transition
was particularly painful for some people because of this.

> 7) Scheculed / periodic tasks. Haven't had a problem with this
> one in a while. Step-7 and Logix both have it, at least. It
> would be nice to formally declare it a requirement. The days of
> "one big ladder diagram" are over... or at least should be.

This of course is also one of those features which is used extensively in a few application areas, and almost never anywhere else.

> 8) Conveniance functions. Akin to the C standard library,
> perhaps. Virtually all PLCs have math functions like square root
> and cosine, and of course motion functions have started to become
> de riguer. But where are hash tables? Dictionaries / maps?
> Sorted sets? Bounded queues and stacks? Quick sort / binary
> search? Logging? Time-stamping? Time/Date calculations?

What you really want is to be able to call subroutines written in a modern scripting language which has those features. That is, you want at its simplest something analogous to a CGI call in a web server, or in a more complex case a call gateway to a parallel process running a different language.

Adding these features into ladder or IL would create a horrible monstrosity, much in the way that attempting to graft modern features onto Visual Basic did.

As well as the language features, you are going to want the libraries which play a large part in making these modern scripting languages so useful. It would be better to simply allow an existing computer programming language (such as Python) to be accessed from a ladder program. This should be possible if the "PLC" was a soft logic system, even if the soft logic system was running on embedded hardware.

> 9) Strings should be first class citizens, including functions
> for ASCII serial read/write communication. Most modern systems
> deal with strings, some far more elegantly than others. Logix
> comes close, but doesn't allow string literals in ladder. Plus,
> you have to declare a string type for each maximum size you want,
> which requires a download. That's not “first-class citizen” in
> my book. <

The string handling could be done by a call to a modern scripting language as described in the previous point. Or do you really relish handling unicode in ladder?

 

In reply to Jeremy Pollard: IEC 61131-3 attempts to describe a set of languages useful for programming automation systems. A "language standard" describes a language in enough detail that a conformant implementation of that language can be created by anyone.

Two "conformant implementations" of a standard should produce identical results. The best test of whether a standard adequately describes a language is the degree to which independent implementations of the standard are similar. The further the implementations diverge from each other while still conforming with the standard, the less useful the standard is.

Quite frankly, there is another approach to the "standards" problem which seems to work much better. That is, everyone contributes to a soft logic system which can run on embedded hardware or on PCs, and everyone simply uses that instead of writing their own. License the system under a GPL license to keep the big vendors from shafting the smaller ones as well as each other. Now everyone is compatible because everyone is using the same software.

Customers will still buy PLCs from their preferred vendors because they still need PLCs and they aren't going to build them in their basements (or maintenance shops). The customers though will be able to load ladder programs into their PLCs without having to rewrite them for each different model.

Where's the downside to this? I can't see one. Unless of course, the problem would be that everyone would actually really be compatible with everyone else, which is perhaps the opposite to what some of the vendors really want.

 

Thank you, Michael Griffin! Great responses, and exactly the kind of thing I was hoping for!!!

I've cut out a lot to decrese the length.

MG: "What you are describing is "symbolic addressing".

Yep.

MG: "Siemens Step-7 does this for most variables (although not all)."

News to me. More on this later.

MG: "A well written S7-300/400 program should have most data local to each function block (FB)."

Also true of a well written program in ANY language.

MG: "You just create the variable, define the type, and let the Step-7 software decide where to put it."

Ah, but you're still exposed to WHERE it put it, within that function block. This is what I meant above when I was snarky about S-7 using symbolic addressing for most variables. So input, output, input/output, and local variables still have an offset from 0, and you can address those (with Lxxx, I think, though it's been a little while since I tried it.) True that local variables are much easer to deal with than globals.

Unfortunately, as I mentioned before, there is no way to share a variable amonst seveval FBs/FCs, so you have to resort to globals, since you can't pass a local variable to an FC inside an FC.

MG: "Your description of your problems with Step-7 are a bit vague."

Guilty as charged. The biggest problem I had was in making changes to an existing UDT, though I've forgotten some of the details now. Also, my "..." there was an attempt to lead into my point about array indexing.

MG: "With Step-7 for the S7-300/400, you have to use pointers."

I'm sure this is possible. My only access to Siemens technical support is through my local distributor. Within about 8 hours I had vastly out-run their expertise. By luck, I ran into some extremely competent Step-7 programmers on a job I was on for a while, and picked up a few things from them. However, only one of them knew how to use pointers, and he played with for five minutes before giving up and saying it was possible but he didn't have time to figure it out for me. So right now I can't do it at all.

MG: "The S7-200 is completely different and comes with simple and useable indirect addressing instructions."

Okay, I really DIDN'T know that. I've only worked with S7-300.

MG: "The only sort of variable scoping that would do what you want and be understandable would be nested scoping. Most PLCs though don't support the concept of nested subroutines."

I don't understand your answer, which makes me think I didn't write my initial point clearly. In pure Siemens language, let me try it this way:
Imagine being able to take a group of FCs and creating a new data table that only those FCs could access. Only FCs within that group could call others within that group. This is exactly what Logix does. But Logix DOESN'T have the local variables that Step-7 does.

MG: "I very much doubt that you can call [nested subroutines] 'to any depth', even when doing recursion."

Okay, okay, an exaggeration. I am prone to hyperbole. But 32 or 64 or some other number is essetially infinity in this case.

MG: "The Siemens S5 had a call depth of I believe somewhere between 7 and 10. I never ran into that limit in practise."

Yeah, in practice I doubt I've hit ten either.

MG: "In most practical software people avoid recursive algorithms because the dangers and limitations."

I don't actually WANT recursion. In fact, I was shocked when Logix let me. I was just pointing out that calling sub-routines from within sub-routines is a requirement for me on a PLC, perhaps with a bit of hyperbole thrown.

MG: "There is weak typing, strong typing, and dynamic typing. Each has it's proponents, and each has its benefits and downfalls. The people who created the S7 evidently liked strong typing."

S7 is beyond strong typing. I can't think of any other language so strict in it's conversions. Which backfires horribly, because I end up "casting" by accessing the memory directly.

MG: "As for "why is a WORD different from and INT?". Well a WORD *is* different from an INT. A WORD is an unsigned basic unit of memory, while an INT is a signed integer number."

Logix (and Java) solve this problem by not having an unsigned type and not allowing you to get a "basic unit of memory."

MG: "Some people had the same attitude when they were writing 'C' or 'C++' programs, and their successors ended up painfully debugging the those same programs when they were ported to a different architecture where the word, integer, and pointer sizes were different."

Yes. That's why Java defined the type sizes, and why any C/C++ programmer who works for me gets 40 lashes if he doesn't use the C99 type definitions.

Still, surely one should be able to compare a floating point number to an integer? Or a counter value to an integer?

Actually, disagreement is one of the things I was looking for. So my list of things *I* want in a PLC programming language inclues being able to pass an int when a float is expected, but others want a compile timer error. Fair enough.

MB: "[Scheculed / periodic tasks] of course is also one of those features which is used extensively in a few application areas, and almost never anywhere else."

Wow. That's surprising to me. Again, this kind of thing is why I wanted people to respond. I've only dealt with a few Siemens systems, but they all had one of those OBxx set to some time value or another to do SOMETHING. I guess my "pure" software background leads me towards ALWAY using scheduled tasks because I find it easier to think about.

JI: Conveniance functions.
MG: "What you really want is to be able to call subroutines written in a modern scripting language which has those features."

That is decidedly NOT what I want. Right now, in just about any PLC, there is a cosine function. I also want a sort function. (Actually, Logix has this.) And I want this to be a standard set of library functions, akin to the C Standard Library, the C++ Standard Template Library, and the java.* class library.

MB: "It would be better to simply allow an existing computer programming language (such as Python) to be accessed from a ladder program. This should be possible if the "PLC" was a soft logic system, even if the soft logic system was running on embedded hardware. "

Many systems let you do this, actually. SoftLogix, the PC-based version of ControlLogix, allows arbitrary DLL calls. So do many other "soft PLC" packages, which I assume includes Siemens. Siemens and some others also let you compile C code to call from ladder, even on "actual" PLC hardware. But again that's not what I want. And I'm not sure I agree with "better" either. I try to use individual, add, subtract, multiply, and divide blocks, instead of the Logix "Compute" block that allows you to type out an equation. This is essentially a "script." But it's generally harder for a maintenance guy to figure out at 3 in the morning.

MG: "Do you really relish handling unicode in ladder?"

Well, no, but I would damn sure like to be able to move a string literal into a string variable on a rung of ladder, much like I currently move an integer literal into an integer variable.

Good stuff! Somebody else jump in! The water's great! So the's hyperbole! I have more hyperbole than ANYONE ELSE ON EARTH!!!

-James Ingraham
Sage Automation, Inc.

 

I have seen a lot of "trick" programs done and usually think it is better to KISS (keep it simple stupid). Hell I have written some programs that I cannot even figure out what I was doing... (short term memory loss).

Europeans tend to write in general in my experience, really well software programs. (IE Siemens), but Americans tend to want to see the "inerds". So using bit shifting, or shifting arrays, etc. confuses the end user.

Now I argue sometimes that if you write it so that it does not breaks, then who cares.

I say ladder survives because the end user wants it.

Dave

 

Moin Mr Friedrich,

I am new to ST prorgamming and find it hard to find some example program in ST. I have found a few from PLCOpen and from 61131.com. But they are quite insufficent. Could someone please help me with some programs, it would great.

warm regards
hari

 

You mentioned the desire for a standrad XML format, and you can now get the PLCopen XML standard decuments for free. The PLCopen XML schemas and documentation as well as an introduction are available free to anyone on the internet at http://www.control-xml.com The downloadable files include a 156 page Explanation of the PLCopen XMLSchema, 58 page document on XML Formats for IEC 61131-3, and XML Schema files. A number of PLCopen member companies are supporting the XML standard including independent software suppliers 3-S, KW-Software, and KirchnerSoft.

You also might want to check out http://www.AutomationML.org for information on other open standards.

Bill Lydon
PLCopen North America
414-427-5853

 

Nice information about Ideal PLC Programming language and software. Get more info about programming languages, software companies list, operating system, software, online games and more only at
http://www.altiusdirectory.com/Computers/software-companies-lists.html

 

I think that working with PLCs in python is a fantastic idea; python is a computer industry standard language that is nowhere as esoteric as the current PLC programming architecture.

I've seen that somebody has created a python module for this; however, I've yet to try it.

Hopefully, it will work well.