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!
(30.05.2012 11:32 )M Nussbaumer schrieb: Ist passwortgeschützt Aber versteh ich das grundsätzlich richtig, du stellst in den verschiedenen Tabs deine Messwerte dar welche durch unabhängige (Datenmässig) Messungen erfasst wurden?
Gruss Marc
Ja, das siehst du richtig. Habs neu angehängt, ohne Passwort...
Neu, aber motiviert. Nehme immer gern Verbesserungsvorschläge an!
Das ganze VI konnte ich leier nicht begutachten, da mein Bildschirm dafür nicht ausreicht.
Hier noch ein Punkt, der mir gleich aufgefallen ist. Auch hier scheint eher gebastelt worden zu sein:
Eventstruktur und Case-Struktur (Messung starten) passen so nicht ganz zueinander? Oder ist das noch die Umbauphase? Selbst bei einem Klick auf 'Messung starten' kann ich mir nicht vorstellen, dass die Messung 'immer gestartet' wird, da der Button parallel zum Ereignis abgefragt wird.
Auch hier sei auf die Programmstruktur 'Producer-Consumer'-verwiesen, die sich hier super eignen würde. Buttonabfragen per Event. Und ein Verbraucher der darauf reagiert und aktiv wird. Dies kann man natürlich auch mit einer Statemaschine (im Verbraucher) kombinieren, muss aber nicht sein, kommt auf das Ergebniss an, was am Ende rauskommen soll.
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
(31.05.2012 06:19 )NWOmason schrieb: Eventstruktur und Case-Struktur (Messung starten) passen so nicht ganz zueinander? Oder ist das noch die Umbauphase? Selbst bei einem Klick auf 'Messung starten' kann ich mir nicht vorstellen, dass die Messung 'immer gestartet' wird, da der Button parallel zum Ereignis abgefragt wird.
Das ist sozusagen die aktuelle Baustelle. Hier versuche ich gerade zu überlegen, wie ich das machen soll.
Zitat:Auch hier sei auf die Programmstruktur 'Producer-Consumer'-verwiesen, die sich hier super eignen würde. Buttonabfragen per Event. Und ein Verbraucher der darauf reagiert und aktiv wird. Dies kann man natürlich auch mit einer Statemaschine (im Verbraucher) kombinieren, muss aber nicht sein, kommt auf das Ergebniss an, was am Ende rauskommen soll.
Hmm, ok. Ist dann das so gemeint, dass ich in einem Event Abfrage, ob der Button gedrückt wurde, dann Queue ein Signal an eine parallel liegenden Case Fall schicke. Ist der einzige Vorteil daran nicht, dass ich mehrer Buttonklicks hintereinander abarbeiten kann? Warum packe ich nciht einfach die komplette Case Abfrage, die in dem obigen Ausschnit für den "Messung starten" Button zu sehen ist, nicht in die Eventstruktur direkt? Habe jetzt gesucht und gefunden, dass die Struktur toll ist, aber nicht warum.
Grüße,
Takuro
Neu, aber motiviert. Nehme immer gern Verbesserungsvorschläge an!
(31.05.2012 08:32 )Takuro schrieb: Hmm, ok. Ist dann das so gemeint, dass ich in einem Event Abfrage, ob der Button gedrückt wurde, dann Queue ein Signal an eine parallel liegenden Case Fall schicke.
Genauer gesagt, an die Schleife, welche parallel läuft
(31.05.2012 08:32 )Takuro schrieb: Warum packe ich nciht einfach die komplette Case Abfrage, die in dem obigen Ausschnit für den "Messung starten" Button zu sehen ist, nicht in die Eventstruktur direkt?
Theoretisch geht das schon, dann ist aber die Eventstruktur solange blockiert, bis der Eventcase abgearbeitet ist. Es wird dann auf keine weitere Benutzereingaben reagiert. Erst, wenn der Eventcase fertiggestellt ist, werden die anderen Eingaben abgearbeitet. Generell benutzt man die Eventstruktur um auf Benutzereingaben zu reagieren, diese aber an anderer Stelle abarbeiten zu lassen.
Wenn dies bei dir aber generell nicht der Fall ist, sondern immer die gleichen Reihenfolge der Benutzereingaben zu tätigen ist, dann ist eine State-Machine die bessere Wahl.
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
Die Reihenfolge dabei ist beliebig. Daher ist ne State-Maschine nicht das richtige. Die wäre gut, wenn er z.B. immer erst Schritt a macht, dann b dann c usw. Sobald die Messung gestartet ist, soll er nix anderes mehr amchen können. Deswegen kann ich den in die Eventstruktur direkt integrieren, weil dann solange automatisch die Abfrage der anderen Buttons angehalten wird.
Wenn ich aber z.B. lange Zeit brauchen würde, bis der Parametersatz eingeladen ist, wäre ein Producer/Consumer teil nicht schlecht, damit der Nutzer gleichzeitig dann auch einen Parametersatz manuell eingeben kann. Wenn aber der Nutzer gar keine Zeit verstreichen sieht, bis der Parametersatz eingeladen ist weil die sofort abgearbeitet ist, dann brauche ich auch keine Producer/consumer Struktur, dann reicht mir eine Eventabfrage für alles.
Habe ich das so richtig zusammengefasst?
Ziemlich interessante Strukturen, die es da gibt, wenn man weiß wann man was einsetzten kann.
Grüße,
Takuro
Neu, aber motiviert. Nehme immer gern Verbesserungsvorschläge an!
(31.05.2012 09:11 )Takuro schrieb: Die Reihenfolge dabei ist beliebig.
Was ja für Prod/Con spricht. Aueßerdem kann er ja auch mit dem gleichen Parametersatz mehrere Messungen hintereinander machen wollen.
(31.05.2012 09:11 )Takuro schrieb: Deswegen kann ich den in die Eventstruktur direkt integrieren, weil dann solange automatisch die Abfrage der anderen Buttons angehalten wird.
Nein, das ist nicht ganz richtig. Die Interaktion mit den anderen Element wird schon erfasst, aber erst abgearbeitet, wenn der Eventcase mit der Messung abgearbeitet ist.
Man kann zwar das FP in der Zeit locken, die Events werden aber trotzdem registriert.
LabVIEW Help schrieb:Lock front panel (defer processing of user actions) until this event case completes—Locks the front panel when this event occurs, deferring processing of further user action until all Event structures finish handling this event. You can turn this option off for notify events but not for filter events. Caution Make sure your Event structure is in a loop which executes often to ensure your user interface is responsive. If no Event structure executes to handle an event and front panel locking is enabled, the user interface of the VI becomes unresponsive.
Was du natürlich machen kannst, dass du alle FP-Elemente deaktivierst (disabled & greyed out), wenn die Messung gestartet ist. Nach Beenden der Messung wieder aktivieren. Kann es auch vorkommen, dass die Messung abgebrochen werden kann?
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
(31.05.2012 09:11 )Takuro schrieb: Die Reihenfolge dabei ist beliebig.
Was ja für Prod/Con spricht. Aueßerdem kann er ja auch mit dem gleichen Parametersatz mehrere Messungen hintereinander machen wollen.
Hier muss ich glaub ich anführen, dass eine Messung in der Regel meherer Stunden, wenn nicht Tage dauert. Minimum jedoch 45 min.
Zitat:
(31.05.2012 09:11 )Takuro schrieb: Deswegen kann ich den in die Eventstruktur direkt integrieren, weil dann solange automatisch die Abfrage der anderen Buttons angehalten wird.
Nein, das ist nicht ganz richtig. Die Interaktion mit den anderen Element wird schon erfasst, aber erst abgearbeitet, wenn der Eventcase mit der Messung abgearbeitet ist.
Man kann zwar das FP in der Zeit locken, die Events werden aber trotzdem registriert.
Jap, ist mir bewusst, hab mich falsch ausgedrückt.
Zitat:Was du natürlich machen kannst, dass du alle FP-Elemente deaktivierst (disabled & greyed out), wenn die Messung gestartet ist. Nach Beenden der Messung wieder aktivieren. Kann es auch vorkommen, dass die Messung abgebrochen werden kann?
Deaktivieren tue ich bereits. Ja, die Messung kann auch über einen Button abgebrochen werden. Die Abbruchbedingung ist entweder Manueller Abbruch, alle Parametersätze abgearbeitet oder Ausfall der Versorgung der Anlage mit Trägersubstanz.
Ich denke das einzig Sinnvolle wäre hier Producer/consumer, was allerdings aufgrund von extrem kurzen Verarbeitungszeiten von einzelnen Nutzereingaben eher eine Spielerei ist, weil der Nutzer nicht merkt, dass es direkt in der Eventstruktur steht und somit angehalten wird. (In meinem Gesicht steht hier jetzt ein "Oder?" )
Grüße,
Takuro
Neu, aber motiviert. Nehme immer gern Verbesserungsvorschläge an!
(31.05.2012 09:41 )Takuro schrieb: Ich denke das einzig Sinnvolle wäre hier Producer/consumer, was allerdings aufgrund von extrem kurzen Verarbeitungszeiten von einzelnen Nutzereingaben eher eine Spielerei ist, weil der Nutzer nicht merkt, dass es direkt in der Eventstruktur steht und somit angehalten wird. (In meinem Gesicht steht hier jetzt ein "Oder?" )
Wobei man das ganze dann schon nochmal hinterfragen muss. Aktuell wird der 'Messung beenden'-Button ja nur abgefragt, wenn die Messung läuft. Würdest du alles ein eine Eventstrukur packen, wie du es bis jetzt beschrieben hast, kannst du diesen Button natürlich nicht per Event abfragen, was aber die Eventstruktur wiederrum ad absurdum führt
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
Ich habe mich jetzt entschloßen, die schon gezeigte Eventstruktur zu behalten und dort noch die Messung starten Case abfrage zu integrieren. Der Button zum Abbrechen der MEssung bleibt so wie er ist. Das sollte mMn funktionieren, leider geht gerade Testen nicht.
Aber wird schon. Danke für die viele Info und Hilfe!
Grüße,
Takuro
Neu, aber motiviert. Nehme immer gern Verbesserungsvorschläge an!
Aber versteh ich das grundsätzlich richtig, du stellst in den verschiedenen Tabs deine Messwerte dar welche durch unabhängige (Datenmässig) Messungen erfasst wurden?
Hier versuche ich gerade zu überlegen, wie ich das machen soll.