Do functions listen to global variables under while loops (Stopping functions)

If I have a function running within a while loop, where the condition of the loop is a live variable (ex. a pressure sensor), will the function be stopped if the while loop condition is met while the function runs?

In this application. I have a function programmed to move motors to a certain orientation, the while loop in the main code file where the function is called is sensing if pressure = 0, if the pressure changes (~=0) before the motors have reached their orientations will the function be stopped?

[Rik]

I'm not sure what you mean. In principle all Matlab functions run sequentially, so the condition must be true when the while statement is evaluated. If it becomes false while the code inside the loop is running that is not relevant.

[rough93]

So effectively MATLAB is single threaded in this respect. If the sensor is receiving live feedback it won't affect the while loop until the loop is complete. For example:

pressure = readDevicepressure

while pressure == 0
    (x, y, z) = function(move the pressure reader to x,y,z)
end   

If at any point while the function is moving the motor to (x,y,z) coords the pressure changes, the loop will not stop until the function has moved the motor to the point?

[Walter Roberson]

MATLAB does not have "live variables". It does have global variables, which only live in one place so any change to a global through any means is known to all uses of the global.

A global can be updated inside a callback for a timer or serial port or network connection or data acquisition object or any of a number of other background callbacks.

The one issue to watch out for is that graphic object callbacks such keypressfcn are typically queued and cannot interrupt other code until the code does something that permits the event queue to be examined, such as drawnow()

[rough93]

Awesome, thanks Walter. So for the above response example, I would need to recheck the pressure variable inside the function and then return from the function if the variable is met? I would effectively have to make every other line in the function a callback in order to have the effect of running the check concurrently?

[Walter Roberson]

You can use nested functions and shared variables.

You could also potentially move to an event driven approach where you add listeners to an event and broadcast an event when you receive a new value. However this can have more overhead and so can be slower.

[rough93]

For this it sounds like I'll need to use events/listeners then, as I'm not quite sure how I'd be able to nest the function or share variables in such a fashion. Off to learn about listeners!

[Walter Roberson]

In MATLAB, two functions cannot execute at the same time except when you use the Parallel Computing Toolbox (in which case each of the executing functions is in a different process.)

However:

• There are internal routines that somehow fill or empty I/O buffers in the background. It is not specified as to how they work or when they can interrupt. They do not operate at the MATLAB level, but they do alter some information that can be queried at the MATLAB level, such as number of bytes currently in the buffer. To prevent inconsistencies, there is probably some locking of the appropriate variables, but this is not certain. It is possible that they operate on a different thread at the C++ level that underlies MATLAB.
• There are MATLAB-level callbacks that can be triggered in response to I/O, such as when end-of-line is detected on a serial port, or end of a camera frame loaded. It is not clearly documented as to when these callbacks can be triggered, but probably it is between any two physical lines of MATLAB code (not at the end of each part of a compound command such as one separated with semi-colons -- but if those compound commands happen to invoke MATLAB code, then the interruption can happen between lines of that MATLAB code.)
• There are MATLAB-level callbacks that can be triggered in response to timers. It is documented that these can be triggered between any two physical lines of MATLAB code (not at the end of each part of a compound command such as one separated with semi-colons -- but if those compound commands happen to invoke MATLAB code, then the interruption can happen between lines of that MATLAB code.)
• There are MATLAB-level event listeners. At the moment I do not know what the rules are for when an event listener can be triggerred.
• There are MATLAB-level GUI callbacks such as KeyPressFcn or uicontrol('style', 'button') 'Callback' function. When these requested, MATLAB checks to see if a GUI callback is already executing, and if so then it checks the GUI object's Interruptible property to determine whether an interruption can occur, or if instead the callback can be queued. You should assume that callbacks will be queued unless you deliberately changed the object properties. https://www.mathworks.com/help/matlab/creating_guis/callback-sequencing-and-interruption.html . Queued callbacks are not given a chance to run until drawnow() or pause() or uiwait() or waitfor() is executed, or until figure() is asked to either create a new figure or activate an existing figure. If you have a loop of code that depends upon a variable that is changed in a callback, then you are much better to assume you need to call drawnow() to give the callback a chance to execute to change the variable.

[Walter Roberson]

I wonder about your motor control function. Is it a MATLAB level routine that is operating through the Data Acquisition or Instrument Control toolbox, continually asking for position updates and sending individual motor control commands? Or are you talking to an arduino or raspberry PI to do the motor control for you? If you are talking to an arduino or Raspberry Pi then it would seem to make the most sense to provide the pressure information directly to it and for it to make the decisions about stopping if pressure readings suggest that.

[rough93]

The code is talking to a arduino in order to send commands and receieve position feedback. I've implemented the Arduino hardware control toolbox in order to communicate through the arduino (which only acts as a middleman). It sounds like your suggestion would cause the arduino to stop all running code however, which I don't want to neccessarily do, just the current loop.

[Walter Roberson]

No, the arduino is looping around in its control loop. You would have it check to see if a command has come in from the host to set the goals. If not, then it should check the pressure sensors to see whether it should stop moving towards its current goal. If the sensor is okay, then it should figure out the next motor command to send and send it; if the sensor is exceeded, then it should send any needed motor stop commands and should mark itself as idle. If it has not been given a goal or has stopped moving towards a goal because of sensor, or has reached the goal, then it would mark the current goal as idling for which it would not bother to check pressure or send a command to the motor. But no matter what, it loops back checking for commands again. There is never a point where it stops running all code (unless you send a shutdown command), but there are points where it does not need to issue motor commands this cycle.

Answer 1

[dpb]

pressure = readDevicepressure
while pressure == 0
    (x, y, z) = function(move the pressure reader to x,y,z)
end   

only reads the pressure before the loop starts; there's nothing that updates it (unless your function reads it again internally).

If you want to be continuously monitoring the pressure, then do so--

pressure = readDevicepressure;
while pressure == 0
  (x, y, z) = function(move the pressure reader to x,y,z)
  pressure = readDevicepressure;
end

[rough93]

Truly continuously monitoring would have to be inside the function still though right? Otherwise this function will complete and then re-read the pressure. I need to find a way to give the motor a move-to command and read pressure simultaneously while the motor is in motion so it can stop if hits something.

[dpb]

That is true, yes, this only polls the pressure sensor when the function completes.

The typical RT system control loop in polled operation ensures there's no section of code longer than some allowable time interval before inputs are polled.

Otherwise, one needs it to be interrupt-driven, not polled. In ML that would be a timer in the base product; I don't know if there are other features in some other toolboxes for such purposes or not. The data acquisition TB can control specific data acq devices but whether your device falls under it or not we don't know.