Hallo Tom,
Zitat: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?
- Die QSM (als Konstrukt an sich) wird diesen Fehler nicht hervorrufen. Nur der Code, den du innerhalb der QSM aufrufst (und wie oft du ihn aufrufst), kann den Fehler bewirken…
- Lokale Variablen an sich auch nicht - nur eben wieder die Werte, die sie enthalten. Ändert sich der Wert einer lokalen Variable irgendwann? Wozu benötigst du hier überhaupt (noch) lokale Variablen?
Wenn deine Schleife wirklich wie gewünscht funktioniert, dann packst du den enthaltenen Code in ein subVI und rufst dieses eine subVI in deiner QSM auf. Der Code sollte dann genauso wie in der Schleife funktionieren!
Guten Tag,
ich nutze für die Erstellung des rampenförmigen Signalverlaufs zwei Zustände. Im "csv StartMeasurement"-Zustand erzeuge ich die Rampe und gib diese per For-Loop aus. Im "csv WaitMeasurementTime"-Zustand wird einfach eine gewisse Zeit gewartet, solange eben der Plateau-Wert gehalten werden soll.
Aber der Timer zählt nicht durch, sondern nur 1 bis 2 sekunden, dann passiert für 2 Sekunden nichts und anschließend wird wieder weitergezählt. Der Zahlenwert des Timers verläuft erst normal, zählt also hoch (z. B. 1, 2, 3), stoppt für 2 Sekunden und zählt dann aber weiter, aber mit den 2 Sekunden berücksichtigt (also 6, 7, 8) und das durchgehend. Scheint als würde die State Machine in den Timeout wechseln und damit in den Frontpanel-Refresh-Zustand "GET Output/Limit/Mode" regelmäßig wechseln.
Wie kann ich das für bestimmte Zustände unterbinden? Ist das überhaupt möglich?
Danke für eure Hilfe.
Grüße
Hi Tom,
Zitat:Wie kann ich das für bestimmte Zustände unterbinden? Ist das überhaupt möglich?
In einer Statemachine legst du programmatisch fest, welcher State als nächster aufgerufen wird. Wenn also nicht der richtige State abgearbeitet wird, dann ist dein Programm nicht korrekt...
Wie kann das sein? Ich gebe ja in jedem Zustand den Folgezustand an und dennoch wechselt die StateMachine in den Idle bzw. Refresh.
In der aktuellen Version wechsel ich von "csv StartMeasurement" zu "csv UI" um das Frontpanel zu deaktivieren, dann in "csv RampVoltage", sowie " csv RampCurrent" um die Rampen für Spannung und Strom aufzubauen. Anschließend gehts in besagten "csv WaitMeasurementTime"-Zustand, wo der Fehler auftritt. Dieser Zustand ruft sich solange selbst auf, bis die vorgegebene Zeit erreicht wird. Naja er ruft sich auch selbst auf, allerdings eben mit dieser Gedenkpause dazwischen.
Die Selbe "Gedenkpause" tritt übrigends später auch im bzw. nach dem "csv NextPoint"-Zustand auf. Dort wird entschieden, ob ein weiterer RampenaufbauZyklus durchlaufen werden soll.
Mein VI ist im allg. langsam, aber besonders nach auftreten des Fehlers reagiert das VI extrem langsam.
Wie sieht es mit Referenzen aus um Teile des Frontpanels zu deaktivieren? Frisst das viel Zeit?
Hi Tom,
Wie das sein kann?
LabVIEW und andere Programmiersprachen machen normalerweise nur das, was programmiert wurde. Aber selbst, wenn es doch einmal anders sein sollte, hilft Debuggen immer - ganz sicher :-)
Wenn du deine VIs in einer älteren LabVIEW Version speichern würdest, dann könnte ich und viele andere einmal einen Blick darauf werfen und vielleicht auch etwas mehr dazu sagen.
Hallo Tom,
Zitat:Wenn du deine VIs in einer älteren LabVIEW Version speichern würdest, dann könnte ich und viele andere einmal einen Blick darauf werfen und vielleicht auch etwas mehr dazu sagen.
Das gilt auch für mich…
Außerdem: bitte deine Signatur anpassen, wenn du jetzt eine neue(re) LabVIEW-Version nutzt!