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

[Axel]

Finall I solved the mystery. In the end its all about timing and what Matlab does when it opens a serial communication (via serialport; I do not know if there are other workarounds in Matlab). It turns out that the Arduino was indeed not ready to answer at the time Matlab requested it despite the 5 second pause because I had not calculated in that opening a communication (via Serialport) results in a reset of the Arduino and that it takes a bit of time for the Arduino to prepare for serial communication. I made the mistake that this command (Serial.begin) was not executed very early in the setup function of the Arduino so that the Aruino did something else for a few seconds before opening a serial connection. Hence it started listening to serial communication very late (after more than 5 seconds) and the request arrived too early. Prolonging the break to more than 7.2 seconds solved the problem for Matlab and this is also the reason why executing the script slowly worked.

However, beginning serial communication on the side of the Arduino as the first command after reset is the real solution (because waiting for 7 seconds seems a ridicilous long time for communication nowadays). Now it reacts virtually in an instant to serial communication.

Thx for any feedback, also from Matlab Support.

Answer 2

[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.