Aktorsteuerung mittels Encoder und PWM

[krambambuli]

Hallo Zusammen,

ich habe mir letzte Woche den RevPi Core 3 gekauft (bin also noch recht neu) und möchte zukünftig folgendes Projekt umsetzen:
Steuerung von 10 DC-Motoren (24V, 2A) mittels PWM (Geschwindigkeitsregelung). Die Ansteuerung der Aktoren soll aufgrund der 2A mittels Treiber realisiert werden. Der Treiber wird dann mittels PWM-Spannungsregulierung angesprochen. Die Motoren liefern mir die aktuelle Position mittels Inkrementalgeber mit ca. 100 Impules/Sekunde. Ich würde das Projekt gerne mittels den DIO-Modulen realisieren. Gesteuert wird das ganze später über eine GUI am RevPi Core (hatte gehofft meine bereits entwickelte WinForms Anwendung mit Mono auf dem RevPi zu laufen zu bekommen, VB.NET ist allerdings aktuell noch problematisch. Notfalls muss die GUI zukünftig komplett in Python portiert werden ).

Meine Frage:
Ich habe hier im Forum schon nach der maximalen Eingangsfrequenz der DIO-Module gesucht (Encoder) und bin dabei auf die Zahl 2kHz gestoßen. Das würde ja mehr als ausreichen. Die Frage ist dann, wie schnell der RevPi Core 3 ist, um die Signale von 10 Aktoren parallel mit jeweils 100 Impulsen/Sekunde zu erfassen und die PWM-Ausgänge entsprechend auszuschalten. Die Zykluszeit des RevPi Core ist ja mit 5ms angegeben. Jedoch kommt ja noch die Rechenzeit bei 10 Aktoren und Encodern hinzu?

Viele Grüße

[volker]

Hi,
unsere DIO /DI Module lassen maximal 6 Zähler oder Encoder zu. Mit einem DIO könntest Du also an 12 Eingängen 6 Encoder betreiben und gleichzeitig 10 PWM Ausgänge (Achtung! Die Ausgänge sind 24 V, die meisten günstigen treiber Boards verwenden aber Logikpegel (3,3 V oder 5 V)).
Ein Core 3 wird in dieser Konstellation eventuall bis zu 20 ms Zykluszeit auf der PiBridge haben. Das bedeutet ca. folgende Verzögerung:
Nach maximal 20 ms landet der Zählerwert im Prozessabbild.
Dort liest Du ihn zyklisch in eine Applikation (z.B. Python), deren Zyklus zum Beispiel 10 ms ist. Das wären dann zusätzlich max. 10 ms Verzögerung.
Die Applikation vergleicht den Zählerwert mit einem Sollwert und reagiert mit einem Schreiben des neuen Prozesswertes (Motor) in das Prozessabbild. Die Rechenzeit ist unerheblich, weil im µs Bereich. Aber normalerweise würde eine PLC (logi.cad oder codesys) nun erst beim nächsten Zyklus (also nach 10 ms) ins Prozessabbild schreiben (lässt sich zwar auch anders realisieren, aber dann bist Du von der klassischen zyklischen PLC Verbarbeitungsweise weit entfernt...). Das bedeutet nochmal 10 ms Verzögerung. Dann wird der Wert nach spätestens einem piBridge-Zyklus (20 ms) im DO/DIO landen und wenige µs später am Motortreiber.
Der worst case wäre also so bei 60 ms zu erwarten. Das ist für einen 100 Hz betriebenen Encoder eine Zählabweichung von bis zu 6 Zählerwerten. Da dieser Wert wegen der Asynchronität der Bus- und PLC Zyklen nicht konstant ist, kann er nicht durch Kalibrierung ausgeglichen werden, sondern entspricht dem "Jitter". Du musst daher überlegen, ob diese Abweichung von 6 Zählereinheiten noch akzeptabel für die Genauigkeit der Achsensteuerung ist oder nicht.

[krambambuli]

Hallo Volker,

danke für die schnelle und ausführliche Antwort!
Deine Angaben beziehen sich auf ein DIO Modul. Da ich ja 10 Aktoren nutzen möchte, werde ich zwei DIO Module nutzen. Welchen Einfluss hat das auf die Verarbeitung? Die Daten müssten ja theoretisch identisch übertragen werden und es kommt dann nur die Datenverarbeitung im µs Bereich dazu, oder? Ergänzung: Ich würde parallel dazu auch noch 20 Analoge Eingänge nutzen um pro Aktor zwei Ströme (4-20mA) zu messen (Kraftwerte, da kommt es aber nicht auf die Zykluszeit an).

[Eduard]

Hallo,
die gemachten Berechnungen vom Volker basieren auf zwei DIO's, deswegen wird sich an den 20ms pyBridge-Zykluszeit nichts ändern.
Um die 20 Analoge Eingänge messen zu können brauchst du 5 AIO's, dadurch wird sich der pyBridge-Zyklus nochmal auf ca. 40ms erhöhen.