Hi

I have a GUI app that controls a moving scanner and reads data from an A/D board while the axes are moving.

My "SCAN" button callback loops, say, 1000 times reading the A/D board and processing data while the axes are moving.

I have another "STOP" button on my GUI to stop the axes' motion.  

If I am in the SCAN button callback, the STOP button callback will not execute, which means there's no way to do a stop (emergency or otherwise) until the SCAN loop is complete.

Can I construct a STOP callback that can interrupt the SCAN callback?

--Ed

Ed Nieters wrote:

> I have another "STOP" button on my GUI to stop the axes' motion. 
> If I am in the SCAN button callback, the STOP button callback will not 
> execute, which means there's no way to do a stop (emergency or 
> otherwise) until the SCAN loop is complete.
> 
> Can I construct a STOP callback that can interrupt the SCAN callback?

Please read the following documentation:

http://www.mathworks.com/access/helpdesk/help/techdoc/creating_guis/bq61qtj-1.html

Alternatively, could I read the A/D board in a periodic timer function?
My problem then is how do I pass the read data back so the GUI can see it?
Are timer functions run in separate (interruptible) threads?
--Ed


Walter Roberson <roberson@hushmail.com> wrote in message <hu6fhs$e8j$1@canopus.cc.umanitoba.ca>...
> Ed Nieters wrote:
> 
> > I have another "STOP" button on my GUI to stop the axes' motion. 
> > If I am in the SCAN button callback, the STOP button callback will not 
> > execute, which means there's no way to do a stop (emergency or 
> > otherwise) until the SCAN loop is complete.
> > 
> > Can I construct a STOP callback that can interrupt the SCAN callback?
> 
> Please read the following documentation:
> 
> http://www.mathworks.com/access/helpdesk/help/techdoc/creating_guis/bq61qtj-1.html

Ed Nieters wrote:

> Are timer functions run in separate (interruptible) threads?

timer functions are, as far as I know, _not_ run in separate threads. The 
documentation I pointed you to describes the conditions under which a callback 
is eligible for interruption, and lists the various points at which pending 
interrupts will actually cause context switches. You need to code one of those 
calls in to your SCAN callback. If you cannot do so, if the SCAN callback is a 
"black box", then you will not be able to accomplish what you had hoped to do.

 > Alternatively, could I read the A/D board in a periodic timer function?

Yes.

 > My problem then is how do I pass the read data back so the GUI can see it?

See guidata()

Walter Roberson <roberson@hushmail.com> wrote in message <hu6hgo$hnf$1@canopus.cc.umanitoba.ca>...
> Ed Nieters wrote:
> 
> > Are timer functions run in separate (interruptible) threads?
> 
> timer functions are, as far as I know, _not_ run in separate threads. The 
> documentation I pointed you to describes the conditions under which a callback 
> is eligible for interruption, and lists the various points at which pending 
> interrupts will actually cause context switches. You need to code one of those 
> calls in to your SCAN callback. If you cannot do so, if the SCAN callback is a 
> "black box", then you will not be able to accomplish what you had hoped to do.
> 
I recently had a discussion with technical support regarding timer functions. I believe timer functions have changed how they operate. I think initially they ran like any other callback and waited paitently for the event queue to be flushed (e.g., drawnow or a return to the Matlab prompt). I am not sure what "thread" they run on, but according to technical support, timers callbacks can now exceute between any 2 lines of code. I am not sure what defines a line of code. I think that mex files may be a single line of code. I think that one line with two commands on it, might be 2 lines of code.