IEC 1131-3 Software

P

Thread Starter

Paul

Hi, newbie here!

I currently have a lot of logic for various projects in an overview format in Micrografx Designer. It works relatively well and the sheets can be handed out to be coded for whatever vendor PLC is being used. However this system is "dead" and has no tag database each function forms a separate designer plan with the interconnected tags being manually handled. What I would really like is IEC 1131 compliant software that is not PLC vendor specific and would allow me to code the logic in a live system recognising tags and attributes etc. What would be even better is if the system would then allow creation of vendor PLC code...

Any help or suggestions gratefully received.

pscockram @ yahoo. co. uk
 
J

Jeremy Pollard

Paul - you and a million others. IEC-61131 does not post process as such. You develop in the development environment for the hardware you are going to use.

Check out my series at controldesign.com on IEC-61131 on what it is and what it isn’t.
The original premise of IEC61131 WAS to provide an independent platform - ain't happening!!

However, there are a lot of companies that have private labeled 3S software (no slight against any of the other development vendors). If you develop in their IDE, then you may be able to re-use more of the code regardless of the
hardware platform than others.

That is to say if you developed code using Wago's supplied programming system, I am not sure if you can even open the file using generic 3S software. Something I haven’t checked.

Has anyone tried this??

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
 
Really, there are no such a premise in the original IEC61131 standard. More over it does not contain any declaration of aim at all.

Only OpenPLC community considers the standard has the premise you point out. It seems to me the main premise of the IEC 61131-3 is wiches of the big guys to protect their segments of market.

--
Best regards,
Vladimir
 
J

Jeremy Pollard

Vladimir - I submit that the intent of the standard was to provide commonality between hardware platforms.

PLCopen is trying to move the implementation of the standard to a different level, and as former managing director of PLCopen, the organization is not doing enuff towards that goal. Whether the goal can be reached is still very debatable.. to your last statement .. all vendors will want to protect their segment..

Regardless of WHO it is!!!!

I submitted to the Board of Directors 4 or 5 years ago the concept of having a set of PLCopen standards or specs.. and provide the users a list of who meets them.. PLCopen tested if you will. Then users can ask for PLCopen certified compatible products and technologies... but I'm not sure that can happen since the organization is funded by vendors..

Its up to the users right now to figure things out for themselves - how's that working for you????

If more users got involved then the outcome may be different..

I still want to know if ST from Siemens can be cut and pasted into ControlLogix directly... or a Wago program file can be opened by 3s native.

That is part of the platform that PLCopen can support and nurture... that sort of testing can help users understand why they may want to investigate using IEC61131, along with the PLCopen initiated programs such as motion control function blocks etc.

Or help understand why the world really hasn’t changed in 25 years...

Man I'm having some bad days!!!!

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

Michael Griffin

In reply to Jeremy Pollard: Something that would be very useful would be a set of PLC programs that act as conformance tests. At its most basic, it would be an IL program where each network (rung) conducted a different test.

The first and most obvious test would be if the PLC accepted the program and recognised all the instructions, addresses, and constants. This means PLCopen would have to define a minimum instruction set and address types for conformance.

The next step would be to run the program and see if it produced the expected output. This involves proving the instructions one by one. First you exercise some fundamental instructions, and prove they work. Then you can use those instructions to help prove other instructions, in a boot-strap like process.

When an instruction test passes, it turns on a memory flag. By examining the memory flags, you can see which tests passed, and which failed.

The standard test program(s) would be in IL in text format. It would be up to the person conducting the test to get the program into the programming software, and then into the PLC (the objective of this test isn't to standardise the programming software).

If this idea is pursued, the test program(s) should be freely available to anyone so that customers can conduct their own tests. This is the only way to make the process relevant, as vendors will simply not bother with conformance testing if they know that no one else can test their hardware without their cooperation. If the vendors know that customers will be free to test their hardware anyway, then they will have some incentive to take the initiative so as to have some control over how the results are presented to people.

PLCopen could conduct (or approve labs to conduct) official tests and certify the results. Vendors could then use these official results in their advertising.

At present though, I don't know if any vendor would pass enough tests to meet a reasonable certification. Some of the smaller ones might, but I doubt the larger ones would. Probably the best thing PLCopen could do initially would be to just start publishing some (non-certified) results on a regular basis. That would help create the publicity which is needed to get the process off the ground.
 
J

Jeremy Pollard

Hello Michael,

Certification is already done to the IEC standard. The website plcopen.org lists the certified vendors with the certified languages and 'modes'. While there aren't many, I have always stood on the side of 'it really doesn’t matter' because of the extensibility. Staying in the bounds of the standard is very limiting and I'm not sure you could do any real work with it.

Having said that, it would be useful to have a 'conformance' test that shows what the product is and what it does re data types etc including the extensions.

Your key comment was 'customers' - PLCopen is not user-involved enuff through no fault of their own (I think). They need to be to drive the perceived benefits.

PLCopen-certified... interesting concept!!

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

Control Design www[.]controldesign.com Manufacturing Automation www[.]automationmag.com
 
B
While the world isn't perfect, the PLCopen XML interchange standard is gaining in acceptance. The XML standard allows interchange of programs between editors and simulation software. I believe the adoption of the XML interchange standard will be good because the management at major I have been meeting with need this in order to use simulation software to design machines and processes, including control logic before implementation. The driving force is the experience users are having using simulation before implementation with reductions of engineering, commission, and start-up times by 30% or more. The new XML standard is designed to make this seamless. More information can be found at: http://www.automation.com/resources...gains-acceptance-as-digital-factory-interface

Bill Lydon, Managing Director
PLCopen North America
[email protected]
 
M

Michael Griffin

In reply to Bill Lydon: I'm not sure what point you are addressing with your XML based interchange spec. I had a look at it last year, and it seemed to have a very narrow scope of application. It seems to be concentrated on presentation, whereas I have been discussing function.

Specifications will always be to some extent ambiguous. That is, there is often more than one way to interpret the description. This ambiguity is inevitable in English, or in any other natural language. What is needed to clear up the ambiguities is some sample programs which exercise those instructions to produce certain expected results.

For example, I have been working on writing a soft logic system. For each instruction, I read the documentation as to how that instruction should work and then write the code to implement the instruction. Then I write a small PLC program which uses that instruction in several different ways and see if it produces the expected result. If the result is not as expected, then I need to correct it (at the moment I see a window on my screen telling me my rotate-right result is wrong). However, the "expected result" is *my* interpretation of a written description. There is no guaranty that everyone else would interpret it the same way.

While we are on the subject of test PLC programs, I can see two other areas in which establishing standards would be useful. One is in measuring execution speed, and the other is in determining how large a program a PLC can hold.

PLC manufacturers like to cite the speed of boolean operations, usually in terms of microseconds per instruction, or milliseconds per thousand operations. These numbers are susceptible to manipulation because there is no standard (that I am aware of) for which instructions are being tested or how they are combined in to rungs, or under what conditions. I can for example, make my soft logic system appear to be nearly twice as fast just by some careful selection of which boolean instructions to test and how they are combined together. A standard benchmark test program would allow more comparable results between vendors.

Another area that could use standardisation is in rating how large a program a PLC can hold. Vendors typically rate their PLCs in terms of kilo-bytes of RAM. That isn't very useful though, because it doesn't tell you how much RAM a program needs. If they were rated in terms of a size factor based on a standard program (e.g. "holds 2.3 standard programs"), then it is easier for customers to compare different PLC models. This is useful information for someone using a new PLC for the first time. I once compared two different product lines from the same vendor, and found that an equivalent program for one model was only 40% of the size (in kilo-bytes) as when written for the other model, so the differences can be significant.

These sorts of tests and benchmarks are commonplace for computer programming languages, or web browsers, or anything else that involves interoperability standards. You don't know if you are interoperable unless you test for it, and tests are meaningless unless everyone uses the same tests. Furthermore, customers don't (in the computer business) trust tests or benchmarks that can't be repeated by anyone who wants to do a test because of the long history of results being manipulated for commercial PR reasons.

If PLCopen wants to promote standardisation, then I think this is a useful area for them to look into.
 
Jeremy-

I will limit my comments to the motion control function blocks. I have come to realize that PLCopen certification is a farce. The vendors self-certify by signing a paper stating that certain function blocks are supported, but there is no 3rd party testing to see that the function blocks operate in accordance with the standard. I have come to find out that different vendors implementation of the function blocks are not the same, and hence the function block results are not the same. Very frustrating, considering what the IEC standard was supposed to accomplish.
 
J

Jeremy Pollard

Guess you did what PLCopen was designed to do, and what Ken Crater tried to start with a 3rd party validation lab.

So again it seems that IEC-61131 is MY standard and not YOUR standard from a coding point of view. The market is still somewhat closed, and will be for a while.

IEC-61499 hopefully will change some of that...

PLCopen can do some good things, and while I think their hands may be tied by the vendor support they have, they have no funds to break out on their own, and have minimal user support.

Guess the only real benefit is the user/operator/maintenance transition game from one hardware vendor to another yes?? Programmers are a different story!!

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

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

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579
 
In reply to Jeremy Pollard: The automation industry seems to be full of what are known in the computer industry as "architecture astronauts". That is, people who view things from such a high level that they lose sight of the problems that the average person is actually trying to solve. What I have seen of IEC 61499 looks like it has blasted out of orbit and headed out past the moon. I think that IEC-61499 will have even less influence on the industry than 61131-3 has had.

I think that what most people want is they want a better ladder language. They want ladder, but with something added to it to help organise it into sequences. They want a regular data table, but they don't want to have to worry about what sort of integer a number is, or how many bytes a particular floating point format occupies. They want to take what they've got and are familiar with, but make it easier and faster to use.

And if you look at what people really complain about, they complain that every model of PLC needs its own different programming software that requires constant (and expensive) updates in order to keep functioning. I haven't seen the IEC or PLCOpen proposing to do anything about that.
 
J

Jeremy Pollard

I'm not sure I would agree with you Michael re IEC 61499 .. it COULD be a pancea for some.. and a true standard for all...

Guess we'll see how the 'free markets' screws that up!!

Common programming platforms will never happen due to marketing etc. and as IEC-61131 was supposed to address that we have beaten that horse to death
...

I agree with the ease of use thing... datatypes shold take care of various issues I would think, but the designers of software still assume that user knows something..

No disrespect meant, but it you keep it dumb and simple, then the tasks can get done by most if not all... the software STILL requires way to much intimate knowledge

Remember the 3 in the morning wake up call!!

Cheers from : Jeremy Pollard, CET The Caring Canuckian!
http://www[.]tsuonline.com
Control Design www.controldesignmag.com
Manufacturing Automation www[.]automationmag.com
3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579
 
In reply to Jeremy Pollard: So far as I can tell, IEC 61499 is a wrapper around IEC 61131-3, and is the product of the same committee. I don't see how it could fix the problems in IEC 61131-3, when it is simply an extension of that standard. We'll still have a 100 flavours of ladder and IL and 7 different incompatible "standard" networks.

As for "remember the 3 in the morning wake up call", I suspect that IEC 61499 might be a good thing for those who are looking forward to billing by the hour to get such calls. If you would rather have a good night's sleep though, you might wish to avoid it. IEC 61499 is all about event driven distributed control. Neither of those concepts is simple or easy to implement properly. Problems are not made simpler by adding complexity.

There is also a lot of talk about it being used to "protect intellectual property". This doesn't sound good for the guy on the shop floor who is trying to troubleshoot yet another block box. I hope you have all your license keys handy for each function block.

I have read over various literature on IEC 61499, and what I have seen so far is more or less "let's plaster another layer of software on top of everything we've already got, and then we can sell it as a DCS". I think this is what the major PLC vendors see in it for them. I don't see what it would do for someone who just wants a PLC though.
 
J

Jeremy Pollard

Reply to M Griffin

IEC61499 uses IEC-61131 to generate the code that resides on each node. the networkability of the standard is nothing like 61131 as such.

The devices themselves are the controllers.

Dr James Christiansen was a driving force behind it.. from a website:

IEC 61499-1 defines an open architecture for distributed and embedded control and automation. In conjunction with an appropriate compliance profile as defined in IEC 61499-4 and software tools meeting the requirements of IEC 61499-2, reusable software modules (function blocks) can be developed and deployed in distributed systems that will meet the requirements of:

* portability: Software tools can accept and correctly interpret software components and system configurations produced by other software tools.

* interoperability: Embedded devices can operate together to perform the functions needed for distributed applications.

* configurability: Any device and its software components can be configured by software tools from multiple vendors.

It defines much more tan the software model and software layers.

Whether it gains any traction remains to be seen.. check out isagraf.com - one of the few 61499 development environments

And the PLC doesn't exist in an IEC61499 design... so true enuff.. if one needs/wants a PLC, then they need to stick with that!!:)

Cheers from : Jeremy Pollard, CET The Caring Canuckian!
http://www[.]tsuonline.com
Control Design www.controldesignmag.com
Manufacturing Automation www[.]automationmag.com
3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579
 
In reply to Jeremy Pollard:

If you look at Christiansen's presentation "IEC 61499: A Standardized Architecture for Adding Value in Industrial Automation", you will see several diagrams showing "typical" systems. The equipment includes the range of AB hardware (Christiansen works or worked for AB) including an AB Contrologix PLC, an AB HMI panel, a variable speed drive, etc. It's a pretty conventional networked hardware system.

The "handwavy" parts of the concept talk about the 61499 function blocks being distributed in some sort of nebulous cloud fashion. However, if you read about the use of "proxies" you can see that most of the system is actually hosted inside a conventional PLC, although they never actually say "PLC". Yes some things like drives could control themselves, but they can already do that now.

The problems with distributing all the logic into each end device are two fold. First is cost. It's not practical from a cost perspective to make every limit switch and pneumatic cylinder a fully programmable logic device.

Second is the communications interconnections. Most of the logical relations in a PLC program are between internal states or derived values, not between physical I/O addresses. This means that in a truly distributed system the amount of communications required will increase geometrically with the number of logic conditions.

This second problem is addressed by the 61499 "proxy". The proxy reads and writes the actual I/O and acts as an intermediary to the 61499 function blocks and can host the blocks themselves. And the function blocks themselves are really just ordinary ladder (or IL) with a wrapper around them. This however just effectively reintroduces the PLC under another name.

I see the proposal addressing mainly architecture astronautics but without a lot of practical applications (although there may be some). That probably shouldn't be too surprising though when you consider that the same document describes the differences between PLCs and DCSes in terms of Hegelian dialectics.
 
Hello,

> If you look at Christiansen's presentation "IEC 61499: A standardized Architecture for Adding Value in Industrial Automation", you will see several diagrams showing "typical" systems. The equipment includes the range of AB hardware (Christiansen works or worked for AB) including an AB Contrologix PLC, an AB HMI panel, a variable speed drive, etc. It's a pretty conventional networked hardware system. <

> The "handwavy" parts of the concept talk about the 61499 function blocks being distributed in some sort of nebulous cloud fashion. <

Yes, James Christensen's presentations about the networking issues are not very concrete. But in the meantime there is a lot of possibilities to realize the networking platform for IEC61499 systems. I like the concept of HARNESS (http://www.csm.ornl.gov/harness)

> The problems with distributing all the logic into each end device are two fold. First is cost. It's not practical from a cost perspective to make every limit switch and pneumatic cylinder a fully programmable logic device. <

Most of IOs are today networked devices. It costs cents to add a more powerful micro processor for the additional control tasks . So costs is not a real issue.

> Second is the communications interconnections. Most of the logical relations in a PLC program are between internal states or derived values, not between physical I/O addresses. This means that in a truly distributed system the amount of communications required will increase geometrically with the number of logic conditions. <

The nodes of a distributed system are intelligent nodes. These nodes are doing local processing and this will lower the need for the communication between nodes.

> This second problem is addressed by the 61499 "proxy". The proxy reads and writes the actual I/O and acts as an intermediary to the 61499 function blocks and can host the blocks themselves. <

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.

> And the function blocks themselves are really just ordinary ladder (or IL) with a wrapper around them. This however just effectively reintroduces the PLC under another name. <

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

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

Ken Emmons Jr.

This standard smells to me like it is very useful for certain applications, but overly complex for others. If you don't need to tie workcells together the need for distributed control within one small area becomes more of an acedemic exercise for the "cool" factor.

KEJR
 
C

Curt Wuollet

And whenever a vendor starts talking about value add, keep your hand on your wallet. This translates to: How do we sell a new system, which does the same thing as the old system once we've run out of marketing BS. And against all trends, charge more for it. Everyone's looking for that quantum leap in usability. Strangely, all of the proposals seem to be heading in the wrong direction.

I think they should keep PLCs simple for the things they do well. And rather than try to make compute engines out of them, they should be working on how to bring far more capable computers down to that dividing line. But, almost everybody already knows how to do that, it just can't be done with acceptable reliability with the negligent
choices they have made for software.

There's nothing wrong with having different classes of hardware for different parts of a solution. The utterly amusing part is that
they will eventually converge on something that looks a lot like a Software PLC on a PC. Only their solution will be perverted to have
all the incompatibility and Tower of Babel problems of the present mess because they feel that is crucial to profitability and world domination. It is this myopia that is the real problem with progress in automation. Without it, this all would have been sorted out by now. They are way, way, behind general computing.

Regards
cww
 
In reply to Armin Steinhoff:

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. Industrial control normally operates entirely at the other end of the scale. There are a lot of frameworks for distributed computing, but they all presume very high processing loads. I wouldn't expect much of what HARNESS does to be directly applicable to the problems faced by IEC 61499.

>The nodes of a distributed system are intelligent nodes. These nodes are doing local processing and this will lower the need for the communication between nodes. <

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

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

Here are a couple of headings from the document that I referenced earlier:

"IEC 61499 Algorithms are programmed in IEC 61131-3 Languages". There is a footnote that says "Also Java, C++, etc, depending on software tool support", but it is pretty clear from the context that IEC-61131-3 languages are predominant.

"IEC 61499 Reuses 61131-3 Data Types". It goes on to describe the restrictions placed on types and combinations of types. This means that other languages are "compatible" with 61499 only so long as they follow the same type model. Since a lot of popular modern languages *don't* follow this type model, they aren't (strictly speaking) compatible with 61499.

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

However, that still leaves the question of what problem is it trying to solve?
 
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