Unity pro XL - ST example code?

bajsmannen

Member
Join Date
Mar 2016
Location
gbg
Posts
9
Hallo!

Having a hard time finding information about how it works in Unity pro XL.

Anyone got some simple example code? Maybe with some loops, delay and such?


Kind regards
 

Hello
Thanks. Seen the video but it's too short. I've looked through the manual but it's pretty hard to get started. Doesn't really explain the things I need which I would call basic functions. But no. :(

This is what I'm doing:

if pushbutton_1 or 2 = 0
then
a=1 and e=0

if pushbutton_1 = 1
then
timer 2 sec
a=0
b=1
c=0
e=1
timer 3 sec
b=0
c=1
timer 5 sec

etc...a simple traffic light.

Should I use loops as timer? I remember that I did like it that in C (I knew the time it took for one increment).
 
Last edited:
Look up the TON, TOF, TP functions in the unity help.

in the program section, whether it is ladder, FBD, or ST, press CTRL+i and the function input assistant will appear.

Type TON in the FFB type text box.
Press enter.

in the ST section the function call for a timer has been inserted for you:

Code:
TON_0 (IN := (*BOOL*),
       PT := (*TIME*),
       Q => (*BOOL*),
       ET => (*TIME*));

Change the comments to the tag names of your type. If you enter a tag name that doesn't exist hit SHIFT+ENTER to create the tag.
 
Hi
I did not get any good advice. Start with ladder? No thanks. Won't help me. Can't you agree with me that this is a case with very little info in the web?

One guy offered example code but never sent it.


So why start a new thread on the same subject ?

Anyway, I don't agree, have you actually taken the time to look for documentation, try this for a start, i found this in 1 minute, the ST section:

http://download.schneider-electric....533442681&p_File_Name=33003101_K01_000_17.pdf
 
Is there no other way of doing a simple delay? In other languages there is a simple function called "waittime, delay, wait..." etc. I've tried with %S6 also

I need a timer here. I can't understand how it works.

IF not PB_1 and not PB_2
THEN
DIOD_1:=1 AND DIOD_2:=0;
ELSEIF PB_1 OR PB_2
then
*DELAY 2 sec*
DIOD_1:=0 AND DIOD_2:=1;
END_IF;

This would be super easy in another programming language. It's just the timer making it difficult...
 
Last edited:
Code:
run_timer1 :=0;
if ((PB1 OR PB2) and not timer_done) then
  run_timer1 :=1;
end_if;

TON_0 (in:= run_timer1, PT := t#2s, Q=>timer1_done);

if (timer1_done) then
   (* do stuff one time*)
end_if;

run_timer2 :=0;
if ((PB1 OR PB2)) then
  run_timer2 :=1;
end_if;

TON_1 (in:= run_timer2, PT := t#2s, Q=>timer2_done);

if (timer2_done) then
   (* do stuff continuously after 2s *)
end_if;
you will also need to consider when to write your outputs back to 0.

generally this is "doing it wrong". after you see how cumbersome it is to use ST for certain types of logic you will begin to understand the strengths of Ladder and FBD
 
Code:
run_timer1 :=0;
if ((PB1 OR PB2) and not timer_done) then
  run_timer1 :=1;
end_if;

TON_0 (in:= run_timer1, PT := t#2s, Q=>timer1_done);

if (timer1_done) then
   (* do stuff one time*)
end_if;

run_timer2 :=0;
if ((PB1 OR PB2)) then
  run_timer2 :=1;
end_if;

TON_1 (in:= run_timer2, PT := t#2s, Q=>timer2_done);

if (timer2_done) then
   (* do stuff continuously after 2s *)
end_if;
you will also need to consider when to write your outputs back to 0.

generally this is "doing it wrong". after you see how cumbersome it is to use ST for certain types of logic you will begin to understand the strengths of Ladder and FBD

(n) He thinks ladder is old school, that it may be but its quicker and better than ST in many more applications.....

But I agree with you.
 
Yes, I know it's an old thread; close it now if that is your policy, no harm no foul.

But AFAICT the OP's fundamental understanding was never addressed. Yes, OP is almost certainly long gone, but others might find this thread and have a similar question.

Is there no other way of doing a simple delay? In other languages there is a simple function called "waittime, delay, wait..." etc. I've tried with %S6 also

I need a timer here. I can't understand how it works.

IF not PB_1 and not PB_2
THEN
DIOD_1:=1
DIOD_2:=0;

ELSEIF PB_1 OR PB_2
THEN
*DELAY 2 sec* (* <=== PLCs do not work like C! *)
DIOD_1:=0
DIOD_2:=1;

END_IF;



This would be super easy in another programming language. It's just the timer making it difficult...
"Toto, I've a feeling we're not in Kansas anymore."

It's not the programming language, it is the environment that is "other;" once the environment is understood, it becomes easy again. Trying to write PLC code based on C code experience is akin to treating the Land of Oz like Kansas.

In a PLC environment, the PLC code written by the programmer is executed in a loop, and that loop executes repeatedly as long as the PLC is in RUN mode. Each pass through that loop is called a scan cycle and executes ALL of the PLC code on each pass. Each pass must complete within a certain "watchdog" timeout period, or else the PLC Executive, which is "outside" of and runs the scan cycle, will detect a watchdog timeout and halt the PLC.

So the code cannot be designed as if it were to be executed in a linear fashion; specifically, PLC code cannot have a long delay in the code where execution stops during a single scan cycle, or else the PLC Executive process will trigger a watchdog timeout and halt the PLC.

An over-simplified model of a PLC would look like the following. Everything in red is part of the PLC Executive process and executes unconditionally and independently of any PLC code the programmer writes.

while (IN_RUN_MODE) // The Executive starts the scan cycle
{ // C-style shown
read_inputs()l // The Executive copies physical input states into local memory buffer

(* Start programmer's ST code *)

VAR

ton_2s : TON;
END_VAR;

IF not PB_1 and not PB_2 AND NOT button_was_pressed
THEN
DIOD_1:=1
DIOD_2:=0;​
ELSEIF (PB_1 OR PB_2) AND NOT button_was_pressed
THEN
*DELAY 2 sec*
button_was_pressed := 1;
ELSEIF expiry_2s_timer
THEN
DIOD_1:=0
DIOD_2:=1;​
END_IF;

(* The TON timer is a time accumulator that runs *)
(* on every scan cycle. As long as its input .IN *)
(* Boolean assignment evaluates to True, the time *)
(* accumulation, .CV, increases by the amount of *)
(* time since the previous TON's call. Once the *)
(* time accumulation reaches the Preset Time .PT, *)
(* i.e. once the timer expires, the .OUT Boolean *)
(* becomes 1. When the .IN assignment evaluates *)
(* to False, then the .CV accumulation value is *)
(* reset to 0, and the .OUT Boolean is reset to 0 *)
(* N.B. those resets happen whether the timer had *)
(* expired or not. *)

ton_2s(IN:=
button_was_pressed
,PT:=T#2s
,OUT=>expiry_2s_timer
);

(* End programmer's ST code *)

write_outputs(); // The Executive writes buffered output values in memory to physical outputs
} // Executive ends this pass of the "while" loop



Caveat: that code is incomplete: there should be some condition that resets the value of button_was_pressed back to 0.
 
In a conventional computer language the 'state' of the machine may correlate to where the computer is in executing the code. Flow charts were kind of a way of showing this. If you stopped the processor you could tell what it was doing before the stop by where it is in the code sequence. If you need more that one thing going on at a time you had to have parallel threads of execution.

With most PLC languages the state is held in data, not in code. You know where it is in the machine's cycle by which relays are on and which relays are off. More than one thing can go on at a time by using some relays for process A and some for process B. This is true for LD, FBD, and ST. An ST timer is exactly like an LD timer - it does not halt execution at that point until the timing is done. Timing continues as long as the program is repeatedly executed until the timing is done. The end of the timing is not marked by a change in program sequential solving order. It is marked by a change in the data associated with the timer - sometimes it is called the Done bit.

In this case the problem is not with ST, the problem is with the understanding of how PLC programming languages work.

The horse of a different color is SFC where the state appears to be defined by 'where' the processor is executing the code. That's the power and the danger of SFC. It requires skill to get it to reach it's goals without crashing and burning.

There are methods to encode state transition diagrams into languages like LD . They should be part of every PLC programmer's toolkit.
 

Similar Topics

Hi, I am newbie at programming PLC's so I need M340 Unity Pro example project. Simple draining pump station with three pumps. First pump starts...
Replies
2
Views
3,947
I need M340 Unity Pro example projects to download!! Just a simple Project for water treatment plant . With pumps and mixer . Please...
Replies
2
Views
3,085
Hi I have an a applcation with SE M340 and ATV61. I want to control frequency and start and stop the ATV61. I have a correctly configured...
Replies
2
Views
2,682
Hello, I am using Unity pro V15. I have Quantum CPU 671 and Ethernet NOE 77101 configured. I have configured IO scanning on NOE. I have attached...
Replies
5
Views
173
HELLO MY FRİENDS ı have problem. ı tought you can solved thıs problem for me. First of all When I checked all the cable connections of the...
Replies
0
Views
401
Back
Top Bottom