Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
timer priority

Subject: timer priority

From: Jerry Gregoire

Date: 9 Oct, 2012 22:41:08

Message: 1 of 3

I have searched the User community and google and have not been able to get a definitive answer to my question.

I have found by experimentation that one timer will not interrupt another. They are uninterruptable. For example, I ran two timers, A and B, A was set at 1 sec and executed a simple fprintf stm, B conversely was set to 5 seconds and took several seconds to execute. Once B kicked in, A had to wait till B got finished. And then they operated A A B A A B ... as expected since the default is to drop serviced requests, (think the double A is because two of them get in the stack before the A timer starts dropping).

My question is can I make it so A will interrupt B, i.e., set the priority of A higher than B.
 
My application requires a precisely timed execution of one Fcn, (A's Fcn), while B can execute at any time in the background.

Subject: timer priority

From: Jerry Gregoire

Date: 25 Oct, 2012 22:40:08

Message: 2 of 3

"Jerry Gregoire" <jerryglenREMOVETHIS@neuralynx.com> wrote in message <k52964$e48$1@newscl01ah.mathworks.com>...
> I have searched the User community and google and have not been able to get a definitive answer to my question.
>
> I have found by experimentation that one timer will not interrupt another. They are uninterruptable. For example, I ran two timers, A and B, A was set at 1 sec and executed a simple fprintf stm, B conversely was set to 5 seconds and took several seconds to execute. Once B kicked in, A had to wait till B got finished. And then they operated A A B A A B ... as expected since the default is to drop serviced requests, (think the double A is because two of them get in the stack before the A timer starts dropping).
>
> My question is can I make it so A will interrupt B, i.e., set the priority of A higher than B.
>
> My application requires a precisely timed execution of one Fcn, (A's Fcn), while B can execute at any time in the background.
___________________________________________________
I did not get satisfactory ans so I submitted the issue to Matlab technical support. The upshot is that a timer will not interrupt another timer, although it is something that may be fixed someday in the future. This seems to be a glaring deficiency on Matlab's part.

This should be possible even with single threading, (Matlab is not multithreading capable), but ML can't do it. This is disappointing because it limits any 'quasi real time Matlab' useless if more than one timer is running. I am currently using 2011B, however I don't think it has changed. Here is the conversation I had with the Mathworks if anyone is interested.
____________________________
Hello Jerry,
I am writing in reference to your Service Request # 1-K3BW22 regarding 'Timer priority'.
I had some more questions regarding the issue. These are as follows:-
1) Do you want the Timer B to start after Timer A finishes executing?
2) Do you want Timer A and Timer B to run concurrently once Timer B starts after 5 seconds?

____________________________
Apratim,

Thanks for the reply. The idea is simply to allow a timer to exercise
real time control, i.e., its function will execute after the current
statement, (any statement), is finished. Ideally, it would be great if
it could execute immediately, but this would require multi-threading,
which as I understand Matlab does not currently support.

So if BFcn is executing, AFcn would interrupt at the conclusion of the
current statement in BFcn, run and return control to BFcn when AFcn is
finished. It would operate just the same as if a non timer function or
script were executing. From what I have been able to determine a timer
function, (A), will interrupt another function unless the other
function is a timer function, (B). In this case the second timer
function, (B), must complete before control is handed over the first
timer function, (A).

 2) Do you want Timer A and Timer B to run concurrently once Timer B
starts after 5 seconds?
In the code I sent you, Timer A and B start at the same time, B simply
waits 5 seconds until its function executes.

Jerry
___________________________
Hi Jerry

Thank You for your answers. One possible suggestion that I can offer is that instead of starting both the timers in the main function, you can define a 'StopFcn' for Timer A(which is the callback executed once Timer A stops executing), in which you can start Timer B. Therefore, Timer B will start as soon as Timer A stops.
Details about StopFcn have been shared in the following documentation page for Timer Objects.
http://www.mathworks.com/help/releases/R2011b/techdoc/ref/timer.html
Let me know if a 'StopFcn' will help you achieve your use case.
Thanks
Apratim
_____________________
Apratim,

The problem is still the same. If BFcn is executing, A cannot
interrupt it. This would only work if the time to execute timer BFcn <
timer A period which is not guaranteed. In the example code I sent,
the time of execution for BFcn is 8.34 seconds, (on my machine),
while the period of timer A is 1 second.

__________________________
 Hello Jerry,

I am writing in reference to your Service Request # 1-K3BW22 regarding 'Timer priority'.

Unfortunately, two timers won't interrupt one another. The functionality used to control GUI callbacks (UIWAIT, UIRESUME, WAITFOR, etc). does not behave as documented when used in TIMER callbacks. Only callbacks corresponding to the same timer may be interrupted using the 'BusyMode' property.

An enhancement has alrady been submitted in order to incorporate such an attribute in a future release. I will, however, not be able to suggest a workaround at the moment. In case you can share the application that you are working on, which requires this attribute, maybe I will be able to suggest a different workaround to approach that problem.

Subject: timer priority

From: Bruno Luong

Date: 26 Oct, 2012 05:20:08

Message: 3 of 3

I wouldn't hope such limitation would satisfactory getting solved any soon. In order to make a real concurrent runs among timers, All MATLAB builtin functions has to be thread safe. This is really a major change from TMW.

You should forget about MATLAB if you want to get the realtime job done, or limit the goal to very specific tasks (acquisition, calculation) with MEX programing.

Bruno

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us