TimerFcn und StopFcn verstehen

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

RoMalle

Forum-Newbie


	Beiträge: 3

	Anmeldedatum: 14.11.16

	Wohnort: ---

	Version: ---

Verfasst am: 29.11.2016, 10:34 Titel: TimerFcn und StopFcn verstehen

Guten Morgen zusammen.

Ich habe einige Fragen zur Funktionsweise von Timern in MatLab. Doch vorab zu meinem Problem. Ich möchte über MatLab eine Kommunikation zu einem Empfänger aufbauen, die über eine UART-Schnittstelle abläuft. Für jede gesendete Nachricht aus MatLab soll ein Timer starten, während dessen MatLab auf eine Quittierung des Empfänger warten soll. Trifft die Quittierung noch vor Ende des Zeitintervalls ein, soll der Timer ausgeschaltet werden. Nachfolgend die Codeschnipsel aus meinem Protokoll:

Code:

function Current_Source_Control_GUI_OpeningFcn(hObject, eventdata, handles, varargin)

handles.output = hObject;

guidata(hObject, handles);

handles.timer_init_response = timer('Name','timer_init_response', ...
'Period',1.0, ...
'TasksToExecute',10, ...
'ExecutionMode','fixedRate', ...
'BusyMode', 'queue', ...
'TimerFcn',@Init_response_TimerFcn, ...
'StopFcn', @Init_response_StopFcn);

function connect_COM_Port_Callback(hObject, eventdata, handles)
% hObject handle to connect_COM_Port (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles structure with handles and user data (see GUIDATA)

global serialPort;
global USB_COM_Port;
global connect_COM_Port;
global Status;
global timer_init_response_enable_serialPort_close;

set(handles.static_USB_COM, 'String', get(USB_COM_Port, 'String'));

instrfind()
if ~isempty(instrfind)
fclose(instrfind)
end

%------------------------ Erzeuge USB-Serial Port ------------------------%
if(isempty(serialPort))
try
serialPort = serial(get(USB_COM_Port, 'String'), 'BaudRate', 9600);
serialPort.Parity = 'none';
serialPort.Databits = 8;
serialPort.StopBits = 1;
serialPort.BytesAvailableFcnMode = 'byte';
serialPort.BytesAvailableFcnCount = 1;
serialPort.BytesAvailableFcn = @incomingMessage
%disp('Serialobjekt erzeugt');
if(~isempty(serialPort))
try
fopen(serialPort);
boxhandle=msgbox(['Verbindung hergestellt.']);
waitfor(boxhandle);
disp('Verbindung hergestellt');
set(connect_COM_Port, 'string', 'Verbindung beenden');
get(serialPort,{'Name', 'Status', 'Port'});
fwrite(serialPort, ['I'], 'uchar');

timer_init_response_enable_serialPort_close = 'true';
start(handles.timer_init_response);

catch exc
boxhandle=msgbox(['Objekt serialPort is leer. ' exc.identifier ';' exc.message]);
waitfor(boxhandle);
% set(connect_COM_Port, 'string', 'Verbindung hergestellt');
end
end
|
|
.
.
.

function incomingMessage(hObject, eventdata, handles)

global Status;
global serialPort;
global timer_init_response_enable_serialPort_close;

number_of_bytes = serialPort.bytesavailable;

if(number_of_bytes ~= 0)
incomingMessage = char(fread(serialPort, number_of_bytes, 'uchar'));
state = char(transpose(incomingMessage))

switch state
case 'CIR' % Anfrage des Nios ii Prozessors nach einem Init Signal.
fwrite(serialPort, ['I'], 'uchar');
timer_init_response_enable_serialPort_close = 'true';
start(handles.timer_init_response);
set(Status, 'string', 'Initialisierung der Nios ii Uart-Register');
state = [];

case 'RID' % Nios ii Prozessor initialisiert und im Empfangsmodus.
set(Status, 'string', 'Sendebereit');
state = [];
timer_init_response_enable_serialPort_close = 'false';
stop(handles.timer_init_response);
%delete(handles.timer_init_response);

otherwise disp('Kein zutreffender Case-Fall eingetrofen.')
state = [];
end
end

function Init_response_TimerFcn(hObject, eventdata, handles)

global try_counter_init_response;

try_counter_init_response = try_counter_init_response + 1

% if(try_counter_init_response == 5)
% timer_init_response_enable_serialPort_close = 'false'
% stop(handles.timer_init_response);
% end

function Init_response_StopFcn(hObject, eventdata, handles)

% global serialPort;
global Status;
global timer_init_response_enable_serialPort_close;
global try_counter_init_response;

enable = timer_init_response_enable_serialPort_close;

switch enable
case 'false'
disp('timer_init_response gestoppt.')
try_counter_init_response = 0;

case 'true'
try_counter_init_response = 0;
%serialPort=[];
%fclose(serialPort);
%delete(serialPort);
%clear(serialPort);
set(Status, 'string', 'UART-Verbindung getrennt.');
boxhandle=msgbox({'Es ist eine Zeitüberschreitung während der Initialisierungsphase aufgetretten. Bitte beenden Sie die GUI, schalten Sie die Hardware erneut ein und starten Sie daraufhin erneut die GUI. Stellen Sie zum Schluss eine neue UART-Verbindung her!'});
waitfor(boxhandle);
end

Funktion ohne Link?

Nun wenn ich das Programm ausführe geschieht folgendes. MatLab sendet das notwendige Wort aus und erhält darauf hin auch die entsprechende Quittierung. Jedoch wird der Timer nicht gestopt, sondern die TimerFcn führt sich heiter weiter aus und ich kriege folgende Warnung:" Warning: The BytesAvailableFcn is being disabled. To enable the callback property
either connect to the hardware with FOPEN or set the BytesAvailableFcn property.".
Nun zu meinen Fragen. Kann es sein, dass ein aktiver Timer alle anderen Funktionen und Callbacks blockiert? Wenn ja, wie kann ich mit MatLab eine Zeitüberwachung auf eine Quittierung realisieren, damit MatLab nicht ewig auf eine Quittierung warten muss?

Ich danke euch schon einmal für eure Anregungen.

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 29.11.2016, 13:57 Titel: Re: TimerFcn und StopFcn verstehen

Hallo RoMalle,

Und wieso wird der Timer nicht gestoppt? Mit dem debugger solltest Du das heraus finden können: Setze einen Breakpoint in die Zeile, die den Timer stoppt und überprüfe, warum das nicht erfolgreich funktioniert.

Die Logik Deines Codes nachzuvollziehen ist nicht einfach, weil die häßlichen globalen Variablen das unnötig erschweren. Code mit globals ist grundsätzlich in Debugbarkeit und Wartbarkeit deutlich eingeschränkt und wie in jeder Programmiersprache ist es eine gute Praktik darauf zu verzichten. Daten statt dessen in den handles zu speichern, den User- oder ApplicationData von GUI-Elementen, oder als PERSISTENT Variablen in einer eigenen Funktion ist deutlich besser, weil dann nachzuvollziehen ist, aus welchem Programmteil die Daten geändert werden.

Wenn ein TimerCallback auf globale Variablen zugreift, kann das geschehen, während ein GUI-Callback ausgeführt wird. Das ist richtig tückisch.

Gruß, Jan


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2025 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.