' schrieb:Ich habe mein Programm jetzt mal soweit fertig, dass es funktioniert.
Habe versucht so viel wie möglich in Sub-Vi´s auszugliedern.
Trotzdem habe ich jetzt irgendwie das Gefühl, dass es schlampig gemacht ist^^
Hat vielleicht jemand Lust mal drüber zu schauen?
Da kann man bestimmt noch einiges von der Struktur verbessern und ich wäre für jeden Denkanstoß sehr dankbar.
Hallo, ich habe die VIs noch nicht im einzelnen betrachtet aber hier schon mal ein paar allgemeine Anregungen.
1) Es ist sinnvoll, um Deinen VIs einen Prefix zu geben (LG200 scheint mir hier durchaus gut geeignet). Die Chance dass Du in einem grösseren Programm plötzlich mehrer Messwerte.vi oder Status.vi bekommst sind einfach zu gross. Da VIs einen globalen Namespace innerhalb eines Projektes haben bekommst Du dann Namenskollisionen. Eine Alternative ist um eine Library davon zu machen die allen VIs innerhalb dieser Library auch so etwas wie einen Prefix mitgibt.
2) mfc71.dll und msvcr71.dll kannst Du nicht einfach mit Deiner Library mitkopieren. Zwar in diesem Fall nicht weil es illegal wäre (sind ja redistributable DLLs und dürfen also mitkopiert werden) sondern weil Windows sie innerhalb des VI Directories schlichtweg nie finden wird. Diese DLLs werden wohl durch Deine LJIF.DLL gebraucht und deshalb hat LabVIEW selber keinen Einfluss darauf von wo sie geladen werden. Bei LJIF.DLL selber kann LabVIEW die DLL selbst noch suchen, und tut das auch unter anderem im Directory wo das VI das diese verwendet steht. Aber die indirekten Abhängigkeiten kann LabVIEW nicht kennen und werden von der DLL direkt angefragt. Dort sucht aber Windows dann nur in:
1. Speicher selber, wenn die DLL schon geladen wurde
2. Application Directory (wo LabVIEW.exe oder Deine built application steht)
3. Windows Directory
4. System Directory
5. alle Directories die in der Path Variablen vorkommen
Da diese DLLs normalerweise auf neueren Windows Systemen ohnehin im Systemverzeichnis anwesend sind geht es gut (werden aber die von Dir mitgekopierten DLLs gar nicht verwendet). Wenn diese DLL aber nicht anwesend sind hilft das Kopieren der DLLs in das VI Directory aus Gründen der obengenannten Suchpfade auch nichts.
3) Datenabhängigkeit: Was Du hier gemacht hast ist eine Kollektion von VIs und die wiederum in andere VIs hineingepflanzt ohne irgendwelche Datenabhängigikeit. Das funktioniert zwar für kleine Demoapplikationen aber ist innerhalb einer richtigen Applikation kaum zu integrieren und noch viel weniger zu managen.
Dein LJ-G Interface.vi ist eine willkürliche Anordung von drei völlig verschiedenen Operationen ohne jede Datenabhängigkeit. Der Aufrufer muss genau wissen dass man das VI erst mit dem connect Boolean = true aufrufen muss bevor man etwas anderes machen kann. Das ist kein intuitiv verwendbares VI.
Schau Dir mal als Anregung die Library an die ich für die Beckhoff Busklemmen
hier gepostet habe. Das gibt Dir eine Idee wie man die Funktionen gestalten kann, um eine saubere Datenflussabhängigkeit durch verbinden des Error Clusters zu bekommen.
Mache aus den verschiedenen DLL Aufrufen jeweils ein SubVI, das einen error in und error out Cluster besitzt.
Das sähe dann so aus dass Du ein
LG200 Connect.vi
LG200 Get Measurement.vi
LG200 Trigger.vi
LG200 Set Auto Zero.vi (Nullen)
LG200 Error Convert.vi (ReportValues aber dann in einen error Cluster)
Die VIs Status.vi und Messwerte.vi machen keinen Sinn innerhalb der Library für so ein Device. Status.vi hat eh nicht viel Sinn da Du normalerweise die Datenaquisition innerhalb Deines Programmes eh intelligenter machen musst als stur in einer Loop immer pollen. Ein Error während des Connects beispielweise ist zwar schön zu sehen in Deinem Hauptprogramm, aber Du wirst di DAQ Loop doch echt so programmieren müssen dass sie einen reconnect versucht, statt danach stur Daten lesen zu wollen.
Ob Du Messwerte.vi verwenden willst innerhalb einer Applikation ist Dir überlassen. Aber bitte entferne die Property Node im Lesen Case. Der verursacht nähmlich höchstens Verwirrung und ist viel langsamer als das direkte Lesen des Shiftregisters. Zudem verwendest Du das Shiftregister gar nicht sondern verwendest das Ausgangsterminal als Zwischenspeicher, was auch noch mögliche Probleme bei Userinteraktionen mit dem Frontpanel geben kann.
Rolf Kalbermatter
/
Problem beim Einbinden einer DLL
