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 hätte da mal eine Frage: Und zwar liegt mein Problem darin, dass zu bestimmten, festen Zeitpunkten x1, x2, ..., xn mein Programm Aufgaben erledigen muss. Nun wäre es super, wenn diese Aufgaben so zeitnah wie möglich passieren. Momentan läuft es folgendermaßen, dass ich in einer event-Struktur die vorgegeben Zeitpunkte x1, x2, etc alle 50ms überprüfe. Dementsprechend kann es einen Fehler von 50ms geben...
Ist es denn nicht irgendwie möglich die Zeitpunkte für einen Schleifendurchlauf festzulegen? Geht das vielleicht mit der timed loop structure? Ich würde ja am liebsten das stetige Überprüfen mit einer while-Schleife umgehen wollen und etwas "eleganter" vorgehen (wenn möglich).
Mit einer Timeloop Struktur kannst du genau die Zeit eines Schleifendurchlaufes bestimmen. Die Schleife zeigt auch auf, sollte es Abweichungen in der Ausführungszeit geben.
Die Frage ist, was du genau machen musst / willst zu den Zeitpunkten. Dann kann man auch sagen, wie es eventuell elegant zu lösen geht.
Von einer Eventstruktur würde ich sonst eher abraten für Zeitmessungen. Nutz hier besser den Millisekundentimer oder die Funktion "Bis zum nächsten Vielfachen warten". Damit kannst du zeitkritische Erledigungen bis theoretisch 1ms timen.
Grüße
A few weeks of developement and testing can save a WHOLE afternoon in the library!
Der Benutzer steuert ein Gerät per Software und hat die Möglichkeit 4 verschiedene Ventile zu schalten. Diese 4 Ventile haben jeweils nur 2 Positiionen (offen und geschlossen).
Nun kann der Benutzer für jedes Ventil das Zeitintervall einstellen, in welchem es geschaltet werden soll.
z.B.:
V1 schaltet alle 2,5s,
V2 schaltet alle 10s,
V3 und V4 schalten alle 24,8s.
Es gibt hierfür momentan zwei Möglichkeiten, welche ich angewandt habe:
1) Erstellung eines Zeitpunkt-Arrays, in welchem die Zeitpunkte vorberechnet sind. Die Überprüfung, ob geschaltet werden soll oder nicht, wird in einem timeout vorgenommen.
2) Sequentielles berechnen der Zeitpunkte. Das Programm hat keine festen Zeitpunkte mehr, sondern berechnet nach jedem erfolgtem Schaltvorgang die nächste Schaltzeit.
Das Problem bei den Punkten 1und2 ist, dass ein einfaches Verschieben des Programmfensters, die Subroutinen unterbricht und es zu Unregelmäßigkeiten in den Schaltvorgängen kommt. --> Einfach ein Programm die ganze Zeit verschieben, dann weißt du was ich meine...
Ich hoffe das Problem ist nun etwas klarer geworden
' schrieb:Das Problem bei den Punkten 1und2 ist, dass ein einfaches Verschieben des Programmfensters, die Subroutinen unterbricht und es zu Unregelmäßigkeiten in den Schaltvorgängen kommt. --> Einfach ein Programm die ganze Zeit verschieben, dann weißt du was ich meine...
Ich hoffe das Problem ist nun etwas klarer geworden
Das heisst, das dein zeitkritischen Code im UserInterface ausgeführt wird, und nicht für sich ein eigenes "Execution System" hat.
Da nützt auch die Einstellung "Subroutine" nichts, oder jedenfalls nicht viel.
Das heisst, du musst die Bedienung und die Logik für die Ventile trennen.
Ich nehme mal an, das du das direkt aus der Eventstruktur machst, und das ist falsch.
Dazu gibt es hier viele Themen die das Thema Eventstruktur, StateMachine und Queue thematisieren, lies dich doch mal durch.
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
' schrieb:Das heisst, das dein zeitkritischen Code im UserInterface ausgeführt wird, und nicht für sich ein eigenes "Execution System" hat.
Da nützt auch die Einstellung "Subroutine" nichts, oder jedenfalls nicht viel.
Das heisst, du musst die Bedienung und die Logik für die Ventile trennen.
Ich nehme mal an, das du das direkt aus der Eventstruktur machst, und das ist falsch.
Dazu gibt es hier viele Themen die das Thema Eventstruktur, StateMachine und Queue thematisieren, lies dich doch mal durch.
hmmm, also ich weiß nicht, wie mir da jetzt die state machine weiterhilft...das Problem bleibt das Gleiche: Wenn ich das Fenster bewege, braucht LabVIEW länger zum Ausführen der Prozesse...vielleicht kannst du mir ja in dieser Richtung einen spezifischen Link geben, der das Problem löst.
Anbei ein Beispiel VI in welchem mit einer State-Machine 3 Balken gefüllt und geleert werden.
' schrieb:hmmm, also ich weiß nicht, wie mir da jetzt die state machine weiterhilft...das Problem bleibt das Gleiche: Wenn ich das Fenster bewege, braucht LabVIEW länger zum Ausführen der Prozesse...vielleicht kannst du mir ja in dieser Richtung einen spezifischen Link geben, der das Problem löst.
Anbei ein Beispiel VI in welchem mit einer State-Machine 3 Balken gefüllt und geleert werden.
Viele Grüße und Danke, Martin
LabVIEW Version 8.5:
[attachment=41446:Beispiel.vi]
ist das Ganze zu kompliziert oder trivial? Denn egal, wie ich es bewerkstellige, das Problem bleibt das Gleiche...
' schrieb:ist das Ganze zu kompliziert oder trivial? Denn egal, wie ich es bewerkstellige, das Problem bleibt das Gleiche...
Sorry, aber ich habe im Moment grad etwas wenig zeit.
Habe mir deine Antworten nochmals durchgelesen.
Verwendest du zum ansteuern der Ventile, NI-DAQ/VISA ?
Wenn du damit das ansteuern der Ventile in einer eigenen Schlaufe machst, sollte das automatisch von LV in den DAQ Task gestellt werden und die Ventile werden zeitgenau angesteuert. (soweit das unter Windows halt möglich ist)
Die Anzeige wird aber vermutlich immer noch verzögert sein. (wobei es da auch eine Einstellung, glaube in der INI gibt, fällt mir grad nicht ein)
Ich denke mal, das noch viele das Problem haben und noch gar nie bemerkt haben.
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
' schrieb:Sorry, aber ich habe im Moment grad etwas wenig zeit.
Habe mir deine Antworten nochmals durchgelesen.
Verwendest du zum ansteuern der Ventile, NI-DAQ/VISA ?
Wenn du damit das ansteuern der Ventile in einer eigenen Schlaufe machst, sollte das automatisch von LV in den DAQ Task gestellt werden und die Ventile werden zeitgenau angesteuert. (soweit das unter Windows halt möglich ist)
Die Anzeige wird aber vermutlich immer noch verzögert sein. (wobei es da auch eine Einstellung, glaube in der INI gibt, fällt mir grad nicht ein)
Ich denke mal, das noch viele das Problem haben und noch gar nie bemerkt haben.
so wieder zurück
Hmmm, leider läuft die Ansteuerung nicht über VISA/NI-DAQ sondern über simple serielle Befehle, welche von unserem Gerät verarbeitet werden...
Es muss doch möglich sein, auf die Millisekunde genau eine Aktion auszuführen, ohne zu sehr von der CPU-Auslaustung abhängig zu sein.
Wäre cool, wenn ihr mir da weiterhelfen könntet...
' schrieb:Hmmm, leider läuft die Ansteuerung nicht über VISA/NI-DAQ sondern über simple serielle Befehle, welche von unserem Gerät verarbeitet werden...
Und wie gehen sie seriellen Befehle von LV raus? VISA oder DaqMX? Oder was anderes? Was dann?
Zitat:Es muss doch möglich sein, auf die Millisekunde genau eine Aktion auszuführen, ohne zu sehr von der CPU-Auslaustung abhängig zu sein.
Eigentlich möchte ich sagen, unter Standard-Windows geht "auf die Millisekunde genau" nicht.
Du könntest ein hochpriorisiertes SubVi als Task machen. Das ist dann relativ unabhängig. Nur: Der Nachweis hierfür ist schwierig.
Oder du nimmst ein RT-System.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Eigentlich möchte ich sagen, unter Standard-Windows geht "auf die Millisekunde genau" nicht.
Und wie lange dauert überhaupt das Schalten der Ventile selber? Brauchst du wirklich 1 ms genau? Ist im Standard-Win mit seriellen Befehlen sicher nicht möglich.
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
