matlab-scriptknoten oder dll?

Hallo Zusammen!

ich programmiere ein größeres Programm zur Scanmirkoskopsteuerung. Es werden also daten aufgenommen und verwertet. Gerade versuche ich die Performance etwas zu verbessern, da ich über 6Mdatenpunkte(U16) Memory-Probleme bekomme.
Die Grobstruktur läuft folgendermaßen: ich initialisiere einen Array entsprechend der Aufnahmeparameter, lese innerhalb einer Schleife die neu dazu gekommenen Werte aus, schreibe diese in den Array und zeige jeweils das aktuelle Bild an.

Da ich fünfdimensional aufnehme (x,y,z,zeit,unterschiedliche Farben) wird die initialisierung mir zu unübersichtlich in Labview, und daher mache ich das mit Matlab. Ich rufe einen Matlab-Skriptknoten auf, von dem aus ein .m file aufgerufen wird, das mir einen Array erstellt, den ich aus dem Knoten auslese. Meine Daten sind U16, der Scriptknoten verwendet Double. Das braucht sicher einiges an Konvertierung. Außerdem benötige ich Speicher in LV für die Daten und redundant dazu auch in Matlab.
Nun war meine Idee, aus dem Matlab-code eine dll zu machen und die einzubinden. Hat da jemand erfahrung? geht das gut?

Und außerdem: kann man den LV zur verfügung stehenden Speicher erweitern?

LV version 2009
danke, viele Grüße H

Anzeige

Hallo H,

Zitat:Da ich fünfdimensional aufnehme (x,y,z,zeit,unterschiedliche Farben) wird die initialisierung mir zu unübersichtlich in Labview,

Ähem:
   
Unübersichtlich?

(28.07.2011 10:59 )GerdW schrieb:  Unübersichtlich?

das unübersichtliche ist ehrlich gesagt sogar nur 2dimensional - der ansteuerungsarray für die positionierung, der von vielen parametern abhängt.

Hallo Hep,

Zitat:der ansteuerungsarray für die positionierung, der von vielen parametern abhängt.

Wie wäre es mit einem 1D-Array of (typedef'd) Cluster?

(28.07.2011 11:47 )GerdW schrieb:  (typedef'd)

Hallo Gerd,
wie meinst du das? Bzw was heißt denn das? kenn ich gar nicht..

H

Hallo Hep,

du kannst eigene Datentypen per Typdefinition festlegen - bewährt haben sich Cluster mit benannten Elementen...

Schön, dass es die Kontext-/Onlinehilfe gibt...

Anzeige

(28.07.2011 10:41 )Hep schrieb:  Da ich fünfdimensional aufnehme (x,y,z,zeit,unterschiedliche Farben) wird die initialisierung mir zu unübersichtlich in Labview, und daher mache ich das mit Matlab. Ich rufe einen Matlab-Skriptknoten auf, von dem aus ein .m file aufgerufen wird, das mir einen Array erstellt, den ich aus dem Knoten auslese. Meine Daten sind U16, der Scriptknoten verwendet Double. Das braucht sicher einiges an Konvertierung. Außerdem benötige ich Speicher in LV für die Daten und redundant dazu auch in Matlab.
Nun war meine Idee, aus dem Matlab-code eine dll zu machen und die einzubinden. Hat da jemand erfahrung? geht das gut?

Die Matlab DLL wird an Deinem Performance Problem kaum etwas ändern. Der Transfer mit Datenkonvertierung wird im wesentlichen bestehen bleiben. Dein Problem ist ein typisches: will man während der Entwicklung Zeit und Gehirnschmalz sparen kostet das später jedesmal Zeit und Performance bei jedem Run. Wenn man sich dagegen hinsetzt und einmal genau darüber nachdenkt was wie getan werden muss, kann man mit etwas "trial and error" auch 5-dimensionale Arrays bändigen. Das geth in LaVIEW selbst sehr einfach da Du da ja auch nicht jedesmal crasht wenn etwas nicht stimmt. In C oder mit DLLs kann ein Byte zu wenig schon genug sein und Du darfst die Applikation wieder neu starten. Man macht sich diese Mühe einmal und hat dann eine Applikation die auch schnell läuft.

Zitat:Und außerdem: kann man den LV zur verfügung stehenden Speicher erweitern?

LabVIEW kann soviel Speicher benützen wie Windows per Applikation zur Verfügung stellt. Unter Windows 32 bit ist das 4GB von dem die Hälfte für Windows reserviert ist. Mit einem switch in boot.ini kann der verfügbare Speicher per App auf 3GB erhöht werden. Natürlich sollte die Maschine dann auch 4GB verfügbaren Speicher haben (eventuellen shared Video Speicher kann da ziemlich negativ reinschlagen) anders macht der 3GB Switch die Dinge nur noch schlimmer.
Unter 64 Bit Windows mit 64 Bit LabVIEW hast Du per Applikation erst mal beinahe soviel Speicher verfügbar wie die Maschine an physikalischem Memory zur Verfügung hat.

(29.07.2011 07:09 )rolfk schrieb:  Dein Problem ist ein typisches: will man während der Entwicklung Zeit und Gehirnschmalz sparen kostet das später jedesmal Zeit und Performance bei jedem Run.

na gut, dann investier ich mal Gehirnschmalz
Wie ist denn das, wenn ich zu test/alignment/überwachungszwecken in einer case struktur ein matlabskript aufrufe - dann sollte das meine Performance doch im normalbetrieb, wenn er also einen anderen case abarbeitet, nicht beeinträchtigen?

Danke für die hilfreiche Antwort!

Hallo

Poste doch mal ein VI oder Bild, dann sieht man was Du meinst.

Gruss, BDB

(29.07.2011 10:05 )Hep schrieb:  

(29.07.2011 07:09 )rolfk schrieb:  Dein Problem ist ein typisches: will man während der Entwicklung Zeit und Gehirnschmalz sparen kostet das später jedesmal Zeit und Performance bei jedem Run.

na gut, dann investier ich mal Gehirnschmalz
Wie ist denn das, wenn ich zu test/alignment/überwachungszwecken in einer case struktur ein matlabskript aufrufe - dann sollte das meine Performance doch im normalbetrieb, wenn er also einen anderen case abarbeitet, nicht beeinträchtigen?

Danke für die hilfreiche Antwort!

Da könnte einmalig ein wenig Zeit anfallen beim Laden des VIs, aber zur Laufzeit sollte das tatsächlich keinen merkbaren Unterschied machen. Die Idee ist sogar sehr gut. Zum debuggen kannst Du schnell mal zwischen dem (hoffentlich als korrekt getestetem) Matlabskript und Deiner LabVIEW Implementation hin und herschalten. Wenn's denn korrekt läuft lässt Du die LabVIEW Variante aktiviert.