Anlagensteuerung oder anders: Wie sehr sollte man in sub-VIs aufsplitten?

Hui, daß der Thread solche Resonanz auf sich zieht hätt' ich nicht gedacht.

Aber diskutiert ruhig weiter, da ich für jeden Erfahrungsratschlag dankbar bin. Mehr als ein Netzteil steuern und eine DAC-Karte (Keithley KPCI 3116) auslesen kann ich ja eh noch nicht. Und da das Projekt noch in den Kinderschuhen steckt ist es eh sinnvoll auf eure Tipps zu hören. Letztlich programmiert es sich so sogar schneller, das Programm läuft stabiler und wenn mein Nachfolger es mal anschaut bekommt er auch keinen Schreck...

@abrissbirne: Das mit der state machine klingt sehr gut. Hast Du da evtl. mal ein Beispiel zu? Laufen die sub-VIs dann quasi die ganze Zeit und werden nur "an und ausgeschaltet"? Wäre ja im Prinzip das, was Lucki auch beschreibt (Initialisieren/Schließen) - dann hätte ich das sogar mal verstanden

@TSchAC: Auch von Dir würd ich ja zu gern mal ein Bild sehen - klingt nach echt sauberem Programmieren. Ja, da bin ich leider noch weit von entfernt. Wie meinst Du das mit "Datenfluss über Errorline steuern"? Soll ich jedem sub-VI ein IF und ne Adresse verpassen und für die Auswahl es mit an die Errorline legen?

@Lucki: Tut mir leid aber mit den perversen Sequenzen triffst Du sogar voll ins Schwarze. Soll ich verraten, wer mich verdorben hat? Der Onkel Testpoint war's . Und es ist tatsächlich so, daß man die größeren Programme dort recht schnell selbst nicht mehr durchblickt. Die Möglichkeit, in LabVIEW da alles in sub-VIs zu zerlegen ist daher IMHO ein Segen. Die Frage ist nur, wo man die Grenze zieht. Das Netzteil-VI ist nun schon ziemlich groß und ich gebe zu, auch sequentiell aber wenn man es "ein und ausschalten" könnte bräuchte ich eh keine Angst vor Kollisionen auf dem RS232 haben. "Netzteil an" und "Netzteil aus" habe ich eh schon als suv-VIs liegen. Auch der Stellwert wird extern berechnet. Die ursprüngliche Frage war dann ja bloß, wie weit ich die Kommunikation zerlegen sollte und wie die einzelnen Schritte aufgerufen werden. Dazu hatte ich sowas wie "push" im Testpoint vermisst, was halt ein sub einmalig aufruft. Deinem Statement entnehme ich aber, daß es genau diese Funktion aus gutem Grund nicht gibt, weil man damit serielle Programmierung provoziert.

Den eigentlichen Programmablauf später mit einer state machine zu realisieren ist IMHO eh die einzig sinnvolle Lösung. Einfach nen Zähler laufen lassen, der am Ende jedes Programmteils um eins erhöht wird. Die werden z.B. per Ring-Objekt im Mainscreen ausgewählt. Die Schleife guckt dann nur noch, was im X'ten Ring ausgewählt wurde und startet das entprechende sub, bis irgendwann in einem davon "Ende" ausgewählt wurde. Müßte so klappen, oder?!

Gruß,
Dennis

Anzeige

' schrieb:...
@TSchAC: Auch von Dir würd ich ja zu gern mal ein Bild sehen - klingt nach echt sauberem Programmieren. Ja, da bin ich leider noch weit von entfernt. Wie meinst Du das mit "Datenfluss über Errorline steuern"? Soll ich jedem sub-VI ein IF und ne Adresse verpassen und für die Auswahl es mit an die Errorline legen?
...

1. ein Bild von mir gibts im Profil, Bilder von meinen Projekten veröffentliche ich nicht wegen meinem Boss.

2. Die Errorline:
so wie du sagst: jedes VI bekommt ein ErrorIN und ein ErrorOut. im VI kommt ne Casestruktur, bei fehler passiert nix, der error wird nur durchgereicht. wenn kein fehler am eingang liegt, wird das vi normal ausgeführt. innerhalb des VIs aufgetretene Fehler werden behandelt oder eben an den Fehlerausgang gereicht. Im hauptprogramm verbindest du dann deine VIs mit den errorverbindungen so, dass es sinnig ist. natürlich muss nicht alles in einer reihe liegen, es können auch mehrere Errorlines nebeneinander laufen, die dann eben unabhängig sind.

LG
Torsten

Hey Torsten,

okay - das mit dem Chef ist ein Argument. Geht mir ja (leider) mit Teilen meiner Anlage nicht anders

Den Trick mit den Errorlines habe ich soweit verstanden, es ist bloß eine Frage - vermutlich einfach aufgrund LV-Praxis - offen: Du sagst, wenn ein Fehler anliegt tut das sub-VI nichts bzw. einige Fehler könnte man auch schon im sub-VI verarbeiten. Aber wer bzw. welches Objekt macht das? Bisher dachte ich, Fehler würde man hauptsächlich erfassen und dem Benutzer in irgendeiner Form ausgeben bzw. notfalls halt z.B. das Programm damit stoppen...

Gruß,
Dennis

' schrieb:Hey Torsten,

okay - das mit dem Chef ist ein Argument. Geht mir ja (leider) mit Teilen meiner Anlage nicht anders

Den Trick mit den Errorlines habe ich soweit verstanden, es ist bloß eine Frage - vermutlich einfach aufgrund LV-Praxis - offen: Du sagst, wenn ein Fehler anliegt tut das sub-VI nichts bzw. einige Fehler könnte man auch schon im sub-VI verarbeiten. Aber wer bzw. welches Objekt macht das? Bisher dachte ich, Fehler würde man hauptsächlich erfassen und dem Benutzer in irgendeiner Form ausgeben bzw. notfalls halt z.B. das Programm damit stoppen...

Gruß,
Dennis

Bei meinen Programmen gibt es kritische Punkte wo ich direkt reagieren sollte. Beispiel Wasserkreislauf mit einer Pumpe. Nun kann es sein, dass das Rohr irgendwie verstopft ist (Dreck, Eis, kaputtes Ventil). In so einem Fall sollte die Pumpe umgehend gestoppt werden. Stelle ich also die Situation: "Volumenstrom = 0" und "Pumpe läuft" fest, erzeuge ich einen Fehler. Dieser Fehler wird dann nciht erst bis zum Ende des Programms durchgeschleust, sondern direkt behandelt. In der entsprechenden Fehlerbehandlung wird dann die Pumpe ausgeschaltet, eine Mail und eine SMS an das Wartungsteam geschickt und das System vorübergehend deaktiviert. Erst danach gehts im Programm weiter und Die Messdaten werden gesichert und ähnliches.

Ein anderer Fall wäre, wenn von den ca. 500 Thermoelementen eines unsinnige Werte liefert. In diesem Fall muss nicht gleich das ganze System abgeschaltet werden. Es muss nur darauf geachtet werden, dass dieses defekte Element nciht mehr in spätere Berechnungen einfließt. also wird in der direkt folgenden Fehlerbehandlung ein Flag gesetzt, welches angibt, ob ein Sensor für Berechnugnen verwendet werden soll, oder nciht. Danach kanns ganz normal weiter gehen. Auf der Oberfläche erscheint ein Lämpchen (Sensor ausgefallen) und es wird eine Mail verschickt. Eine sms sparen wir uns an der stelle aus kostengründen. ist ja schließlich ncihts dringendes.

Ich hoffe, dass macht dir die Sache wieder ein stück weit klarer.

LG
Totti

Heyho!

Auf jeden Fall - vielen Dank für die ausführliche Erklärung. Ich denke, das schießt aber schon ne Nummer übers Ziel hinaus bzw. ich würd' es eher als "fortgeschrittenes Programmieren" bezeichnen. Was ich dagegen mache ist ja Kindergarten: 6*PT100 (und das ist schon viel für die Anlage), Spannung und Strom über nen Shunt. Dann noch ein bisschen RS232-Spielerei für Netzteil, automatische Kalibrierung mit Keithley 2100 (wäre auch schon ein Novum) und evtl. noch Kryostat und Waagen zur Dosierung eines Volumenstroms. Die Pumpen kann ich mit 0-10 V wieder über den DAC der internen A/D-Karte ansteuern und wenn ich dem Ganzen die Krone aufsetzen will kommen noch Signalleuchten an den Abzug, die mit den 5V des DIO angeknipst werden...

Du siehst also, im Vergleich zu Deinen Projekten ist mein Vorhaben eher überschaubar und mich hätte ein Bild von deinen Schaltungen wohl eh nur verwirrt. Mehr als 'ne einzelne Waage auszulesen habe ich aber bisher mit LV leider nicht zustande gebracht. Nun soll mein Kalorimeter aber endlich nicht mehr unter Testpoint, sondern unter LabVIEW laufen. Zusätzlich zum komfortgewinn habe ich bei LV nämlich auch eine Verbesserung der Messgenauigkeit beobachtet. Die rührt wahrscheinlich von der größeren Anzahl Nachkommastellen, mit denen die 2000 Werte/sek*Ch gemittelt werden. Anders könnte ich es mir nicht erklären, denn A/D-Karte und Messverstärker sind dieselben.

BTT: Ich setze mich jetzt mal noch nen halbes Stündchen ans LV. Vielleicht bekomme ich ja nen Rohentwurf eines sinnvollen sub-VI fertig. Wenn ihr den noch ein wenig pimpt wäre der ja ggf. auch was für den DL-Bereich. So quasi als erstes Handwerkszeug zum sinnvollen Programmieren...

Gruß,
Dennis


EDIT: Also - case-Struktur ist klar. Wenn ich den "true" case für "Fehler liegt an" nutze, würde ein einfacher Error-handler ja genügen und an dessen booleschen Ausgang kommt der Case, klar. Was mich etwas irritiert ist, daß ich keinen Error-In in einen Case hinein tunneln darf. Ich hätte dann so weiter gemacht, daß in den false-Case ein "do...while" kommt, welches die state-machine darstellt. Die kann man dann ja als "Status" nach außen geben bzw. von außen an- und ausknipsen.

(...was für'n Denglisch. Aber die deutschen Wörter sind ja meist noch schlimmer... )

Nochmal ich - Ah, jetzt ja!!!

So in etwa?




Aaaaach - da fällt mir noch was ein: Ne while-Schleife im sub-VI ist unschön, oder? Wie löse ich das mit der state-machine dann. Dritter case? Oder einfach den Fehlercase aktivieren...?

Edit... Äh ne, diesmal nicht... (wird sonst echt unübersichtlich)

Schau mal den an - sieht doch schon ganz brauchbar aus. Der Case hat auch was Gutes: Man muß sich im Platzbedarf der VIs zusammen reißen...

So - nu' aber gute Nacht. Muß morgen noch nen ganzen haufen Klausuren abarbeiten und um 15:00 wareten schon wieder Termine...

2 kleine Tips:

1. Du kannst den Error-Cluster auch direkt an den Selector Eingang einer Case-Struktur anschließen.
2. Und bitte, von links nach rechts programmieren, nicht unter einem VI eine Draht zu seinem Eingang verstecken! Sieht so aus, als ob es der der Error-Out ist...

Gruß, Jens

Im prinzip macht es keinen Unterschied ob du 6 oder 600 Pt100 verwendest. Wenn du von anfang an eine übersichtliche struktur verwendest, kannst du das später problemlos erweitern. Bei meinen Versuchsständen habe ich bis zum entgültigen verkablen auch keinen blassen Schimmer wie viele Elemente genau engeschlossen werden. Dein Projekt scheint meinem ziemlich ähnlich zu sein, was die zu erfassenden Größen angeht.

Auf deinen Upload bin ich schon gespannt! Mal sehen was man da so rausholen kann.

Die Sache mit deiner CaseStruktur habe ich noch nicht ganz verstanden. Wenn du in einem SubVI einen ErrorIN und einen ErrorOut anlegst und dazwischen eine CaseStruktur unterbringst, bist du schon fast fertig. Ich bastel mal schnell ein Beispiel dazu.


  Errorbeispiel.vi (Größe: 15,42 KB / Downloads: 172)

@TSchAC
Mich würde mal interessieren wie du deine Fehlerbehandlung bei den kritischen Fällen gestaltest. Schickst du einen Notifier an eine While-Schleife, die nur für die Fehlerbehandlung zuständig ist und dann gestartet wird, wenn ein Notifier gesendet wird?
Ich habe bei meinem Projekt ein ähnliches Problem. Mir schwebt da eine Klassifizierung der Fehler vor. Dazu wollte ich einen Fehlercluster mit einem String (für die Fehlerquelle) und der Fehlerklasse zu einem weiteren Cluster bündeln und diesen dann in einer Whileschleife auswerten.

' schrieb:@TSchAC
Mich würde mal interessieren wie du deine Fehlerbehandlung bei den kritischen Fällen gestaltest. Schickst du einen Notifier an eine While-Schleife, die nur für die Fehlerbehandlung zuständig ist und dann gestartet wird, wenn ein Notifier gesendet wird?
Ich habe bei meinem Projekt ein ähnliches Problem. Mir schwebt da eine Klassifizierung der Fehler vor. Dazu wollte ich einen Fehlercluster mit einem String (für die Fehlerquelle) und der Fehlerklasse zu einem weiteren Cluster bündeln und diesen dann in einer Whileschleife auswerten.

Okay also ich versuchs mal irgendwie in Worte zu fassen. Das ganze ist natürlich ein ziemlich komplexes Thema. Bei mir sind Fehler unterteilt in kritisch und unkritisch.

Zunächst di unkritischen Fehler. Diese Fehler sind eher als Warnung zu verstehen. Sobald ein solcher Fehler auftritt, wird er behandelt und gelöscht. Unkritische Fehler haben keinen Einfluss auf das System, daher muss das Programm nicht beendet werden. Die behandlung dieser Fehler sieht meist so aus, dass ein vermerk in der logdatei hinterlegt wird, der zuständige versuchsleiter per mail informiert wird, gegebenfalls ein flag gesetzt wird um diesen fehler in zukunft zu vermeiden (z.b. fehlerhaftes thermoelement wird bei messung ignoriert).

Kritische Fehler dagegen sind die Fehler, die nicht ohne folgen gelöscht und ignoriert werden können. Dazu gehören Dateizugriffsfehler, systemfehler oder wie vorher schon mal erwähnt hardware gefährdende Fehler. Da in diesen Fällen ein fortfahren das Programms zu großen Problemen (Datenverlust, defekte Hardware, falsche Daten) führen kann wird das programm gestoppt bzw unterbrochen. Da unterscheidet sich allerdings auch wieder einiges. Manche fehler lassen sich durch einwirken des benutzers direkt beseitigen (falsche Pfadangaben, volle Laufwerke usw.) andere erfordern mehr aufwand. Da wird also dann der kritische Fehler bis zum Ende des Programms durchgeschleust. Da in meinen VIs jede aktion mit Fehler ein und ausgang versehen ist, werden nur noch Variablenwerte weiter gereicht. das ist in jedem fall unkritisch. durch das durchschleusen des fehlers bis ans ende des programms ist sichergestellt, dass das programm ordnungsgemäß beendet wird. Es werden alle schleifen beendet und das logfile bzw die noch im speicher befindlichen daten werden gesichert. dann is schluss. natürlich wird noch versucht, den fehler per mail/sms bildschirmpopup und ähnlichen dingen bekannt zu machen. je nach fehler ist das allerdings uach nciht möglcih (internetverbindungen reißen auch mal ab).

Für die Fehlerbehandlung am ende habe ich auch ein eigenes VI. Natürlich mit Fehler eingang und Fehler ausgang!

Ich hoffe das war einigermaßen verständlich.

LG
Torsten