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!
ich habe ein Problem.
Ich habe Programm, in dem ich ein VI erweitert habe, bei dem man - in Events - ein Gerät, einen Befehl und eine Tabelle auswählen kann.
Ich habe das VI so verändert dass die Tabelle nun als Tabelle und nicht als Tabellen-String ausgegeben wird.
Zusätzlich kann man Zellen der Tabelle doppelklicken und den Inhalt übernehmen oder in eine Untertabelle springen.
Dann Habe ich noch eine Knopf "LAST TABLE" hinzugefügt über den man wieder in die Obertabelle kommt, das habe ich mit lokalen Variablen gemacht.
Nun mein Problem:
man kann alle Funktionen die ganze Zeit über ausführen, außer das wechseln zwischen den Tabellen.
Man kann zwar immer aus der Obertabelle mit einem Doppelklick in die Untertabellen springen, wenn man aber den Knopf "LAST TABLE" betätigt, hängt sich das Programm auf.
Manchmal hängt es sich gleich beim ersten mal Knopf drücken auf, manchmal aber auch erst nach ein paar mal hin und her wechseln.
Man kann aber den selben Tabellenwechsel auch über das Ring-Element TABLE herbeiführen und da hängt sich das Programm auch auf, dauert nur länger.
Es liegt also nicht zwangsweise an dem Knopf-Event.
Ich habe einfach keine Idee woran das liegen könnte.
Es sieht zwar nach einem Speicherzugriffs- oder Speicherüberlaufsproblem aus, aber es könnte auch mit den .dll Dateien zu tun haben.
Ich weiss weder wieso oder was man dagegen tun könnte.
Wenn einer von euch eine Idee hat wäre ich froh.
Danke!
Anbei schicke ich einen Screenshot und meine Fehlerberichte, der 1. entsteht beim Wechsel der Tabellen, der 2. beim zwangsweise beenden des Programms.
MfG
Robert
Anzeige
25.06.2008, 08:10 (Dieser Beitrag wurde zuletzt bearbeitet: 25.06.2008 08:26 von A.Berndsen.)
nach dem Screenshot und den Fehlermeldungen zu urteilen handelt es sich um eine compilierte Form (EXE) Deines Programms.
Stimmt das?
Wenn dem so ist, läuft es in der Entwicklungsumgebung ohne Probleme, oder gibt es dort die gleichen Schwierigkeiten?
Hast Du mit der Highlight-Funktion versucht dem Fehler auf die Spur zu kommen?
Ich denke, dass es fast unmöglich ist ohne das VI gesehen zu haben rein durch die Fehlerbeschreibung eine Lösung zu erahnen.
Ich vermute jedoch, dass das Problem in Zusammenhang mit dem compilieren steht.
Grüße
Andreas
PS: Thema aus der LV Buglist :verschoben1:nach Application Builder.
Edit: Hab eben gesehen, daß die gleiche Frage im Allgemeinen Board ebenfalls gepostet wurde. Doppelposts mögen wir garnicht!
Wenn Du deine Frage im richtigen Forum stellst bekommst Du sicher eine Antwort, wenn jemand unter der Problembeschreibung etwas versteht.
Laß das in Zukunft bitte sein!
das Problem tritt leider in der entwicklungsumgebeung bei laufendem VI genau so auf.
Das mit dem Highlighten hab ich probiert, aber beim aufhängen, komm ich nicht mehr ins Blockschaltbild.
Ich schicke das VI mit, aber es wird alleine nicht lauffähig sein bzw. nach dem start ne Fehlermeldung aus spucken
und man kann die Tabellen nicht laden, da diese in einem externen Ordner sind.
Aber vielleicht hilft es ja trotzdem.
ich hab mir das Programm angesehen und mir fällt nichts direkt ins Auge was zu dem Problem führen könnte.
Die Ereignisse "Table Wertänderung" und "Last Table Wertänderung" sind aus meiner Sicht vergleichbar und sind auch identisch programmiert.
Da hätte ich vermutet, dass dann auch beides funktioniert.
Wenn Du mit der Highlight-Funktion den Fehler eingrenzen möchtest, kannst Du versuchen einen Haltepunkt am Anfang des problematischen Programmteils zu setzen, das Programm bis dorthin ausführen und erst dann die Glühbirne aktivieren. Vielleicht kannst Du dann sehen bis wohin das Blockdiagramm abgearbeitet wird.
Ja, aber zur api32.dll und die habe ich auch schon mal ausgetauscht und sichergestellt dass der Pfad korrekt ist.
Aber ich wüsste auch nicht was da dann so einen Fehler verursacht, oder fällt dir da was ein?
Ich hab davor schon ein Programm mit EDIABAS VIs geschrieben, da hatte ich garkeine Probleme.
Allerdings war mein Programm nicht annährend so komplex und auch ohne Events.
Ich versteh halt nicht warum das alte Prog. das Problem nicht hat, muss was mit der Darstellung als Tabelle oder den Doppelklick-Events zu tun haben.
Wüsste aber nicht was.
Trozdem danke.
26.06.2008, 07:50 (Dieser Beitrag wurde zuletzt bearbeitet: 26.06.2008 08:09 von rolfk.)
' schrieb:Ja, aber zur api32.dll und die habe ich auch schon mal ausgetauscht und sichergestellt dass der Pfad korrekt ist.
Aber ich wüsste auch nicht was da dann so einen Fehler verursacht, oder fällt dir da was ein?
Ich hab davor schon ein Programm mit EDIABAS VIs geschrieben, da hatte ich garkeine Probleme.
Allerdings war mein Programm nicht annährend so komplex und auch ohne Events.
Ich versteh halt nicht warum das alte Prog. das Problem nicht hat, muss was mit der Darstellung als Tabelle oder den Doppelklick-Events zu tun haben.
Wüsste aber nicht was.
Trozdem danke.
Zum Beispiel eine falsch konfigurierte Call Library Node die nicht mit der aufgerufenen Funktion übereinstimmt. Oder was ein ganz beliebter Fehler ist bei Call Library Node Benützern ist um zu "vergessen", dass C Pointer durch den Aufrufer auf die nötige Länge alloziert werden müssen. Das heisst wenn da irgendwo ein Buffer ist in dem die DLL Informationen zurückgeben soll, muss der in Deinem LabVIEW Diagramm genügend gross angelegt werden. Dies geht zum Beispiel sehr gut mit der Initialize Array Funktion.
Wenn der Buffer zu klein ist kann die DLL über das Ende des Buffers schreiben und damit andere wichtige Informationen im Speicher zerstören. Das braucht nicht unmittelbar zu crashen, da der Bereich direkt hinter einem Buffer nicht automatisch benützt sein muss aber früher oder später muss das einmal krachen.
LabVIEW ist entgegen der Meinung einiger Leute hier wirklich sehr stabil. Wenn Du dann ein Projekt hast wo Du eine DLL mittels Call Library Node anrufst würde ich bei Crashes, Access Violations, und dergleichen grundsätzlich immer erst diese DLL Aufrufe verdächtigen bevor ich auch nur in Erwägung ziehe, dass LabVIEW das irgendwie selber macht. Und meine jahrelange Erfahrung auch mit Interfacing nach DLLs in LabVIEW bestätigt diese goldene Regel 100%.
Hier auch gleich eine Warnung an alle die Call Library Node VIs schreiben. Nur weil es nicht kracht heisst das noch lange nicht dass es alles perfekt ist. Zu klein allozierte Ausgabebuffer für Funktionen ist ein wirklich beliebter Fehler. So kann es lange gut gehen, weil zum Beispiel bei den Tests immer nur ein kurzer String von der Funktion zurück kommt, aber wenn dann in der Produktion plötzlich ein realer String zurückkommt geht es schief.
Oder die DLL schreibt zwar frisch fröhlich über das Ende des Buffers aber da der Speicher unmittelbar danach in diesem Moment nicht benützt ist geht es gut. Kleinste Änderungen am LabVIEW Diagramm erzwingen aber eine Rekompilation und plötzlich ist das Memorylayout anders angeordnet und BUMMS.
Eine andere Möglichkeit ist dass die DLL zwar gültige Daten überschreibt die aber im Moment nicht benötigt werden. Zum Beispiel die internen Verwaltungsstrukturen des Tabellenkontrolls. Wenn LabVIEW dann ein Displayupdate für das Kontroll machen will krachts halt wieder.
Oder die zerstörten Daten werden während der Runtime gar nicht benötigt sondern erst später wenn Du eine Editoperation an einem VI machst, oder gar erst wenn Du LabVIEW abschliesst und es beim ordentlichen Aufräumen aller allozierten Speicherlemente über durch die DLL ungültig gemachte Pointer stolpert.
Jeder dieser genannten Fehlerfolgen kann selbst durch kleine Änderungen an dem LabVIEW Programm plötzlich in einen der anderen Folgen veränderen. Auch eine Möglichkeit die ich öfters sah ist,dass es im Entwicklungssystem normal scheinbar gut ging aber in einer Build Applikation plötzlich crashte.
Deshalb an jeden der mit der Call Library Node arbeiten will und diese VIs in ein Produktionssystem einbauen will: Sorgfältig arbeiten, die nötigen C Kenntnisse erlernen, und Testen, Testen, Testen, Testen!!!
danke für deinen Tipp, sowas hab ich mir auch schon gedacht.
Aber ich finde leider keine möglichkeit die Größe des Arrays festzulegen, höchstens mit Array initialisieren die Dimension und die ist mit 2 korrekt.
In den VIs wird das Array mit Hilfe von indizierenden Tunneln und For-Schleifen gebildet.
Wo kann ich denn die größe festlegen?
MfG
Robert
01.07.2008, 13:36 (Dieser Beitrag wurde zuletzt bearbeitet: 01.07.2008 13:41 von rolfk.)
danke für deinen Tipp, sowas hab ich mir auch schon gedacht.
Aber ich finde leider keine möglichkeit die Größe des Arrays festzulegen, höchstens mit Array initialisieren die Dimension und die ist mit 2 korrekt.
In den VIs wird das Array mit Hilfe von indizierenden Tunneln und For-Schleifen gebildet.
Wo kann ich denn die größe festlegen?
MfG
Robert
Und wo denkst Du schreibt Deine "Ediabas Result Text" Funktion den Text, den Du danach mit Format into String benützst, hinein wenn sie aufgerufen wird? Dieser Buffer musst Du schon innerhalb dieses VIs anlegen und dann an die Funktion übergeben, so dass diese etwas hat um ihren Tratsch loszuwerden ohne anderen Speicher zu überschreiben!!!
Ein String ist auch nur ein Array (von Bytes) und muss genau gleich ordentlich angelegt werden bevor man ihn an eine C Funktion übergibt wie alle anderen Arrays auch.
