LabVIEWForum.de - PSU-VI Problem mit Timer-Abbruch

LabVIEWForum.de

Normale Version: PSU-VI Problem mit Timer-Abbruch
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3
Hallo Tom,

Zitat:Aber jetzt tut die Timer-Ftn gar nichts mehr bzw. gibt lustige Zahlen aus und Verweilt im Zustand, also vermutlich eine Dauerschleife erzeugt. Die Zahl wirkt willkürlich, könnte vllt die Anzahl Sekunden seit Systemstart sein, wobei "1054666:55:58" doch etwas viel scheint.
Leider weiß ich nicht, was in deinem subVI so gemacht wird.
Ich vermute mal, du bekommst die Zeit nach LabVIEW-Epoch, also Sekunden seit 1.1.1904...

Edit:
Habe gerade nochmal deinen Code runtergeladen: wie vermutet die Zeit seit 1.1.1904.
Wenn ich dein TimeEngine-VI mehrfach aufrufe und "advance time" auf TRUE setze, dann funktioniert es wie erwartet...
Seltsam, "sw Pause" entspricht dem "advance time" im Timer-Engine.vi nur eben negiert somit solange auf True bis der Pause-Button gedrückt wird. Aber ich sehe, das ich nen weiteres Wait im Zustand habe, vllt stört das.
Hallo Leute,

ich habe ein schwerweigendes Problem, auf dessen Lösung ich einfach nicht komme. Ich hatte das Problem schon einmal kurz angesprochen, aber nicht die Priorität darauf gesetzt.

Wenn ich das VI starte kann ich zwar noch die Werte für Spannung und Strom setzen, aber sobald ich den Output aktiviere, gibt das Netzgerät den Output frei, allerdings nur für 1-2 Sekunden, danach fällt Strom und Spannung auf 0 ab.

In der QSM wird nach VI-Start kurz in den "Init"-Status gewechselt und anschließend nur noch zwischen dem Status "Main/Idle/WaitForEvent" und dem Status "GET Output/Limit/Mode" hin und her gewechselt, das ist so gewollt. Der "GET..."-Zustand dient nur dem Refresh des Frontpanel und dessen Anzeigen (Indicators).

Setze ich einen Wert, funkt die "Event"-Loop dazwischen und wechselt in den jeweiligen "SET..."-Zustand um anschließend wieder im oben genannten "Main/Idle/WaitForEvent" <=> "GET Output/Limit/Mode" Zustandswechsel zu enden.


Da keine Fehlermeldung ausgegeben wird und ich mir nicht weiter zu helfen weiß, habe ich den "GET Output/Limit/Mode"-Inhalt in ein VI geschmießen, zusammen mit den nötigen "SET..." Funktionen und eine Schleife außenrum gesetzt. Und dieses TEST-VI läuft ohne Probleme...an den SET und GET - SubVIs scheint es also nicht zu liegen.

Jetzt das interessante, sobald ich mein PSU-VI starte, tritt der oben erwähnte Fehler auf und alle Werte fallen auf 0. Das macht auch Sinn, da anfangs der Init-Zustand die Werte auf 0 setzt. Dennoch ist das TEST-VI in dauerschleife und müsste die Werte neu setzen und den Output aktivieren. Und ja, die Werte werden gesetzt, der Output funktioniert aber nicht.
Auch wenn ich zuerst das PSU-VI starte und anschließend das TEST-VI, dann werden zwar auch wieder die Werte für Spannung und Strom des TEST-VI gesetzt, aber es kommt nichts an den Klemmen an. Den Output über das TEST-VI aktivieren bringt nichts.

...Schließe ich das PSU-VI wieder, werden die Werte wieder richtig gesetzt und an den Klemmen des Netzteils richtig ausgegeben.


Woran könnte der Fehler liegen? Könnte es an den oben genannten lokalen Variablen liegen?

Entschuldigt den Wall Of Text, aber ich weiß wirklich nicht mehr weiter.

Ich wäre euch wirklich sehr dankbar für eure Hilfe.


Grüße
Hallo Tom,

Bilder lassen sich echt schlecht in LabVIEW debuggen…

Hast du deine PSU-Statemachine mal debugged? So mit Probes und highlight-Execution? Dann läuft sie zwar deutlich langsamer, aber vielleicht sieht man ja, wann ("bei welchem subVI") deine PSU wieder abschaltet…
Ich habe inzwischen mittels Probe den kompletten "GET Output/Limit/Mode" abgetestet, die beiden "SET OutputVoltage" und "SET OutputCurrent", sowie den "SET OutputOn/OFF" Zustand überprüft, nichts auffälliges, alles läuft wie es soll.

Überprüft ob vllt einer der Buttons im csv-Modus aktiv ist, ohne es zu wissen, aber nein und zur Sicherheit in jeden Zustand eine Fallunterscheidung ob csv-Modus aktiv ist, eingebaut.

Mit externen Tool mit welchem es möglich ist einzelne Befehle ans PSU zu schicken, genutzt und nachdem das PSU-VI in den Fehler gelaufen ist, die Spannungs- und Stromwerte geändert, funktioniert. Den Output aktivieren/deaktivieren und wieder aktivieren, scheint am PSU anzukommen, da bei Anfrage an das PSU, dieses passend antwortet.

Also, die Spannung und Strom kann gesetzt werden, Klemmen-Ausgabe mittels Output On/Off auch, aber es passiert nichts an den Klemmen, nachdem der Fehler eintritt.

Ich bin inzwischen komplett ratlos. Ich könnte mir höchstens noch vorstellen, dass das PSU mit zuviel Befehlen gefüttert wird und dieses in einen internen Fehlermodus wechselt, aber es gibt auch keinen Fehler aus...
Hallo nochmal,

Es geht um das Thema übertragen von Daten zwischen Event Loop und Message Handling Loop. Ich verstehe noch das Senden von Event Loop (EL) nach Message Handling Loop (MHL), aber wie packe ich Daten umgekehrt von der MHL in die EL? Wie sieht der Aufbau aus? Könntet ihr mir bitte das anhand eines States zeigen? Verstehe ich das richtig, dass man "To Variant" nur einmal setzen muss, um im Kommando-Cluster diesen "Datentyp" anzulegen und danach nicht mehr nötig ist?

Wie wechsel ich in der MHL den Zustand, also wie bekommen ich die Zustandsänderung in die Kommando-Leitung (Queue-Leitung?)?
Benötige ich für den Datenverkehr Register durch beide Loops?

Anbei mein Versuch der Umsetzung.

Danke für eure Hilfe.

Grüße
Hallo Tom,

Zitat:wie packe ich Daten umgekehrt von der MHL in die EL?
Ist das Senden der Daten in die Event-Loop wirklich nötig?
Eine Event-Loop bearbeitet Events, also könntest du ein User-defined Event verwenden und so Daten in die Eventloop hinein senden…

Zitat:Wie wechsel ich in der MHL den Zustand, also wie bekommen ich die Zustandsänderung in die Kommando-Leitung (Queue-Leitung?)?
In dem du einfach ein entsprechendes Kommando in die Queue schreibst. Die Queue-Referenz ist ja in der Message-Loop bekannt…

Statt der Wartezeit in der Messageloop könntest du auch ein TimeOut beim Dequeue verwenden. Und du könntest das TimeOut des Dequeue auswerten und in diesem Fall eh gleich den Idle-State aufrufen…

Beides mal im Bild:
[attachment=62757]

Zu deinem "Test String-CommaToPoint": mit dem richtigen Formatcode ist das etwas sehr einfaches mit FormatIntoString/ScanFromString! Einfach mal die Hilfe zu beiden Funktionen lesen und auf die Tabelle mit den Formatcodes achten…
Guten Tag,

vielen Dank für das Beispiel.
Ich habe gerade nochmal paar Test durchgeführt, u. a. auch Last an und abschließen. Seltsam dabei ist, dass der Fehler nicht auftritt, wenn a) keine last an den Klemmen hängt und b) wenn zusätzlich zur Spannung ein Strom eingestellt ist. Setze ich nur die Spannung und öffne den Output, tritt der Fehler genauso auf, wie wenn ich eine Last an die Klemmen hänge und Spannung wie Strom einstelle.
Die Last ist btw ein 25 Ohm Widerstand welcher maximal 300W aushält. Meine Grenzen sind dementsprechend gesetzt.

Könnt ihr damit was anfangen? Könnte es am Netzteil liegen? Oder könnte dafür eine Race Condition verantwortlich sein?

Update: Die Spannung fängt nach 3min doch an langsam richtung 0V zu fallen. Man kann nach 3min förmlich zuschauen, wie sie alle paar Sekunden um ca. 100mV fällt...
Wieso hält sich die Spannung ohne Last aufrecht und fällt nicht sofort ab, wie in all den anderen Fällen? Ist das die Restspannung im Kondensator des Netzteils?

Grüße
Hallo Tom,

Zitat:Ich habe gerade nochmal paar Test durchgeführt, u. a. auch Last an und abschließen. Seltsam dabei ist, dass der Fehler nicht auftritt, wenn a) keine last an den Klemmen hängt und b) wenn zusätzlich zur Spannung ein Strom eingestellt ist. Setze ich nur die Spannung und öffne den Output, tritt der Fehler genauso auf, wie wenn ich eine Last an die Klemmen hänge und Spannung wie Strom einstelle.
Dann stell doch einfach einen Strom ein, wenn der Fehler dann nicht mehr auftritt…

Wie sehen denn die OV/OC-Anzeigen aus, wenn der Fehler auftritt?

Zitat:Update: Die Spannung fängt nach 3min doch an langsam richtung 0V zu fallen. Man kann nach 3min förmlich zuschauen, wie sie alle paar Sekunden um ca. 100mV fällt...
Wieso hält sich die Spannung ohne Last aufrecht und fällt nicht sofort ab, wie in all den anderen Fällen? Ist das die Restspannung im Kondensator des Netzteils?
Wenn ohne Last die Spannung fällt, stimmt irgendwas mit deiner PSU nicht (vielleicht hast du ja noch irgendeine Einstellung vergessen/übersehen). Hast du mal mit dem Delta-Service darüber gesprochen?
Der Fehler tritt auch auf, wenn ich den Strom setze, allerdings erst nach 2-3 Minuten. Also ist es nur für 3min fehlerfrei, wenn neben der Spannung auch der Strom gesetzt ist und auch nur, wenn keine Last an den Klemmen hängt...

Ich denke es liegt an meiner State Machine. Denn wenn ich nur meine SubVIs für Spannung und Strom setzen und alle GET-SubVIs zum auslesen des Netzgeräts in eine Schleife schmeiße funktioniert alles wunderbar.
Kann der Typ der StateMachine, also die QSM diese Art von Fehler hervorrufen? Können lokale Variablen dafür verantwortlich sein?

Du hast vermutlich recht, mein VI ist deaktiviert, die Werte sind Laut Display-Anzeige direkt am Gerät noch gesetzt. Wenn ich den "Klemmen"-Output direkt am Gerät aktiviere passiert nichts, kein Output!
Scheinbar setzt mein VI irgendwo eine Art Output-Sperre obwohl dieser aktiviert ist?!
Der Watchdog ist deaktiviert, das habe ich als erstes überprüft...

Manchmal meldet das Netzteil auch einen DC-Fail. Der Fehler tritt laut Bedienungsanleitung auf, wenn die Gleichstromquellen 5% unter oder über dem Setzwert der Spannung sind.

Noch etwas, mein VI scheint vor allem nach auftreten des Fehlers immer langsamer zu werden.
Seiten: 1 2 3
Referenz-URLs