A Simple PID with GUI using xPC-Target/Matlab, UDP and GUIDE A Tutorial Carl Wilhelmsson 31 january 2007

1

Introduction

This work is carried out as an course “project” by the author. The aim of the project is of course not to supply the world with the greatest PID controller of all times, but to give the author understanding about advanced Matlab/xPC Target design. Things like Matlab Events, Matlab UDP and TCP/IP communication, development of Matlab Graphical User Interfaces (GUI) and design in the Matlab/Simulink rapid prototype environment “xPC-Target” were carried out in order to get the system working. Through this an understanding of the limitations with the environment are gained for the author and hopefully this will be shared with this document. Even tough the logics residing in the system for now is of rudimentary nature, the design of complex systems are imminent for the author, and this small project serves as a stepping stone for more complex control designs.

2

The Environment

The setup consists of two PC computers, one “normal” desktop computer with the 2006b installation of Matlab on it, the version of Matlab available to the author are fully equipped with all toolboxes. The other computer is a low performance one with an “National Instruments” PCI6024E data acquisition/counter card mounted (NIADC). The computer with the National Instruments card mounted (xPC) are booted with the Matlab xPC target operating system from a floppy disk and are hence free of hi-quality Microsoft products. The Matlab OS offers an true real-time operating system, and control schemes developed in Simulink can be run upon the xPC after building them with the Matlab toolbox “Real Time Workshop” (RTW). Once the Simulink diagram has been built using RTW it is downloadable and runnable on the xPC! No low-level software development are hence needed in order to get the xPC to run with new control logics. The communication between the xPC and the “normal” PC are completely carried out through UDP both for exchanging runtime data, and for re-configuring the xPC. Both computers are connected on the normal network, and the normal firewall are enabled on the desktop PC, the xPC however needs a fix IP address. As a desktop control experiment an passive low pass filter is used, as commonly 1

known such a filter can be used as a “feedback controlled” voltage source. Load disturbance are modulated through the change of the resistance of the circuit. It is hence possible to develop and test a PID controller controlling the voltage over the low pass filter. The measurement signal (the filter voltage) for the controller are connected to the input of the ADC of the NI card. The output affecting the voltage over the lowpass filter (the actuator of the controller) are PWM counter 0.

3

Functional description

The xPC were running the logics which is shown in figure 1. Every 0.001 second the system acquired a sample from the NIADC, this sample were feed both to the PID controller and to an “xPC target scope” which visualizes data on the screen of the xPC. The sample from the NIADC were down sample to 10Hz using a zero order hold circuit and were depending on the settings in the GUI either sent sample by sample or buffed in a 92 sample buffer. Which signal “slice” that were buffered was depending on the trigger level set in the GUI, the trigger level are referring to an voltage level of the NIADC input, this sampling method can be used to “capture” step response experiments. If the “sliding” sampling mode were selected in the GUI one datagram was sent every 0.1 s containing the latest down sampled samples of both the input and the output of the PID, the aware reader notices that the input to the PID corresponds to the output of the NIADC. Due to the limitations regarding dynamic scaling of signals in Simulink the two samples that were sent in each datagram in the sliding mode had to be padded with 2*91 doubles. A very simple protocol indicating the contents of the datagram for the receiver were included in the padding, the absence of certain values in certain positions of the datagram indicates that it was the complete content of the 2*92 sample buffers instead of single sample datagrams. By now the aware reader has noticed that the communication protocol were a “push” protocol meaning that the xPC forces the UDP datagrams to be sent regardless of the receiver, the benefit with this was that the xPC is completely independent of the normal PC running the GUI for its operation. The PC running the GUI were capable of signaling certain variables, such as control settings and PID settings to the xPC in order to affect the control process. The protocol in this direction was again rudimentary consisting of a number of doubles (9 to be precise) and the different settings of the control scheme in the xPC were hence controllable from the GUI. The xPC polls incoming UDP channel every second, and decodes the received data with the help of special xPC-target UDP blocks for Simulink.

4

Graphical User Interface, Matlab, GUIDE

The development of the user interface was carried out in the Matlab built-in tool for GUIs called GUIDE. GUIDE is easy to use and further explanation is found in the help of GUIDE, the only thing noticeable is the strong recommendation from the author NOT to use the command “plotyy” in combination with GUIs developed in GUIDE.

2

Target Scope Id: 2 PCI-6024E National Instr. Analog Input

Scope (xPC) 1

y

PCI-6024E AD

Controller on, Manual

u

In1

Out1

0

Analoge 2 PWM

Uc, K, Ti, Td, Tt

PCI-6024E National Instr. Pulse Gen.

PCI-6024E PWM Generate

PID

Target Scope Id: 1 Scope (xPC) 1

y Send data

u

Pack

UDP Send Binary

Pack1

Send

Control signal

Sampler

Selector Target Scope Id: 3 Scope (xPC) 2

UDP Receive Binary

Unpack

Receive

Unpack

Figure 1: The logics compiled by RTW and receding in xPC.

The numerical edits in the GUI is left out of the explanation since the only thing the callback for the edits did were to store away the content of the edit in a vector for later access. The interesting parts in the drive of the GUI were the three buttons “connect”, “disconnect” and “send” in combination with the axis used to plot data. The visualisation of data were event driven, meaning that when a datagram containing data arrived to the PC a Matlab event were generated. A special function “RecieveDatagram.m” were during connection opening assigned to take care of incoming events, this function plotted the received data in the correct way in the axis of the GUI. The receive function distinguishes between the two different types of datagrams depending on the content of them. When the “connect” button was pushed a new UDP connection were started and the “RecieveDatagram.m” function were assigned as the “datagram received function”, some additional parameters were also set. In the corresponding way when pushing the “disconnect” button the connection was closed, the file identifier were however not deleted. Please note that if the “disconnect” button were not pressed before ending the GUI Matlab has to be restarted in order to release the port selected for the communication. The “send” button simply did send the content of the settings vector to the xPC, it is noticeable that is was possible to in a calm manner adjust as many parameters as needed before pressing “send” all adjustments arrived at the xPC simultaneously.

3

Figure 2: A screen dump showing the GUI during a voltage step between 1V and 4V.

4

5

Limitations and drawbacks

There are of course some limitations to note, both regarding the xPC-target/Simulink environment and to express it mildly, the tutorial PID are not flawless either (not spoken more of). One large limitation was the fact that it is not possible to have dynamic signal lengths in Simulink, this may sound like a minor issue, but when for example trying to send datagrams with variable length it was a real limitation especially in combination with the fact that it is impossible to have two “UDP send” blocks on the same connection (meaning same IP and port). It is hence impossible to send datagrams with variable length on the same port. Speaking of UDP send it is also impossible to send arbitrary long datagrams (there is a upper maximal datagram length limit which is not specified in the help), these limitations all together makes it in reality impossible to cope with only one connection for complex systems, however a cosmetic issue! One more severe issue is that it is impossible to access the “workspace” from an xPC-Target diagram, it is neither possible to implement functions in Simulink using a “normal” m-file, in the same mammer for example the Simulink block “Fcn” can not be used. As far as the author understands one has to use level 2 m-files (S-functions) in order to carry out the same tasks as the “normal” m-functions or “built in Matlab function” blocks can handle. Never the less xPC-Target, GUIDE and Simulink was shown to be great tools with very high flexibility!

6

Operational instructions 1. Set up the system, see code listing and system description! 2. Create new directory and extract xPCPIDTut.zip, you now have four files in the directory 3. Write ControllerCom.m in the Matlab prompt, xPC logic are compiled, downloaded and started on the xPC 4. Press the connect button in the GUI

7

Software Listing

The look of the Simulink diagram “XPClogic10.mdl” are apparent from figure 1 and the look of the figure composing the GUI are seen in figure 2. Here is hence listed the two files running in the PC (NOT in the xPC) “RecieveDatagram.m” which handles the data when an UDP datagram arrives (the function are invoked by the “RecieveDatagram.m” Matlab event) and the callback function handling the GUI, “ControllerCom.m”.

7.1

ControllerCom.m

function varargout = ControllerCom(varargin)

5

% CONTROLLERCOM M-file for ControllerCom.fig % CONTROLLERCOM, by itself, creates a new CONTROLLERCOM or raises the existing % singleton*. % % H = CONTROLLERCOM returns the handle to a new CONTROLLERCOM or the handle to % the existing singleton*. % % CONTROLLERCOM(’CALLBACK’,hObject,eventData,handles,...) calls the local % function named CALLBACK in CONTROLLERCOM.M with the given input arguments. % % CONTROLLERCOM(’Property’,’Value’,...) creates a new CONTROLLERCOM or raises the % existing singleton*. Starting from the left, property value pairs are % applied to the GUI before ControllerCom_OpeningFunction gets called. An % unrecognized property name or invalid value makes property application % stop. All inputs are passed to ControllerCom_OpeningFcn via varargin. % % *See GUI Options on GUIDE’s Tools menu. Choose "GUI allows only one % instance to run (singleton)". % % See also: GUIDE, GUIDATA, GUIHANDLES % Edit the above text to modify the response to help ControllerCom % Last Modified by GUIDE v2.5 31-Jan-2007 10:32:06 % Begin initialization code - DO NOT EDIT gui_Singleton = 1; gui_State = struct(’gui_Name’, mfilename, ... ’gui_Singleton’, gui_Singleton, ... ’gui_OpeningFcn’, @ControllerCom_OpeningFcn, ... ’gui_OutputFcn’, @ControllerCom_OutputFcn, ... ’gui_LayoutFcn’, [] , ... ’gui_Callback’, []); if nargin && ischar(varargin{1}) gui_State.gui_Callback = str2func(varargin{1}); end if nargout [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:}); else gui_mainfcn(gui_State, varargin{:}); end % End initialization code - DO NOT EDIT % --- Executes just before ControllerCom is made visible. function ControllerCom_OpeningFcn(hObject, eventdata, handles, varargin) % This function has no output args, see OutputFcn. % hObject handle to figure % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % varargin command line arguments to ControllerCom (see VARARGIN) % Choose default command line output for ControllerCom handles.output = hObject;

6

% Update handles structure guidata(hObject, handles); %Global declarations global theSt; global comstr; global IP; global port; global u; %Default values comstr = [1.0 0.0 2.5 10 1000000 1.0 1000000 1.0 1.0]; IP = ’130.235.81.151’; port = 6666; disp(’Please wait...’); rtwbuild(’XPClogic10’) tg = xpctarget.xpc; +tg; % UIWAIT makes ControllerCom wait for user response (see UIRESUME) % uiwait(handles.figure1); % --- Outputs from this function are returned to the command line. function varargout = ControllerCom_OutputFcn(hObject, eventdata, handles) % varargout cell array for returning output args (see VARARGOUT); % hObject handle to figure % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Get default command line output from handles structure varargout{1} = handles.output; function edit1_Callback(hObject, eventdata, handles) % hObject handle to edit1 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit1 as text % str2double(get(hObject,’String’)) returns contents of edit1 as a double global comstr; comstr(4) = str2num(get(hObject,’String’)); % --- Executes during object creation, after setting all properties. function edit1_CreateFcn(hObject, eventdata, handles) % hObject handle to edit1 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER.

7

if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end function edit2_Callback(hObject, eventdata, handles) % hObject handle to edit2 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit2 as text % str2double(get(hObject,’String’)) returns contents of edit2 as a double global comstr; comstr(5) = str2num(get(hObject,’String’)); % --- Executes during object creation, after setting all properties. function edit2_CreateFcn(hObject, eventdata, handles) % hObject handle to edit2 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end function edit3_Callback(hObject, eventdata, handles) % hObject handle to edit3 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit3 as text % str2double(get(hObject,’String’)) returns contents of edit3 as a double global comstr; comstr(6) = str2num(get(hObject,’String’)); % --- Executes during object creation, after setting all properties. function edit3_CreateFcn(hObject, eventdata, handles) % hObject handle to edit3 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end function edit4_Callback(hObject, eventdata, handles) % hObject handle to edit4 (see GCBO)

8

% eventdata % handles

reserved - to be defined in a future version of MATLAB structure with handles and user data (see GUIDATA)

% Hints: get(hObject,’String’) returns contents of edit4 as text % str2double(get(hObject,’String’)) returns contents of edit4 as a double global comstr; comstr(7) = str2num(get(hObject,’String’)); % --- Executes during object creation, after setting all properties. function edit4_CreateFcn(hObject, eventdata, handles) % hObject handle to edit4 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end function edit6_Callback(hObject, eventdata, handles) % hObject handle to edit6 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit6 as text % str2double(get(hObject,’String’)) returns contents of edit6 as a double global comstr; comstr(3) = str2num(get(hObject,’String’)); % --- Executes during object creation, after setting all properties. function edit6_CreateFcn(hObject, eventdata, handles) % hObject handle to edit6 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end % --- Executes on button press in checkbox1. function checkbox1_Callback(hObject, eventdata, handles) % hObject handle to checkbox1 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hint: get(hObject,’Value’) returns toggle state of checkbox1

9

global comstr; if get(hObject,’Value’) comstr(1) = 2; %set(handles.edit8,’BackgroundColor’, [0.7529 0.7529 0.7529]); set(handles.edit28,’Visible’,’Off’) set(handles.edit8,’Visible’,’On’) else comstr(1) = 1; %set(handles.edit8,’BackgroundColor’, [1 1 1]); set(handles.edit8,’Visible’,’Off’) set(handles.edit28,’Visible’,’On’) end % --- Executes on button press in pushbutton1. function pushbutton1_Callback(hObject, eventdata, handles) % hObject handle to pushbutton1 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) global comstr; global u; %fwrite(u,uint8(comstr(1)),’uint8’) %fwrite(u,swapbytes(double(comstr(2:6))),’double’) fwrite(u,double(swapbytes(comstr)),’double’); function edit8_Callback(hObject, eventdata, handles) % hObject handle to edit8 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit8 as text % str2double(get(hObject,’String’)) returns contents of edit8 as a double global comstr comstr(2) = str2double(get(hObject,’String’));

% --- Executes during object creation, after setting all properties. function edit8_CreateFcn(hObject, eventdata, handles) % hObject handle to edit8 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end

10

function edit9_Callback(hObject, eventdata, handles) % hObject handle to edit9 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit9 as text % str2double(get(hObject,’String’)) returns contents of edit9 as a double

% --- Executes during object creation, after setting all properties. function edit9_CreateFcn(hObject, eventdata, handles) % hObject handle to edit9 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end function edit11_Callback(hObject, eventdata, handles) % hObject handle to edit11 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit11 as text % str2double(get(hObject,’String’)) returns contents of edit11 as a double global port; port = str2num(get(hObject,’String’)); % --- Executes during object creation, after setting all properties. function edit11_CreateFcn(hObject, eventdata, handles) % hObject handle to edit11 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end global port; port = get(hObject,’String’); function edit12_Callback(hObject, eventdata, handles) % hObject handle to edit12 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

11

% Hints: get(hObject,’String’) returns contents of edit12 as text % str2double(get(hObject,’String’)) returns contents of edit12 as a double global IP; IP = get(hObject,’String’); % --- Executes during object creation, after setting all properties. function edit12_CreateFcn(hObject, eventdata, handles) % hObject handle to edit12 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end global IP; IP = get(hObject,’String’); % --- Executes on button press in pushbutton2. function pushbutton2_Callback(hObject, eventdata, handles) % hObject handle to pushbutton2 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) global global global global global global

u IP port comstr hand data

if ~strcmp(get(u,’Status’),’open’) data.y = ones(92,1); data.u = ones(92,1); nbrRec = 0; u = udp(IP,port); hand = handles; u.DatagramReceivedFcn = @ReciveDatagram; u.LocalPort = port; u.InputBufferSize = 6400; fopen(u);

12

fwrite(u,double(swapbytes(comstr)),’double’); end % --- Executes on button press in pushbutton3. function pushbutton3_Callback(hObject, eventdata, handles) % hObject handle to pushbutton3 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) global u if strcmp(get(u,’Status’),’open’) fclose(u) end

% --- Executes on button press in checkbox2. function checkbox2_Callback(hObject, eventdata, handles) % hObject handle to checkbox2 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hint: get(hObject,’Value’) returns toggle state of checkbox2 global comstr; set(handles.checkbox3,’Value’,0.0) comstr(8) = 1.0; % --- Executes on button press in checkbox3. function checkbox3_Callback(hObject, eventdata, handles) % hObject handle to checkbox3 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hint: get(hObject,’Value’) returns toggle state of checkbox3 global comstr set(handles.checkbox2,’Value’,0.0) comstr(8) = 2.0;

function edit27_Callback(hObject, eventdata, handles) % hObject handle to edit27 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit27 as text % str2double(get(hObject,’String’)) returns contents of edit27 as a double

13

global comstr comstr(9) = str2double(get(hObject,’String’));

% --- Executes during object creation, after setting all properties. function edit27_CreateFcn(hObject, eventdata, handles) % hObject handle to edit27 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end

function edit28_Callback(hObject, eventdata, handles) % hObject handle to edit28 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: get(hObject,’String’) returns contents of edit28 as text % str2double(get(hObject,’String’)) returns contents of edit28 as a double global comstr comstr(2) = str2double(get(hObject,’String’)); % --- Executes during object creation, after setting all properties. function edit28_CreateFcn(hObject, eventdata, handles) % hObject handle to edit28 (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,’BackgroundColor’), get(0,’defaultUicontrolBackgroundColor’)) set(hObject,’BackgroundColor’,’white’); end

7.2

RecieveDatagram.m

function reciveDatagram(obj, event) %****************First part from "instrcallback" func incl skeletorn in Mlab**************

14

%-------------------------Error handling------------------------% Define error message. error1 = ’Type ’’help instrument\instrcallback’’ for an example using INSTRCALLBACK.’; error1Id = ’MATLAB:instrument:instrcallback:invalidSyntax’; switch nargin case 0 error(error1Id, sprintf([’This function may not be called with 0 inputs.\n’,... ’Type ’’help instrument\instrcallback’’ for an example using INSTRCALLBACK.’])); case 1 error(error1Id, error1); case 2 if ~isa(obj, ’instrument’) || ~isa(event, ’struct’) error(error1Id, error1); end if ~(isfield(event, ’Type’) && isfield(event, ’Data’)) error(error1Id, error1); end end % Determine the type of event. EventType = event.Type; % Display the error string. if strcmp(lower(EventType), ’error’) fprintf([EventData.Message ’\n’]); end %**************Application specific part!******************* %-------------------------Receve data------------------------global data global hand nbrBytes = get(obj,’BytesAvailable’); dat = fread(obj,nbrBytes./8,’double’); dat = swapbytes(dat); %First double in datagram == 1 AND sum absulute value of the 89 folowing %doubles == 0 AND last double are -1 decodes sliding window sampling if dat(1) == 1 && sum(abs(dat(3:91))) == 0 && dat(92) == -1 data.y = [data.y(2:end) ; dat(2)]; data.u = [data.u(2:end) ; dat(93)]; set(hand.edit9,’String’,num2str(dat(2))); set(hand.edit8,’String’,num2str(dat(93))); else %Otherwise triggered 92 sample window! data.y = dat(1:92); data.u = dat(93:184); set(hand.edit9,’String’,num2str(mean(dat(1:92)))); set(hand.edit8,’String’,num2str(mean(dat(93:184)))); end

15

%-------------------------Plot the data------------------------plot(hand.axes1,1:92,data.y); set(hand.axes1,’XMinorTick’,’on’); set(hand.axes1,’YMinorTick’,’on’); set(hand.axes1,’XGrid’,’on’); set(hand.axes1,’YGrid’,’on’); set(hand.axes1,’Ylim’,[0 5]); plot(hand.axes2,1:92,data.u,’r’); set(hand.axes2,’XMinorTick’,’on’); set(hand.axes2,’YMinorTick’,’on’); set(hand.axes2,’XGrid’,’on’); set(hand.axes2,’YGrid’,’on’); set(hand.axes2,’Ylim’,[-1000 1000]);

16