Sign in to follow this  
Followers 0
DWIM

Timers do not work in Sturctural Text

8 posts in this topic

Hi,

I have a problem because a TON Timer instance in an ST program does not start running.

Is this a known limitation on FX5U CPU's or ST Language in General ?

On the internet are some discussions, and there is a person which says it works for FX CPU's:
https://stackoverflow.com/questions/58463316/delay-timer-in-structured-text?noredirect=1&lq=1
But not for me....

And some discussions here in the forum:
http://forums.mrplc.com/index.php?/topic/20864-plc-failing/
http://forums.mrplc.com/index.php?/topic/37923-calling-a-timer-in-st-code/

The last one is interesting, but it did not helped in this simple case.

 

For clarification, I created a very small program in GX Works3 (v1.057K)

The FB instance in Picture 1 works very well if one sets M10 to True.
The ST instance in Picture 2 does not start when setting M20 to True.

Has anybody a clue?
Any help welcome

DWIM

 

ST_Timer0.png

ST_Timer1.png

ST_Timer2.png

ST_Timer3.png

ST_Timer4.png

Share this post


Link to post
Share on other sites

don't know about ST on Mitsi but...

 

is it scanned?

are you sure that Start is on (inside PoU, not M20)? if not problem is not the timer but type of parameter transfer

so what is the type of transfer for parameter "Start"? If "VAR_INPUT" transfer type corresponds to ByVal (which i am pretty sure it does), then it will never change from FALSE to TRUE even if M20 does. changing signals must be transfered ByRef. easy way to test is is to make sure M20 is on when your sub is called. Or just remove timer and activate Hello directly by Start

ByRef is usually represented by "VAR_INPUT_OUTPUT" or just "VAR_OUTPUT".

 

Share this post


Link to post
Share on other sites

Hi panic_mode

First, I cannot remove the timer. I need one. The sample code is only for testing. I have a a more or less communication code and I do not want to scare everybody with it. ;-)

I looked into your tips and went ahead and just replaced "Start" input with M20 altogether inside the ST block.
Now, M20 is M20 is M20 is M20. Not? At least it lighted up in the code. I then changed the code a bit so i can toggle it during simulation.

==> It had no effect!!!

==> It seems in ST an Timer instances die after the code is finished after a scan.

 

Then I tried to reference a global timer variable, did not helped.

The only thing that worked was more or less to copy the line in the docs :

My_Timer(M30,INT_TO_TIME(2000),Hello,ElapsedTime);

With  "My_Timer" is local TON or TON_10 variable, "Hello" is a standard output variable, "ElapsedTime" is a local variable inside the ST Functionblock.

Well...that was obvious......

Share this post


Link to post
Share on other sites

" It seems in ST an Timer instances die after the code is finished after a scan. "

well, this is true for ALL programs (used language makes no difference). that is how computers work in general. task that need to run continously is placed into a loop. this is what PLC scan really is....

Share this post


Link to post
Share on other sites

Well, you are right, sort of. In a function a variable dies. Yes.  I just don't see how a timer can/is  garbage collected after a scan. The mechanism is not clear to me in ST. The timer must be re-created. I have to call the whole constructor every time ==> My_Timer(M30,INT_TO_TIME(2000),Hello,ElapsedTime);
If it would follow standard behaviour the timer would never fire because it is instanciated every time and start at time zero. It is a local variable, Not? 

Even more with global variable timers, which does not work too.
It is not enough to use My_Timer.IN and My_Timer.Q inside a scan. This is just quirky.

 

Share this post


Link to post
Share on other sites

I think you are confusing Mitsubishi PLC programming with .Net or Java etc.  There are no instances of objects created or destroyed (no reference types so nothing to garbage collect). When you use VAR_INPUT_OUTPUT  its not referencing the variable but copying its value, then using it, then copying the result back to the original variable.  

As other have said the timer needs to be scanned all the time – no different than ladder. It's the same in other PLC's as well. For example below is a timer in Allen Bradley ST. If you commented out (or deleted) the timer on line 2 the timer would stop working.

 

1.       DelayPumpStart.PRE := 5000;

2.       TONR(DelayPumpStart);

3.       DelayPumpStart.TimerEnable := ValveOpen_Verified_V45LEX;

Edited by Nightfly

Share this post


Link to post
Share on other sites

exactly... this is not OO environment, programing style is procedural and on most systems (not just Mitsubishi) all data resources are already created (and initialized) so you just access them. for example you get fixed number of M devices for certain CPU. and fixed number of D registers.... some of them have special function so you need to check documentation. CPUs with more memory may offer larger blocks of data and possibility to trade size of one data type for another (within limits) or specify areas are backed up (retentive). an smaller CPUs all of this is fixed.

Share this post


Link to post
Share on other sites

Looking at your ST code, you never ran the timer.  You simply put values at its input and looked at the output.  The timer itself is not in your code.

It would look something like this:

TE_ON(In:=Start, PT:=t#10s)

To leave the logic as you have it, simply add the execution of the timer.

TE_ON()

Then your line looking at the output would work fine.

Pretty sure their manuals show this, I haven't done it on Mitsu in a few years, but this is how IEC structured text works.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0