Serial communications does not seem to update within a script but on command line it does. Why?

I am using an Arduino as a serial device receiving commands and responding to it. I do not use the arduino library itself because it does not fit within the project. I checked communications with Arduino IDE, so I know that communication works as intended on the side of the Arduino. I initialize the Arduino as a serialport object in Matlab (see code below). Here is the strange thing that I do not understand:

If I send a command, the command arrives (the device shows the intended reaction) and it sends a response (like "job done") but the serialport obejct does not show any data available (NumBytesAvailable=0) if the command is send within the script. Hence the response cannot be read within the script (Timeout error) because there is nothing to read.

But here is the strange thing: If I send the exact same command from the Command Window, I can see that a response is received (NumBytesAvailable>0) and can read it (with readline).

So it seems as if the serialport object does not update the read buffer within the script, but on command line it does. I played around with pauses just to make sure Matlab does not try to read too quickly but that did not change the behavior. Is there some kind of "refresh" or "redraw" action that is not triggered in a script but on command line?

myArduino = serialport( "COM3" , 9600 );

configureTerminator( myArduino , "LF" );

pause(5);

myArduino.flush;

pause(1);

writeline( myArduino , 'IDN?' );

pause(3);

%answer = read(myArduino , myArduino.NumBytesAvailable , "char" );

answer = readline( myArduino );

[Torsten]

Contact support:

https://uk.mathworks.com/support/contact_us.html

[Axel]

Thanks for caring.

I submitted a support ticket.

Answer 1

[Varun]

One thing that stands out is the call to:

myArduino.flush;

The serialport documentation states that flush clears data from the serial port object's buffers. If the Arduino responds quickly, it is possible that data is being discarded before you attempt to read it.

Also, the serialport interface reads data asynchronously, and MathWorks recommends using configureCallback when you want to react to incoming data as it arrives. If NumBytesAvailable remains zero in the script but not in the Command Window, a documented troubleshooting step would be to remove the flush call and use a callback to verify whether MATLAB is receiving data from the device.

For example:

configureCallback(myArduino,"terminator",@(obj,event)disp(event))

This lets MATLAB notify you when data terminated by the configured terminator arrives. If the callback fires, then the issue is likely related to when or how the script is attempting to read the data rather than to the serial connection itself.

References:

• readline documentation
• Transition Your Code to serialport Interface
• Reading data from a serialport connection
• Configure Serial Port Communication Settings

[Axel]

Thank you for caring.

I tried the callback approach and get the same behavior. If executed on command line, the callback fires instantly after the IDN? request is sent. If executed in the script, there is no reaction at all (several minutes).

The flush command is/was intended to delete any previous data that may or may not have accumulated, in particular because the data from the previous run was not received or at least not shown to have arrived. Removing .flush does not change the behavior.

One more thing I noted afterwards. If the script is executed slowly step-by-step (slowly meaning 1 sec per line), it works as intended and data is shown to arrive. If the script is executed step-by-step as fast as possible, it behaves as if the script simply runs without step-by-step execution.

[Varun]

The fact that the communication works when commands are entered from the Command Window and also when the script is executed slowly step-by-step, but not when the script runs continuously, suggests that the behavior is timing-related rather than a basic serial configuration issue. Since removing flush and using configureCallback did not change the outcome, it seems that the callback processing and data reception are not occurring as expected during normal script execution, even though the device is responding.

Given that the behavior depends on the execution context and timing, and that the same code path works when sufficient delay is introduced between commands, I would recommend contacting MathWorks Technical Support and providing a minimal reproducible example along with the observed differences between script execution, step-by-step execution, and Command Window execution. This should help determine whether the behavior is related to the serialport implementation or a product issue specific to your workflow.