Auf einem Mess-PC sollen mit Hilfe einer AD-Wandlerkarte (ADLINK DAQ-2016) Messdaten erfasst (2Kanäle + externer Trigger) und ausgewertet werden. Die Parametrierung, Messung und Datenanalyse soll mit Matlab erfolgen. Auf dem Mess-PC ist jedoch kein Matlab installiert. Die Matlab-Anwendung wird auf einem Entwicklungs-PC realisiert und mit dem Matlab-Compiler als C Shared Libary (dll) übersetzt. Diese dll wird dem Mess-PC zur Verfügung gestellt und dort mittels einer StandAlone Applikation angesteuert. Diese Applikation ist mittels LabWindows/CVI 2010 (National Intruments) generiert worden.
Der ADLINK-Treiber wurde sowohl auf dem Mess-PC als auch auf dem EntwicklungsPC installiert.
Matlab Info vom Entwicklungs-PC: ADLINK_INFO = AdaptorDllName: 'C:\ADLINK\DAQ-MTLB\DLL\mwADLINK.dll', AdaptorDllVersion: '1, 3, 0, 0'
Wird die Matlab Funktion zu einer Standalone Applikation (.exe) übersetzt, läuft diese wie gewünscht auf dem Mess-PC.
Wird die gleiche Matlab-Funktion jedoch als dll übersetzt, so tritt beim Aufruf der dll ein Fehler auf.
Fehler:
Die LabWindows-Applikation tritt ordnungsgemäß in die übersetzte Matlab-dll ein, konfiguriert die ADLINK-Karte und löst m.E. eine Messung aus (Matlab Code Zeile 27 start(ai_device))
Im darauffolgenden try-catch Gebilde springt das Programm in den catch-Pfad (Matlab Code Zeile 37: Timeout) und die Messung bricht ab. In der LabWindows-Applikation gibt die Matlab-Funktion den entsprechenden Rückgabewert aus.
Dieser Fehler tritt immer dann auf, wenn man die Applikation direkt aus der Entwicklungsumgebung (LabWindows) heraus startet. (Compile+Run)
Erzeugt man aus LabWindows eine exe und startet dann diese direkt, so funktioniert die Anwendung ordnungsgemäß.
Die nicht ideale Konstellation Matlab, Adlink und LabWindoes ist leider so vorgegeben.
Wer hat eine ähnliche Anwendung schon einmal zum laufen gebracht? Wäre toll, wenn mir hier jemand weiterhelfen könnte.
Umgebung:
Entwicklungs-PC:
Windows XP Prof. 32Bit SP3.
Matlab R2011a mit MatlabCompiler 4.15 und Data Aquisition Toolbox 2.18
Mess-PC:
Windows XP Prof. 32Bit SP3.
ADLINK DAQ-2016
Development System: National instruments LabWindows/CVI 2010
Code:
Code:
function ret = f_callADlink(N)
ret=0;
retstr= ' ';
N=1000;
SR=1000;
Range=5;
try
ai_device = analoginput('mwadlink', 0);
catch errordlg('no ADC card found!','Error');
ret = -1;
retstr= 'no card found';
end
if ret == 0,
ai_channel0 = addchannel(ai_device, 0);
ai_channel1 = addchannel(ai_device, 1);
try set(ai_device, 'SampleRate', SR);
set(ai_device, 'SamplesPerTrigger', N);
start(ai_device);
catch errordlg('System error or this card not support!','Error');
ret = -2;
retstr= 'card not support';
end end if ret == 0,
try
wait(ai_device, 20);
catch errordlg('Timeout!','Error');
ret = -3;
retstr= 'Timeout';
end end if ret == 0,
data = getdata(ai_device);
else
stop(ai_device);
ret = -4;
retstr= 'Daten nicht abgeholt';
end
Verfasst am: 06.07.2011, 10:35
Titel: Einige Gedanken
Hallo,
Ich kenne mich leider nicht mit der LabWindows Umgebung aus.
Es hört sich aber danach an, als würde das Compile + Run in einer Art Debug Mode ablaufen. Kann es sein, dass LabWindows versucht die Kommunikation mit dem externen Gerät zu überwachen/zu loggen und dadurch ein timeout verursacht? Es funktioniert ja außerhalb der LabWindows Umgebung.
Kann man Einstellungen vornehmen, die den Compile + Run Modus betreffen? Wenn ja welche? Ein Screenshot der Einstellungsmöglichkeiten würde auch helfen. Welche Aussagen gibt es von NI bezüglich des Ablaufs von Compile + Run? Es scheint ja etwas anders zu sein im Gegensatz zum Start außerhalb der LabWindows Umgebung.
ein solches System habe ich leider nicht zum ausprobieren. Ein Tipp, der (vielleicht) helfen könnte: in der kompilierten Anwendung ist nicht immer leicht rauszubekommen, was nun schief gegangen ist.
Hilfreich war mir dabei schon häufiger folgendes Vorgehen: in der catch-Anweisung den Fehler speichern und in MATLAB anschauen, d.h.
Code:
try
wait(ai_device, 20);
catch ME
save('C:\temp\errormsg.mat', 'ME');
errordlg('Timeout!','Error');
ret = -3;
retstr= 'Timeout';
end
und dann in MATLAB nachher einladen. Hier allerdings wird nicht viel zu holen sein, denn dass der Fehler zwei Zeilen höher auftritt, ist ziemlich eindeutig. Vielleicht aber sagt die Fehlermeldung in ME irgendwas, was hilfreich ist ...
Aussagen von NI zum Debug-Ablauf liegen mir (noch) keine vor.
Das Labwindows die AD-Karte überwacht ist eher unwahrscheinlich. Strenggenommen "weis" die LabWindows-Umgebung nichts von der Karte. Die Steuerung übernimmt die Matlab-dll vollständig über das "ai_device"-Objekt.
Den compile/build prozess kann man beeinflussen (siehe Anhang), aber leider kenne ich mich hier zu wenig aus. Eine Idee?
vielen dank für den catch-Tip.
Hat mich auf eine heiße Spur gebracht. Der Timer in wait läuft einfach aus, bevor das ai_device-Objekt "fertig" ist (siehe unten). Offenbar läuft die LabWindows Apllikation im compile+run-Modus wesentlich langsamer als die exe-Version (was ja auch irgendwie einleuchtet, da die Debug-Funktionalität wegfällt). Der Fehler tritt nicht mehr auf, wenn ich die Intialisierung, Start und Auslesen innerhalb der Matlab-Funktion als Statutsmaschine realisiere, die ich über LabWindows steuere. Dazu sind die relevanten Objekte persistent ausgeführt. Im Status 1 wird das ai_device erzeugt, im Status 2 initialisiert, Status 3 startet eine Messung, Startus 4 liest die Daten aus usw.
Warum der Timer in der Compile+Run Version genau zuschlägt, erschließt sich mir noch nicht, aber immerhin habe ich jetzt ein lauffähiges System.
Vielleicht hat ja jemand eine ähnliche Erfahrung gemacht, damit klar wird, was genau hier die Ursache ist?
Code:
% catch message Properties:
identifier: 'daq:wait:timeout'
message: 'WAIT reached its timeout before OBJ stopped running.'
cause: {}
stack: [2x1 struct] : D : D
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
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.
RSS