Inheritance (object-oriented) in PLC programming?

  • Thread starter Zen Master Soso
  • Start date
J

James Ingraham

Dave:

>Please explain to me EXACTLY
>how DeltaV (PAC) and RSLogix (PAC/PLC)
>do not adhere nor have the ability to
>adhere to an object oriented
>methodology. <

RSL5K cannot do encapsulation. Encapsulation lets you describe a THING, as well as the ACTIONS that thing can do. A UDT is a structure. You cannot add an AOI to the UDT. An AOI is a function; you cannot define a data type within the AOI. So if I create a UDT of type "Gun" I can have data like size, muzzle velocity, caliber, number of rounds, etc. But I can't describe its ACTIONS, like "fire" and "clean." You can "instantiate" an AOI; an AOI does not persist the way a tag of type "My_UDT" does. It has ACTION, but no STATE.

As a sub-point of encapsulation, there is no way to hide data. If I pass a UDT to an AOI or JSR, the called routine can do anything it wants with that data. There's no such thing as "private" scope. Which means that a rogue routine could put the data into an invalid state, like setting the "HasFired" field to true without first turning the "SafetyIsOn" field to false.

There is no way to accomplish polymorphism in RSL5K. An AOI can take only the data types defined at design time. You can not create a "function pointer" that allows different AOIs/JSRs to be called depending on which UDT I send it. So I call the AOI "Fire" which takes a "Gun" UDT. If I have a different UDT called "Canon", I will have to create an entirely sepereate AOI that takes Canon as input instead of Gun. I have to do this for each data type.

There is no inheritance. A UDT can CONTAIN another UDT, but it can't EXTEND the UDT. This is one of the reasons there is no polymorphism. If there was a "Weapon" UDT, and Gun and Canon both extend it, I should be able to call any AOI that expects a "Weapon." Of course, since there is no encapsulation inheritance doesn't make much sense anyway. There are already no methods (AOIs) in the UDT, so "extending" the UDT doesn't buy me anything.

>Please detail how DeltaV class based
>objects and dynamos <

I don't know DeltaV, but that much certainly sounds like OOP.

>and RSI's AOI/UDT
>and Global Objects fail to adhere to
>the "norm". <

Well, RSL5K certainly adheres to the "norm." In the USA, it IS the norm. In Europe, Step 7 is the norm, which is comparable for the purposes of this discussion. That doesn't make them object-oriented. Again, I'm not sure object-oriented is particularly useful in the automation world. Whatever success OOP has had does not mean that procedural, functional, aspect-oriented, event-driven, or constraint programming aren't better choices.

>Please include DETAILED explanations of
>projects you have done in both products
>and their failures (using the latest
>versions listed) <

I haven't used RSLogix 5000 v17 yet. Been using v16 since it came out, and RSLogix 5000 itself since version 2.21. It has indeed come a long way, especially adding the AOI instructions. My company makes industrial gantry robots. These are usually 4-axis machines, in a Cartesian systems with a rotating manipulator. We run them off of ControlLogix (or CompactLogix) either with Allen-Bradley's Kinetix 6000 over SERCOS or Rexroth's IndraDrive over Profibus. (Actually, we're doing our first project talking to the IndraDrive's over EtherNet/IP, which will make me a lot happier.) In the past we had to use the analog motion control cards (MO2AE) to run the old Rexroth Ecodrive or A-B 1394. We did a few systems with 1394 or Ultra 3000 on SERCOS. The Logix series was the first viable PLC / PAC we found that could control our machines without our software guys (e.g. me) rebelling. I wouldn't call myself an expert, but I've logged a lot of hours on Logix. Feel free to check out
our website, http://www.sagerobot.com.

"DeltaV (8.5 and higher)"

Haven't used DeltaV, since I don't do plant / process control. Still, does DeltaV really count as an IEC 61131-3 based PAC? I mean, it's got a LOT more to it. In looking over the DeltaV website I can't actually find anything I would call a PAC. This could just be me being an idiot, but I don't see something that roughly equates to a ControlLogix or S7-300.

>I really appreciate
>(in advance) the DETAILED explanations
>you will provide <

<sigh> Detailed I can do. What I can't do, apparently, is "civil." I'm not entirely sure what I said that upset you. It certainly wasn't my intent. I went back, and I actually think my original post is pretty detailed. And my final statement was that there are no PLCs or PACs that have a built in Dictionary class. This is pretty specific. Granted, you can do maps in procedural languages. And maps are really a capability of a LIBRARY, not of a LANGUAGE. Still, Logix doesn't have it. FSC (File Search and Compare) is a good little instruction. It'll take any array, and I can even give it my own expression. That's getting pretty close. But I can't build that expression into a UDT, nor even an AOI. That's a prime example of NOT being object-oriented. Oh, and it's linear only. And SRT (File Sort) will only take primitives, not UDTs.

I know you were being facetious. But I am rather literal. So I'm answering your question literally, because that's what I do, even though most likely I will just upset you more, and all of the other people reading control.com will roll their eyes at how I just keep digging the hole deeper. Sorry. And sorry about the run-on sentences, too.

-James Ingraham
Sage Automation, Inc.
 
D

DAVE FERGUSON

See comments below..........realize that I am not going to take any where near the time expanding on this...........................

On August 9, 2008, DAVE FERGUSON wrote:
> >Please explain to me EXACTLY> >how DeltaV (PAC) and RSLogix (PAC/PLC)> >do not adhere nor have the ability to> >adhere to an object oriented> >methodology. <> > RSL5K cannot do encapsulation. Encapsulation lets you describe a THING, as well as the ACTIONS that thing can do. A UDT is a structure. You cannot add an AOI to the UDT. An AOI is a function; you cannot define a data type within the AOI. So if I create a UDT of type "Gun" I can have data like size, muzzle velocity, caliber, number of rounds, etc. But I can't describe its ACTIONS, like "fire" and "clean." You can "instantiate" an AOI; an AOI does not persist the way a tag of type "My_UDT" does. It has ACTION, but no STATE.

DF: Between the combination of UDT, AOI and AOI internal variables why cannot I do this very thing ? The upper level UDT is for a class of Weapon including a "type" variable, the AOI with internal embedded ST uses if then for "Type" of weapon and between internal variables and logic, what the AOI does dirres depending on the "type" of weapon. Or Type of weapon is embedded in an AOI within Weapon.

I do not claim to be a 100% expert but what is the difference here. But the combination of UDT, internal variable within an AOI and AOI allow you to describe things as well as actions for those things.

> > As a sub-point of encapsulation, there is no way to hide data. If I pass a UDT to an AOI or JSR, the called routine can do anything it wants with that data. There's no such thing as "private" scope. Which means that a rogue routine could put the data into an invalid state, like setting the "HasFired" field to true without first turning the "SafetyIsOn" field to false.

DF: I can hide data within the internal variables of the AOI

> > There is no way to accomplish polymorphism in RSL5K. An AOI can take only the data types defined at design time. You can not create a "function pointer" that allows different AOIs/JSRs to be called depending on which UDT I send it. So I call the AOI "Fire" which takes a "Gun" UDT. If I have a different UDT called "Canon", I will have to create an entirely sepereate AOI that takes Canon as input instead of Gun. I have to do this for each data type.

If internal variable type = gun then UDT = x , else UDT = y ? I am not sure the entire point, if I build an object in a class based system I still at some point have to write the function pointers internally at design time. The software does not have the embedded AI (Artificial Intel) to just morph itself unless I am missing something here (entirely possible)

> > There is no inheritance. A UDT can CONTAIN another UDT, but it can't EXTEND the UDT. This is one of the reasons there is no polymorphism. If there was a "Weapon" UDT, and Gun and Canon both extend it, I should be able to call any AOI that expects a "Weapon." Of course, since there is no encapsulation inheritance doesn't make much sense anyway. There are already no methods (AOIs) in the UDT, so "extending" the UDT doesn't buy me anything.

DF: Think this was covered above..not sure your point and being Saturday not willing to expend any more brain cells on it (being honest)

> > >Please detail how DeltaV class based> >objects and dynamos <> > I don't know DeltaV, but that much certainly sounds like OOP.> > >and RSI's AOI/UDT> >and Global Objects fail to adhere to> >the "norm". <> > Well, RSL5K certainly adheres to the "norm." In the USA, it IS the norm. In Europe, Step 7 is the norm, which is comparable for the purposes of this discussion. That doesn't make them object-oriented. Again, I'm not sure object-oriented is particularly useful in the automation world. Whatever success OOP has had does not mean that procedural, functional, aspect-oriented, event-driven, or constraint programming aren't better choices.> > >Please include DETAILED explanations of> >projects you have done in both products> >and their failures (using the latest> >versions listed) <> > I haven't used RSLogix 5000 v17 yet. Been using v16 since it came out, and RSLogix 5000 itself since version 2.21. It has indeed come a long way, especially adding the AOI instructions. My company makes industrial gantry robots. These are usually 4-axis machines, in a Cartesian systems with a rotating manipulator. We run them off of ControlLogix (or CompactLogix) either with Allen-Bradley's Kinetix 6000 over SERCOS or Rexroth's IndraDrive over Profibus. (Actually, we're doing our first project talking to the IndraDrive's over EtherNet/IP, which will make me a lot happier.) In the past we had to use the analog motion control cards (MO2AE) to run the old Rexroth Ecodrive or A-B 1394. We did a few systems with 1394 or Ultra 3000 on SERCOS. The Logix series was the first viable PLC / PAC we found that could control our machines without our software guys (e.g. me) rebelling. I wouldn't call myself an expert, but I've logged a lot of hours on Logix. Feel free to check out our website, http://www.sagerobot.com. > > "DeltaV (8.5 and higher)"> > Haven't used DeltaV, since I don't do plant / process control. Still, does DeltaV really count as an IEC 61131-3 based PAC? I mean, it's got a LOT more to it. In looking over the DeltaV website I can't actually find anything I would call a PAC. This could just be me being an idiot, but I don't see something that roughly equates to a ControlLogix or S7-300.

DF: Not sure that I said anything about DV being a 61131-3 based PAC, may have said that it contains some of the languages of the standard but here again (see points below) there have been numerous articles written and discussed on this list about which softwares even adhere to 61131-3 so not sure I would reopen this endless rant of who adheres to 61131 any more than the fact we are discussing what adheres to object oriented thinking.

> > >I really appreciate> >(in advance) the DETAILED explanations> >you will provide <> > <sigh> Detailed I can do. What I can't do, apparently, is "civil." I'm not entirely sure what I said that upset you. It certainly wasn't my intent. I went back, and I actually think my original post is pretty detailed. And my final statement was that there are no PLCs or PACs that have a built in Dictionary class. This is pretty specific. Granted, you can do maps in procedural languages. And maps are really a capability of a LIBRARY, not of a LANGUAGE. Still, Logix doesn't have it. FSC (File Search and Compare) is a good little instruction. It'll take any array, and I can even give it my own expression. That's getting pretty close. But I can't build that expression into a UDT, nor even an AOI. That's a prime example of NOT being object-oriented. Oh, and it's linear only. And SRT (File Sort) will only take primitives, not UDTs.> > I know you were being facetious. But I am rather literal. So I'm answering your question literally, because that's what I do, even though most likely I will just upset you more, and all of the other people reading control.com will roll their eyes at how I just keep digging the hole deeper. Sorry. And sorry about the run-on sentences, too.

DF: I do not think you are being anything but yourself, I am not upset nor mad. My point is that sometimes these terms are interpretations of the author. There are many out there who interpret whether something adheres or doesn't to certain "models" as they understand them based on their perceptions of the "standard". I have sat in many a discussion about symantecs and it usually boils down to perspective and interpretation. I think that if I create an object "valve" describe its "properties" and define it's actions and create instances of them that will "inherit" structure from the parent combination of UDT and AOI and internal tags, there is no way for me to them claim that it doesn't function as an object "final control element" unless I have had the forsite as a programmer to create the object "final control element" first and defined all of that structure to include the type "valve", "motor" and "hydraulic ram" etc.

Without having that forsite unless I am missing something (again entirely possible), in any language to have in some place created that class structure, will the software whether "object oriented" of not to "morph" into something I did not program.

I think that a better way of saying it is that there are NO PLCS that adhere to your interpretation of what you understand object oriented progamming to be. But I will fill a room with 100 "computer science experts" and not only will we not be able to all agree on the semantics of this discussion, but we could never all agree on what kind of donuts to buy if we all have to agree on one definition of what a donut is (we would all starve first). PS: Must have jelly, must have jelly.

I think just like we cannot get IT programmers to agree about which developement software adheres to all the "perfect" programming rules PERL, vs JAVA versus .NET etc, we will never agree on the abilitities of PAC/PLC programming tools, they are all interpreters. I have never had an issue with adhering to some form of "norm" by getting really creative but you must admit (and have) that they are much closer to the BUZZ than before and with some creativity can adhere to the "model".

Hell I sit on the ISA HMI and alarms standards committee's and we can take 11 months talking about what color an "object" should be when on and what color when "off".

Wasted enough brain cells for a Saturday.........................We can agree to disagree on some points in the discussion, I say that conceptually there are PLC/PACS out there that adhere to the jist of ORP, you say there are NONE.

Dave
 
J

James Ingraham

> "DF: Between the combination of UDT, AOI
and AOI internal variables why cannot [we implement OOP]?" <

The AOI is tied to the UDT, but the UDT isn't tied to the AOI. If I export the UDT and use it in another project, I don't get the AOIs with it. That's the whole point of OOP. This isn't just semantics; putting data and code together is what makes it object-oriented.

DF: "The upper level UDT is for a class of Weapon including a "type" variable..."

Again, this is what OOP is designed to avoid. Now you have a big switch statement. "If weapon==1 else if weapon==2 ..." If I add a new weapon type I have to change the AOI.

DF: "I can hide data within the internal variables of the AOI."

No, you can't. If you have a field for "SafetyIsOn" in the AOI, the value goes back to the default as soon as the AOI finishes. The data doesn't persist from one call to the next. If the field is in the UDT, I can edit it from anywhere. Can't be done.

DF: "If internal variable type = gun then UDT = x , else UDT = y ? I am not sure the entire point, if I build an object in a class based system I still at some point have to write the function pointers internally at design time. The
software does not have the embedded AI to just morph itself unless I am missing something here
(entirely possible)."

Yes, you're missing something here. The whole if..else is what OOP can get rid of. True, I have to write the function somewhere. (Unless inheriting the default works.) But, and this is the key point, I DON'T MODIFY ANY PRE-EXISTING CODE. Suppose you've given me a Gun class, and code which calls myWeapon.fire(). And I write a BowAndArrow class, including writing a fire() method. The code that calls myWeapon.fire() doesn't change. I didn't add a "if type==BowAndArrow" line anywhere. It just works.

"DF: Not sure that I said anything about
DV being a 61131-3 based PAC"

No, but I did. My original comment: "There are virtually no OOP capabilities in any current PLC / PAC." After you said, "You are wrong," I clarified: "A PLC/PAC, using any one of the 5 IEC 61131-3 [languages]." And I listed three things that are lacking that counts them out; polymorphism, encapsulation, and inheritance.

DF: "I am not upset nor mad."

Glad to hear that. Because the language in your previous post was rather belligerent.

DF: "My point is that sometimes these terms are interpretations of the author."

Sure. Always an issue. But there are clear-cut cases. Smalltalk is an object-oriented language. Period. No current implementation of IED 61131-3 is. Period. The definitions may have some wiggle room, but not enough to count a UDT (a classic structure) or an AOI (a classic sub-routine) as object-oriented.

DF: "...many a discussions boil down to perspective and interpretation."

Yes. But there are things we can say for certain. It's one of the things I like about my job, actually. I know my machines have functioned because product is put on a truck and sent somewhere. The work is measurable. Argue all you want, but if an 18-wheeler full of boxes didn't pull away from the dock we didn't do our job.

DF:
>I think
>that if I create an object "valve"
>describe its "properties" and define
>it's actions and create instances of
>them that will "inherit" structure from
>the parent combination of UDT and AOI
>and internal tags, there is no way for
>me to them claim that it doesn't
>function as an object "final control
>element" unless I have had the forsite
>as a programmer to create the object
>"final control element" first and
>defined all of that structure to
>include the type "valve", "motor" and
>"hydraulic ram" etc.

Wow. That equaled MY run-on sentences. But I'm afraid it precisely says the opposite of what you want. Having to have the foresight to include everything is what OOP avoids. Having to remember which AOIs and which UDTs go together is what OOP avoids. Basically OOP was invented to avoid the limitations of EXACTLY what you just said. It's a completely different paradigm for creating software.

DF:
>Without having that forsite unless I am
>missing something (again entirely
>possible), in any language to have in
>some place created that class
>structure, will the software whether
>"object oriented" of not to "morph"
>into something I did not program.

Yes. It morphs. Without the foresight. That's the point. You write a program with a type Weapon that uses BowAndArrow, without ever having conceived of a ShoulderLaunchedMissle. If I write a ShoulderLaunchedMissle class that extends Weapon and send it to your program your program will work just fine, without ever changing a line or even recompiling.

DF: "...we could never all agree on what kind of
donuts to buy if we all have to agree on one definition of what a donut is..."

True. But you would all agree quickly that a chair was not a donut.

DF: "I say that conceptually there are PLC/PACS out there that adhere to the jist of OOP, you say there are NONE."

Yep. And for sure RSLogix 5000 isn't. If we count DeltaV as a PAC, I'll have to defer.

-James Ingraham
Sage Automation, Inc.
 
The main question is:
Which way can OOP simplify control algorithms programming?

Yes. It can. Theoretically. When we need to process complex data structures, but it is not a case for a vast majority of the algorithms. Complexity of language vs. usability of additional linguistic means. Advantages of OOP must be under question (for PLC programming).

Really, PLC programming just needs no OOP means.
--
Best regards,
zyubin
 
D

DAVE FERGUSON

Belligerent... wow, what color is the pot...

You need to spend some more time with internal/external variables and in/out parameters in AOIs and Global Objects and again you say potato and I say patata, doesn't make you right, it makes you right in your mind. I have made logic function to your interpretation of OOP (100% no but close enough at 99.5% conceptually to my interpretation) and again re-read the words YOUR INTERPRETATION. I can make the UDT part of the AOI and when I import in XML (or other) they are created automatically as if part of the AOI. I can persist by attaching as internal/external variables. Remember that all of the code exists somewhere.

Again, so that I can be sure you get my point... WE CAN AGREE TO DISAGREE.

This will be my last post on the topic, so as always you can get the last word in (please disregard your interpretation of belligerent here). Or maybe you already have (but I doubt it).

So with your reply, you WIN... the loudest minority usually does.

Dave
 
Object Oriented Programming for PLC is definitely an interesting topic. I have recently moved from the PC programming world to the PLC world and I have a few opinions on the subject.

Abstraction is a very powerful tool - you can make wonderful things happen by just typing "SomeObject.DoSomething". But abstraction comes at a cost, it divorces you from the low level code that is actually implemented - which as a PLC programmer is what you are interested in most of the time.

Highly abstracted code hides complexity, but when you are debugging abtracted code you often have to trace through the layers of abstraction to find where/what the code that is actually implemented. That is why people recommend a maximum of 3 levels of abstraction if you can help it.

As PLC programmers we work close to the physical I/O and there is no point abstracting ourselves from the hardware if we don't need to. Device drivers are normally written in low level languages such as C or Assembly language for the same reason. The programmer needs control of what is happening at the hardware level.

I personally like to write code that deals with real outputs in ladder - it is a no non-sense WYSIWYG low level visual language. I like to use FBD for sections of code that have lots of timers and/or other function blocks. I think drawing a couple of power rails on either side of a cluster of function blocks and calling that ladder is wrong - I am talking about you RSLogix! And nothing beats the power of structured text when it comes to data manipulation.
 
V

Vladimir E. Zyubin

Saturday, September 06, 2008, 7:49:16 AM, twu026 wrote:

TA> As PLC programmers we work close to the physical I/O and there is no point abstracting ourselves from the hardware if we don't need to.

It will be correctly to say: As IEC61131-3 programmer we work...

The languages have no (or too low) means for structurization of control algorithms. BTW, OOP has the same problems as well. There is no way to inherit "Create.Vacuum" from "Open.Valve" and "Start.Pump" in OOP.

Logical parallelism (e.g., divergence/convergence of control flow), synchronism (e.g., timeouts, latencies), event-driven polymorphism (e.g., changes in the algorithm because of a fault)... OOP can not meet the requirements in a clear and weakless style, etc.

To be short, control algorithms need process oriented programming/languages.

--
Best regards,
Vladimir E. Zyubin
 
J

James Ingraham

>[In] OOP... There is no way to
>inherit "Create.Vacuum" from
>"Open.Valve" and "Start.Pump" in OOP.

I have to disagree. First, you've got that backwards. It would be "Valve.Open" and "Pump.Start." Second, this is exactly what interfaces are for, and what you want is very commonly used. It's common enough to be described by the Gang of Four as the Command Pattern. You can make an interface that defines the method "Actuate." Both Pump and Valve implement the interface. When you write your Pump class, the .Actuate method calls "Start" internally.

>Logical parallelism (e.g.,
>divergence/convergence of control
>flow), synchronism (e.g., timeouts,
>latencies), event-driven polymorphism
>(e.g., changes in the algorithm because
>of a fault)... OOP can not meet the
>requirements in a clear and weakless
>style, etc.

I'm not sure I completely understand what you're saying there, but I think I disagree here as well. In OOP I can most certainly accomplish logical paralleism and event-driven polymorphism, quite easily. In fact, by thinking about communication between objects as message passing those two features fall in place rather naturally. Synchronism I'm not sure about, but I think that concept can be implemented in OOP or structured programming without fundamentl alterations to the languages.

>To be short, control algorithms need
>process oriented programming/languages.

This I quite agree with. While I hate to inflict another language on the world I would like to see a truly modern language for implementing controls. LabView is reasonable example, but I think it has weaknesses that prevent it from being a true replacement for ladder logic and the other 61131 languages. Function block diagrams look a lot like LabView, but not as elegant. Sequential function charts and flow charts are a BAD idea; they try to allow structured programming but don't actually enforce the rules. It's like going back to "goto" statements all over the place.

-James Ingraham
Sage Automation, Inc.
 
V

Vladimir Zyubin

>>[In] OOP... There is no way to
>>inherit "Create.Vacuum" from
>>"Open.Valve" and "Start.Pump" in OOP.
>
> I have to disagree. First, you've got that backwards. It would
> be "Valve.Open" and "Pump.Start." Second, this is exactly what
> interfaces are for, and what you want is very commonly used. It's
> common enough to be described by the Gang of Four as the Command
> Pattern. You can make an interface that defines the method
> "Actuate." Both Pump and Valve implement the interface. When you
> write your Pump class, the .Actuate method calls "Start" internally. <

Well,
1. Valve.Open <-> Open.Valve. Really, it is the question of philosophy (systematization). Operation and process are the key aspect for technologist, not objects, and, especially, actuators kinda valves, pumps, motors, etc. So, the order just reflect this circumstance. But if you insist to use the OOP-style order, I have no objections.

2. With my heartfelt respect to the Gang of Four, method "Actuate" is just an attempt to put a brave face on a sorry business (to hide the OOP problems in the case). Actuate/deactuate, construct/deconstruct is just a generalization, kinda "do something". Technologists think in terms of verbs: open, close, turn on, turn off, start, stop, move, jog, clamp, clench, etc. Control algorithms written by the only method "actuate" have the problem with readability. So, such programs will have problems with maintainability and verification. So it will be a bad program.

>>Logical parallelism (e.g.,
>>divergence/convergence of control
>>flow), synchronism (e.g., timeouts,
>>latencies), event-driven polymorphism
>>(e.g., changes in the algorithm because
>>of a fault)... OOP can not meet the
>>requirements in a clear and weakless
>>style, etc.
>
> I'm not sure I completely understand what you're saying there, but
> I think I disagree here as well. In OOP I can most certainly
> accomplish logical paralleism and event-driven polymorphism, quite
> easily. In fact, by thinking about communication between objects
> as message passing those two features fall in place rather
> naturally. Synchronism I'm not sure about, but I think that concept
> can be implemented in OOP or structured programming without
> fundamentl alterations to the languages. <

1. Yes, logical parallelism and event-driven polymorphism could be implemented by OOP-languages... as well as in Assembler (obviously), or in any other programming language, even esoteric one. The problem is the concepts are outside of OO-programming. So, the concepts will be implemented by different ways by different programmers at least. It is just a hell (problems with readability, etc.) So, even LD with all its problems will be more preferable than C with thousand of pluses.

..."quite easily", if only! I think, if it will be true, then nobody will be in need of the IEC 1131-3 languages.

2. When I wrote "synchronism" I meant the necessity to synchronize control algorithm with physical processes on the controlled object (necessity to use a time maintenance system, necessity of active manipulations with time entities such as time interval, time delay, and timeout). And again, such things is out of scope OOP. They are implemented with alien means (of OS).

>>To be short, control algorithms need
>>process oriented programming/languages.
>
> This I quite agree with. While I hate to inflict another language
> on the world I would like to see a truly modern language for
> implementing controls. LabView is reasonable example, but I think
> it has weaknesses that prevent it from being a true replacement
> for ladder logic and the other 61131 languages. Function block
> diagrams look a lot like LabView, but not as elegant. Sequential
> function charts and flow charts are a BAD idea; they try to allow
> structured programming but don't actually enforce the rules. It's
> like going back to "goto" statements all over the place. <

FBD and G (LabVIEW) are data-flow languages. A brain-crushing technique in case of control algorithms. Yes, I like LabVIEW because of means to create user interface, but use it for the control part in very few cases of simplest (SCADA-style) algorithms. Yes, SFC is a BAD idea, as well as any things based on the Petri-net model. I think, the truly modern language you would like to see ought to look like finite state machine (thoroughly cleaned from the historical layers (fuzzy terminology, concepts) and enhanced a bit to reflect the basic specific of the field and encourage program implementation).

--
Best regards,

Vladimir E Zyubin
Institute of automation and electrometry
 
J

James Ingraham

"...if you insist to use the OOP-style order, I have no objections."

Well, it's not so much that I'm insisting. It's just that if we're talking about OOP, odds are it'll be written OOP-style order. It would be very difficult to do it the other way. You could, of course, use functions/methods to keep that order, e.g. Actuate (valve3), but we both get the point.

"2. With my heartfelt respect to the Gang of Four, method "Actuate" is just an attempt to put a brave face on a sorry business (to hide the OOP problems in the case)."

That's got to be the best sentence on Design Patterns I've ever read. No disagreement here.

"Control algorithms written by the only method "actuate" have the problem with readability."

Good point. Of course, won't that be a problem in ANY language? In ladder you have on/off or else you get a special function name for each thing, like timer, counter, etc.

"...logical parallelism and event-driven polymorphism... concepts are outside of OO-programming."

I'm not sure that that's a deal breaker. I mean, just about EVERYTHING is outside the scope of OOP, or any other programming paradigm. There's no such thing as a "Chair" in OOP, but OOP models chairs quite well.

"So, the concepts will be implemented by different ways by different programmers..."

True enough. My "Chair" class will probably look slightly different from yours. But they should both be fairly understandable to either of us.

"even LD with all its problems will be more preferable than C with thousand of pluses."

The market agrees with you on that point. Although personally I just don't THINK in ladder logic. C (C++, Java, C#, etc.) just flows better for me. I'd like to think that the C programs I did in the first 7 or so years of my career are fairly easy to follow. Of course, I also like to think that my ladder logic programs of the last 7 or so years are easy to follow. (There's overlap in those two sets of years.)

Naturally, I've seen badly written programs in just about every language, including C and ladder.

"...'quite easily', if only! I think, if it will be true, then nobody will be in need of the IEC 1131-3 languages."

Not sure I agree. Okay, it's a lot easier to get started by popping open Step 7 or RSLogix or whatever than to open Notepad write C++ code and compile it on the command line. But there's LOTS of stuff out there controlled by C, Ada, C++, etc. There's no IEC 61131-3 application out there that COULDN'T be done in some OOP flavor or another. Still, however good or popular C or Java or language XYZ ever becomes, I think relay ladder logic will still carve out a niche.

"When I wrote "synchronism" I meant the necessity to synchronize control algorithm with physical processes on the controlled object... [This] is out of scope OOP."

Sort of. I model some object. I can then link an instance to a physical device. True, that link method isn't specified. But that's a write-once-use-many problem. For example, if I were to make a class IO_Block, I could implement Modbus/TCP as the method to synchronize to the block. (This is a real world example; I've done this.) From there on out as an application developer you don't care HOW it's synchronizing, it just does. And if I add EtherNet/IP or Profinet communications to the class my code looks the same, bar perhaps a different initialization.

"I think, the truly modern language you would like to see ought to look like finite state machine (thoroughly cleaned from the historical layers (fuzzy terminology, concepts) and enhanced a bit to reflect the basic specific of the field and encourage program implementation)."

Sounds reasonable. To quote Megadeth: "If there's a new way I'll be the first in line. But it better work this time." :)

-James Ingraham
Sage Automation, Inc.
 
V

Vladimir Zyubin

> "Control algorithms written by the only method "actuate" have the
> problem with readability."
>
> Good point. Of course, won't that be a problem in ANY language?
> In ladder you have on/off or else you get a special function name
> for each thing, like timer, counter, etc. <

It's rather native problem of OOP-approach. The languages (OOP) allow to use arbitrary identifier for a method. We have problem with the "actuate" because of the wrong structure of program we try to use. ;-) (AFAIK, we have the ON/OFF restriction in the LD language when we deal with the concept of relay only. We can use function with various identifiers as well as in others languages. Just a remark.)

> "...logical parallelism and event-driven polymorphism... concepts
> are outside of OO-programming."
>
> I'm not sure that that's a deal breaker. I mean, just about
> EVERYTHING is outside the scope of OOP, or any other programming
> paradigm. There's no such thing as a "Chair" in OOP, but OOP models
> chairs quite well. <

Sounds like you mean "OOP rules". Unfortunately, can not agree. OOP covers many things and do it well enough, but there are areas where OOP sucks. Not only logical parallelism, physical parallelism as well. Keywords: klasters, mpi, multicore, vhdl, mdmi.

And yes, we can tune an OOP-language for a specific task (patterns, etc.), but there is a dilemma we want to tune, or we need to work (program control algorithms). Necessity to work is the answer for the question, why 4GL-es exist.

> "So, the concepts will be implemented by different ways by different programmers..."
>
> True enough. My "Chair" class will probably look slightly
> different from yours. But they should both be fairly understandable to either of us. <

Sorry, many of us don't want to knock up the chair, and know about nails, planes, fish-glue, upholstery. Many of us (and I as well) just want to sit with comfort.

> "even LD with all its problems will be more preferable than C with thousand of pluses."
>
> The market agrees with you on that point. Although personally I
> just don't THINK in ladder logic. C (C++, Java, C#, etc.) just
> flows better for me. I'd like to think that the C programs I did
> in the first 7 or so years of my career are fairly easy to follow.
> Of course, I also like to think that my ladder logic programs of
> the last 7 or so years are easy to follow. (There's overlap
> in those two sets of years.) <

I don't insist that the language must looks like LD. And let's just remember that many years ago C++ was called "C with classes". If you like C, "C with processes" will be a good choice.

> Naturally, I've seen badly written programs in just about every
> language, including C and ladder.
>
> "...'quite easily', if only! I think, if it will be true, then
> nobody will be in need of the IEC 1131-3 languages."
>
> Not sure I agree. Okay, it's a lot easier to get started by
> popping open Step 7 or RSLogix or whatever than to open Notepad
> write C++ code and compile it on the command line. But there's LOTS
> of stuff out there controlled by C, Ada, C++, etc. There's no IEC
> 61131-3 application out there that COULDN'T be done in some OOP
> flavor or another. Still, however good or popular C or Java or
> language XYZ ever becomes, I think relay ladder logic will still
> carve out a niche. <

Yes, any IEC application could be done in C, C++, Java, Assembler and even in machine codes. The difference is in time expenses of various approaches (at least).

And yes, LD have unique features (the metaphoric nature). It provides easy learning. For simple tasks LD is good enough.

> "When I wrote "synchronism" I meant the necessity to synchronize
> control algorithm with physical processes on the controlled
> object... [This] is out of scope OOP."
>
> Sort of. I model some object. I can then link an instance to a
> physical device. True, that link method isn't specified. But
> that's a write-once-use-many problem. For example, if I were to
> make a class IO_Block, I could implement Modbus/TCP as the method
> to synchronize to the block. (This is a real world example; I've
> done this.) From there on out as an application developer you
> don't care HOW it's synchronizing, it just does. And if I add
> EtherNet/IP or Profinet communications to the class my code looks
> the same, bar perhaps a different initialization. <

I rather meant transfer functions (PID), latencies for functioning, actuation times we need to control, the things we need to think about when we program control algorithms. Protocols (very important part of the systems) are just an auxiliary layer and the programmers have no needs to be aware which way it works. So, I agreed when you point out an application developer. There is an application developer and there must be somebody else, an system programmer. The programmer who perfectly knows of PID, OSI/ISO, target technology, C++, patterns, etc. is too expensive to employ. Just an economic reason.

> "I think, the truly modern language you would like to see ought
> to look like finite state machine (thoroughly cleaned from the
> historical layers (fuzzy terminology, concepts) and enhanced a bit
> to reflect the basic specific of the field and encourage program
> implementation)."
>
> Sounds reasonable. <

Thanks.

--
Best regards,
Vladimir
 
M

Michael Griffin

In reply to Vladimir Zyubin: On the one hand you say SFC and Petri nets are bad, while on the other hand you would like to base a language on finite
state machines. How would you do a finite state machine that doesn't look anything like an SFC or Petri net and which doesn't have any of the problems that you perceive with the latter two?
 
V

Vladimir Zyubin

<p>The solution is simple as the Egg of Columbus. You have no needs to provide parallelism inside FSM. Just provide parallelism of FSM and organize the program as a set of enhanced FSMs. No need to say, all problems with "colored markers" and convergation will vanish.

<p>Conceptual level:
1. Introduce concept of Process (FSM-like program unit)
2. Introduce operations START, STOP process
3. Introduce new state PASSIVE for process
4. Introduce possibility to check current state of process.

<p>The following code demonstrates the idea of divergence and convergence of two "dumb"-processes in ST-like syntax:
<pre>
PROCESS Main
STATE FirstState (* divergence *)
START PROCESS SecondProc;
START PROCESS ThirdProc;
NEXT;
END_STATE
STATE SecondState (* convergence *)
IF((PROCESS SecondProc IN STATE PASSIVE) AND (PROCESS ThirdProc IN STATE PASSIVE))
THEN
(* do all you want *)
END_IF
STOP;
END_STATE
END_PROCESS

PROCESS SecondProc
STATE FirstState
STOP;
END_STATE
END_PROCESS

PROCESS ThirdProc
STATE FirstState
STOP;
END_STATE
END_PROCESS
</pre>
<p>Just to demonstrate the idea of process-oriented programming (POP).

<p>Best regards,

<p>Vladimir
 
I would like to give everyone my first impressions as a 23 year old recent graduate in electrical engineering and computer science.

My opinions are drawn from having learned and worked with IEC 61131-3 for one year and number of different desktop programming languages for about 5 years. My opinions are not biased by decades of experience and scared feeling some might get at the prospect of having to learn something new.

I am also not suggesting that change is something that can just come even in the next 2 years. I do however believe that ladder logic and even IEC-61131-3 is a horrible thing to have to program. Once a system becomes more complex than simply a few I/O points and especially when human interaction is involved, programs written in ladder logic become horrendous to read, understand and debug.

My experience is more with pumping stations and irrigation systems that involve everything from pressure, flow, weather, solenoids, soft-starters, touch screens, 2-wire decoders, water quality measurement and other sensors. I agree that for small, independent systems such as counting bottles on a belt or closing a door when something happens ladder logic is great; easy and simple. Designing SYSTEMS however, it is extremely clumsy. I do understand that PLCs are mainly used for small independent projects, that's why, like I said, PLCs will probably always use ladder logic in some way or another unless a more intuitive method is found.

Humans like names, descriptions and associations to real life object. Having to deal with addresses and single I/O points was my biggest problem with the primitiveness of PLC programming.

The speed at which software based companies such as Microsoft are evolving is due to ideas from the masses of people who have practiced programming since their 13th birthday. If we look at how these high level programming language develop it is steady growth each day, each month and each year.

Now look at the PLC. Since the 1960s PLCs have not changed a great deal in terms of software. Yes, hardware has improved greatly with modern electronics. Yes, software in processors and chips has improved. Yes, IEC 61131-3 was introduced to provide more flexibility. Yes, desktop tools are getting better. BUT... the general PLC programming concept is still based on I/O, ladder logic, scan cycles, etc...

I do agree that because PLC programming is a specialised industry and it not something you can just take home and practice unless a company is willing to give you a couple of thousand dollars worth of hardware. It is hard for new leaps and bounds to take place. Other problems include safety concerns, having to re-train people, having to change software licenses, etc... That's why I understand very much why PLC programming can't just evolve like computer programming does.

Until now the PLC industry has been content with ladder logic because that is how systems used to be physically wired or drawn. It made sense for a long time because as some people have said, technicians and engineers who program PLCs are generally not software programmers. I strongly agree that using languages such as C or C++ or even high level languages such as Java or .NET is NOT a solution because it requires full programming experience. However I think that the problem isn't to improve PLC programming; it's to create something different and better. New hardware, new software and a new language. PLCs stay for small modules of control but something new is needed to design Automation "Applications" if you will.

I think if PLCs moved towards a language that is similar to a higher level it would open the doors not only for specially trained technicians or engineers, but for common computer scientists and programmers. Such programming would then follow the design cycle similar to that of desktop programs. This would definitely be an improvement if it forces people to actually create a design document in the first place. We all know that people are generally lazy.

In summary: Change will be slow, but a new device is needed for control system or automation "applications". "Applications" are programs that are more than just switching a few things on and off given some analog signal. It should employ a language that is more similar to modern high level and abstract programming.

Anyway, that's just my ramble.
 
W

William Sturm

The PLC is just another tool in our toolbox, albeit a very useful and important one.  Other tools are SCADA and MMI systems for PCs, high level languages for PCs, motion controllers, loop controllers, data acquisition hardware and software, and CNC controls.  One of the keys to success is selecting the right tool or combination of tools for the job.

If you try to do too much with a PLC, you can get into trouble.  In those cases, you need to design a system with other components to suit your needs.  Maybe a network of small PLCs for basic control with some object oriented computer software to oversee the process would be better suited.
 
In reply to Oliver: What the computer software industry learned some years ago is what they term "there is no silver bullet". That means, there is no magic answer to improving software development methods. What is possible is steady, incremental improvements in methods, practices, and languages.

To address some of your specific points however:

>Once a system becomes more complex than
>simply a few I/O points and especially when
>human interaction is involved, programs
>written in ladder logic become horrendous
>to read, understand and debug.

People have said the same thing about 'C', and yet there is no sign whatsoever of C disappearing as *the* general purpose programming language any time soon. What has happened is that new methods and languages have been developed for specific narrow applications (e.g. PHP for Web programming). What might make more sense for PLC applications is different methods, languages, or libraries for things such as HMI interaction.

>The speed at which software based
>companies such as Microsoft are evolving
>is due to ideas from the masses of
>people who have practiced programming
>since their 13th birthday.

If you have a point to make, you've picked a bad example to illustrate it. Microsoft's product technology is generally about 5 to 10 years behind the rest of the software industry and of notoriously poor quality. People still pay ridiculous sums of money for it however because it's what they are used to and they don't want to change. So I don't think the automation industry is unique in clinging to old ideas.

>I do agree that because PLC programming
>is a specialised industry and it not
>something you can just take home and
>practice unless a company is willing to
>give you a couple of thousand dollars
>worth of hardware. It is hard for new
>leaps and bounds to take place.

Since we are talking about *software* techniques, you don't need specialised hardware. Soft logic systems can run on a general purpose PC. That in fact is what you would want if you were experimenting with new software methods. Development effort is much less on a PC than on custom embedded hardware (which is what a PLC is).

As for whether anyone would be willing to give a soft logic system away for free, well a number of people do exactly that, including me. If you want to experiment with new PLC programming languages, you can download the source code and experiment to your heart's content. Maybe you'll come up with a great new idea.

>Other problems include safety concerns,

Safety is a red herring. Typical PLCs are not safety devices.

>having to change software licenses,

Most programming languages in the computer industry are distributed under free/open source licenses. Proprietary languages such as Microsoft's are the exception, rather than the rule. In industrial applications, it's the other way around with proprietary systems being in the majority. That probably has more to do with the relative pace of change in each industry than any other reason.

>Such programming would then follow the
>design cycle similar to that of desktop
>programs. This would definitely be an
>improvement if it forces people to
>actually create a design document in the
>first place. We all know that people are
>generally lazy.

Up to this point your remarks have been reasonable, but I have to question this point. Typical custom desktop programs are written based on design documents? You must be referring to how things are done on a different planet. Masses of Visual Basic spaghetti code whose only documentation is a few cryptic code comments are probably a lot more common than a ladder logic program with no symbols.

Typically, making a machine run in automatic mode is the easy part of a project. It's adding in things like the HMI, recipe handling, alarms and events, diagnostics, and all the other "extra" things that seems to be the most work. Incremental progress could come from improvements in making these routine things easier.

I don't hold out a lot of hope for this though. The way the automation industry works today, each vendor would implement it in a different incompatible way. I see that as a barrier to progress, because people have to spend their time learning a hundred different ways to do the same thing instead of increasing and applying their knowledge. You could come up with a wonderful new way of doing things, but AB, Siemens, Schneider, etc. aren't going to adopt it because they don't have control over it.

I wonder though how much longer the traditional vendors will dominate the industry. I think that small PLCs will become so cheap that they will undermine the economics of the traditional distribution channel. Koyo is selling a small PLC for 69 USD. I/O modules are very cheap as well, and programming software is free of charge. I could easily imagine some Korean and Chinese companies getting into the market at a similar price point. Say what you like about AB, Siemens, etc., at some point the alternatives become too cheap to ignore.

For larger or more sophisticated applications, PC based soft logic systems have become a viable alternative now that solid state drives and fanless systems have become common place and cheap. Soft logic software systems are not difficult to create, so there is no reason why they need to be expensive either (I think free is inevitable).

I think that these changes (especially soft logic systems) and others mean that people who have traditionally gotten by with learning a bit of ladder logic need to expand their range of knowledge to include more technologies from the PC industry. They need to learn more about networking, Web protocols, operating systems, databases, etc. If they don't, they will be left behind when the changes do come.
 
Good arguments abound. The old acronym still holds. KISS - Keep it simple stupid. As a non-engineer who does a lot of engineering work, I find many machines with systems that are way too complex. Some programs have timers timing timers and subroutines that are there for the sake of data acquisition, and the list goes on. I agree that it is time for some advancement in the standards. But not toward more complexity, but back to basics, so that a technician does not have to be a graduate of computer science or electrical engineering to fix and repair machines in the realm of manufacturing processes. It seems to me that PLCs, while good at handling I/O, are just part of an advanced control system. I think a DCS like Delta V, running a machine with PLC I/O would be awesome. I love the ability of the DCS to use tags and HART and, well, lots of other things, but then the simplicity of ladder logic for I/O seems like it's missing. I will not pretend to have the answers to these questions, but as a guy in the trenches I would ask all you programmers to keep the pld acronym in mind, as well as the guy fixing the machines.
 
There are many ways in which Step7 Siemens PLC implements OOP that are not available in the RSLogix AOI. Step 7 allows the UDT to be declared within the Function Block. RSLogix doesn't allow a UDT to be passed into the block.

Here is an example of OOP using SCL in Step 7:

FUNCTION_BLOCK FB100 // Tech CPU Basic Axis Motion Block
VAR_INPUT
Axis_Num : INT; // Axis Number from Technology Controller
Estop_Okay : BOOL; // Signal to Enable Axis or Remove Power
Jog_FWD : BOOL; // Run or Jog Forward request bit
Jog_REV : BOOL; // Run or Jog Reverse request bit
Move_ABS : BOOL; // Absolute Positioning Move
Move_REL : BOOL; // Relative Positioning Move
Stop_Now : BOOL; // Set Stop Now to Stop Axis at any time
Home_Axis : BOOL; // Reference Axis to Encoder Homing Position
Tech_Error : BOOL; // Technology Fault bit from Axis TO
Clear_Fault : BOOL; // Reset Axis Faults
Params : BasicDynamics; // Structure of Dynamic Parametes for Velocity & Position
END_VAR

VAR_OUTPUT
AxisState : INT;
Enabled : BOOL;
Faulted : BOOL;
Warning : BOOL;
Moving : BOOL;
Target_Reached : BOOL;
END_VAR

VAR_TEMP
// Temporary Variables
END_VAR

VAR
// Static Variables
AxisPower : MC_Power; // Enable Axis Power
AxisReset : MC_Reset; // Acknowledge Axis Errors
AxisHome : MC_Home; // Reference Axis Encoder
AxisVelocity : MC_MoveVelocity; // Run Axis @ Velocity Setpoint
AxisStop : MC_Stop; // Stop Axis Movement
ABSMove : MC_MoveAbsolute; // Absolute Positioning of the Axis
RELMove : MC_MoveRelative; // Relative Positioning of the Axis
TargetClear : TON;
FaultTimed : TON;
HomingActive : TON;
AxisStateMem : INT;
JogDirection : INT;
JogVelocity : REAL;
JogTrig : BOOL;
Jog_ONS : BOOL;
CAM_ON_ONS : BOOL;
Move_ABS_ONS : BOOL;
Move_REL_ONS : BOOL;
Gear_ON_ONS : BOOL;
Stop_Now_ONS : BOOL;
Gear_ABS_ONS : BOOL;
Home_Axis_ONS : BOOL;
PowerReady : BOOL;
PowerError : BOOL;
HomeError : BOOL;
ABS_Error : BOOL;
REL_Error : BOOL;
StateUpdate : BOOL;
END_VAR

CONST
PowerMode := 0; // 0: Default (according to the axis configuration)
PowerStop := 0; // 0: DefaultStop (Emergency-stop deceleration
END_CONST

PowerReady := TRUE;
Moving := AxisState > 1 AND AxisState < 7;
Warning := Tech_Error;

// MC_Power --- Axis Enable ---
AxisPower(Axis := Axis_Num // IN: INT
,Enable := (Estop_Okay AND PowerReady) // IN: BOOL
,Mode := PowerMode // IN: INT
,StopMode := PowerStop // IN: INT
// ,QOutputValue := // IN: REAL
// ,FOutputValue := // IN: REAL
);
Enabled := AxisPower.Status; // OUT: BOOL
PowerError := AxisPower.Error; // OUT: BOOL

// MC_Reset --- Acknowledge Axis errors ---
AxisReset(Axis := Axis_Num // IN: INT
,Execute := Clear_Fault // IN: BOOL
,Restart := FALSE // IN: BOOL
);

IF NOT Estop_Okay THEN
AxisState := 0;
END_IF;

IF Faulted THEN
AxisState := 20;
END_IF;

IF AxisState <> AxisStateMem THEN
AxisStateMem := AxisState;
StateUpdate := TRUE;
ELSE
StateUpdate := FALSE;
END_IF;
// Axis State Model of Operation
CASE AxisState OF
0 : // Axis at ESTOP or Disabled
IF Enabled THEN
AxisState := 1;
END_IF;

1 : // Axis is Ready to accept command
// Request to Jog or Run Axis with MC_Velocity
IF (Jog_FWD AND NOT Jog_ONS) THEN
JogDirection := 1;
AxisState := 2;
END_IF;

IF (Jog_REV AND NOT Jog_ONS) THEN
JogDirection := 3;
AxisState := 3;
END_IF;

IF (Move_ABS AND NOT Move_ABS_ONS) THEN
AxisState := 4;
END_IF;

IF (Move_REL AND NOT Move_REL_ONS) THEN
AxisState := 5;
END_IF;

IF (Home_Axis AND NOT Home_Axis_ONS) THEN
AxisState := 19;
END_IF;

2..3 : // Axis is in a Jog or Run State
IF StateUpdate OR (AxisVelocity.Busy AND JogVelocity <> Params.Velocity) THEN
JogTrig := TRUE;
JogVelocity := Params.Velocity;
ELSE
JogTrig := FALSE;
END_IF;

// MC_MoveVelocity --- Jog or Run Axis at Velocity Setpoint ---
AxisVelocity(Axis := Axis_Num // IN: INT
,Execute := JogTrig // IN: BOOL
,Velocity := Params.Velocity // IN: REAL
,Acceleration := Params.Jog_Accel // IN: REAL
,Deceleration := Params.Jog_Decel // IN: REAL
,Jerk := 0 // Use Trapezodial // IN: REAL
,Direction := JogDirection // IN: INT 1=Positive direction of rotation, 3=Negative direction of rotation
,Current := FALSE // IN: BOOL
,PositionControl := TRUE// IN: BOOL
,Mode := 0 // IN: INT
,DoneFlag := 0 // IN: INT
);

IF (NOT Jog_FWD AND NOT Jog_REV) OR (Jog_FWD AND Jog_REV) THEN
AxisState := 6;
END_IF;

IF Stop_Now THEN
AxisState := 6;
END_IF;

4 : // Axis is Commanded to an Absolute Move
// MC_MoveAbsolute --- Absolute Axis Move ---
ABSMove(Axis := Axis_Num // IN: INT
,Execute := StateUpdate // IN: BOOL
,Position := Params.Position // IN: REAL
,Velocity := Params.Velocity // IN: REAL
,Acceleration := Params.ABS_Move_Accel // IN: REAL
,Deceleration := Params.ABS_Move_Decel // IN: REAL
,Jerk := Params.ABS_Move_Jerk // IN: REAL 0: Use trapezoidal motion profile
,Direction := 2 // IN: INT 2: Shortest distance
,Mode := 0 // IN: INT 0: Override motion The current motion is canceled
,DoneFlag := 1 // IN: INT A DoneFlag[1] is generated in the MCDevice DB
);

// ABS_On_Target := ABSMove.Done; // OUT: BOOL
// ABS_Busy := ABSMove.Busy; // OUT: BOOL
// := DBxxx.CommandAborted; // OUT: BOOL
// ABS_Error := ABSMove.Error; // OUT: BOOL
// := DBxxx.ErrorID; // OUT: WORD

IF ABSMove.Done THEN
Target_Reached := TRUE;
AxisState := 1;
END_IF;

IF Stop_Now THEN
AxisState := 6;
END_IF;

5 : // Axis is Commanded to a Relative Move
// MC_MoveRelative --- Absolute Axis Move ---
RELMove(Axis := Axis_Num // IN: INT
,Execute := Move_REL AND Enabled// IN: BOOL
,Distance := Params.Position // IN: REAL
,Velocity := Params.Velocity // IN: REAL
,Acceleration := Params.REL_Move_Accel // IN: REAL
,Deceleration := Params.REL_Move_Decel // IN: REAL
,Jerk := Params.REL_Move_Jerk // IN: REAL 0: Use trapezoidal motion profile
,Mode := 0 // IN: INT 0: Override motion The current motion is canceled
,DoneFlag := 1 // IN: INT A DoneFlag[1] is generated in the MCDevice DB
);

IF RELMove.Done THEN
Target_Reached := TRUE;
AxisState := 1;
END_IF;

IF Stop_Now THEN
AxisState := 6;
END_IF;

6 : // Axis is Commanded to a STOP
// MC_Stop --- Reference Axis position ---
AxisStop(Axis := Axis_Num // IN: INT
,Execute := StateUpdate // IN: BOOL
,Deceleration := Params.Stop_Decel // IN: REAL
,Jerk := 0 // IN: REAL Use Trapezodial
,DoneFlag := 1 // IN: INT
);

IF AxisStop.Done THEN
AxisState := 1;
END_IF;

7..10 : // Axis is Commanded to a Automatic Machine State

;

19 : // Axis is Commanded to Reference the Encoder
// MC_Home --- Reference Axis position ---
HomingActive(IN := NOT StateUpdate// IN: BOOL
,PT := T#250ms// IN: TIME
);

AxisHome(Axis := Axis_Num // IN: INT
,Execute := StateUpdate // IN: BOOL
,Position := Params.Home_Position // IN: REAL
,Mode := 3 // 3 = Direct homing
,DoneFlag := 1 // INT A DoneFlag[1] is generated in the MCDevice DB
);
// := DBxxx.Done; // OUT: BOOL
// := DBxxx.Busy; // OUT: BOOL
// := DBxxx.CommandAborted; // OUT: BOOL
HomeError := AxisHome.Error; // OUT: BOOL
// := DBxxx.ErrorID; // OUT: WORD

IF HomingActive.Q (* AND AxisHome.Done *)THEN
AxisState := 1;
END_IF;

20 : // Axis is Reported to be Faulted
IF Enabled OR NOT ESTOP_Okay THEN
AxisState := 0;
END_IF;

ELSE:
// Statements_ELSE
;
END_CASE;


// One Shot Control Bits
Jog_ONS := Jog_FWD OR Jog_REV;
Move_ABS_ONS := Move_ABS;
Move_REL_ONS := Move_REL;
Stop_Now_ONS := Stop_Now;
Home_Axis_ONS := Home_Axis;

TargetClear(IN := Target_Reached// IN: BOOL
,PT := T#3s// IN: TIME
);
IF TargetClear.Q THEN
Target_Reached := FALSE;
END_IF;

FaultTimed(IN := (Estop_Okay AND NOT Enabled) OR Tech_Error// IN: BOOL
,PT := T#500ms// IN: TIME
);
IF FaultTimed.Q THEN
Faulted := TRUE;
ELSE
Faulted := FALSE;
END_IF;



END_FUNCTION_BLOCK

The ojbect here is a servo drive.
 
Top