04.03.2022, 09:10
Beitrag #1
|
Kiesch
LVF-Stammgast
Beiträge: 415
Registriert seit: Mar 2009
2019, 2018, 2016
2009
DE
04519
Deutschland
|
Sequentielle Ausführung von Befehlen
Hallo liebe LFVler.
Ich hab mal ne Frage zu timings auf DAQmx Geräten. Konkret:
Ich habe NI USB 6001 und 6002 die ich anspreche. Meine Externe Hardware ist dumm ausgelegt (aber da komm ich nicht drumrum), so dass ich dem Schrittmotortreiber gleichzeitig Highs in FWD und REV senden könnte, was vermutlich zu allem zwischen unerwartetem Verhalten bis frühen Tod führen kann.
Ich bin mir einigermaßen sicher, dass ich das auf der HW Ebene ebenfalls blocken könnte, so dass ich mich um LV timings nicht scheeren müsste, aber das wäre aktuell erheblicher Mehraufwand. Daher meine Frage:
Wenn ich an einem NI USB 6001 oder 6002 auf zwei verschiedene Kanäle desselben Ports schreibe (derzeit als verschiedene Tasks angelegt aus strukturellen Gründen und nicht als Schreiben auf den Port oder in einem Befehl auf denselben Task). Garantiert mir Labview dann eine sequentielle Ausführung in der Ausführungsreihenfolge oder nicht? Oder zumindest (durch den gemeinsamen Port) eine gleichzeitige Ausführung die ebenfalls akzeptabel wäre.
Spricht: Haltet ihr es für hinreichend sicher hier einfach nur ein Wait (100ms?) zwischen den Befehlen einzufügen?
Ist das bei Zusammenfassen in einem Task hinreichend sicher (also eine Schreiboperation für beide Kanäle)?
Ist die Ausführungsreihenfolge überhaupt vom Port abhängig? Ich frage weil ich erwarten würde, dass der Port hardwareseitig immer - auch bei Einzelkanaloperationen - komplett beschrieben wird und Labview das lediglich für mich als Nutzer maskiert. Dementsprechend würde ich hier am ehesten erwarten, dass das irgendwo auf eine Befehlsqueue geht dir mir die Ausführungsreihenfolge garantiert.
Spätestens auf Geräteebene ist die Ausführung ja vermutlich quasiparallel.
Viele Grüße,
Kiesch
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
|
|
|
08.03.2022, 17:09
Beitrag #2
|
|
|
10.03.2022, 13:05
Beitrag #3
|
TpunktN
LVF-Gelegenheitsschreiber
Beiträge: 219
Registriert seit: Jul 2011
2021
2011
EN
70***
Deutschland
|
RE: Sequentielle Ausführung von Befehlen
(04.03.2022 09:10 )Kiesch schrieb: ..so dass ich dem Schrittmotortreiber gleichzeitig Highs in FWD und REV senden könnte, was vermutlich zu allem zwischen unerwartetem Verhalten bis frühen Tod führen kann.
Ich nehme an mit Tot meinst du den des Motors/Anlage, sonst muss ich BNT recht geben und da muss Hardware zum Schutz rein.
Zitat:Ich bin mir einigermaßen sicher, dass ich das auf der HW Ebene ebenfalls blocken könnte, so dass ich mich um LV timings nicht scheeren müsste, aber das wäre aktuell erheblicher Mehraufwand.
Rein um die Hardware zu schützen solltest du das dennoch machen, was schief gehen kann wird irgendwann schief gehen..
Zitat:Wenn ich an einem NI USB 6001 oder 6002 auf zwei verschiedene Kanäle desselben Ports schreibe (derzeit als verschiedene Tasks angelegt aus strukturellen Gründen und nicht als Schreiben auf den Port oder in einem Befehl auf denselben Task). Garantiert mir Labview dann eine sequentielle Ausführung in der Ausführungsreihenfolge oder nicht? Oder zumindest (durch den gemeinsamen Port) eine gleichzeitige Ausführung die ebenfalls akzeptabel wäre.
Da fehlt mir jetzt die Erfahrung, generell würde ich da aber vorsichtig sein, Windows hängt da dazwischen. Ich glaube aber schon, das die Abarbeitungsreihenfolge beibehalten wird.
MfG Timo
Justieren ist dem Gerät sagen was es anzeigen soll, kalibrieren ist die Kontrolle dieser Anzeige. Eichen ist ein längerer Prüfprozess und darf nur das Eichamt!
|
|
|
13.03.2022, 15:50
Beitrag #4
|
|
|
15.03.2022, 15:30
(Dieser Beitrag wurde zuletzt bearbeitet: 15.03.2022 15:36 von Kiesch.)
Beitrag #5
|
Kiesch
LVF-Stammgast
Beiträge: 415
Registriert seit: Mar 2009
2019, 2018, 2016
2009
DE
04519
Deutschland
|
RE: Sequentielle Ausführung von Befehlen
(08.03.2022 17:09 )BNT schrieb: Zitat:zu allem zwischen unerwartetem Verhalten bis frühen Tod führen kann
Wenn die Gesundheit von Menschen (oder z.B. Tieren) in Gefahr ist, muss unbedingt eine Hardware-Lösung implementiert werden!
Gruß Holger
Glücklicherweise nur früher Tod der Hardware. Bei 5 bzw. 24V die angesteuert werden, sehe ich Menschen noch nicht ernsthaft in Gefahr.
(13.03.2022 15:50 )BNT schrieb: "Ich glaube aber schon, das die Abarbeitungsreihenfolge beibehalten wird."
Die Ausführungsreihenfolge wird im LabVIEW nur dann garantiert, wenn es eine Datenfluss Abhängigkeit gibt.
Das kann z. B. auch mittels Semaphore implementiert werden.
Gruß Holger
Das Hauptproblem ist, ich kann über Datenfluss sicherstellen, dass die Befehle nacheinander abgesetzt werden an die Hardware. Ich weiß nur nicht wie sich die Tasks anschließend verhalten - ob die echt nach first available first serve oder FIFO abgearbeitet werden. Und da das unterschiedliche Tasks wären kann ich wie gesagt zwar sicherstellen, dass der eine von Labview definitiv sicher vor dem anderen angehauen wird was zu tun, aber danach verliere ich die Kontrolle übers timing und weiß nicht ob mir da Labview irgendwas garantiert.
Ne echte HW Lösung müsste ich noch zusammenschießen lassen nehme an da müssten NANDs oder NORs rein die den zweiten Kanal blocken solange der erste aktiv ist. Dann kann mir die Ausführung im Labview egal sein, da die HW dann die Reihenfolge garantiert.
Aber im Prinzip weis es keiner genau... schade. NI will für die Info wahrscheinlich nen Wartungsvertrag sehen den wir als Uni leider nicht haben...
Danke euch trotzdem für die Unterstützung.
Gruß Kiesch
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
|
|
|
16.03.2022, 18:09
Beitrag #6
|
Kiesch
LVF-Stammgast
Beiträge: 415
Registriert seit: Mar 2009
2019, 2018, 2016
2009
DE
04519
Deutschland
|
RE: Sequentielle Ausführung von Befehlen
Hab jetzt endlich mal ein Datenblatt von der Treiberkarte gefunden und die interne Verschaltung die ich ansteuere:
Die ist über ANDs eigensicher so verschaltet, dass der Fall HIGH HIGH korrekt abgefangen wird und nicht zu einer Schalthandlung führt. Ergo kann mir das Timing Schnurz sein. Also dann doch kein großere Programmieraufwand da nichts sicherheitskritisches passiert was abgefangen werden muss.
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
|
|
|
| |