Code execution sequence of Structured Text vs Ladder Logic

[extendedSolutions]

(subtitle: should I bother with structured text? AKA: Panasonic FP gurus please contact me.)

Newbie question, but hope someone can help me clarify some basic points. I do apologize if I am not using the right lingo for technical specifics, my background is more in embedded systems (microcontrollers) and classical software development (c, c++, python... hence my interest in Structured Text - ST) So please use some imagination while reading this post. Also, you will probably find some of my understandings inaccurate, please do point those out and correct me.

In ladder logic, each rung is equal, and all rungs (connected to power rail) are active at the beginning of each scan cycle. Since rungs are not executed sequentially, the programmer controls sequential behavior by triggering a cascade of coils (R registers for example.) I do not expect sequential execution from rung 1 to rung N, or should I?

In Structured Text, can I expect sequential execution of code line by line, or should I view ST as just a different way to specify ladder rungs? Below is an example of ST:

(* rung 1... *)
if( X1 ) Then
variableJJ := 5;
end_if;

(* rung 2.. 3...4.... 5... *)

(* rung 6 *)
if( X1 ) Then
variableJJ := 80;
end_if;


Should I expect (Scenario 1) rung 1 will execute first, then 2, 3, 4... and finally 6, in discrete time steps? Or (Scenario 2) should I read this as rung 1 and rung 6 both executes at the same time, and variableJJ could be 5 or 80, depending the how the compiler generates the instructions or a race condition in the CPU? or is it CASE 3, *you tell me.*.

If Scenario 1 is true, PLC programming in ST is great! I get free sequential features of single-thread programming without setting a bunch of coils. In this case, I can think of Scan time being divided into smaller steps for each rung/line of my code.

If Scenario 2, ST is just another way to input ladder logic with no additional benefits. BTW, in this case ST is reminiscent of a concurrent programming language, like Erlang (without the recursive calls.)

For example, in serial communication we often need to send different parameters one after another. I am seeing some strange things happen when I try:

(* in ST code - Modbus write register address with data *)
(* strange syntax is for Panasonic, 16# is for hex. *)
sendSerialCommand(address:=16#30, data:=16#FF);
sendSerialCommand(address:=16#31, data:=16#0F);
sendSerialCommand(address:=16#32, data:=16#F0);
(*assume I wrote a function called sendSerialCommand that works if called once. *)

Calling a function (that worked when called once) twice produced behavior that is not expected. I.e., did not send parameters correctly. (Sadly, I use Panasonic hardware, so not much help on the web. If you are a Panasonic user, please contact me. We want to find a capable individual to program this project for us.)

Love to hear your thoughts!

[Pete.S.]

Code execution is always in sequence. And you can never stop the execution.

ST is just like any other structured programming language like C, pascal or whatever.

Ladder is just another way to do primarily logic programming.

Execution of both is the same. And you could easily convert both into machine code even though many PLCs are running some kind of engine to execute the code (similar to java or .NET).

However depending on the PLC inputs and outputs may not be read or written to except once per scan of the program. On a bus system you may have other delays as well.

PS. I/O is non-blocking or asynchronous if you like. When you use a command for sending serial data the program will not stop and wait for it to be sent. If you send too much it is possible that you fill the I/O buffers. Modbus protocol requires a response to be received back as well but that is hopefully something that the PLC is doing for you. You have to read up on that. It's likely that you have to check some flag or something before you can send the next modbus message or if there is a queue or buffer that it is not full.


.

[jstolaruk]

IIRC, Modicon is one of the exceptions on how a rung is evaluated; where most are Left-to-Right Top-Down, Modicon is Top-Down Left-Right.

[Diameter157]

Not sure if this will help you because I"m am only just in the process of using modbus myself for the first time.

But the sample program I am using as a guide works as follows:
(pseudo code)


sendSerialCommand(address:=16#i, data:=16#FF);
if error=true then displayerrormessage
if done=true and i<32 then i=i+1 else i=30


So maximum 1 modbus message is sent per cycle and you also wait for a done message first. I can try and find the exact code if you can't find a sample program for you PLC.

[DwSoFt]

With Ladder Logic you are assuming it is a relay logic wiring diagram. They all solve at the same time. In ladder Logic Altho it resembles relay logic it is scanned in sequence.

[extendedSolutions]

Pete,

Thanks for your thoughtful reply. From what you have said, I figure my assumption that "all rungs are active at once" is incorrect. And rungs are executed in sequence from top to bottom (rung 1 followed by 2.. so on. ) It seems that way in the "program code", an assembly-like output of the compiler, at least for simple programs that I can trace. So I gather that this sequential output of the compiler is what I could expect and count on. This definitely make things a bit more clear. In my ST example, the variable should contain 80.

And you other point that execution never stops is well taken. I am not sure how to deal with it yet, but I recognize that as a fact.

[extendedSolutions]

jstolaruk, thanks for pointing out the exception. At least I can assume everyone is left to right in ST. Would be weird if not...

[extendedSolutions]

Dimeter,
That is a clever way to send out data in sequential addresses. I will give that a try. Thanks!

[extendedSolutions]

DwSoft,
You are right, I was assuming that ladder logic behaves like relay logic, which ladder simulates, but not exact. So things are still executed in sequence. I will revise my understanding.

[LadderLogic]

This is very important to reiterate since this is usually something that initially confuses people coming to PLC from other programming backgrounds: a PLC program ALWAYS runs an infinite loop. It runs it by itself, without a programmer having to do anything. This infinite loop is called "scan" in PLC parlance; the scan execution time is monitored by a watchdog timer.

If a PLC supports multitasking, each task runs its own scan, with different priority levels (i.e. a task with a higher priority may interrupt the scan of another, lower-priority task which in turn will complete its scan when the higher-priority task is done). Within each task scan all the statements, be they ladder or ST, are evaluated in "top to bottom, left to right" order.

Some PLCs have commands that can alter the scan execution order: IF, FOR, WHILE, CASE and such. One should always be careful when using these though: if you program a FOR...NEXT or a WHILE loop with too many iterations that executes for too long, your scan will not complete in the alotted time and the PLC will fault out due to the watchdog trip.

[Pete.S.]

Originally Posted by Diameter157

But the sample program I am using as a guide works as follows:
(pseudo code)

SendSerialCommand(address:=16#i, data:=16#FF);
if error=true then displayerrormessage
if done=true and i<32 then i=i+1 else i=30

If you wanted to implement the code above in a PLC you can't write it like that. Let's say were are doing something like real modbus communication then it would similar to the code below.

Actually a real implementation would need a couple of more things, but I didn't want to make the code too long.

This would look pretty much the same if you for example were doing it in C in a small embedded microcontroller.

Proper name for this is a finite state machine but many call it just a sequence. You could implement this in any kind of language including ladder. The basic principle being that you have a number of states that you transition between depending on what you are doing and what the result is. And depending on what state you are in you are executing different code.

Comments:
timer is a millisecond timer that is counted up all the time
seq_step is to keep track of what we are doing
we trigger the action by doing seq_step:=1;
if everything is working the sequence would then go 1,2,3 and back to 0 when done.

case seq_step of
   0 : // waiting to start (we are doing nothing here)
       seq_step:=0;
       
   1 : // send modbus message
       SendSerialCommand(modbus_message);
       timer:=0; // reset timer
       seq_step:=2; // goto next step

   2 : // wait for response from slave
       if response_has_arrived then
          timeout_error:=false; // clear error flag
          if response_is_good then
             seq_step:=3;
          else
             seq_step:=1; // retransmit immediately
          end_if;
       end_if; 
       // check that we are not waiting here forever for the response
       if timer>100 then
          // no response from slave, timeout error
          timeout_error:=true;
          timer:=0;
          seq_step:=4;
       end_if;

   3 : // message has been sent and response was good
       seq_step:=0; // go back to waiting
       
   4 : // wait a while (500ms)
       if timer>500 then
          seq_step:=1; // go back and try again
       end_if;
end_case;

[Diameter157]

You are totally right Pete, I simplified it too much.

Here is the basic code I was basing it off of:

Siemens v90 modbus

Although you can't see all the code because some of it is "know how protected".

[shooter]

ST and LAD are treated same way like rungs and are run from top to bottom, so the result will be 60, in any case. however the preresult is another problem.
The last is counting.
And you are correct a relaisdigram has all rungs active same time, a PLC has not. It has only one rung active at same time.
The outputs are only set when ladder is completed. same for inputs they are read before the laddert or ST styarts.