IEC 1131-3 Software

In reply to Curt Wuollet:

The document I referred to earlier lists 13 "architectural requirements" for IEC 61499. 7 of those requirements relate to protecting and extending "intellectual property (IP)". That bit of market-speak should ring a bell for most people. In other words, the majority of the "architectural requirements" for IEC 61499 relate to finding new ways of copy protecting and charging for software components.

The document also spends an entire page creating a new definition for "open" that has nothing to do with being open. Instead, an "open architecture" is redefined as being one that is portable, inter-operable, and configurable. And then portable and inter-operable are defined away to an equally meaningless degree because there is no requirement for this to work with software or devices from different vendors.

In other words, the system will look like this. You'll buy a PLC and programming software from your favourite vendor. That will get you a bare bones system. If you want to start using the various features that they advertised though, you have to start buying function blocks. That can include third party function blocks. I imagine there would be something like the console game or phone market where the platform vendor takes a cut of each transaction in return for allowing the software onto the platform.

I'm sure we're all looking forward to this.
 
Hello all,

> HARNESS is for use in "High Performance Computing" (HPC). Or in other words, supercomputers. That is solving problems at an entirely different scale. With HPC, you have large arrays of very powerful processors with very fast interconnects. <

HARNESS is at first a 'heterogeneous distributed virtual machine and
fault tolerant runtime environment' and can be used for HPC and other distributed systems.

This middleware doesn't say any thing about the type of the computing at every node. It says also nothing about the type of media it is working on. The motivation to build a cluster can be very different: in HPC it is bundling CPU power ... in the automation it is the integration of distributed nodes.

Why should we not e.g. use Ethernet/IP as a communication media in order to create a network which is seen from the users perspective as a single machine? This would an ideal environment for IEC61499. So the user has not to care about the distributed nature of his application ... he is working with a single machine.

>> The nodes of a distributed system are intelligent nodes. <<
--- snip ---

> The problem is that there is typically a lot of global state to be distributed. The majority of addresses used in a typical PLC program are not I/O addresses. They are internal states that coordinate the I/O, often through multiple layers of abstraction. The scope for local processing is limited unless you bring all the related inputs and outputs into a single device and control them there. Once you do that however, you have just re-introduced the PLC under a new name. Yes, you could have multiple small "proxies" divided between functional machine units, but typical modern production lines have multiple small PLCs divided along similar lines. So, what is new here (other than the software layer)? <

The IEC61499 applications are not bound to discrete PLCs or DCs. applications can be distributed in different ways over the PLCs or DCs. So at the end you can add or remove a systems without changing the application. this is at least the approach :)

>> The concept of the proxy shows just the possibility to read and write IOs...but it is not a core concept of the IEC61499 standard. <<

> Well, the point I was making was the existence of the large gap between the "concept" and the practical implementation. Once you bring the concepts to an actual implementation, you end up with something that looks a lot like what we have today, except with IEC 61499 added on top. <

What we have today is a bunch of PLCs with polling operation. the
support of multiple controllers are not covered by the IEC61131-3 standard.

IEC61499 is strictly designed for event oriented processing and
distributed operation ... every block has a ECC which works in that way. So the IEC61499 is the logical and consistent step into the world of automation networks.

>> James mentioned also that the algorithms can also be implemented with C, C++ or Java. so there is no focus on PLC devices. <<

> Sure, and you can program machines today using C, C++, or Java. However, what I have read about IEC 61499 talks about the implementation part of the 61499 FB as being IEC 61131-3, right down to the same data types and the same languages. You can call that what you like, but it looks a lot like a PLC (or soft logic system) to me. <

The IEC61499 "standard" is a draft. So I wouldn't take statements about the usage of IEC1131-3 as programming tool for function blocks not too seriously.

> My original point of discussion with Mr. Pollard was that I don't see how IEC 61499 solves the problems of IEC 61131. 61499 is simply built on top of 61131, not a replacement for it and so inherits all the problems of 61131.

IEC61499 isn't built on top of IEC61331. that's a complete miss
understanding. How could IEC61131 provide event oriented processing?

How could IEC61131 provide support of multiple controllers for
distributable application?

> It doesn't appear to be intended to even try to solve the problems of 61131, so I can't really fault it on that point. <

See my statements before. and if you want to learn something about the differences: http://www.fordiac.org

Best Regards
Armin Steinhoff
http://www.steinhoff-automation.com
 
In reply to Armin Steinhoff:

I looked at the web site that you referenced (http://www.fordiac.org), and right on the front page it says the same thing that I have been saying. Here's what they say:

"The domain of automation industry is characterised by a highly proprietary environment. Different platforms and different tools are in use. In most cases there is no interoperability between different solutions of different vendors. The standard IEC 61131-3 provides a very small basis for common modelling of control programs, but platforms and tools are not able to interoperate."

This is the same as what I said previously.

The web page then goes on to quote directly from the IEC 61499 presentation that I have been quoting from with regards to "portability, configurability, and interoperability". It follows this up with their own conclusion of:

"A look at the current status of the developments in the domain of IEC 61499 shows, that these targets may be failed."

So, the web page that you reference to support your position says that as it stands, IEC 61499 is an outright failure. That is putting things much more strongly than I did.

Now it does state that they hope to salvage something from the current mess by taking the concept in a new direction. That's great, and I hope they succeed.

However, they don't appear to have abandoned IEC 61131-3 altogether. They incorporated Christiansen's slides within their own presentation, and those in turn reference IEC 61131 (see "Modelling Distributed Control Systems within 4DIAC" by Zoitl and Strasser, from the 4DIAC web site). So, it is unclear to me where they really stand on this. Their current software seems to be a C++ code generator, but is that really suitable for someone who is currently a PLC user?

If you look on page 26 of the above mentioned document however, they have a slide (copied from Christiansen) showing a function block whose algorithms are implemented by IEC 61131-3 (see page 26).

So, their conclusion seems to be that IEC 61499 is a failure, but they hope to "fix" it somehow. What that "fix" is to be however isn't clear to me.
 
C

Curt Wuollet

It might be just as well, I haven't seen a job available in automation since March. Well, save the ones that want a MSME or MSEE and 20 yrs experience to install openers for a garage door company. Perhaps they will make working in automation sufficiently repugnant where changing paths back to CS or IT or electronics doesn't bother me. Automation appears to be quite dead in this part of the world for the time being. Of course, I can't see any reason for businesses to invest given the existing political climate. When the automation majors layoff, perhaps they'll start with the authors of all that doublespeak.

Regards
cww
 
Hello,

> I looked at the web site that you referenced (http://www.fordiac.org), and right on the front page it says the same thing that I have been saying.Here's what they say: <

> "The domain of automation industry is characterised by a highly proprietary environment. Different platforms and different tools are in use. In most cases there is no interoperability between different solutions of different vendors. The standard IEC 61131-3 provides a very small basis for common modelling of control programs, but platforms and tools are not able to interoperate." <

> This is the same as what I said previously. <

> The web page then goes on to quote directly from the IEC 61499 presentation that I have been quoting from with regards to "portability, configurability, and interoperability". It follows this up with their own conclusion of:

> "A look at the current status of the developments in the domain of IEC 61499 shows, that these targets may be failed." <

> So, the web page that you reference to support your position says that as it stands, IEC 61499 is an outright failure. <

IEC61499 is not only a standard for "portability, configurability, and interoperability" ... it covers a lot of other problems which can't be solve with IEC61131-3.

The mission of the 4DIAC group is to build an open implementation that can be used as a base for "portability, configurability, and interoperability".

So I would say your conclusion is an outright failure. BTW, do you believe a new standard could change commercial rules of the automation market ??

> That is putting things much more strongly than I did.

> Now it does state that they hope to salvage something from the current mess by taking the concept in a new direction. That's great, and I hope they succeed. <

> However, they don't appear to have abandoned IEC 61131-3 altogether. They incorporated Christiansen's slides within their own presentation, and those in turn reference IEC 61131 (see "Modelling Distributed Control Systems within 4DIAC" by Zoitl and Strasser, from the 4DIAC web site). So, it is unclear to me where they really stand on this. Their current software seems to be a C++ code generator, but is that really suitable for someone who is currently a PLC user? <

> If you look on page 26 of the above mentioned document however, they have a slide (copied from Christiansen) showing a function block whose algorithms are implemented by IEC 61131-3 (see page 26). <

A function block consist at least out of 2 parts: the Excecution Control Chart (ECC) and the algorithm for processing data. The algorithm can be written in e.g. C/C++, Java or IEC1131-3. The real-time behavior is defined by the ECC and not by the IEC1131-3 code. So what's bad with the IEC61131-3 code?

> So, their conclusion seems to be that IEC 61499 is a failure, but they hope to "fix" it somehow. What that "fix" is to be however isn't clear to me. <

You are simply misinterpreting the statements of the 4DIAC group. The only failure is to believe that a new standard could change the rules of the market ...

Best Regards
Armin Steinhoff
http://www.steinhoff-automation.com


 
In reply to Armin Steinhoff:

You said:
>> So I would say your conclusion is an outright
>> failure.

Uh, that wasn't my conclusion. I was restating the conclusion from the web site that *you* referenced. They said "A look at the current status of the developments in the domain of IEC 61499 shows, that these targets may be failed." If you have a problem with that, I suggest that you take it up with 4DIAC, not me. I said that they were putting things much more strongly than I would.

You said:
>> BTW, do you believe a new standard could
>> change commercial rules of the automation
>> market ??

No, I think that the automation market would need to change before we will get a standard that anyone cares about. If 4DIAC can do that, then that's great. However, I don't know if that is their intention. If it is their intention, then I don't think they would accomplish it by convincing the major automation vendors to change. They would have to do it by offering something to people that can be used directly, and so bypassing the major vendors. If the market changes the major vendors may follow. They won't initiate that change though.

You said:
>> A function block consist at least out of 2
>> parts: (...) So what's bad with the IEC61131-3
>> code?

What is "bad with the IEC61131-3 code" is that 4DIAC said that IEC 61499 can't achieve "portability, configurability, and interoperability" using IEC 61131-3. However, they still mention it as part of IEC 61499.

I know their current software uses C++. They have basically created an IDE and run time library for C++ embedded applications. I'm sure that is a very laudable thing to do. But it isn't going to have any significant effect on the overall automation market as PLC programmers are not suddenly going to turn into embedded C++ programmers.

However, if we go back to the original point of this discussion, Mr. Pollard was stating that he hoped that IEC 61499 would address the deficiencies of IEC 61131-3. I stated that I didn't see how that could happen, as 61499 (in PLC type applications at least) was based on 61131. I don't see 4DIAC addressing any of those problems, or indeed even intending to address them. I'm not going to pile anyone's hopes of an open market upon them when they have shown no interest in that burden. So, for people who want to use a PLC or soft logic system (as opposed to an embedded C++ program), I don't see how IEC 61499 can live up to Mr. Pollard's hopes for it.
 
C
Hi Armin,

If cooperation on a standard can't change the rules of the market, the whole effort is a waste of time and futile in the extreme. Forget about it. I can live with that and it's a far better thing than creating a bunch of churn for something that doesn't solve any of the real problems, which are artificial and market driven. History shows that everyone gets jerked around for these brilliant ideas that get meager acceptance at best and then merely serve to further Balkanize the market for years. The phrase "More harm than good" comes to mind.

Regards
cww
 
Hello all,

> You said:
>
>>> So I would say your conclusion is an outright failure. <<<

> Uh, that wasn't my conclusion. I was restating the conclusion from the web site that *you* referenced. <

It was your conclusion that the whole IEC61499 will fail because of it can't solve the issue "portability, configurability, and interoperability". The 4DIAC web site was telling us that IEC611499 will fail to solve the aspects "portability, configurability, and interoperability" and not more.

> [ clip]
> What is "bad with the IEC61131-3 code" is that 4DIAC said that IEC 61499 can't achieve "portability, configurability, and interoperability" using IEC 61131-3. <

ICE 61131-3 doesn't achieve until today "portability, configurability, and interoperability" ... why should it be useful in that aspect for IEC61499?

> However, they still mention it as part of IEC 61499. <

Again, the IEC61131-3 standard isn't part of the IEC 61499 standard.

> I know their current software uses C++. They have basically created an IDE and run time library for C++ embedded applications. I'm sure that is a very laudable thing to do. But it isn't going to have any significant effect on the overall automation market as PLC programmers are not suddenly going to turn into embedded C++ programmers. <

The majority of programmers will not design base level function blocks using C/C++, Java or IEC1131-3 code ... they will mostly build composite function blocks based on base level function blocks as done e.g in a IEC61131-3 environment.

> However, if we go back to the original point of this discussion, Mr. Pollard was stating that he hoped that IEC 61499 would address the deficiencies of IEC 61131-3. I stated that I didn't see how that could happen, as 61499 (in PLC type applications at least) was based on 61131. <

IEC61499 isn't based on IEC61131-3! This also not the case for PLC
type application.

Best Regards
Armin Steinhoff
http://www.steinhoff-automation.com
 
Hi Curt,

> If cooperation on a standard can't change the rules of the market, the whole effort is a waste of time and futile in the extreme. <

IMHO ... that conclusion is to hard. Have a look to the compatibility of C/C++ compilers ... C applications written with the Visual C are not fully compatible with the GNU C/C++ compilers. Versions of the GNU C/C++ compilers are not compatible to each others.

Would you say the ANSI C standard is a "waste of time and futile in the extreme" ?

Best Regards
Armin Steinhoff
http://www.steinhoff-automation.com
 
C
Hi Armin,

> IMHO ... that conclusion is to hard. Have a look to the compatibility of C/C++ compilers ... C applications written with the Visual C are not fully compatible with the GNU C/C++ compilers. Versions of the GNU C/C++ compilers are not compatible to each others.
>
> Would you say the ANSI C standard is a "waste of time and futile in the extreme" ?

I would say that it is that way in part because some folks try to meet the standard and some folks don't, which is a better situation than automation where it seems all want to set their own standard regardless. And C and to a lesser extent C++ aren't very good examples because at the very low levels you simply can't make the hardware work the same way and with the very complex processors, optimization will make for some differences.

A better example would be BSD style sockets. Across many OS, many architectures, many compilers, etc. the effort is made to see that they will connect. The author implements the routines to see that what goes on the wire is compatible in byte order, representation, etc. NFS, RPC, and the like _are_ standards because they were there and you standardize or it doesn't work. The automation majors and some other companies we won't mention do not want any standard that they can't own and believe they should set the standard and everyone else should come to them, via a tollbooth, of course. If they were at all interested in real standards, they could study how these came to pass. They were either done without commercial interest, or at some point some entity sacrificed commercial interests for the sake of having a standard. They are not licensed. You don't have to be a member of a club, you don't have to be certified and no money changes hands if I write to these standards. History shows us this type of altruism is utterly and totally absent in the principals of these "standards organizations" making them a farce. Anything preceded by IEC, historically, has been a better example of an anti-standard than a standard. What is needed to progress in our lifetime, is a standards body free of commercial interests as far as possible, that could pick and choose from proposals based on merit, enforce public ownership, and see that the efforts of standard breakers simply won't work. Successful standards achieve this by being ubiquitous, it's unthinkable to take over the web, well.... except in Redmond, and they failed. We need a stepping stone between chaos and this reality, not a barroom brawl with nice PR.

Regards
cww
 
In reply to Armin Steinhoff: I can probably sum up your position as being that IEC 61499 can succeed in portability, interoperability, etc. by ignoring IEC 61131-3 (or at least most of it) and concentrating on implementing everything as a pure function block and that this is the approach that 4DIAC is taking.

So, do you believe that:

a) IEC 61499 will replace IEC 61131-3 in most applications?

or

b) IEC 61499 will simply supplement existing ladder and IL in certain limited applications?

or

c) You really don't know or care about "a" or "b" and just wanted to make the point that IEC 61499 could be implemented without incorporating all of IEC 61499?

I am trying to understand how your argument fits in with your statement that "the only failure is to believe that a new standard could change the rules of the market". If IEC 61499 isn't going to change the market, then where do you think it fits in?
 
In reply to Curt Wuollet: I think that C (and C++) is a great example. If IEC 61131-3 offered the same degree of compatibility that C does, we would have very little to complain about. In fact, that degree of compatibility is exactly what most people want and what the IEC process has failed to deliver.
 
C
If it were like C under UNIX, that might be OK. C on DOS and Windows is nowhere near as portable to UNIX, for example, unless you stay with GCC. An awful lot of C programming for the real world involves system calls which are OS specific. The actual K&R book and ANSI standard don't do much IO which is what automation is about. You would need a universal IO API or something.

Regards
cww
 
> I can probably sum up your position as being that IEC 61499 can succeed in portability, interoperability, etc. by ignoring IEC 61131-3 (or at least most of it) and concentrating on implementing everything as a pure function block and that this is the approach that 4DIAC is taking.
>
> So, do you believe that:
>
> a) IEC 61499 will replace IEC 61131-3 in most applications? <

No, I don't think so. The targets of both standards are different. IEC61499 is targeting automation system with distributed processing. IEC61131-3 targets are automation systems with centralized processing.

> or
>
> b) IEC 61499 will simply supplement existing ladder and IL in certain limited applications? <

IEC61499 is not a supplement of any thing ...

> or
>
> c) You really don't know or care about "a" or "b" and just wanted to make the point that IEC 61499 could be implemented without incorporating all of IEC 61499? <

The first implementations of IEC61499 can't cover all aspects of this
(draft) standard.

> I am trying to understand how your argument fits in with your statement that "the only failure is to believe that a new standard could change the rules of the market". If IEC 61499 isn't going to change the market, then where do you think it fits in? <

It fits in in the area of reconfigurable "automation networks" ...

Best Regards
Armin Steinhoff
http://www.steinhoff-automation.com
 
Thread starter Similar threads Forum Replies Date
S General Automation Chat 1
C Languages 3
T Motion Control 7
C Programmable Logic Controller - PLC 7
B General Automation Chat 1
Top