USB callback "terminator" fails to trigger a read when messages are close together

My App Designer program uses USB communication to an Arduino

It usually works but every once in a while Matlab fails to read.

configureCallback(app.PicoCom,"terminator",@app.PicoInput);

...

function PicoInput(app,src,~) 
% check if there is more than 1  line. For some reason I don't get another callback!!!
while (app.PicoCom.NumBytesAvailable>0)
    raw = readline(src); 

I've already added the while loop which mostly fixed it except if the messages are 20msec apart.

The only time it fails (and not very often) is between 2 messages that are known to be 20 ms apart.

When it fails (App Designer says "Run" ... no action), I can go into the debugger (with a special pause I put in to read app properties) and check with

K>> app.PicoCom

ans =

Serialport with properties:

Port: "COM6"

BaudRate: 57600

NumBytesAvailable: 11

K>> read(app.PicoCom,11,"char")

ans =

'z73851718

'

And there it sits, not being read.

Sure, there are probably work arounds (I'm open to suggestions to manage it now) but isn't this a bug!

My next attempt to handle this is to add a pause(0.03); at the end of the while loop but this is very unsatisfying and how do I know it will NEVER fail?

Answer 1

[Gavin]

See answers to other ways I asked this question and related issues

https://www.mathworks.com/matlabcentral/answers/2152950-in-app-designed-app-when-does-a-function-called-within-another-function-spawn-a-new-thread?s_tid=srchtitle

https://www.mathworks.com/matlabcentral/answers/2154685-can-i-call-a-function-from-another-function-and-not-come-back?s_tid=srchtitle

The ultimate solution

https://www.mathworks.com/matlabcentral/answers/2154685-can-i-call-a-function-from-another-function-and-not-come-back?s_tid=srchtitle

No point repeating answers, it just took me a while to figure out the real problem and how to ask about it.

Answer 2

[Matlab Pro]

Hi @Gavin

Here I am sednig to pieces of code:

1): simple example where you just wait for NumBytesAvailable to get some posistive value, read the data and thats all..

2): reading expected # of bytes:

Are you handling some kind of protocol with the Arduino?

I believe that the answer is 'yes', so the protocol should have some bytes pointing to the expected data length.

In the example below: the expected dataLength given in bytes #3 and #4

After caculateding the expeced dataLength - the code cotiues reading (with a minimal delay) till goal is achieved

Good luck @Gavin!

% 1) Reading while NumBytesAvailable = 0
switch class(portObj)
    case 'internal.Serialport'
        write(portObj,data_write,"uint8");
        while (portObj.NumBytesAvailable == 0)
            pause(0.01);
        end         
        out = read(portObj,portObj.NumBytesAvailable,"uint8");         
end

% 2) Reading expected # of bytes (BY PROTOCOL)
switch class(portObj)
    case 'internal.Serialport'
        write(portObj,data_write,"uint8");
        while (portObj.NumBytesAvailable == 0)
            pause(0.01);
        end
        out = read(portObj,portObj.NumBytesAvailable,"uint8");

        % If you expect that some of the data still can not be read
        % (delayed data)
        dataLength = out(3)*256+data(4);
        % Some data is still delayed on channel...
        while length(out) < dataLength
            while (portObj.NumBytesAvailable == 0)
                pause(0.01);
            end
            tmp = read(portObj,portObj.NumBytesAvailable,"uint8");
            out = [out,tmp];
        end
end

[Gavin]

Thanks for trying but it's not so simple. BTW you can't call pause(x) in this kind of program as it stops everything!

There is no "expected number of bytes"

It's a complicated program where MatLab App Designer GUI is telling Pico what to do for the next trial and then logging the results. I need to use the 'terminator' version of callback as once Pico gets the Go signal it takes many seconds for the trial to run depending on the dats it is acquiring from sensors and actions it takes based on the command given. Meanwhile, there are too many possible interactions with the user to have any main line code. The whole point of Apps is that they can run and actions (methods) are triggered by callbacks. What is happening is that the Pico initiated (CRLF) callbacks don't happen, especially not in the debugger.

It's now in a situation where it's not working at all at a certain point and eventually MatLab itself crashes (if I go Continue,and not break in the debugger. I can't even stop the program or quit MatLab without CTRL-ALT-DEL End task !!

Using break as each trial starts (just be for I send Pico another Go command) should work since an entire trial is processed before the next one gets called and I get to the Go again. But MatLab isn't reading and processing the inputs before starting the next trial:

Look how chars have piled up, there are no replies longer than 20 characters so this buffer of NumBytesAvailable is way behind where it should be.

K>> app.PicoCom

ans =

Serialport with properties:

Port: "COM6"

BaudRate: 57600

NumBytesAvailable: 587

I've asked for the app.PicoCom handler info at the next break when the whole trial should have been processed.

Maybe (According to dbstack) the callback never ends so can't be retriggered?

K>> dbstack

> In MouseOdor12/RunTrial (line 429)

In MouseOdor12/RerunIgnoredTrials (line 544)

In MouseOdor12/ManageResults (line 942)

In MouseOdor12/PicoInput (line 387)

In MouseOdor12>@(varargin)app.PicoInput(varargin{:}) (line 333)

In internal/Serialport/callbackFunction (line 1472)

In internal.Serialport>@(varargin)obj.callbackFunction(varargin{:}) (line 980)

I wondering if I have a problem re-entering a routine that's running already when I RerunIgnoredTrials though I've tried to avoid that. There is always an open arrow pointing to

configureCallback(app.PicoCom,"terminator",@app.PicoInput); 

I guess meaning that it's supposed to be always running.

And as far as the suggestion above, I've already added to the input processor function

function PicoInput(app,src,~) 
while (app.PicoCom.NumBytesAvailable>0)
    do my stuff for one line
end
end

So that any responses missed and piling up will get handled until the buffer is cleared

Do I need to call PicoInput(...) on a timer or something to work around this problem? Remember there is NO main line code running all the time. Between actions the App Designer debugger is showing Run, not Continue until I hit a breakpoint. Should I add

if (app.PicoCom.NumBytesAvailable>0)
    PicoInput(app,src,~)
end

into the RunTrial procedure to be sure it has finished?

This is not an easy one so please don't try to answer if you don't know App Designer applications using external callback functions intimately.

[Gavin]

I tried adding at the start of a RunTrial call

if (app.PicoCom.NumBytesAvailable>0)
    PicoInput(app, app.PicoCom);
end

Seems like that should help. Tracing a bit when I try to enter a function Manage

ManageResults(app,app.TrialNumberField.Value, ...
    app.PicoType,app.PicoData);

It pops up something ominous:

classdef (Hidden) AbstractNumericComponent < ...

matlab.ui.control.internal.model.ComponentModel & ...

matlab.ui.control.internal.model.mixin.EditableComponent & ...

matlab.ui.control.internal.model.mixin.HorizontallyAlignableComponent & ...

matlab.ui.control.internal.model.mixin.FontStyledComponent & ...

matlab.ui.control.internal.model.mixin.BackgroundColorableComponent & ...

matlab.ui.control.internal.model.mixin.PositionableComponent& ...

matlab.ui.control.internal.model.mixin.EnableableComponent & ...

matlab.ui.control.internal.model.mixin.VisibleComponent & ...

matlab.ui.control.internal.model.mixin.TooltipComponent & ...

matlab.ui.control.internal.model.mixin.PlaceholderComponent

% This undocumented class may be removed in a future release.

% This is the parent class for edit field components that only accept numeric inputs.

% e.g. Numeric edit field, Spinner

% Copyright 2014-2022 The MathWorks, Inc.

And NOT stepping into the ManageResults() function that needs to run!

---------------

New thought... My USB callback is just a function because in App Designer creating a callback using the button only allows callbacks to USER interaction. I noticed that AppD managed e.g. buttons with callbacks have CALLBACK EXECUTION CONTROL BusyAction options: queue or cancel

Can I set (or be sure that) my function that's a USB Serial callback will always be cued? Could this be the problem?