Eventstruktur in zeitgesteuerter Schleife

Hallo an alle,
Ich habe seit Tagen folgendes Verhalten.
LabVIEW wird bei laufenden Programm geschlossen und ein "schwerwiegender Fehler" visualisiert.
Ursprung kann das Verhalten in einer Eventstruktur sein. Muss aber nicht zwangsläufig.
Die Abstürze sind oft so heftig, dass nach Neustart von LabVIEW alle VISA-Schnittstelen nicht mehr angezeigt werden. Erst ein Neustart des Systems bringt die Schnittstellen zurück.
Kurz:
Die Eventstruktur ist in einer zeitgesteuerten Schleife in dem 2. Schleifendurchlauf positioniert und ist zugegeben recht gross.
Ich betätige eine Eigabe, das ein Ereignis durchführen soll. Nun passiert folgendes. Nicht jede Eingabe wird von der Struktur übernommen. Nur kurz und es sprigt auf den ursprünglichen Wert zurück. Die Übernahme ist willkürlich.
Die Positionierung der Eventstruktur in der 2. Schleife ist wegen der lokalen Variablen, die beschrieben werden um den momentanen Sollwerzustand für den jeweiligen Event zu geben.
Die zeitgesteuerte Schleife ist so eingestellt, dass jede Schleife etwas später startet, wenn die davor beendet wurde.
Habe ich wegen Schreiben und Lesen von lokalen und globalen Variablen so eingerichtet.
Ich weiss auch, dass man die Eventstruktur so konfigurieren kann, dass der momentane Event so lange blockiert, bis der Wert übernommen wurde,
Leider habe ich nach Freischlaten von LabVIEW nicht mehr die Möglichkeit, deises zu kontrollieren. ich habe nur LV BASE.
Falls jemand mal schaun kann.
Danke und eine feinen Tag wünscht der,
frehdie

Wer soll sich denn da bitte zurecht finden?

(26.09.2012 10:27 )Achim schrieb:  Wer soll sich denn da bitte zurecht finden?

Nun , es ist schon etwas mehr, als nur von einem Gerät ein Istwert lesen.
Es ist eine komplexe Appartur, die sowohl über ein Rezept als auch im Stand alone Verfahren gesteuert werden soll. Es ist sehr umfangreich und man muss es auch nicht verstehen. Das hochgeladene VI ist nur ein Teil des Projekts. Dort werden aber scheinbar die Absatürze veruracht. Mein Bitte ging dahin, zu schaun, ob die Eventstruktur richtig konfiguriert ist.
Danke.

Da fehlen auch die ganzen SubVIs der Event-Struktur. Vielleicht läuft auch da was falsch. Ich hatte bei Event-Strukturen bisher noch nie das Problem, dass alles komplett abschmiert und nur ein Neustart des Systems hilft. Kannst Du die SubVIs mal hochladen?

Noch was: Nur weil das Programm komplex ist, heißt es nicht, dass deshalb alles größer sein darf. Gerade da solltest Du modular programmieren und nicht alles größer als eine Bildschirmgröße machen, aber das muss ich einem "alten Hasen" wie Dir (Erfahrung seit 1996) ja nicht sagen.

Gruß Markus

(27.09.2012 06:50 )Y-P schrieb:  aber das muss ich einem "alten Hasen" wie Dir (Erfahrung seit 1996) ja nicht sagen.

Hab ich auch gelesen...sieht man dem Code nicht an!

(27.09.2012 06:50 )Y-P schrieb:  Da fehlen auch die ganzen SubVIs der Event-Struktur. Vielleicht läuft auch da was falsch. Ich hatte bei Event-Strukturen bisher noch nie das Problem, dass alles komplett abschmiert und nur ein Neustart des Systems hilft. Kannst Du die SubVIs mal hochladen?

Noch was: Nur weil das Programm komplex ist, heißt es nicht, dass deshalb alles größer sein darf. Gerade da solltest Du modular programmieren und nicht alles größer als eine Bildschirmgröße machen, aber das muss ich einem "alten Hasen" wie Dir (Erfahrung seit 1996) ja nicht sagen.

Gruß Markus

Hallo Markus,
das ist mir durchaus klar, dass ein komplexes LabVIEW programmn nicht unbedingt eine "Tapete" sein muss. Aber, wie Du bestimmt festgestellt hast, sind einige SubVI's durchaus eingefügt und werde nach Bedarf abgearbeitet. Ich mag es auch lieber überschaulicher. Es wird auch vieles in SubRoutinen abgearbeitet. Nun aber, warum so gross.
Also, wie schon angeführ, ist dieses Programm so angelegt, dass ein Prozess in Art einer Rezeptsteuerung, so wie auch in einem Stand alone Verfahren abgearbeitet werden soll. Das Ganze soll so angelegt sein, dass man auch in einem Rezeptschritt in diesem Prozess durch aktualisieren von Sollwerten eingreifen kann.
Das bedeutet, das jeder Schaltzustand und Sollwertzustand aus einem Rezeptschritt übernommen werden muss. Das bedeutet (leider) Lokale Variablen einrichten. Beim Einsetzten von Lokalen Variablen muss man so einiges beachten. Ist klar. Ich könnte natürlich auch Referenzen zu VI's einrichten. Aber, ob die mehr Übersichtilichkeit in einem Blockdiagramm schaffen, kann ich sehr anzweifeln. Zudem gibt es Bestimmte Zustände zu beachten, die man nicht in SubRoutinen auslagern kann, da sei auch auf deisem einen Frontpanel visualisiert werden sollen.
Falls jemand weiss, wie man eine Multifunktionale Steuerung von annähernd 24 Schaltzuständen und 26 Sollwerte so anlegen kann, dass es in einer dynamischen Rezeptsteuerung, so wie in einer Stand alone Steuerung, mit Datenspeicherung, die auch dynamisch sein soll, sowie dynamishem Graphen und das alles auf einem Frontpanel und nicht in verschiedenen Fenstern, bin ich dankbar.
einen feinen Sonntag.
Gruss, der frehdie

Anzeige

Hier einmal ein kleiner Tipp zum Aufräumen des BD:

Das rot markierte ist identisch mit deinem Konstrukt:
   
Und weiter: Eine Reihe von FP-Elementen lassen sich logisch in Cluster zusammenfassen (z.B. deine Ventile), das schafft wieder Übersicht im BD.
Wenn du beim Auslesen eines Clusters nicht alle Elemente benötigst, dann lass die doch weg in der Anzeige, z.B. so:
   

Gruß, Jens

P.S.: Hast du eine Chance, auf LV 2012 umzusteigen? Dort ist auch in der Base Edition die Eventstruktur enthalten, du könntest sie also wieder editieren.

(07.10.2012 11:43 )jg schrieb:  Hier einmal ein kleiner Tipp zum Aufräumen des BD:

Das rot markierte ist identisch mit deinem Konstrukt:

Und weiter: Eine Reihe von FP-Elementen lassen sich logisch in Cluster zusammenfassen (z.B. deine Ventile), das schafft wieder Übersicht im BD.
Wenn du beim Auslesen eines Clusters nicht alle Elemente benötigst, dann lass die doch weg in der Anzeige, z.B. so:


Gruß, Jens

P.S.: Hast du eine Chance, auf LV 2012 umzusteigen? Dort ist auch in der Base Edition die Eventstruktur enthalten, du könntest sie also wieder editieren.

Danke Jens,
was ich hochgeladen hatte, waren eh die Tools in der Entwicklung, wo die Abstürze passierten. Die Cluster (nach Namen) sind von mir schon lange "aufgeräumt" worden. Genau in der Art, wie Du es empfohlen hast. Danke.
Alle anderen Cluster auch nur nach Bedarf minimiert worden. Weil es eine multifunktionale Steuerung sein soll, war das alles noch offen, und daher so aufgeschlüsslet. Ich habe LV 12 und bin dankebar für die Info. Ich muss es nur von 11 auf 12 auf meinem Systzem updaten. Jedoch ist das System, auf dem das Programm letztenlich laufen soll Win.XP und LV 8.6. Ich könnte dann ja das Programm auf LV 8.6 tranferieren. ZU einer Tapete wird das Programm ja durch die viele Eigenschaften. Also, bei bestimmten Zuständen sollen Schalter deaktiviert werden, einige Sachen verblockt, bis ein Zustand eingetroffen ist. Das betrifft viele Messtellen und Sollwertvorgaben. Ob das zu minimieren ist???..Trotzdem Danke
So langsam kristallisiert sich der Ursprung der Abstürze heraus. Es ist scheinbar der DDE-Server, der dort sehr zickig ist. Damit werden Module von AdamControl-DDE angesprochen, der scheinbar noch auf 8 od. 16 bit funktioniert. Ein Update auf 32 bit ist in Arbeit.
Danke für Deien Info.
Gruss, der frehdie

Ein paar Aufräum-Ideen, z.B.
Zusammenfassung deiner Ventilsteuerungen und Anzeigen in (typdefinierte) Cluster, s. Screenshot:
   
Hier ist absichtlich der Rahmen des einen Clusters noch nicht durchsichtig.

Vorteil bei den Ventilen, die kannst du alle 4 auf einmal (de)aktivieren, einfach über die Cluster-Eigenschaft.
Die Event-Struktur kannst du weiterhin verwenden, denn du kannst auch auf Events von Cluster-Elementen reagieren.
   
Nachteil, im Disabled-Zustand sieht man es, wenn du den gesamten Cluster deaktivierst:
   
Bei den Anzeigen lohnt sich das Clustern bestimmt, siehe die verbesserte Codeübersicht, und das Ganze dann mal 3...
   
Die PropertyNodes würde ich an deiner Stelle nur dann setzen, wenn sich wirklich etwas an der Eigenschaft ändert, da das Setzen jeder PropertyNode einen Wechsel in den UI-Thread und ein FP-Update erzwingt.

In diesem Sinn lässt sich bestimmt noch mehr logisch zusammenfassen.

Was hält dich übrigens davon ab, auf dem Zielrechner am Ende eine -Exe laufen zulassen?
Oder dort LabVIEW 2012 zu installieren (hängt natürlich von deiner Lizenz ab).
Die Einzel-Lizenz darfst du auf bis zu 3 Systemen + Privat-PC installieren, aber nicht gleichzeitig laufen lassen.

Gruß, Jens