1

I'm writing a program for a Schneider PLC using structured text, and I'm trying to do it using object oriented programming.

Being a newbie in PLC programming, I wrote a simple test program such a this:

okFlag:=myObject.aMethod();
IF okFlag THEN
   // it's ok, go on
ELSE
  //  error handling
END_IF

aMethod must perform some operations, wait for the result (there is a "time-out" check to avoid deadlocks) and return TRUE or FALSE

This is what I expected during program execution

1) when the okFlag:=myObject.aMethod(); is reached, the code inside aMethod is executed until a result is returned. When I say "executed" I mean that in the next scan cycle the execution of aMethodcontinues from the point it had reached before.

2) the result of method calling is checked and the main flow of the program is executed

and this is what happens:

1) aMethod is executed but the program flow continues. That is, when it reaches the end of aMethod a value it's returned, even if the events that aMethod should wait for are still executing.

2) on the next cycle, aMethod is called again and restarts from the beginning

This is the first solution I found:

VAR_STATIC
   imBusy: BOOL
END_VAR 

METHOD aMethod: INT;

IF NOT(imBusy) THEN
  imBusy:=FALSE;
  aMethod:=-1; // result of method while in progress
ELSE
  aMethod:=-1;         
  <rest of code. If everything is ok, the result is 0, otherwise is 1>
END_IF
imBusy:=aMethod<0;

and the main program:

CASE (myObject.aMethod()) OF
  0: // it's ok, go on
  1: //  error handling
ELSE
    // still executing...
END_CASE

and this seems to work, but I don't know if it's the right approach.

There are some libraries from Schneider which use methods that return boolean and seem to work as I expected in my program. That is: when the cycle reaches the call to method for the first time the program flow is "deviated" somehow so that in the next cycle it enters again the method until it's finished. It's there a way to have this behaviour ?

Marconi
  • 11
  • 1
  • 5

2 Answers2

2

generally OOP isn't the approach that people would take when using IEC61131 languages. Your best bet is probably to implement your code as a state machine. I've used this approach in the past as a way of simplifying a complex sequence so that it is easier for plant maintainers to interpret.

Typically what I would recommend if you are going to take this approach is to try to segregate your state machine itself from your working code; you can implement a state machine of X steps, and then have your working code reference the statemachine step.

A simple example might look like:

stepNo := 0;
IF (start AND stepNo = 0) THEN
    StepNo = 1;
END_IF;

(* there's a shortcut unity operation for resetting this array to zeroes which is faster, but I can't remember it off the top of my head... *)
ActiveStepArray := BlankStepArray;

IF stepNo > 0 THEN
  IF StepComplete[stepNo] THEN
      stepNo := stepNo +1;
  END_IF;

  ActiveStepArray[stepNo] := true;
END_IF;

Then in other code sections you can put...

IF ActiveStep[1] THEN
   (* Do something *)

   StepComplete[1] := true;
END_IF;

IF ActiveStep[2] THEN
   (* Do Something *)
   StepComplete[2] := true;
END_IF;

(* etc *)

The nice thing about this approach is that you can actually put all of the state machine code (including jumps, resets etc) into a DFB, test it and then shelve it, and then just use the active step, step complete, and any other inputs you require.

Your code is still always going to execute an entire section of logic, but if you really want to avoid that then you'll have to use a lot of IF statements, which will impede readability.

Hope that helps.

Squanchy
  • 77
  • 10
0

Why not use SFC it makes your live easier in many cases, since it is state machine language itself. Do subprogram, wait condition do another .. rince and repeat. :)

Don't hang just for ST, the other IEC languages are better in some other tasks and keep thing as clear as possible. There should be not so much "this is my cake" mentality on the industrial PLC programming circles as it is on the many other programming fields, since application timeline can be 40 years and you left the firm 20 years ago to better job and programs are almost always location/customer or atleast hardware specific.

http://www.automation.com/pdf_articles/IEC_Programming_Thayer_L.pdf

V.Tile
  • 1
  • 1