Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
02.12.2008, 15:52 (Dieser Beitrag wurde zuletzt bearbeitet: 02.12.2008 16:15 von schaaff.)
gleich vorab muss ich gestehen, dass ich nicht aus der Programmiererecke komme und mich seit 2 Jahren aber doch rel. intensiv mit LabVIEW beschäftige.
Momentan binde ich eine DLL eines Abstandsmessgerät-Controllers ein.
Ich erhalte immer wieder dubioseste Fehler. Ich hatte schon fast Programme am Laufen und nach einem DLL-Update seitens des Herstellers mit welchem ich ebenfalls engen Kontakt habe, funktionieren plötzlich Funktionen, die sich nicht verändert habe sollen, nach dem DLL-Update.
Jetzt ist es zu folgendem Effekt gekommen. Ich bekam aus der DLL den Rückgabewert:
-10 (ERR_INTERFACE_NOT_SUPPORTED): Com1
Darauf hin sagte der Mitarbeiter der DLL-liefernden Firma:
Sie haben als Interface Com1 angegeben und nicht RS232. Sie müssen IP_Interface=RS232 und IP_Port=Com1 setzen. Nach mehrmaligen hitzigen Diskussionen sagte ich ihm, dass ich alles korrekt setze und auch mache.
Ich habe mit dem Highlightmodus im Untervi SetParameterString, mit welchem beide Parameter gesetzt werden dann ganz genau nachgeschaut. Jetzt - ich konnte es kaum glauben - wurden die richtigen Parameter gesetzt und der anschließende OpenSensor-Command funktionierte.
Ich verstehe das nicht. Es ist auch Immer wieder nachstellbar. LV aus. VI öffnen, starten -> Errorcode (-10) s.o. -> SubVI SetParameterString auf Highlight ->klappt und ich lande beim nächsten Fehler
-8 (ERR_TIMEOUT_READING_FROM_SENSOR): Waiting for ''
der auch bestimmt aus unstimmigen SetParameterInt aufrufen folgte.
Meine Frage, kann es sein, dass LV nicht die Subvi's in der richtigen Reihenfolge aufruft oder nicht wartet bis es weitergeht ?
Hat evtl. das Enumfeld im SubVI immer noch den alten Wert und wird in Echtzeit nicht überschrieben ?
ich sitze seit mehreren Tagen an völlig willkürlichen Fehlern und flehe um Hilfe :-)
Martin
Anbei sind Bilder der VI-Struktur im Highlight-Modus:
in OpenSensorParams sieht man sehr schön die Nacheinanderaufrufung der verschieden Parametersätze.
in SetParameterString ist dann der eigtl DLL-Aufruf mit dem Text aus dem Enum.
' schrieb:Ich hatte schon fast Programme am Laufen und nach einem DLL-Update seitens des Herstellers mit welchem ich ebenfalls engen Kontakt habe, funktionieren plötzlich Funktionen, die sich nicht verändert habe sollen, nach dem DLL-Update.
Kann ich nachvollziehen.
Zitat:kann es sein, dass LV nicht die Subvi's in der richtigen Reihenfolge aufruft
Nein, das kann nicht sein. LV ruft die VIs immer in der Reihenfolge auf, die du vorgibst.
Zitat:oder nicht wartet bis es weitergeht ?
Da alles per Datenfluss verbunden ist, muss auch dieser Aspekt stimmen.
Was anderes ist es, wenn die DLL intern asynchrone Abläufe macht. Die müssen natürlich entsprechend, möglichweise durch Wartezeiten zwischen den DLL-Aufrufen, synchronisiert werden. Normalerweise würde sowas aber über einen Status feststellbar sein.
Zitat:Hat evtl. das Enumfeld im SubVI immer noch den alten Wert und wird in Echtzeit nicht überschrieben ?
Solche Fälle gibt es nicht.
Zweite Frage: Ist denn die DLL - naja zumindest nach Aussage des Herstellers - für LV geeignet?
Dritte Frage: Kannst du nicht mal ein SubVI posten und die DLL dazu?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Danke, dass du dich meiner annimmst.
Leider stimmt das mit der LV6.1. Das ist auch der Grund warum ich heut den Controller mit nach Hause nehmen durfte, da meine Mitbewohnerin auch zum LV-Knecht in ihrer Firma geworden ist.
Sie hat unter 8.5 mal drüber geschaut und meinte im Groben sei alles okay. Dadurch das LabVIEW mit meinen Modulen sehr oft beim Speichern/Ausführen oder sonstigen abstürzt, meinte Sie, dass da Programmierfehler vorliegen. Wo konnte sie mir aber leider nicht sagen.
Ich habe die komplette llb angehängt. Sie ist zwar ohne controller nur bis OpenSensor ausführbar, weils dann ernst wird, aber was mir lieb wäre ist ein grobes:
"Was machst du da" oder ein "Um Himmels Willen" oder ein "Sieht gut aus".
Es sollte auch ein ständiges Abstürzen bei Speicher oder "wiederholten Ausführungen" nachvollziehbar sein.
Auch die Verwendung von Enums in den GetParam/SetParam als Connector nach außen zu führen. Ist das eine gute Idee?
Wie macht ihr das ? Leider bin ich Physiker, kein Programmierer. Aber ich weiß, dass in meinen Delphi/Pascal-Zeiten teilweise nicht solch Statistik bei der Lauffähigkeit auftrat. Wie auch immer.
Eine 8.5er Bibliothek mit DLL ist angehangen.
Ich hab aber noch eine 8.0er dran gehangen
Eine 6.1er kann ich erst morgen wieder in der Firma erstellen.
Danke Danke Danke
Martin
02.12.2008, 23:51 (Dieser Beitrag wurde zuletzt bearbeitet: 02.12.2008 23:52 von IchSelbst.)
' schrieb:meinte Sie, dass da Programmierfehler vorliegen.
Die Frage ist nur, von wem.
Zitat:"Was machst du da"
Hast du die NCDT2401-VIs geschrieben? Die sind doch bestimmt vom Hersteller der DLL?
Zitat:Es sollte auch ein ständiges Abstürzen bei Speicher oder "wiederholten Ausführungen" nachvollziehbar sein.
Zitat:Auch die Verwendung von Enums in den GetParam/SetParam als Connector nach außen zu führen. Ist das eine gute Idee?
Ja, die Idee ist gut - sogar sehr gut.
Was mich aber etwas wundert, ist die Verwendung des Eingangsparameters im SubVI. Dort liegt das Eingangselement in einer Sequenz, in derem zweiten Case dann eine lokale Variable des Eingangsparameters verwendet wird. Das würde ich vorerst nicht so machen. Statt der lokalen Variablen kann man gleich das Element nehmen.
Zitat:Aber ich weiß, dass in meinen Delphi/Pascal-Zeiten teilweise nicht solch Statistik bei der Lauffähigkeit auftrat.
Da hattest du ja auch eine richtige Programmiersprache vorliegen. !!Verräter!! Warum wechselst du auch nach LV.
Guckst du Bild: Der DLL-Knoten im SubVI NCDT2401-GetError ist falsch konfiguriert. Die Funktion in der DLL erwartet einen Pointer auf einen Speicherbereich. Der Bereich muss aber auch vorhanden sein! Das wird dadurch gewährleistet, dass im DLL-Knoten für die "Mindestlänge" des "C-String-Zeigers" der Werte "maxlen" ausgewählt werden muss.
Probiers mal aus und sag Bescheid.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
03.12.2008, 10:31 (Dieser Beitrag wurde zuletzt bearbeitet: 03.12.2008 10:41 von schaaff.)
Danke nochmal für die große Hilfe.
Ich habe die VI's geschrieben. Das ist sozusagen meine Aufgabe. Der Hersteller hat eine LabVIEW-Alternative im Vertrieb und bietet keine VI's. Laut dem Entwickler der DLL ist diese aber bereits von Kunden in LV-Programmen erfolgreich im Einsatz.
Das MaxLen Problem: Dazu ist zu sagen, dass ich in LV6.1 das MaxLen nicht an den StringZeiger knüpfen kann.
Enumgeschichte: Die Enumsache schien mir auch schick und absolut benutzerfreundlich. (Konstante raus, Befehl auswählen i voilá) Das Problem ist, dass wenn ich 2mal SetParameterString so schnell hintereinander ausführe (z.B. bei IP_Interface und IP_Port) bekomme ich die Fehlermeldung wie oben beschrieben:
-10 (ERR_INTERFACE_NOT_SUPPORTED): Com1
Als hätte er den IP_Port auf IP_Interface geschrieben. Quasi dasselbe SubVI wird zweimal aufgerufen mit unterschiedl. Parametern und erschreib den Parameter des ersten Aurufs auf den Parameter des zweiten. *ugly*
Ich habe jetzt in einer letzten Verzweiflung alle Enums gelöscht und mit Strings ersetzt(siehe Anhang), die ich übergebe. Das ist zwar unschön, da anschließend der Benutzer in der Doc. alle Befehle nachschaun muss. So gehts.
Jetzt argwohne ich über die Verwendung der Enums? Wie läuft das ganz genau. Gibt es eine eindeutige Zuordnung zwischen der übergegebenen Konstante und dem Enum im SubVI?
Müssen die Enumbefehle in der selben Reihenfolge sein, wie die Befehle in der DLL-Doc? Klingt wirr, in der Verzweifelung fragt man aber alles.
Ich hab in der Nacht der Änderung auch <important>nachträglich</important> noch Befehle in den Enum hinzugefügt. Macht das Probleme?
Anfängliche Versuche mit nicht allen Parametern im Enum funktionierten nämlich.
Wie verhält sich ein Enum bei nachträglichem hinzufügen. Was muss ich noch ändern, wenn ich einen Enum erweitere ?
Muss ich das SubVI neu reinziehen, wenn ich das Enum darin erweitere ?
Ist der Aufruf des Inhalts über die Eigenschaft Param.text richtig?
Danke
Martin
p.s.: die Verschiebung in die Sequenz davor mache ich, weil ich dachte, dass vll. mit der Dekl. der Variable in einer Seq. davor sicher gegangen werden kann, dass der neue Param aus dem Connector in die Var. geschoben wird BEVOR der DLL-Aufruf kommt. Auch so ein Verzweiflungsversuch.
' schrieb:Das MaxLen Problem: Dazu ist zu sagen, dass ich in LV6.1 das MaxLen nicht an den StringZeiger knüpfen kann.
Dann probiere folgendes:
Mach ein U8-Array der Länge 1024. Dieses Array wandelst du in einen String um. Den String gibst du dann auf den DLL-Eingang. Dann verifizierst du, ab LV noch abstürzt.
Zitat:Enumgeschichte: Die Enumsache schien mir auch schick und absolut benutzerfreundlich. (Konstante raus, Befehl auswählen i voilá) Das Problem ist, dass wenn ich 2mal SetParameterString so schnell hintereinander ausführe (z.B. bei IP_Interface und IP_Port) bekomme ich die Fehlermeldung wie oben beschrieben:
-10 (ERR_INTERFACE_NOT_SUPPORTED): Com1
Als hätte er den IP_Port auf IP_Interface geschrieben. Quasi dasselbe SubVI wird zweimal aufgerufen mit unterschiedl. Parametern und erschreib den Parameter des ersten Aurufs auf den Parameter des zweiten. *ugly*
Ich habe jetzt in einer letzten Verzweiflung alle Enums gelöscht und mit Strings ersetzt(siehe Anhang), die ich übergebe. Das ist zwar unschön, da anschließend der Benutzer in der Doc. alle Befehle nachschaun muss. So gehts.
Das muss mit den Enums auch gehen. Mag sein, dass da 6.1 einen Bug hat. Kannst du nicht auf was neueres Updaten: 8.5, 8.2 oder wenigstens 7.1.1 ?
Zitat:Jetzt argwohne ich über die Verwendung der Enums? Wie läuft das ganz genau. Gibt es eine eindeutige Zuordnung zwischen der übergegebenen Konstante und dem Enum im SubVI?
Das Enum im SubVI ist die übergebene Konstante.
Zitat:Müssen die Enumbefehle in der selben Reihenfolge sein, wie die Befehle in der DLL-Doc? Klingt wirr, in der Verzweifelung fragt man aber alles.
Die Reihenfolge der Aufrufe der DLL mit den entsprechenden Funktionen muss schon so sein wie in der Beschreibung steht. Also z.B erst Interface-Typ (RS232), dann Interface-Instanz (Com1). Innerhalb des Enumerators muss die Reihenfolge nicht mit der in der Beschreibung übereinstimmen. Wohl aber die Zuordnung des Enum-Wertes zum String.
Zitat:Ich hab in der Nacht der Änderung auch <important>nachträglich</important> noch Befehle in den Enum hinzugefügt. Macht das Probleme?
Im Prinzip nicht. Die Zuordnung Enum-Wert - String muss halt stimmen.
Zitat:Anfängliche Versuche mit nicht allen Parametern im Enum funktionierten nämlich.
Wie verhält sich ein Enum bei nachträglichem hinzufügen. Was muss ich noch ändern, wenn ich einen Enum erweitere ?
Muss ich das SubVI neu reinziehen, wenn ich das Enum darin erweitere ?
Ist der Aufruf des Inhalts über die Eigenschaft Param.text richtig?
[*grübel*]
Problem: Weist du was eine "strikte Typdefinition ist"? Ganz wichtig. Machst du's ohne, kriegst du Probleme, wenn du im SubVI den Typ anpasst und im MainVI nicht! Dann ist im MainVI noch der alte Enum-Wert (nicht verwechseln mit Enum-Bezeichner), der aber mit dem neuen im SubVI nicht mehr über einstimmt.
[*nachdenk*]
Hab ich da rote Punkte an den Eingängen gesehen? Das sind Konvertierungspunkte, die bei unterschiedlichen Typen entstehen. Mach aus dem Enum eine strikte Typdefinition und verwende die überall.
Auch wenn ich aufdringlich wirke, ich rate zu einem Update auf 8.5.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Dann probiere folgendes:
Mach ein U8-Array der Länge 1024. Dieses Array wandelst du in einen String um. Den String gibst du dann auf den DLL-Eingang. Dann verifizierst du, ab LV noch abstürzt.
Hab ich gemacht. Problem ist aber weiterhin da.
Zitat:Kannst du nicht auf was neueres Updaten: 8.5, 8.2 oder wenigstens 7.1.1 ?
Ich denke, dass ist ein Mischproblem aus Kompatiblität, die mein Chef nicht riskieren will. Heißt: Er vermutet, dass evtl. alte Programme nicht mehr lauffähig sind, wenn das neue LV kommt. Zum anderen der Preis. Use it until there is a problem you really can't solve with this version.
Zitat:Problem: Weist du was eine "strikte Typdefinition ist"? Ganz wichtig. Machst du's ohne, kriegst du Probleme, wenn du im SubVI den Typ anpasst und im MainVI nicht! Dann ist im MainVI noch der alte Enum-Wert (nicht verwechseln mit Enum-Bezeichner), der aber mit dem neuen im SubVI nicht mehr über einstimmt.
Das klingt vielversprechend. Ich habe leider keine Ahnung von strikten Typdefinitionen, aber wenn es ähnlich Strict-XHTML bei HTML/XML-Files ist, dann kann ich mir vorstellen, was es ist. Ich habe alle Enums in solche mit strikter Typdefinition umgewandelt und die neuen Bedienelement abgespeichert bzw. ersetzt.
Es ändert sich allerdings nix.
Zitat:Hab ich da rote Punkte an den Eingängen gesehen?
Jetzt müssten alle Punkte weg sein. (siehe anhang)
Wenn ich das VI starte/in der Schleife und anschließend im Diagramm das erste Subvi öffne, stürzt LabVIEW ab. Bei dir auch?
trotzdem selber fehler:
-10 (ERR_INTERFACE_NOT_SUPPORTED): Com1
Kannst du auch nochmal schaun, ob GetError mit dem String jetzt richtig ist? und ob die strikten Typdef. stimmen.
Ich kann diesen Fehler mit 8.5 nicht nachvollziehen. Auch ist mir bisher nichts eingefallen, durch welche "falschen" Datenflüsse auch immer dieser Fehler auftreten könnte.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Ich kann diesen Fehler mit 8.5 nicht nachvollziehen. Auch ist mir bisher nichts eingefallen, durch welche "falschen" Datenflüsse auch immer dieser Fehler auftreten könnte.
Ich habe die Testversion von 8.2 jetzt hier laufen und es funktioniert. Was soll man sagen. Es funktioniert. Mir ist es schleierhaft. Warum kann LabVIEW 6.1 nicht mit den Enums umgehen. Auch wenn Sie Typedef Strict.
Ich danke dir riesig. Ohne dich wäre ich nicht so weit gekommen. DANKE
nochmals dankende Grüße,
wenn es das Forum nicht gebe, wäre LV nicht so erfolgreich. Klingt blöd. Ist aber so. Sicherlich wäre es trotzdem "quasi" Industriestandard. Aber die Verwendung unter Laien wird durch dieses Forum unterstützt und ein Laie wird wenn ers einmal verwendet so schnell nicht die sprache wechseln.
a la "Never touch a running system"
/
DLL liefert versch. Errorcodes (Highlight-Modus AUS/Highlight-Modus AN)
