' schrieb: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.
Das eigentliche Schalten der Ventile sollte nicht länger als 100ms dauern...
und nein auf 1ms genau muss es natürlich nicht sein...ich wäre auch schon mit
100ms Genauigkeit zufrieden. Unser Gerät wird über eine Serial to USB Schnittstelle angesprochen, dies geschieht über die "FTD2XX.dll".
Nun muss man sich unser System folgendermaßen vorstellen: Wir haben 2 miteinander verbundene Reservoire, welche abhängig von der Ventilstellung leer- bzw. volllaufen. Dabei soll es vermieden werden, dass sie komplett leerlaufen bzw. volllaufen. Da kommt dann die zeitgesteuerte Ventilschaltung ins Spiel, die abhängig von der Flussrate der Flüssigkeit mal schneller oder auch langsamer schalten muss. Die niedrigste Schaltzeit in unserem System beträgt
0,4s.
Gerade bei der niedrigsten Taktung von 0,4s merkt man deutlich, wie sich die Frequenz ändern, wenn man irgendetwas am Rechner tut, bzw. auch nur das Fenster verschiebt.
Ich hoffe das hilft euch weiter...
Vielleicht würde es ja auch langen, wenn ich dem Programm die höchste Priorität gebe??
' schrieb:Das eigentliche Schalten der Ventile sollte nicht länger als 100ms dauern...
und nein auf 1ms genau muss es natürlich nicht sein...ich wäre auch schon mit 100ms Genauigkeit zufrieden. Unser Gerät wird über eine Serial to USB Schnittstelle angesprochen, dies geschieht über die "FTD2XX.dll".
Aha, und diese DLL ist über den CLF-Node aufgerufen im "RUN in UI Thread" ? (UI= User Interface)
Ob man da einfach auf reentrant wechsel kann, oder die DLL noch anders erstellt werden muss (Thread safety) weis ich jetzt nicht genau.
Ev. hilft dir das weiter.
' schrieb:Das eigentliche Schalten der Ventile sollte nicht länger als 100ms dauern...
und nein auf 1ms genau muss es natürlich nicht sein...ich wäre auch schon mit 100ms Genauigkeit zufrieden. Unser Gerät wird über eine Serial to USB Schnittstelle angesprochen, dies geschieht über die "FTD2XX.dll".
Nun muss man sich unser System folgendermaßen vorstellen: Wir haben 2 miteinander verbundene Reservoire, welche abhängig von der Ventilstellung leer- bzw. volllaufen. Dabei soll es vermieden werden, dass sie komplett leerlaufen bzw. volllaufen. Da kommt dann die zeitgesteuerte Ventilschaltung ins Spiel, die abhängig von der Flussrate der Flüssigkeit mal schneller oder auch langsamer schalten muss. Die niedrigste Schaltzeit in unserem System beträgt 0,4s.
Gerade bei der niedrigsten Taktung von 0,4s merkt man deutlich, wie sich die Frequenz ändern, wenn man irgendetwas am Rechner tut, bzw. auch nur das Fenster verschiebt.
Ich hoffe das hilft euch weiter...
Vielleicht würde es ja auch langen, wenn ich dem Programm die höchste Priorität gebe??
Hallo Martin
Vielleicht ist es ja ein Konflikt mit Windows. Wenn Du beim Verschieben des Fensters die Einstellung "Inhalte beim Verschieben anzeigen" gewählt hast, ist die CPU Last sehr hoch. Dann bleibt für LabVIEW nichts mehr übrig.
Die Einstellung kann man in der Systemsteuerung->Desktop->Darstellung->Effekte ändern.
Gruss, BDB
@RoLe:
Das mit der DLL würde ich derweil auf "Run in UI Thread" lassen, da mir die Zeitdifferenz zwischen DLL und Ausführen des Befehls im Gerät schnell genug und vor allem konstant ist. Es geht wirklich um die Genauigkeit, welche vom Programm übergeben wird.
' schrieb:Hallo Martin
Vielleicht ist es ja ein Konflikt mit Windows. Wenn Du beim Verschieben des Fensters die Einstellung "Inhalte beim Verschieben anzeigen" gewählt hast, ist die CPU Last sehr hoch. Dann bleibt für LabVIEW nichts mehr übrig.
Die Einstellung kann man in der Systemsteuerung->Desktop->Darstellung->Effekte ändern.
Gruss, BDB
ja das hab ich auch schon gemacht, das mit dem Fensterinhalt anzeigen / verstecken.
Die Sache ist ja auch so, dass die Software auch an Kunden geht und da wird die Sache dann auch komplizierter...
Ich habe mal ein zweites Beispiel gebastelt, in welchem die Zeit so genau wie möglich ist (mit der LabVIEW Funktion "wait").
Ich glaube ich werde es wohl über diese LabVIEW Variante machen müssen...
Eventuell werde ich dynamisch SubVI's laden, welche nach Beendigung des Wartens ein Event abgeben, auch welches dann das Hauptprogramm reagiert und das Ventil schaltet...was haltet ihr davon?
Somit wäre der Schaltpunkt relativ genau...Bleibt nur das Problem, wie ich es graphisch für den Benutzer darstelle, der will ja schließlich auch was sehen...
Wie realisiert man denn das?
Anbei ein weiteres Beispiel, wie man es lösen könnte (hoff ich doch...)
[
attachment=14153]
Viele Grüße und vielen Dank für eure Hilfe, Martin!!
' schrieb:Ich glaube ich werde es wohl über diese LabVIEW Variante machen müssen...
Im Prinzip Ja.
Kuck dir
das (Beitrag #12) mal an. Es ist ein Muster ohne Wert. So programmier ich alle Sachen, die was mit Samplen zu tun haben. Genausso kann man auch Ausgaben machen. Entweder per DaqMX-Write-Task, die dann selbständig ein Raster erzeugen kann, oder per Wait (besser Metronom). Mit einer entsprechenden Priorität kann dieses SubVI sehr zeitgenau laufen.
Noch eine Frage:
Ist deine Schnittstelle eine reine USB-Schnittstelle sieht also von LV aus wie ein USB? Oder hat das Endgerät eine RS232-Schnittstelle und am PC hängt ein USB/RS232-Converter? Bei letzterem sollte der Converter doch als COM-Port zu sehen sein und daher mit VISA programmierbar sein?
' schrieb:Im Prinzip Ja.
Kuck dir das (Beitrag #12) mal an. Es ist ein Muster ohne Wert. So programmier ich alle Sachen, die was mit Samplen zu tun haben. Genausso kann man auch Ausgaben machen. Entweder per DaqMX-Write-Task, die dann selbständig ein Raster erzeugen kann, oder per Wait (besser Metronom). Mit einer entsprechenden Priorität kann dieses SubVI sehr zeitgenau laufen.
Noch eine Frage:
Ist deine Schnittstelle eine reine USB-Schnittstelle sieht also von LV aus wie ein USB? Oder hat das Endgerät eine RS232-Schnittstelle und am PC hängt ein USB/RS232-Converter? Bei letzterem sollte der Converter doch als COM-Port zu sehen sein und daher mit VISA programmierbar sein?
Hey das ist ne gute Idee...mit der Programmierung über VISA. Generell ist das schon möglich, da ich den Com-Port bei LabVIEW sehe und es sich bei der Schnittstelle um die RS232 mit "USB to Serial" handelt...Leider ist die komplette Ansteuerung für das Gerät bereits von unseren Partnern geschrieben...und jetzt frage ich mich natürlich, warum sie den Weg über die DLL gegangen sind...
Wie kann ich denn Balken (oder auch einen Countdown) auf dem Frontpanel ablaufen lassen, ohne dass es großartig beeinflusst wird von CPU-Last? Gibt es da spezielle Schleifen, die besser geeignet sind? Klar könnte man über das "wait" die Schleifenzyklen verlangsamen, aber reicht das??
Gruß, Martin
' schrieb:Leider ist die komplette Ansteuerung für das Gerät bereits von unseren Partnern geschrieben...und jetzt frage ich mich natürlich, warum sie den Weg über die DLL gegangen sind...
Alles selbst zu machen hat diverse Vorteile. Sollte es sich bei der Ansteuerung vom geeignete (!) VIs handeln, spricht nichts dagegen, diese zu verwenden.
Zitat:Wie kann ich denn Balken (oder auch einen Countdown) auf dem Frontpanel ablaufen lassen, ohne dass es großartig beeinflusst wird von CPU-Last?
Da ein Balken eine Bildschirmausgabe darstellt, wird das immer - egal wie da was programmiert ist - von der CPU-Last abhängig sein. Es kommt aber darauf an, wer da Last mit welchem Verfahren beanspucht.
Zitat:Klar könnte man über das "wait" die Schleifenzyklen verlangsamen, aber reicht das??
Das reicht.
Du musst nur die Hardwareausgabe von der Bildschirmausgabe entkoppeln. Z.B. mit einer Klasse, die Queue-gesteuert ist. Wenn du vom Verfahren her alles "bildschirmfrei" programmierst und den einzelnen Klassen noch eine hohe Priorität zuteilst, läuft zumindest die Hardwaresache relativ sicher. Ob die Bildschirmanzeige, die ihre Daten z.B. per Melder bekommt, da dann mitkommt, ist nicht mehr notwendig.
' schrieb:Alles selbst zu machen hat diverse Vorteile. Sollte es sich bei der Ansteuerung vom geeignete (!) VIs handeln, spricht nichts dagegen, diese zu verwenden.
Da ein Balken eine Bildschirmausgabe darstellt, wird das immer - egal wie da was programmiert ist - von der CPU-Last abhängig sein. Es kommt aber darauf an, wer da Last mit welchem Verfahren beanspucht.
Das reicht.
Du musst nur die Hardwareausgabe von der Bildschirmausgabe entkoppeln. Z.B. mit einer Klasse, die Queue-gesteuert ist. Wenn du vom Verfahren her alles "bildschirmfrei" programmierst und den einzelnen Klassen noch eine hohe Priorität zuteilst, läuft zumindest die Hardwaresache relativ sicher. Ob die Bildschirmanzeige, die ihre Daten z.B. per Melder bekommt, da dann mitkommt, ist nicht mehr notwendig.
Das macht alles Sinn. Ich werde deine Ratschläge so weit es geht befolgen...
Erst einmal vielen Dank für die Hilfe! Ich werde mich dann melden, wenn es Probleme geben sollte
So far,
Martin