Monitor Pro (Factorylink) IML execution sequence

B

Thread Starter

Buzby

Hi,

It's not very clear in the manual if it is possible for more than one IML procedure to be executing simultaneously.

As there is only one IML task I would expect that each triggered procedure (and all its calls to sub-procedures) must be completed before IML can service another trigger.

This is of course very fast, so it 'looks like' tasks executing simultaneously, but really the triggered executions are sequential and never overlap.

Is this correct?

Also, is it possible somehow to determine how long an IML procedure, or even the IML task, takes to run? Is there a watchdog of some kind to warn of long execution times like those caused by very long WHILE loops?

Thanks.
 
G

Gustavo A. Valero P.

Hi Buzby for 4th time! :)

I write my answers in CAPITAL LETTERS below:

> It's not very clear in the manual if it is possible for more than one IML procedure to be executing simultaneously. <

OF COURSE! THERE IS NO PROBLEM WITH IT, FACTORYLINK CAN RUN SEVERAL IML PROCEDURES IN PARALLEL USING A COMMON OR DIFFERENT TAG AS TRIGGER. IT IS WHAT ANY USER DOES EVERYDAY IN ANY APP.

I THINK THERE IS NO LIMIT TO RUN 'n' IML PROCEDURES IN PARALLEL... NO WORRY!

> As there is only one IML task I would expect that each triggered procedure (and all its calls to sub-procedures) must be completed before IML can service another trigger. <

NO, EACH PROCEDURE IS INDEPENDENT AND RUN BASED ON ITS TRIGGER ONLY. ALSO, IT CAN BE CALLED FROM ANOTHER PROCEDURE.

THE IML TASK JUST VERIFIES THE CODE/SYNTAX (IN CML IS DONE BY C COMPILER) OF PROCEDURES, EXECUTE THEM AND GIVE SOME DEBUGGING OPTIONS/ADVICES IN CASE OF PROBLEMS/ERRORS.

> This is of course very fast, so it 'looks like' tasks executing simultaneously, but really the triggered executions are sequential and never overlap.
>
> Is this correct? <

NO IT ISN'T. AN OVERLAPING CAN OCCUR WITH NO PROBLEM IF THE PROCEDURES ARE WELL WRITTEN AND DON'T HAVE AN ENDLESS LOOP INSIDE.

E.G. YOU CAN HAVE SOME PROGRAMS RUNNING EVERY 2, 3 OR 5 SECS, IN THE SECOND #30 THESE 3 PROGRAMS WILL RUN SIMULTANEOUSLY WITH NO PROBLEM ALWAYS!

...BUT, IF ANY OF THESE HAVE SOMETHING LIKE THIS:

I=0
WHILE I<10
# FORGOT WRITING I=I+1 !!!
WEND

YOU WILL CREATE BY ACCIDENT AN ENDLESS LOOP AND YOUR CPU USAGE WILL RAISE TO 100% MAKING YOUR APP LOOKS LIKE TURTLE!.

ANOTHER COMMON ACCIDENT (OR WRONG PROGRAMMING TECHNIQUE) IS TO SEARCH DATA INSIDE A LONG TAG ARRAY POSITION BY POSITION. E.G:

J=0
WHILE J <15000
MyTotalizer[J]= MyTag[J]
J=J+1
WEND

DUE TO READ THESE 15000 ITEMS COULD LAST TOO MUCH, YOUR CPU USAGE WILL RAISE TO 100% EVERY TIME THIS PROGRAM IS EXECUTED AND YOUR CUSTOMER WILL CLAIM THIS POOR PERFOMANCE EVERYTIME HE SEES YOU!

IN THIS CASE, TO USE CML TASK INSTEAD OF IML IS THE MOST APPROPRIATED OPTION (YOUR IML CODE WILL BE COMPILED). BUT EVEN WITH CML, THIS KIND OF PROBLEM CAN HAPPEN TOO. I HAVE HAD AND SEEN THIS PROBLEM AFTER.

> Also, is it possible somehow to determine how long an IML procedure, or even the IML task, takes to run? Is there a watchdog of some kind to warn of long execution times like those caused by very long WHILE loops? <

MY RULES ARE SIMPLE AND WORK WELL AS FAR:

1) IF THE CPU USAGE RAISES TO MORE THAN 60-70%, SOMETHING WRONG IS HAPPENING WITH SOME TASK(S)

2) IF CPU USAGE INCREASES AND DECREASES IN A CYCLIC WAY (EVERY 35 SECS FOR EXAMPLE) I'D CHECK WHICH EVENT/PROCEDURE(S) IS TRIGGERED EVERY 35 SECS TO VERIFY IF THIS IS THE CAUSE (IT HAS WORKED WELL IN 80-90% OF MY CASES).

3) NO IML/CML PROGRAM MUST LAST MORE THAN THE TIME SET TO ITS TRIGGER, I MEAN, IF I SET A TAG (MyTrig) TO 1 SEC, THE IML/CML PROGRAMS RULED BY 'MyTrig' MUST LAST/FINISH BEFORE 1 SEC. THIS WAY AVOIDS A REAL OVERLAPPING!

4) ALTHOUGH ANY USER CAN SET A LOW TIME TO RUN ANY PROCEDURE VIA A TIMER TAG (10ths, 30ths or 55ths) I PREFER TO USE "1 SEC" AS THE MINIMUM VALUE TO EXECUTE PROGRAMS AND AVOID THE KIND OF HEADACHES INDICATED ON 3).

4) FL HAS TOOLS TO VERIFY THE STATUS OF ITS TASKS: 'FLSTATE' AND 'RTMON'. YOU CAN FIND MORE INFO IN "UtilitiesGuide.pdf" FILE, PAG. 60 AND 70.

Best regards.

Suerte por 4ta vez!

Gustavo A. Valero P.
BIConsulting C.A.
Valencia - Venezuela
gustavo. valero @ biconsulting. com
 
J
True, only one IML procedure at a time, and yes a very easy way to time your IML is to capture SECTIME value in a local variable at the very beginning and ending of your IML and then write the values to local tags (must be LONG Analogs).

This gives you the time with in 1 second.

There are many techniques to speed up the execution time such as using local varables and writeing the results to tags at the end.

Jeff Jacobs
 
Hi Gustavo,

Thanks for your reply, but I think we are not talking about exactly the same thing here.

I know I can trigger many procs with one event, but are they executed in parallel or in sequence?

E.G.

Three procedures with a common trigger:

A_SEC ->> ProcX
A_SEC ->> ProcY
A_SEC ->> ProcZ

(Assume each of these procs is very short, so each executes quickly.)

Are they running in parallel, with 3 instances of the interpreter, one for each procedure? Or are they running in sequence, with a single instance of the intepreter completly executing one proc, then another, then another?

The reason I need to understand this better is because I will have some proc calls like this:

Trig1 ->> ProcX, then ProcX calls ProcA
Trig2 ->> ProcY, then ProcY calls ProcA

ProcA is conditionally manipulating a specific RTDB Tag, the value of which the calling procedure uses. Can I be sure that the values in the ProcX call path will not affect the values in the ProcY path? (Trig1 and Trig2 could happen 'at the same time'.)

I think the other reply, from Jeff, is more like what happens, but I can't work out an experiment to prove it one way or the other!

Thanks again for your help,

Buzby
 
G

Gustavo A. Valero P.

Ok Buzby, now I am clear with what you want, sorry!

Although I didn't develop the IML task and don't work at UGS or Schneider, I prefered to test both theories regarding how IML task works and my conclusion is:

** Each program is running in a sequence and starts when the previous program ends its code. They work as a chain no matter if programs use or not a common trigger! **

I am going to show how I carried out my tests:

1) In M&L Triggers Information Panel, I set the following:
Trigger Tag ->> Procedure
t_clock ->> clock1
t_clock ->> clock2
t_clock ->> clock3
t_clock ->> clock4
t_clock ->> clock5
t_clock ->> clock6

2) In each program, I wrote the following code to get the right time when the program started and finished. Also, I forced/created a different delays to make the procedures last some seconds more:

Proc clock1
{
declare long _time

' Take de Initial time
_time = SECTIME

' Take & Write the initial time (hh:mm:ss,00) to a text file
x = system ("cmd /c ECHO.| TIME > C:\\T_Ini1.txt")

' Force execution to 1 sec (Delay of 'n' secs)
while (SECTIME- _time <= 1)
wend

' Take & Write the end time (hh:mm:ss,00) to another text file
x = system ("cmd /c ECHO.| TIME > C:\\T_End1.txt")
}

3) To make my test more useful, I used several times as delay in statement "WHILE (SECTIME- _time <= XX) WEND" to have and compare better the times among programs (Exec Time, Start Time, End Time)

4) I should write the times (timestamp) in a text file and use the DOS' "TIME" command due to FL doesn't have a timer tag able to show milliseconds or decimal seconds. As you know, "SECTIME" tag shows seconds only.

5) By activating the "t_clock" common tag as trigger, my 6 IML programs ran and these are the results:

Prog Name Delay Time Exec Time Start Time End Time
clock1.prg 1 01,84 12:07:21,42 12:07:23,26
clock2.prg 2 02,98 12:07:18,42 12:07:21,40
clock3.prg 2 02,95 12:07:15,42 12:07:18,37
clock4.prg 3 03,93 12:07:11,42 12:07:15,35
clock5.prg 3 03,95 12:07:07,42 12:07:11,37
clock6.prg 5 05,50 12:07:01,82 12:07:07,32


As you can see, your guess is right!

Keep in mind 2 important things:

a) The starting sequence of procedures begins from the last one to the first one (M&L Triggers Information Panel). I had bet that the first proc to be started would be "clock1.prg" but not... it was the last one!

b) Although "Delay Time" should be almost equal to "Exec Time" in each program, the decimal seconds of difference could be caused by the use of "system()" command, write to external text files, CPU Load, etc.

Well, I hope it helps you to improve your FactoryLink application even more!.

Best regards.

Feliz día!

Gustavo A. Valero P.
BIConsulting C.A.
Valencia - Venezuela
gustavo. valero @ biconsulting. com
 
G

Gilles Allard

FactoryLink scheduler is based on events, a very efficient model abeit more complex. This thread show that there is still some misunderstandings about FactoryLink events.

Buzby asked: As there is only one IML task I would expect that each triggered procedure (and all its calls to sub-procedures) must be completed before IML can service another trigger.

This is mostly true. A triggered procedure (and sub-procedures) will complete execution before any other trigger is served. But this statement is true only for a single domain. In FactoryLink you have a shared domain and a user domain for each user. In a multiuser operating system (eg Unix) you may have tens of domains. For simplification purposes, I will concentrate on a single user application where only 2 domains are involved (1 shared and 1 user).

To answer Buzby's question, his statement is true only if the trigger is used in a single domain.

Gustavo wrote: FACTORYLINK CAN RUN SEVERAL IML PROCEDURES IN PARALLEL

That is not true. FactoryLink will only run no more than one procedure per domain. An endless loop as he described will block all other procedures in the same domain. Procedures in other domains will be able to continue. Please note that the operating system (Unix, Windows, etc) is responsible for switching from one domain to the other.

Here are a few concepts about FactoryLink triggers: - There is no queue: if a trigger is activated many times before the procedure is triggered, the procedure is only called once. - If two triggers are activated at the same time, there is no deterministic way to determine which procedure is called first. - A trigger should never be read from an IML procedure. For example, if SECTIME is read from an IML procedure (in a specific domain), then SECTIME should not be used as a trigger in the same domain. If it is used, then there is a risk than an event be lost.

Buzby wrote: Trig1 ->> ProcX, then ProcX calls ProcA Trig2 ->> ProcY, then ProcY calls ProcA ProcA is conditionally manipulating a specific RTDB Tag, the value of which the calling procedure uses. Can I be sure that the values in the ProcX call path will not affect the values in the ProcY path? (Trig1 and Trig2 could happen 'at the same time'.)

No problem if ProcX and ProcY are in the same domain. As I mentioned, a specific IML instance is single-threaded so if ProcX and ProcY are in the same domain they will not execute concurrently.

I have a lot of experience with FactoryLink. Feel free to ask.

Gilles
 
G

Gustavo A. Valero P.

Hi friends,

I going to contribute putting my 2 cents to clarify other misunderstandings about FactoryLink events/tasks as Gilles says.

On May 6, 2007, Gilles wrote:
> ... A triggered procedure (and sub-procedures) will complete execution before any other trigger is served. But this statement is true only for a single domain. In FactoryLink you have a shared domain and a user domain for each user. In a multiuser operating system (eg Unix) you may have tens of domains... <

It's wrong or something is missing in the above statement!

FL has only one Shared domain and 'N' User domains depending on number or users/clients configured in the application no matter the OS.

In a multiuser application, users run in their own User domain and each User domain
has its own copy of user data/tasks but shares data from the Shared domain (available to all users). You can have tens of domains BUT these will be User domains NOT Shared.

Gilles wrote:
> ... Gustavo wrote: FACTORYLINK CAN RUN SEVERAL IML PROCEDURES IN PARALLEL
That is not true... <

You are right! At the begining, I misunderstood what Buzby wanted to know but later, reading his new post and explanation I could understand well his goal and carried out some tests to verify all this. At the end, my final conclusion according to my tests is:

** When some IML/CML programs are triggered using a common tag as trigger, these will run in a sequence and each program will start when the previous program ends its code. They work as a chain and the starting order is from bottonn to top of the list of procedures configured in M&L Triggers Information Panel **

Gilles wrote:
> FactoryLink will only run no more than one procedure per domain. An endless loop as he described will block all other procedures in the same domain. Procedures in other domains will be able to continue. Please note that the operating system (Unix, Windows, etc) is responsible for switching from one domain to the other. <

True but it depends on the case! If an endless loop is executed in the Shared Domain (again, the only one to be created) this loop will block your RTDB and most probably all your FL clients will be disconected due to a communication timeout with the FL server. If there is no a Shared Domain running, no User Domains will run!.

Gilles wrote:
> If two triggers are activated at the same time, there is no deterministic way to determine which procedure is called first. <

I agree with you but, if 2 or more procedures have a common trigger, I can assure you (as I wrote above) that the starting order is from bottom to top of the list of procedures configured in M&L Triggers Information Panel. I mean, if I have configured:

Trigger Tag ->> Procedure
t_clock ->> clock1
t_clock ->> clock2
t_clock ->> clock3
t_clock ->> clock4

the 1st proc to be started is 'clock4', later 'clock3', 'clock2' and finally.. 'clock1'.

Gilles wrote:
> A trigger should never be read from an IML procedure. For example, if SECTIME is read from an IML procedure (in a specific domain), then SECTIME should not be used as a trigger in the same domain. If it is used, then there is a risk than an event be lost. <

It's wrong and is a misunderstanding of Change Read (Conditional) and Normal Read
(Unconditional) concepts.

Your example is right if and only if you are reading tag's change-status bit (Change Read)and not its real value (Normal Read).

Any FL tag has a change-status bit for each 31 of FL tasks. The "read call" and "write call" functions use these bits within the FL
Kernel to indicate changes in a tag value. With this, any task knows which tags belong to it (its property) and saves processing time because tasks will wake up if they watch only changed values (tags). FL tasks use these change-status bits (On/Off) as exception flags and the FL Kernel acts as the exception processor.

If any user wants to read these change-status bits in a M&L procedure, the "?" symbol before the tag name is the rigth way to carry out a "Change Read" operation, e.g.:

a) WHILE not ?MyTag WEND

b) IF ?MyTag THEN Mytag = Mytag +1
END

As Gilles wrote, in these cases there is a risk to lose an event if this code is executed after some task previously detected the changed value belonging to Mytag's change-status bits.

But there will be no problem using a tag as Trigger in M&L and as variable/tag in another procedure (or in the same where it acts as trigger) if you just read its real value, e.g:

a) WHILE not MyTag =5 WEND

b) IF MyTag >1 THEN Mytag = Mytag +1
END

Best regards.

Feliz día!

Gustavo A. Valero P.
BIConsulting C.A.
Valencia - Venezuela
gustavo. valero @ biconsulting. com
 
Hi to Gustavo and Gilles,

Thanks to both of you for your invaluable help.

Gustavo, you have made a good experiment to prove my suspicion.

Gilles, you have given a good technical description of the way the 'engine' works.

My thanks again to you, and all the other engineers, who make this a really useful forum.
 
O

olivier chesnais

He discovered strange behavior of his system. It looks like the problem comes from IML task treatment mechanism. It looks that in his application one IML procedure can freeze for some time and MPRO starts another IML procedure. He has many IML procedures with different launch triggers and some launch conditions becomes switched off without reasonable cause. He asks us to confirm this IML feature (possibility to interrupt one IML procedure by another IML procedure) or asks our explanation regarding treatment approach for IML task treatment that implemented in MPRO in case of possibility to start many IML task in the same time?
 
Top