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!
22.09.2014, 16:31 (Dieser Beitrag wurde zuletzt bearbeitet: 01.10.2014 20:33 von jg.)
als Einleitung:
Ich bin relativ frisch in der Materie und habe schon etwas im Forum quer gelesen, um Anregungen zu finden, wie man ein vernünftiges Programm aufbaut.
Als Anwendung habe ich für meine Bachelor-Thesis (Fachrichtung Maschinenbau) einen Prüfstand aufgebaut, der zyklisch rein schwellend eine Bolzen-Gelenkverbindung belastet. Ohne jetzt näher darauf einzugehen, muss dennoch erwähnt werden, dass am langen Ende eine Kraft mit einem HBM C2 Kraftaufnehmer gemessen wird, dessen Signal geht in ein QuantumX MX840A. Isochron dazu läuft ein QuantumX MX878, um ein 4/2-Wegeventil anzusteuern.
In dem VI (und diversen SubVIs...) wird die gemessene Kraft mit einer einstellbaren Ober- und Untergrenze verglichen, das ganze läuft dann im Prinzip im Zweipunkt-Regler-Betrieb.
Mein PC kommuniziert über Ethernet und einem Switch mit den Messverstärkern. Ich habe dafür die von HBM mitgelieferten Beispiel-VIs QX_GetAllMeasVals.vi zum Messen und QX_ConfigAnalogOutChannel.vi. verwendet - und natürlich diverse andere zum Verbindungsaufbau etc.
Ehrlich gesagt weiß ich gerade nicht, was ich jetzt alles beschreiben soll, ohne mit sinnlosen Infos alles zu überfluten. Wenn was essenzielles fehlt, bitte einfach kurz ein Stichwort nennen ;-).
Ich hänge alle VIs natürlich an.
Nun aber zu meinem eigentlichen Problem. Die Dauer für eine Schleife innerhalb des VIs beträgt mindestens 12ms. Hinzu kommt, dass das Programm mindestens 3 Schleifenumläufe braucht, um eine gewünschte Reaktion zu zeigen. Ich habe das einmal an Hand dieses nachfolgenden Bildes zu verdeutlichen versucht. Im oberen Teil der gemessene Kraftverlauf, die horizontalen Linien zeigen die angestrebten Hysteresegrenzen. Im unteren Teil ist einmal die gemessene Ventilposition (grau) und, was hier das eigenartigste ist, die Variabel, die im Programm die Ventilposition steuern soll. Und eben diese bleibt mehrere Schleifendurchläufe auf ihrem "alten" Wert stehen, obwohl sie schon längst umspringen sollte. Auf der x-Achse ist die Zeit in ms aufgetragen.
Wie kann das sein?
Zu der Schleifendauer: sicherlich gibt meine Programmstruktur Raum für Optimierung ;-). Ich habe schon viel geändert (ich habe mit 30ms angefangen...), meine fehlende Erfahrung ist da sicherlich ein Problem. Hier im Forum habe ich die goldene Regel gelesen a la "passt dein Programm nicht auf den Bildschirm, ist es zu groß". Daran muss ich definitiv noch immens arbeiten! Das würde sicherlich einiges an Übersichtlichkeit mit sich bringen... Dass das bisher noch nicht passiert ist, dafür entschuldige ich mich bei allen, die sich das anschauen...
Zum Anderen habe ich leider keine Ahnung, was genau ich entfernen sollte, was also Perfomance-Einbußen mit sich bringt, und was ruhig drin bleiben kann. Beispielsweise habe ich eben einmal im "obersten" VI alles entfernt, was nicht unbedingt notwendig ist - ohne erkennbaren Mehrwert.
Fällt euch vielleicht auf einen Blick etwas auf, was möglichst zu unterlassen wäre, wenn man schnell arbeitende Programme haben möchte?
Letztendlich, damit mein Programm für meine Anwendung brauchbar ist, bräuchte ich eine Schleifendauer von ~1ms.
Ich habe einmal Spaßes halber ein kleines Programm geschrieben, was einfach nur eine Schleife hat, worin bis 30.000.000 gezählt wird. Das dauert etwa 1ms...
Großen Einfluss auf die Schleifendauer, das habe ich bereits ausgeklügelt, ist die Messrate der Messverstärker. Gibt es andere Aspekte, die euch pauschal auffallen?
Über eine Antwort würde ich mich sehr freuen! Ich bemühe mich, so viele Infos nachzuliefern, sofern gewünscht!
Edit jg: VI-Anhang auf Wunsch der M.K.D. gelöscht.
Ein Nachtrag zur Dauer einer Schleife:
Trage ich diese über die Zeit auf, stelle ich fest, dass sie teilweise kurzzeitig explodiert. Siehe Bild unten...
Wenn ich das hier richtig interpretiere, hält sich das Interesse an einer Lösung des Problems in Grenzen.
Habe sowieso eine ernüchternde Antwort von HBM bekommen (AnalaogOut über LabVIEW schneller als ~6ms geht nicht), der Thread kann daher geschlossen werden.
Viele Grüße
Matthias
LV2013 SP1 Studentenversion
01.10.2014, 14:34 (Dieser Beitrag wurde zuletzt bearbeitet: 01.10.2014 14:37 von GerdW.)
Zitat:Wenn ich das hier richtig interpretiere, hält sich das Interesse an einer Lösung des Problems in Grenzen.
- Es ist dein Problem, nicht unser.
- Du hast dein VI in LV2013 angehangen. Nicht jeder hier hat diese Version installiert und damit Zugriff auf das BD.
- Nicht jeder hier hat ein Quantum-Gerät auf dem Schreibtisch stehen, um das Problem nachzuvollziehen…
- Manche schauen nur auf die Threads, die in den letzten 24/48 Stunden aktiv waren. Da rutscht dein Thread schnell mal durch…
Zitat:Habe sowieso eine ernüchternde Antwort von HBM bekommen (AnalaogOut über LabVIEW schneller als ~6ms geht nicht)
Dann hat Quantum aber einen schlechten Treiber geliefert…
Hast du inzwischen eine Lösung?
Das von dir gezeigte Bild kann alle möglichen Ursachen haben - die müssen nicht mal was mit dem Quantum-Treiber zu tun haben…
@GerdW: Das Main-VI von M.O.:
Willst du das wirklich in einer 2011-Version sehen? ;-)
--
@M.O. / K.D.:
- Wieso liest du immer im Federberechungs-VI den csv-File "Tellerfedersaeulen.csv" von der HDD?
- Vorsicht vor Race-Conditions zwecks massivem Einsatz lokaler Variabler.
- etc. pp.
Gruß, Jens
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!
Zitat:Wenn ich das hier richtig interpretiere, hält sich das Interesse an einer Lösung des Problems in Grenzen.
- Es ist dein Problem, nicht unser.
- Du hast dein VI in LV2013 angehangen. Nicht jeder hier hat diese Version installiert und damit Zugriff auf das BD.
- Nicht jeder hier hat ein Quantum-Gerät auf dem Schreibtisch stehen, um das Problem nachzuvollziehen…
Das war keineswegs zynisch gemeint. Mir ist klar, dass das nicht jeder meine Kombination vor sich stehen hat und ich meinte das einfach nur so, dass ich mit dem Problem tatsächlich alleine dastehe und es wirklich ganz alleine mein Problem ist ;-)
Aber kommen wir zum sachlichen...
(01.10.2014 14:34 )GerdW schrieb:
Zitat:Habe sowieso eine ernüchternde Antwort von HBM bekommen (AnalaogOut über LabVIEW schneller als ~6ms geht nicht)
Dann hat Quantum aber einen schlechten Treiber geliefert…
Hast du inzwischen eine Lösung?
Das von dir gezeigte Bild kann alle möglichen Ursachen haben - die müssen nicht mal was mit dem Quantum-Treiber zu tun haben…
@Jens:
An meiner Programmstrukur etc, arbeite ich ;-) Den Seitenhieb nehme ich mit Würde an.
Viele der SubVIs (u.a. die Federberechnung) sind alle bereits rausgeflogen, da ich dort die Ursache vermutete. Wenn ich nur den Zugriff auf Steuerung und Messung über eine CaseStructure deaktiviere, braucht meine Schleife 0...1ms. Das heißt nicht, dass da nicht noch einiges schöner und besser werden kann, aber ich denke, ich bin auf dem richtigen Weg.
Ich bemühe mich gerade, die FlatSequence Structure zu verstehen und das dahingehend umzubauen. Auch die Sache mit den lokalen Variablen habe ich auf dem Schirm und nehme ich in Angriff.
Hier einmal meine Anfrage an HBM mit Antwort darunter:
ich schrieb:Wie bereits erwähnt benutze ich für meine Anwendung LabVIEW und greife größtenteils auf die von Ihrer Firma mitgelieferten VIs zurück. Das Problem ist nun, dass die Schleifendauer meines Programms für meine Anwendung mit ~15ms viel zu hoch ist. Ich habe festgestellt, dass dabei das Ansprechen eines Messkanals in meinem MX840A die Schleife etwa um 5ms erhöht und das Ansprechen eines Analogen Ausgangskanals im MX878 15-17ms dauert. Ich habe das einmal geplottet. Untenstehend zunächst nur mit eingeschaltetem Messsignal (ein Kanal), dann bei dem Sprung wurde das VI aktiviert, welches die Steuerung ermöglicht. Gemessen wird die Zeitdifferenz zwischen dem Milisekundenzeitstempel des aktuellen, sowie des vorherigen Schleifendurchlaufs.
Gibt es eine Möglichkeit, das ganze schneller laufen zu lassen?
Die Kommunikation läuft über Ethernet und ein Switch.
Was mich auch wundert, sind die heftigen Ausschläge.
Gibt es da eine Möglichkeit, das Ganze zu beeinflussen? Ich habe schon festgestellt, dass die Einstellungen, zu denen Sie mir in der vorherigen Anfrage geraten haben, das Ergebnis verbessert haben. Gibt es da vielleicht noch andere Stellschrauben?
*Hinweis: in der "vorherigen Anfrage" wollte ich wissen, ob die Anregelzeit für den analogen Ausgang auch in schnell geht (war zunächst auf Grund eines fehlerhaft gewählten Filters bei ~30ms). Das wirkte sich auch auf das VI aus, was mir nicht ganz schlüssig ist... als ob die Schleife darauf warten würde, bis das Signal voll anliegt. Aber das ist hier ein bisschen
HBM schrieb:Ein Messignal mittels GetSinglePoint(wird vom VI benutzt und dauert in der regeln ~6ms) dauert ziemlich viel. Hier könnte man stattdessen eine "richtige" Messung aufsetzen und einfach immer den letzten gelieferten Messwert holen- ich denke das wäre schneller.
Den AnalogOut zu setzen dauert mit diesem VI leider ziemlich lange, da der ganze Connector dem Gerät zugewiesen wird (AssignAdditionalConnector).
Es gibt auf LabVIEW-Treiber Ebene leider keine schnellere Möglichkeit.
Die neue CommonAPI und der darauf basierende HBM LabVIEW Driver wird das Prozess schneller behandeln. Laut unserer Entwicklung das Setzen eines AnalogOut wird ca. 6 ms für Quantums statt wie hier ~15 ms.
(01.10.2014 17:30 )Kurt.Döner schrieb: @Jens:
An meiner Programmstrukur etc, arbeite ich ;-) Den Seitenhieb nehme ich mit Würde an.
Viele der SubVIs (u.a. die Federberechnung) sind alle bereits rausgeflogen, da ich dort die Ursache vermutete. Wenn ich nur den Zugriff auf Steuerung und Messung über eine CaseStructure deaktiviere, braucht meine Schleife 0...1ms. Das heißt nicht, dass da nicht noch einiges schöner und besser werden kann, aber ich denke, ich bin auf dem richtigen Weg.
Ich bemühe mich gerade, die FlatSequence Structure zu verstehen und das dahingehend umzubauen. Auch die Sache mit den lokalen Variablen habe ich auf dem Schirm und nehme ich in Angriff.
SubVIs kannst du ruhig verwenden und drinnen lassen. Sie machen das Blockdiagramm übersichtlicher und den Programm-Ablauf nicht wesentlich langsamer.
Aber bitte nicht alles auf Flat-Sequence umbauen, dafür gibt es
1) Datenfluss
2) State-Machines.
Eine mögliche Bremse ist in deinem neuen Screenshot jetzt zu erkennen: Der File-Access!!! Schreiben von Daten hat in einer "schnellen" Regelschleife nichts verloren, das gehört in einen parallelen Prozess, der bei Bedarf abgearbeitet wird.
Gruß, Jens
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!
(01.10.2014 17:30 )Kurt.Döner schrieb: @Jens:
An meiner Programmstrukur etc, arbeite ich ;-) Den Seitenhieb nehme ich mit Würde an.
Viele der SubVIs (u.a. die Federberechnung) sind alle bereits rausgeflogen, da ich dort die Ursache vermutete. Wenn ich nur den Zugriff auf Steuerung und Messung über eine CaseStructure deaktiviere, braucht meine Schleife 0...1ms. Das heißt nicht, dass da nicht noch einiges schöner und besser werden kann, aber ich denke, ich bin auf dem richtigen Weg.
Ich bemühe mich gerade, die FlatSequence Structure zu verstehen und das dahingehend umzubauen. Auch die Sache mit den lokalen Variablen habe ich auf dem Schirm und nehme ich in Angriff.
SubVIs kannst du ruhig verwenden und drinnen lassen. Sie machen das Blockdiagramm übersichtlicher und den Programm-Ablauf nicht wesentlich langsamer.
Aber bitte nicht alles auf Flat-Sequence umbauen, dafür gibt es
1) Datenfluss
2) State-Machines.
Ich meinte natürlich nicht grundsätzlich SubVIs (sorry für's Missverständnis!), sondern grundsätzlich Komponenten, wie zB den Datenzugriff auf die von dir genannte Datei!
Rest arbeite ich ab, danke für die Hinweise!
(01.10.2014 18:08 )jg schrieb: Eine mögliche Bremse ist in deinem neuen Screenshot jetzt zu erkennen: Der File-Access!!! Schreiben von Daten hat in einer "schnellen" Regelschleife nichts verloren, das gehört in einen parallelen Prozess, der bei Bedarf abgearbeitet wird.
Das ist mir klar, den Effekt kann ich 1:1 sehen, schalte ich ihn über die CaseStructure ein, geht die Schleifendauer etwas hoch. Das kostet mich tatsächlich 3-5ms. Aber das ist berücksichtigt!
Grundsätzlich muss ich mir noch überlegen, wie ich das mache... eigentlich brauche ich nämlich die Daten. Und letztendlich will ich den Prüfstand im schlimmsten Fall 1-2 Tage laufen lassen und hinterher auch die Messwerte noch haben. Ich hatte zunächst das innerhalb der Schleife nur in einen Array geschrieben und beim Beenden der Schleife die Werte in eine Datei geschrieben. Meint ihr, dass das schneller ist?
Als Hintergrund-Info: Ich betreibe damit einen Prüfstand, der mit 15Hz eine rein schwellende Belastung auf ein Bauteil ausüben soll. Im genannten schlimmsten Fall belaste ich das Bauteil 2.000.000 mal. Selbst wenn ich pro Belastungszyklus nur 5x 4 Messwerte aufnehme, ist das ein ziemlich großer Array. Mein Gedanke dahinter war, dass es auf lange Sicht vielleicht schneller ist, den Wert in die Datei zu schreiben, als den Riesen-Array in der Schleife zu halten.
Aber ich bin gedanklich schon darauf vorbereitet, das Konzept zu überdenken... Ich würde die Daten gerne mit Excel auswerten und dort ist bei Zeile ~1,5x10^6 Schluss... :-(
Ergo: Ja, der File-Access frisst Zeit, aaaaber... DAS ist klar ;-)
