Unterschiedliche timing-anforderungen vereinigen

Hallo zusammen
Ich möchte mit einem 9477 DO Modul folgende Aktoren schalten:
Ventile
1 Pumpe
1 Heizung

Zunächst waren die anforderungen an die ansteuerung ziemlich simpel: Die Aktoren können entweder ein oder ausgeschalten werden auf einer makroskopischen Zeitskale (50ms genauigkeit reicht) Das Einschalten erfolgt entweder Prozessbedingt oder manuell über das UI. Ich habe deshalb alle ausgänge in einer globale Variable gesammelt und in einem separaten DO loop alle 10ms die aktuellen werte dieser globalen variable auf das modul geschrieben (NKanäle1Sample).

Nun sind die anforderungen aber komplexer geworden.
Ventile -> unverändert, also SW timing sollte hierfür genügend genau sein
Pumpe -> wird neu per phasenanschnitt angesteuert, welchen ich direkt über meine HW timen muss. Ich muss hier also einerseits auf den Nulldurchgang der Netzspannung reagieren können (welcher parallel gemessen wird) anderseits muss ich auch mit dem timing deutlich genauer sein, also irgendwo im bereich von 500us, damit ich eine halbwelle in etwa 20 stufen unterteilen kann
Heizung -> Neu soll ich jede Halbwelle des der Netzspannung ein oder ausschalten können (10ms). Ein Halbleiterrelais stellt dabei sicher dass die schaltung im nulldurchgang erfolgt.

generell gilt für alle aktoren nach wie vor, dass sowohl manuelles schalten über UI oder Prozessbedingtes schalten möglich sein muss.

meine frage ist also eher konzeptionell.
Wie würdet ihr diese 3 Ansprüche am ehesten "verheiraten"?
Von mir aus gesehen brauch ich nun ganz klar das HW Timing. Wie setze ich das am besten um?
Lohnt es sich evtl sogar, die Aktoren auf verschiedene module zu verteilen welche ich dann den bedürfnis der aktoren anpassen kann?

wäre für einige inputs sehr dankbar
grüsse
Serge

Anzeige

Hallo Serge,

Zitat: Ich habe deshalb alle ausgänge in einer globale Variable gesammelt und in einem separaten DO loop alle 10ms die aktuellen werte dieser globalen variable auf das modul geschrieben (NKanäle1Sample).

So würde ich das auch machen. (Vielleicht hätte ich die globale Variable durch Notifier ersetzt.)

Zitat:Pumpe -> wird neu per phasenanschnitt angesteuert, welchen ich direkt über meine HW timen muss. Ich muss hier also einerseits auf den Nulldurchgang der Netzspannung reagieren können (welcher parallel gemessen wird) anderseits muss ich auch mit dem timing deutlich genauer sein, also irgendwo im bereich von 500us,

Hier benötigst du nicht notwendigerweise "HW timing", du musst nur schnell genug reagieren können! Und das wird mit Windows und DAQmx-Einzelwertabfragen sehr schwierig!

Wie betreibst du das NI9477? In einem cDAQ-Chassis über DAQmx? Oder in einem cRIO (mit ScanEngine oder mit FPGA)?

Bei den Anforderungen würde ich ein cRIO mit FPGA nehmen: der FPGA kann deine Phasenanschnittsteuerung quasi "in Hardware" und ns-genau erledigen…
(Alternativ eine externe Phasenanschnittsteuerung verwenden und diese mit PWM oder Analogsignal ansteuern.)

Hallo Gerd
Danke für deine rasche Rückmeldung. Ja sorry, die information hab ich vergessen zu liefern. Ich verwende aktuell ein cDAQ 9178 Chassis mit daqmx treibern.

1. Ein umstieg auf ein FPGA Chassis wäre wohl denkbar, aber ich versuche wenn möglich davon abzusehen, da dies wohl einige Zeit beanspruchen würde welche ich momentan leider nicht hab
2. Es gibt ja auch bei DAQmx einen "Trigger" Baustein. Konnte den aber noch nie erfolgreich einsetzen und bin deshalb nicht sicher ob es hier einen anwendungsfall gäbe?
3. Angenommen, ich würde die Pumpe auch Halbwellenweise ansteuern und nicht über Phasenanschnitt. Dann müsste ich in maximal 10ms genauigkeit ein und wieder ausschalten können (mein Halbleiterrelais schaltet intrinsisch im Nulldurchgang, muss mich also um das exakte timing nicht kümmern). Kann ich 10ms zuverlässig über SW Timing schalten (also meine bisherige lösung weitgehend übernehmen). Oder bräuchte ich hierfür bereits HW timing?

grüsse
Serge

Hallo Serge,

Zitat:Kann ich 10ms zuverlässig über SW Timing schalten (also meine bisherige lösung weitgehend übernehmen). Oder bräuchte ich hierfür bereits HW timing?

10ms sind "relativ" zuverlässig zu schaffen: Du weißt nie, was Windows im Hintergrund anstellen will…

Andere Idee: Du könntest für die Phasenanschnittsteuerung einen Counter-Ausgang nehmen und darüber eine PWM ausgeben. Dann 100Hz als Grundfrequenz verwenden (=10ms Takt). Dann musst du aber beachten, dass die Netzfrequenz nicht notwendigerweise exakt 50Hz beträgt - das war/ist in den letzten 2 Monaten ja deutlich zu bemerken. (Und "synchron" zu den Nulldurchgängen bist du damit auch noch nicht…)

Hallo Gerd
Hab mal kurz eine timing untersuchung meines DO Handling VIs gemacht.
Anhang 1: Timing wenn ich mein main.vi am laufen hab
Anhang 2: Wenn ich nur das outputs.vi am laufen hab (ab der hälfte der Zeit im Signalverlauf)^. Zusätzlich hab ich den 10ms Delay deaktiviert.

Schaut von mir aus gesehen ziemlich schlecht aus für ein 10ms timing...

Im SubVI "Output Kompl" mach ich nix anderes als meine globalen outputs, welche ich in einem cluster-array speichere, in ein 1D Array umzuwandeln

dann fällt die SW lösung wohl ohnehin schon ins wasser?

lg
Serge

Hallo Serge,

leider sind Bilder nur bedingt aussagekräftig…

Sind die subVIs reentrant oder nicht?
Kann es bei parallel laufendem Code zu blockierenden Aufrufen desselben subVIs kommen? (Du scheinst da ja eine FGV zu verwenden.)

- Mich wundert, dass du bei einem Metronom mit 10ms Wartezeit immer mindestens 13ms für die Schleife benötigst: da scheint irgendwas in den subVIs eben länger als 10ms zu dauern…
- Welches OS benutzt du? Ältere Windows-Versionen können die Zeit nicht auf 1ms genau ausgeben… Verwende doch mal die Funktion HighResolutionTime statt des normalen GetTimestamp…

Anzeige

Hi Gerd
Hmm, also ich hab in meinem Projekt reentrant subvis ja. Das vi dessen code ich gezeigt habe sowie dessen subvis sind aber nicht reentrant.
Was genau ist eine FGV?

Im Anhang noch des blockdiagramm vom Output Kompl Subvi sowie vom DO subvi im case "write"

Das mit dem Metronomtiming leuchtet mir auch nicht ein. Ich dachte immer die loop time wäre dann ein vielfaches dieser zeit, also 10ms/20ms/30ms/40ms. Bei mir kommen da aber wilde sachen raus.

ich verwende Windows7 Enterprise

werde gleich schnell die high resolution time abchecken
--> hmm ok, das verhalten ist auch im highresolution mode genau gleich...

Hallo Serge,

du benutzt ein cDAQ, welches sehr wahrscheinlich über USB angebunden ist.
- Du benutzt den Modus "1 Sample on demand": das ist an sich schon relativ resourcenfressend. Dazu muss außerdem der USB-Bus ständig verfügbar sein für deine Befehle, das könnte bei 100Hz vielleicht schon knirschen…
- Und du schickst da 32 boolsche Werte hin: Ich würde da eher mit einem Port (d.h. U32-Wert) arbeiten, statt mit 32 boolschen Werten…

Zitat:Das mit dem Metronomtiming leuchtet mir auch nicht ein. Ich dachte immer die loop time wäre dann ein vielfaches dieser zeit, also 10ms/20ms/30ms/40ms. Bei mir kommen da aber wilde sachen raus.

Das wundert mich eben auch!
- Irgendwas in der Schleife benötigt dann konstant mehr als 10ms. Da dein Wait aber parallel dazu läuft, bestimmt eben das langsamste Element in der Schleife die Schleifenzeit!
- Wenn du die Mehrfachen von 10ms bekommen willst, müsste das Metronom nach dem Rest in der Schleife aufgerufen werden. (THINK DATAFLOW!)

(22.03.2018 14:40 )GerdW schrieb:  du benutzt ein cDAQ, welches sehr wahrscheinlich über USB angebunden ist.

korrekt

(22.03.2018 14:40 )GerdW schrieb:  - Du benutzt den Modus "1 Sample on demand": das ist an sich schon relativ resourcenfressend. Dazu muss außerdem der USB-Bus ständig verfügbar sein für deine Befehle, das könnte bei 100Hz vielleicht schon knirschen…

ja genau. Also würdest du erstmal mit U32 versuchen oder muss ich das 1Sample on demand über den haufen werfen? Dann wär ich ja automatisch beim HW Timing wenn ich das recht verstanden hab

grüsse
Serge

@serge_franke

Kannst du mal den Graph aus der Schleife eliminieren und statt dessen einen Cluster anzeigen, der die Daten "dT_Min, dT_Max, und dT_Akt" enthält? Anzeige alle 250ms. Ich weiß nicht, ob Graph-Refresh alle 10ms lieber vermieden werden sollte.