Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

To resolve issues starting MATLAB on Mac OS X 10.10 (Yosemite) visit: http://www.mathworks.com/matlabcentral/answers/159016

Unreliable Serial data logging

Asked by Chandrakanth on 21 Aug 2012

ISSUE: Matlab is able to communicate with a device via serial port fine, but when I log data continuously it fails after a while. When it fails the device can no longer receive any commands, neither from Matlab nor from any other software like Hyperterminal /Terminal. There is no error message, it just stops after a while communicating.

Description:

Below is the code - a simplified version of a larger work that reproduces the problem. Here, I'm using a loop with a pause delay between subsequent commands. Serial commands here are specific to the device I'm using (a stepper motor).

try 
    fclose(instrfindall)
end
i = 0;
s = serial('COM3');
set(s,'BaudRate',115200,'BytesAvailableFcnCount',1,...
      'Terminator','CR','BytesAvailableFcn', 'i=i+1;disp([num2str(i) '' -> '' fgetl(s)]);');
fopen(s)
%% The commands below initialise and start motor on the device
fprintf(s,'MC')
fprintf(s,'XI')
pause(5);
fprintf(s,'ST99000000')
fprintf(s,'SS032000000')
fprintf(s,'XO0900')
fprintf(s,'SF0200')
fprintf(s,'HA')
pause(1);
%% Poll for encoder position
for i = 1:1000
    fprintf(s,'RP');
    pause(0.05);
end  
------
Output
------
testcode
0 -> MC0000
0 -> XIP
1 -> RP+00363755
2 -> RP+00364364
3 -> RP+00364968
4 -> RP+00365620
.
.<clipped>
.
237 -> RP+00520844
238 -> RP+00521517
239 -> RP+00522224
240 -> RP+00522932
241 -> RP+00523589
% IT STOPPED REPORTING ! ! !
% LOOP is still running
% Loop has now ended
fprintf(s,'RP')
fprintf(s,'RP')
fprintf(s,'RP')
fprintf(s,'MC')
fprintf(s,'MC')
% NO COMMUNICATION POSSIBLE
fclose(s)
fopen(s)
fprintf(s,'MC')
fprintf(s,'MC')
fprintf(s,'RP')
fprintf(s,'RP')
% No communication possible even after reopening the port.

The RP command in the loop requests the motor control board to push current encoder position into the serial comm. When the programme is run, a few hundred polls are successful and encoder position is displayed in command window. Then it fails and the device can no longer be successfully communicated to. Once this occurs Terminal too fails to communicate with the device (although it can connect to it). I'm having to power cycle the device to re-establish communication. Each time the programme is run, the number of successful polls vary. Usually between 100-1000. The problem appears to be with Matlab, as I'm able to reliably log data continuously for hours using Terminal software on the same PC using the same port.

I've tried the following, in vain -

  1. I'm using serial-usb converters. Tried two different make serial-usb converters and also direct serial port. Problem persists.
  2. Tried it on two different computers running Win7 and Matlab 2012a. Tried it with both 32 and 64 bit versions of Matlab. Both computers had memory in excess of 8GB, with nothing explicitly running in background.
  3. Changed the default buffer size from 512 to 128 * 8192 = 1M. No effect.
  4. Tried fgetl, fgets, fread. Behaviour is the same with each of them.
  5. Original code uses timer objects instead of loop. Doesn't help.
  6. Tried various frequencies of poll from 1ms to 30 sec. Irrespective, the problem occurs.

Whats the problem and is this a known issue with Matlab ?

0 Comments

Chandrakanth

Products

2 Answers

Answer by Chandrakanth on 23 Aug 2012

Strange, not answers yet. Where are the stalwars?

2 Comments

Walter Roberson on 23 Aug 2012

The more active volunteers do not happen to have that toolbox.

Chandrakanth on 15 Jan 2013

No toolbox required. 'serial' function is a part of basic Matlab - at least in R2010a-R2012a.

Chandrakanth
Answer by Jan Simon on 15 Jan 2013

You wrote:

 The problem appears to be with Matlab, as I'm able to reliably log data continuously for hours using Terminal software on the same PC using the same port.

This is not a hard argument: Perhaps the timings are slightly different, when the device communicates with Matlab. If then the device fails due to an uncaught exception, it is not the fault of Matlab, although it happens with Matlab only. Equivalent arguments match, when you have married the "wrong" woman.

0 Comments

Jan Simon

Contact us