' 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.

' 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".

' 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??

' 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

' schrieb:Ich glaube ich werde es wohl über diese LabVIEW Variante machen müssen...

' 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?

' 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...

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?

Zitat:Klar könnte man über das "wait" die Schleifenzyklen verlangsamen, aber reicht das??

' 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.