Elektrotechnik Bericht

PC-basierte Ansteuerung einer hydraulischen Bremse mittels Windows-PC und Python

Technischer Praxisbericht: von der Idee über die Fehlersuche bis zur robusten Bremsregelung

1. Einleitung

Eine hydraulische Bremse präzise über einen Windows-PC und Python anzusteuern klingt zunächst einfach: Messwert einlesen, Regler berechnen, Ausgang setzen. In der Praxis zeigte sich jedoch schnell, dass die eigentlichen Schwierigkeiten in den Details liegen – ungenaue Windows-Zykluszeiten, Encoder-Überläufe, Messjitter, Filterverzögerungen und die richtige Wirkrichtung des Hydraulikventils.

Genau deshalb ist dieses Projekt für die Homepage relevant: Es verbindet reale Hardware mit Software-Engineering und zeigt, wie aus Messdaten ein belastbarer technischer Prozess wird.

Der Fokus lag nicht nur auf der reinen Ventilansteuerung, sondern auf dem gesamten Regelkreis:

• Erfassen der aktuellen Geschwindigkeit
• Berechnen der Ist-Verzögerung
• Vergleichen mit einer Soll-Vorgabe
• Berechnen eines passenden Stellwerts
• Ausgabe eines analogen Signals an die Hydraulik
• Visualisierung und Aufzeichnung der Messwerte

Während der Entwicklung wurde klar: Entscheidend ist nicht nur der Code, sondern das Verständnis der gesamten Wirkkette vom Sensor bis zur Hydraulik. Dieser Bericht dokumentiert die Umsetzung, die typischen Probleme und die konkreten Lösungswege in einer Form, die auch für Nicht-Spezialisten nachvollziehbar bleibt.

2. Systemübersicht

Die Ansteuerung besteht aus mehreren funktionalen Blöcken. Der Windows-PC übernimmt die Datenerfassung, Berechnung, Regelung und Visualisierung in einer zentralen Python-Anwendung.

2.1 Hauptkomponenten

• Das System besteht im Wesentlichen aus:
• Windows-PC
• Python-Anwendung
• grafischer Benutzeroberfläche mit Qt / PySide6
• Inkrementalgeber zur Drehzahl- beziehungsweise Geschwindigkeitsmessung
• 16-Bit-Zähler für die Geberwerte
• Hydraulikventil zur Druckregelung
• analoger Ausgang zur Ansteuerung des Ventils
• Druckbereich ungefähr 0 bis 160 bar
• Steuersignal 0 bis 10 V
• Kommunikationsschnittstelle zur Hardware

Für die Anbindung zwischen PC und Anlage wurde ein CAN-Bus in Kombination mit einem Feldbuskoppler verwendet. Damit konnten Messwerte und Stellgrößen stabil zwischen Software und Hardware ausgetauscht werden.

Die Python-Anwendung liest zyklisch die Messwerte ein, berechnet Geschwindigkeit und Soll-Ist-Abweichung und erzeugt daraus den Stellwert für das Hydraulikventil. Gerade diese enge Kopplung aus Messung, Regelung und Visualisierung war der Schlüssel für eine schnelle und nachvollziehbare Entwicklung.

3. Grundprinzip der Bremsansteuerung

Die hydraulische Bremse wird über ein Ventil beeinflusst. Dieses Ventil wird über ein analoges Signal angesteuert. Der Stellwert der Software wird also am Ende in eine Spannung beziehungsweise in einen Druckwert umgesetzt.

Vereinfacht ergibt sich folgender Ablauf:

1. Encoderwert erfassen
2. Zählerdifferenz berechnen
3. Geschwindigkeit berechnen
4. Signal filtern
5. Soll-Ist-Abweichung berechnen
6. Regler berechnet neuen Druckwert
7. Druckwert in 0–10 V Signal umrechnen
8. Hydraulikventil ansteuern
9. Bremse wirkt auf das System zurück

Das Ziel war, eine definierte Verzögerung einzuhalten, beispielsweise:

a_soll = -0.5 m/s²

Damit entsteht direkt die zentrale Sollbeziehung für den Bremsverlauf:

Bei einer Anfangsgeschwindigkeit von 5 m/s und einer gewünschten Verzögerung von -0.5 m/s² ergibt sich idealerweise ein Bremsvorgang von ungefähr 10 Sekunden:

v(t) = v_start + a_soll · t

Bei:

v_start = 5 m/s
a_soll = -0.5 m/s²

ergibt sich:

v(t) = 5 - 0.5 · t

Die Sollgeschwindigkeit fällt also linear von 5 m/s auf 0 m/s. In Kombination mit den Beziehungen v = s / dt und a = Δv / dt ergibt sich damit der komplette Rechenpfad von Encoderwerten bis zum Regelziel.

4. Umsetzung der Geschwindigkeitserfassung

Ein zentraler Bestandteil der Anwendung ist die zuverlässige Berechnung der Geschwindigkeit. Die Geschwindigkeit wird nicht direkt gemessen, sondern aus den Impulsen eines Inkrementalgebers berechnet.

Dazu wird ein Zählerwert zyklisch eingelesen. Aus der Differenz zwischen dem aktuellen und dem vorherigen Zählerwert wird berechnet, wie weit sich das System in einem bestimmten Zeitintervall bewegt hat.

4.1 Berechnung aus Encoderimpulsen

Grundsätzlich gilt:

delta_counts = aktueller_Zählerwert - letzter_Zählerwert

Daraus wird die zurückgelegte Strecke berechnet:

Strecke = delta_counts / Impulse_pro_Umdrehung · Umfang

Die Geschwindigkeit ergibt sich anschliessend aus:

v = Strecke / dt

Dabei ist dt die Zeit zwischen zwei Messungen.

5. Problem 1: 16-Bit-Zählerüberlauf

Ein erstes praktisches Problem war der 16-Bit-Zähler des Encoders. Ein 16-Bit-Zähler kann nur Werte von 0 bis 65535 darstellen. Danach springt er wieder auf 0 zurück.

Das führt zu einem Problem, wenn man einfach den aktuellen Wert minus den alten Wert rechnet.

Beispiel für einen Überlauf

Angenommen, der alte Wert ist:

last = 65530

und der neue Wert ist:

current = 10

Dann wäre die einfache Differenz:

delta = 10 - 65530 = -65520

Das wäre offensichtlich falsch, denn in Wirklichkeit ist der Zähler nur übergelaufen. Die echte Differenz beträgt:

65536 - 65530 + 10 = 16

Lösung

Die Differenz wurde deshalb mit einer Wraparound-Logik berechnet:

delta = current - last
if delta > 32767:
    delta = delta - 65536
if delta < -32768:
    delta = delta + 65536

Damit wird der Zählerüberlauf korrekt behandelt.

In Python sieht das Prinzip so aus:

def unwrap_16bit_counter_delta(current, last):
    delta = int(current) - int(last)
    if delta > 32767:
        delta -= 65536
    elif delta < -32768:
        delta += 65536
    return delta

Diese Logik wurde später auch für die Umsetzung in CODESYS beziehungsweise für SPS-nahe Berechnungen vorbereitet.

6. Problem 2: Zeitbasis und Jitter bei der Geschwindigkeitsberechnung

Ein zentraler Punkt bei der Geschwindigkeitsberechnung war die Zeitbasis. Die Geschwindigkeit wurde aus der Encoder-Differenz und der vergangenen Zeit berechnet:

v = Strecke / dt

Zu Beginn wurde die Zykluszeit über einen normalen Windows- beziehungsweise Python-Timer ermittelt. Dabei trat jedoch starker Jitter auf. Obwohl der Zyklus auf 50 ms ausgelegt war, lagen die gemessenen Zykluszeiten teilweise ungefähr zwischen 40 ms und 60 ms.

Da die Geschwindigkeit direkt durch dt berechnet wird, führten diese Schwankungen zu sichtbaren Geschwindigkeitssprüngen. In den Messdaten zeigten sich dadurch teilweise Sprünge von etwa 10 bis 20 Prozent im Geschwindigkeitssignal, obwohl die Mechanik selbst deutlich gleichmässiger lief.

Als Zwischenlösung wurde deshalb mit einer festen Zykluszeit gerechnet:

dt = 0.05 s

Das entsprach dem geplanten Abtastintervall von 50 ms und beruhigte das Signal zunächst deutlich. Der Vorteil war, dass der Jitter des Timers nicht mehr direkt in die Geschwindigkeitsberechnung einging. Die künstlichen Geschwindigkeitssprünge wurden dadurch stark reduziert.

Diese feste Annahme hatte jedoch einen Nachteil: Sie stimmt nur, solange der Zyklus tatsächlich ungefähr alle 50 ms ausgeführt wird. Wenn Windows, die Kommunikation oder andere Prozesse eine Verzögerung verursachen, wird die Geschwindigkeit falsch berechnet.

Ein Beispiel: Werden in einem Zyklus 400 Encoder-Counts gemessen, aber der Zyklus dauert real 60 ms statt 50 ms, dann sind diese Counts auf eine längere Zeit verteilt. Die echte Geschwindigkeit ist tiefer. Wird trotzdem mit 50 ms gerechnet, entsteht ein zu hoher Geschwindigkeitswert.

Die endgültige Lösung war deshalb eine präzisere Zeitmessung mit time.perf_counter(). Dadurch konnte die tatsächliche Zeit zwischen zwei Messungen zuverlässiger bestimmt werden:

current_time = time.perf_counter()

if last_time is not None:
    dt = current_time - last_time

last_time = current_time

Damit wurde der starke Jitter des ursprünglichen Timers reduziert. Gleichzeitig konnten echte Zyklusabweichungen, zum Beispiel durch Kommunikationsstörungen, erkannt und korrekt berücksichtigt werden. Die Geschwindigkeit wurde dadurch realistischer berechnet und der Regler reagierte weniger auf künstliche Messspitzen.

7. Problem 3: Windows ist kein Echtzeitsystem

Kapitel 6 zeigt die rechnerische Seite der Zeitbasis. Dieses Kapitel ergänzt die systemische Perspektive: Der PC arbeitet bewusst als flexible Engineering-Plattform, aber eben ohne harte Echtzeitgarantie.

Das bedeutet konkret: Scheduler, Treiber, USB-Kommunikation, Visualisierung und andere Prozesse beeinflussen den zeitlichen Ablauf. Selbst mit verbessertem Timing bleiben deshalb einzelne Ausreißer möglich und müssen im Regeldesign berücksichtigt werden.

Für das Projekt war die Konsequenz klar: Regelung, Filterung und Diagnose wurden robust gegen diese Schwankungen ausgelegt. Dadurch lässt sich ein stabiler Bremsverlauf auch unter Soft-Realtime-Bedingungen erreichen.

Gleichzeitig ergibt sich daraus die ehrliche Einordnung für spätere Produktstufen: Für Prototyping, Parametrierung, Analyse und schnelle Iteration ist der Windows-PC sehr stark. Für harte zeitkritische Serienfunktionen sollte der Kern der Regelung auf SPS oder Echtzeitcontroller laufen.

8. Problem 4: Jitter im Geschwindigkeitssignal

Trotz korrekter Zeitmessung war das Geschwindigkeitssignal nicht perfekt glatt. Es traten weiterhin Schwankungen auf. Ein Teil davon kam vom realen System, ein anderer Teil von Messrauschen, Quantisierung und Timing-Jitter.

Besonders kritisch ist: Die Beschleunigung wird aus der Änderung der Geschwindigkeit berechnet.

Das bedeutet:

a = (v_aktuell - v_alt) / dt

Wenn die Geschwindigkeit leicht rauscht, wird die daraus berechnete Beschleunigung sehr stark rauschen.

Beispiel

Wenn die Geschwindigkeit nur geringfügig springt, kann die berechnete Beschleunigung stark ausschlagen, weil durch eine kleine Zeit dt geteilt wird.

• Das ist typisch bei numerischer Ableitung:
• kleiner Fehler in v → grosser Fehler in a
• Auswirkung auf den Regler

Wenn der Regler direkt auf dieses verrauschte Beschleunigungssignal reagiert, arbeitet er gegen Messfehler statt gegen das echte Systemverhalten.

• Das führt zu:
• unruhigem Drucksignal
• unnötigen Stellbewegungen
• möglichem Schwingen
• schlechter Nachvollziehbarkeit des Bremsvorgangs
• Lösung

Das Geschwindigkeitssignal und teilweise auch abgeleitete Signale wurden gefiltert. Es wurden digitale Tiefpassfilter eingesetzt, um schnelle Messspitzen zu glätten.

9. Digitale Filterung

Für die Filterung wurden Tiefpassfilter verwendet. Ziel war es, hochfrequentes Rauschen und Jitter zu unterdrücken, ohne das Signal zu stark zu verzögern.

Mehr Hintergrund zur Filtertheorie findest du in meinem Bericht Herleitung eines digitalen Tiefpasses 2. Ordnung. Für die praktische Berechnung von Biquad-Koeffizienten passt außerdem der Beitrag Digitale Filter berechnen (IIR / Biquad).

9.1 Herausforderung bei der Filterung

Ein Filter verbessert zwar die Signalqualität, bringt aber immer auch eine Verzögerung mit sich.

• Das ist bei einer Regelung kritisch:
• zu wenig Filterung → Regler reagiert auf Rauschen
• zu starke Filterung → Regler reagiert zu spät

Es musste also ein Kompromiss gefunden werden.

9.2 Filter 1. Ordnung

Ein einfacher Tiefpass 1. Ordnung glättet das Signal moderat und ist relativ stabil.

• Vorteile:
• einfach
• robust
• wenig Rechenaufwand
• gut verständlich
• Nachteile:
• bei starker Glättung deutliche Verzögerung
• bei schwacher Glättung bleiben Störungen sichtbar

9.3 Filter 2. Ordnung

Zusätzlich wurde ein Filter 2. Ordnung betrachtet. Dieser kann stärker glätten, ohne exakt gleich zu wirken wie ein einfacher gleitender Mittelwert.

Dabei wurde der Filter über Grenzfrequenz und Abtastzeit parametriert. In der Python-Anwendung wurden die Koeffizienten abhängig von:

• dt
• Grenzfrequenz
• Ordnung

berechnet.

Ein wichtiger Punkt war: Die Filterparameter müssen zur realen Zykluszeit passen. Wenn ein Filter mit einer angenommenen Zykluszeit von 50 ms berechnet wird, der echte Zyklus aber stark abweicht, verändert sich auch das Filterverhalten.

Lösung

Die Filterung wurde so eingesetzt, dass sie vor allem Messspitzen reduziert, ohne den Bremsverlauf zu stark zu verfälschen. Für die Regelung ist nicht nur ein schönes Signal wichtig, sondern auch ein Signal, das zeitlich noch nahe genug am realen Verhalten liegt.

10. Problem 5: Sollwertvorgabe über Geschwindigkeit statt nur Beschleunigung

Am Anfang lag der Fokus stark auf der Soll-Verzögerung, beispielsweise:

a_soll = -0.5 m/s²

In der Praxis zeigte sich aber, dass es oft besser ist, eine Sollgeschwindigkeit über die Zeit zu erzeugen und den Regler auf diese Geschwindigkeit arbeiten zu lassen.

Warum?

Eine konstante Verzögerung entspricht einer linearen Geschwindigkeitsrampe.

Statt nur zu sagen:

Die Verzögerung soll -0.5 m/s² sein.

kann man sagen:

Die Geschwindigkeit soll zu jedem Zeitpunkt auf dieser Ideallinie liegen.

Also:

v_soll(t) = v_start + a_soll · t

Beispiel:

v_start = 5.0 m/s
a_soll = -0.5 m/s²

Dann ergibt sich:

Zeit 0 s: v_soll = 5.0 m/s
Zeit 1 s: v_soll = 4.5 m/s
Zeit 2 s: v_soll = 4.0 m/s
Zeit 3 s: v_soll = 3.5 m/s

...

Zeit 10 s: v_soll = 0.0 m/s

Vorteil

Der Regler sieht direkt, ob das System zu schnell oder zu langsam ist.

Wenn:

v_ist > v_soll

dann bremst das System zu wenig.

Wenn:

v_ist < v_soll

dann bremst das System zu stark.

Diese Betrachtung ist oft stabiler und anschaulicher als eine reine Beschleunigungsregelung, weil die Beschleunigung aus verrauschten Geschwindigkeitswerten berechnet werden muss.

11. Problem 6: Regler-Vorzeichen und inverse Wirkung der Hydraulik

Ein besonders wichtiger Entwicklungsfehler lag im Vorzeichen beziehungsweise in der Wirkung des Stellwerts.

Bei vielen Regelstrecken gilt intuitiv:

mehr Stellwert = mehr Wirkung

Bei der hydraulischen Bremse war die Interpretation aber nicht ganz so einfach. Je nach Ventil- und Hydraulikaufbau kann ein höherer Druckwert nicht einfach linear als „mehr bremsen“ interpretiert werden. Im konkreten Fall musste sauber verstanden werden, ob der Regler den Druck erhöhen oder reduzieren muss, wenn zu wenig gebremst wird.

In den Tests zeigte sich, dass der Regler teilweise in die falsche Richtung arbeitete. Er erkannte zwar die Abweichung korrekt, setzte die Korrektur aber mit falschem Vorzeichen um. Das führte dazu, dass sich die Bremswirkung nicht verbesserte, der Druck in Begrenzungen lief und das System träge oder instabil wirkte.

Erst durch diese praktische Analyse wurde klar, dass ein Standard-PI-Regler nicht blind übernommen werden kann. Die Reglergleichung muss zur realen Hydraulikstrecke passen.

12. Problem 7: Vorspannung des Drucks

Ein weiterer wichtiger Punkt war die sogenannte Vorspannung. Die Hydraulik reagiert nicht unbedingt sofort ab 0 bar. Es gibt mechanische Totbereiche, Ventilverhalten, Leitungsvolumen und Verzögerungen.

Darum wurde ein Grunddruck verwendet, zum Beispiel:

vorspannen = 20 bar

Diese Vorspannung sorgt dafür, dass das System bereits in einem Arbeitsbereich ist und schneller auf Regelbefehle reagiert.

Problem

In den Messdaten war sichtbar, dass sich das Drucksignal teilweise wie eine Rampe verhielt. Dabei war nicht sofort klar, ob diese Rampe vom Regler, vom Integrator oder von der Vorspannlogik kam.

Es musste unterschieden werden zwischen:

• Grunddruck / Vorspannung
• PI-Regler-Anteil
• Integrator-Anteil
• Begrenzungen
• Rampen oder Sollwertübergängen

Ein Teil des beobachteten Verlaufs war nicht primär der Integrator, sondern die Vorspannung beziehungsweise die Art, wie der Anfangsdruck aufgebaut wurde.

Diese Erkenntnis war wichtig, weil sonst fälschlicherweise der Integrator als Ursache angesehen worden wäre.

Lösung

Die Software wurde so betrachtet und angepasst, dass die einzelnen Anteile klarer getrennt werden:

Ausgang = Vorspannung + Reglerkorrektur

beziehungsweise je nach Wirkrichtung:

Ausgang = Vorspannung - Reglerkorrektur

Wichtig war, die Vorzeichen eindeutig festzulegen und die einzelnen Beiträge im Plot sichtbar zu machen.

13. Problem 8: Integrator-Windup

Beim PI-Regler besteht immer die Gefahr, dass der Integrator zu stark aufläuft. Das passiert besonders dann, wenn der Stellwert begrenzt ist.

• Der Ausgang kann beispielsweise nur in diesem Bereich liegen:
• 0 bis 160 bar
• oder entsprechend:
• 0 bis 10 V

Wenn der Regler mehr verlangt, als physikalisch möglich ist, bleibt der Ausgang an der Grenze. Der Integrator kann aber intern weiter anwachsen. Sobald das System später wieder in einen regelbaren Bereich kommt, ist der Integrator viel zu gross und verursacht Überschwingen.

• Symptome
• Ausgang läuft in Begrenzung
• Regler reagiert später zu stark
• Bremsung wird instabil
• Druck bleibt zu lange hoch oder tief
• System erholt sich schlecht nach Sättigung
• Lösung

Der Integrator wurde begrenzt.

Beispiel:

self.integral += error * dt
self.integral = max(-integral_max, min(integral_max, self.integral))

Damit kann der Integralanteil nicht unbegrenzt anwachsen.

Zusätzlich ist es sinnvoll, den Integrator nur dann weiterlaufen zu lassen, wenn der Ausgang nicht bereits in der Begrenzung steht oder wenn die Integration helfen würde, aus der Begrenzung zurückzukommen.

14. Problem 9: Skalierung von Druck, Spannung und Softwarewerten

Ein weiteres praktisches Problem war die saubere Skalierung zwischen Softwarewerten, hydraulischem Druck und analogem Ausgangssignal. Das Hydraulikventil wurde über ein analoges Signal von 0–10 V angesteuert, während der Druckbereich des Systems ungefähr 0–160 bar betrug.

Damit ergibt sich idealisiert folgende Umrechnung:

10 V = 160 bar
1 V  = 16 bar

Spannung = Druck / 160 · 10

Beispielsweise entsprechen 20 bar etwa 1.25 V, 80 bar etwa 5.0 V und 160 bar dem vollen Ausgangssignal von 10.0 V.

Deshalb wurden die Größen konsequent getrennt: Der Regler arbeitet intern in bar, die Begrenzung liegt bei 0 bis 160 bar, und erst vor der Hardwareausgabe wird der Wert auf 0 bis 10 V umgerechnet.

pressure_bar = max(0.0, min(160.0, pressure_bar))
voltage = pressure_bar / 160.0 * 10.0

Diese klare Trennung macht die Regelung nachvollziehbarer und verhindert, dass Skalierungsfehler als Reglerproblem fehlinterpretiert werden.

15. Problem 10: Darstellung und Interpretation der Messdaten

Ein wichtiger Teil der Entwicklung war die grafische Darstellung der Messwerte. Ohne Plots wäre kaum erkennbar gewesen, ob ein Problem vom Regler, vom Timing, vom Filter oder vom hydraulischen Aufbau kommt. Erst die gemeinsame Betrachtung mehrerer Signale machte die Ursachen sichtbar.

Dafür wurden nicht nur Geschwindigkeit und Druck aufgezeichnet, sondern auch interne Größen wie Reglerfehler, P-Anteil, I-Anteil, Encoder-Differenz, Zykluszeit dt sowie Ausgangswerte vor und nach der Begrenzung. Dadurch ließ sich nachvollziehen, ob der Regler auf ein echtes Systemverhalten reagierte oder nur auf Messrauschen und Timing-Effekte.

Für eine übersichtliche Webdarstellung wären besonders vier Diagramme sinnvoll: ein Blockdiagramm der Systemkette, ein Plot von Sollgeschwindigkeit zu Istgeschwindigkeit, ein Timing-Plot der Zykluszeit und ein gemeinsamer Plot von Druck- beziehungsweise Stellwertverlauf mit der Geschwindigkeit.

16. Umstellung des Regelziels auf Geschwindigkeitsverlauf

Da das eigentliche Ziel eine definierte Verzögerung ist, wurde der Sollwert als Geschwindigkeitsrampe interpretiert.

• Statt nur zu regeln:
• a_ist soll a_soll entsprechen
• wurde stärker betrachtet:
• v_ist soll v_soll folgen
• Das hat mehrere Vorteile:

Die Sollkurve ist einfach sichtbar.

Der Fehler ist direkt interpretierbar.

Das Signal ist weniger empfindlich als eine numerische Beschleunigung.

Der Bremsvorgang kann über den ganzen Verlauf bewertet werden.

Man erkennt sofort, ob zu stark oder zu schwach gebremst wird.

Beispiel für den Fehler

error_v = v_ist - v_soll

Wenn error_v positiv ist, ist das System zu schnell. Es muss stärker gebremst werden.

Wenn error_v negativ ist, ist das System zu langsam. Es wurde zu stark gebremst.

Die eigentliche Stellrichtung hängt dann wieder von der Hydraulik ab.

17. Reglerabstimmung

Die Reglerabstimmung war nicht trivial, weil das System nicht ideal linear ist. Die Wirkung des Drucks hängt vom mechanischen Zustand, der Geschwindigkeit und der Hydraulik ab.

17.1 P-Anteil

Der P-Anteil reagiert direkt auf den aktuellen Fehler.

• Vorteil:
• schnelle Reaktion
• Nachteil:
• bei zu hohem Wert unruhig oder schwingend
• reagiert direkt auf Messrauschen

17.2 I-Anteil

Der I-Anteil beseitigt bleibende Abweichungen.

• Vorteil:
• korrigiert langfristige Fehler
• hilft, wenn ein reiner P-Regler den Sollwert nicht genau erreicht
• Nachteil:
• kann Windup verursachen
• kann das System träge oder instabil machen
• reagiert langsam

17.3 Vorsichtige Abstimmung

Die sinnvolle Vorgehensweise war:

1. Integrator zuerst klein oder aus

2. P-Anteil so einstellen, dass das System sichtbar reagiert

3. Vorzeichen prüfen

4. Begrenzungen kontrollieren

5. I-Anteil langsam erhöhen

6. Messdaten auswerten

Eine zu frühe Optimierung des Integrators hätte die echten Probleme verdeckt, insbesondere Vorzeichenfehler und Timingprobleme.

18. Warum der Druckverlauf alleine nicht genügt

Während der Tests wurde klar: Ein optisch ruhiger Druckverlauf ist hilfreich, reicht aber als Qualitätskriterium nicht aus.

Der Druck ist nur die Stellgröße. Ob die Regelung wirklich funktioniert, zeigt sich erst daran, wie gut die Ist-Geschwindigkeit der Sollkurve folgt.

Für die Beurteilung sind deshalb vor allem diese Größen entscheidend:

• Sollgeschwindigkeit (v_soll)
• Istgeschwindigkeit (v_ist)
• Abweichung zwischen Soll und Ist
• resultierender Stellwert (Druck bzw. Ausgangssignal)

Der Druckverlauf bleibt wichtig für die Diagnose der Reglerarbeit, ist aber nicht das eigentliche Zielsignal.

19. Benutzeroberfläche und Bedienung

Die Anwendung wurde mit einer grafischen Oberfläche umgesetzt. Diese dient nicht nur zur Bedienung, sondern auch zur Diagnose.

• Wichtige Funktionen sind:
• Starten und Stoppen der Ansteuerung
• Einstellen von Sollwerten
• Einstellen der Reglerparameter
• Anzeige von Geschwindigkeit
• Anzeige von Druck oder Stellwert
• Anzeige von Fehlerzuständen
• Plotten von Messwerten
• Speichern von Messdaten

Gerade während der Entwicklung war die Visualisierung entscheidend. Viele Probleme wurden erst durch die grafische Darstellung sichtbar.

20. Wichtige technische Erkenntnisse

Aus der Entwicklung ergeben sich sechs zentrale Erkenntnisse:

20.1 Die echte Zeitbasis ist entscheidend

Eine feste angenommene Zykluszeit ist unter Windows problematisch. Für eine korrekte Geschwindigkeitsberechnung muss die reale Zeitdifferenz verwendet werden.

20.2 Jitter kann wie ein mechanisches Problem aussehen

Ein unruhiges Geschwindigkeitssignal wirkt oft wie ein Defekt der Mechanik, kann aber auch durch Timing, Quantisierung oder Ableitung entstehen.

20.3 Beschleunigung ist empfindlicher als Geschwindigkeit

Beschleunigung entsteht aus der Differenz zweier Geschwindigkeiten und verstärkt dadurch Rauschen. Eine Sollgeschwindigkeitsrampe ist in der Regel robuster.

20.4 Vorzeichen müssen praktisch geprüft werden

Die reine Reglerformel reicht nicht aus. Bei Hydrauliksystemen muss experimentell geprüft werden, ob der Stellwert tatsächlich in die korrekte Richtung wirkt.

20.5 Vorspannung hilft, kann die Analyse aber erschweren

Ein Grunddruck verbessert das Ansprechverhalten, kann im Plot jedoch leicht mit dem Regleranteil verwechselt werden. Daher müssen Signalanteile sauber getrennt betrachtet werden.

20.6 Logging ist unverzichtbar

Ohne aufgezeichnete Messdaten ist die Fehlersuche kaum belastbar. Viele Effekte werden erst sichtbar, wenn Geschwindigkeit, Druck, Zeitbasis und Regleranteile gemeinsam ausgewertet werden.

21. Bewertung der PC- und Python-Lösung

Der Einsatz eines Windows-PCs war in diesem Projekt keine Bastellösung, sondern eine bewusste Engineering-Entscheidung: Entwicklung und Iteration konnten dadurch deutlich beschleunigt werden.

Für Prototyping und Analyse bietet die Kombination aus Windows und Python große Vorteile: Reglerlogik lässt sich schnell anpassen, Messdaten lassen sich sofort visualisieren und auswerten, und neue Hypothesen können innerhalb kurzer Zeit gegen reale Hardware getestet werden.

Gleichzeitig zeigt der Bericht die Grenzen offen und ehrlich: Windows ist nicht echtzeitfähig, Timer sind nicht deterministisch und die Regelung muss deshalb robust gegen Timing-Jitter ausgelegt werden. Für zeitkritische Serienanwendungen gehört der Kern der Regelung typischerweise auf SPS oder Echtzeitcontroller – der PC bleibt dann für Bedienung, Parametrierung, Logging und Diagnose ideal.

22. Mögliche Verbesserungen

Für eine Weiterentwicklung bieten sich mehrere Punkte an.

22.1 Echtzeitnähere Hardware

Die eigentliche schnelle Regelung könnte auf eine SPS oder einen Embedded Controller ausgelagert werden. Der PC würde dann nur noch Sollwerte, Parameter und Visualisierung übernehmen.

22.2 Bessere Signalaufbereitung

• Die Geschwindigkeitserfassung könnte robuster gemacht werden durch:
• bessere Encoder-Auswertung
• hardwareseitige Zähler
• Mittelung über passende Zeitfenster
• adaptive Filterung
• Plausibilitätsprüfung von Ausreissern

Für die automatische Erkennung ungewöhnlicher Signalverläufe wäre auch ein datengetriebener Ansatz denkbar. Thematisch verwandt ist mein Bericht Autoencoder zur Anomalieerkennung.

22.3 Modellbasierte Regelung

Da das Bremssystem nicht ideal linear ist, könnte ein Modell des Systems helfen. Dieses Modell könnte beschreiben, wie Druck, Geschwindigkeit und Verzögerung zusammenhängen.

22.4 Kennfeldregelung

Eine weitere Möglichkeit wäre ein Kennfeld:

benötigter Druck = Funktion von Geschwindigkeit und gewünschter Verzögerung

Der PI-Regler müsste dann nur noch die Restabweichung korrigieren.

22.5 Digitaler Zwilling

Ein digitaler Zwilling könnte verwendet werden, um das erwartete Verhalten mit dem realen Verhalten zu vergleichen.

• Beispiel:
• Sollmodell berechnet erwartete Geschwindigkeit
• Reales System liefert gemessene Geschwindigkeit
• Abweichung zeigt Fehler, Verschleiss oder falsche Parameter

22.6 Lernender Regler

Langfristig könnte auch ein lernender Ansatz eingesetzt werden. Die Software könnte aus vergangenen Bremsvorgängen lernen, welcher Druckverlauf bei welcher Anfangsgeschwindigkeit am besten funktioniert.

Wichtig wäre dabei, dass ein lernender Regler nicht unkontrolliert arbeitet, sondern immer durch Sicherheitsgrenzen und klassische Regelmechanismen abgesichert wird.

Für die Grundlagen neuronaler Verfahren verweise ich auf Neuronale Netzwerke verstehen. Der Bezug ist hier nicht die Sprachverarbeitung, sondern die Idee, technische Muster aus Messdaten zu lernen.

23. Fazit

Dieses Projekt zeigt, dass sich mit Python nicht nur Daten auswerten lassen, sondern reale technische Systeme strukturiert analysieren und regeln lassen. Entscheidend war dabei nicht nur der Code, sondern das Verständnis der gesamten Wirkkette: vom Sensor über Zeitbasis und Signalverarbeitung bis zur Hydraulik.

Die entwickelte Lösung zeigt, dass eine hydraulische Bremse mit einem Windows-PC und Python grundsätzlich präzise angesteuert werden kann. Die grössten Herausforderungen lagen nicht in der reinen Ausgabe eines analogen Signals, sondern in der korrekten Verarbeitung der Messwerte und im robusten Aufbau des Regelkreises.

• Besonders entscheidend waren:
• korrekte Behandlung des 16-Bit-Encoderüberlaufs
• Verwendung des genauen Timers statt des normalen Timers
• Reduktion von Jitter durch geeignete Filterung
• sorgfältige Interpretation der Soll- und Istgeschwindigkeit
• korrektes Vorzeichen des Reglers
• sinnvolle Vorspannung der Hydraulik
• Begrenzung des Integrators
• saubere Skalierung von Druck, Spannung und Softwarewerten
• aussagekräftige Plots zur Analyse

Die wichtigste Erkenntnis war, dass der Bremsvorgang am besten über den Vergleich von Sollgeschwindigkeit und Istgeschwindigkeit bewertet wird. Der Druckverlauf ist relevant, aber nur als Stellgröße. Entscheidend ist, ob das System der gewünschten Verzögerung tatsächlich folgt.

Aus Kryentech-Sicht zeigt dieses Projekt sehr gut den Kern meiner Arbeit: Elektrotechnik, Softwareentwicklung, Regelungstechnik und Fehlersuche an realer Hardware zusammenzuführen – nachvollziehbar, messbar und reproduzierbar.

← Zur Elektrotechnik-Übersicht