Zitat

---

auch wir müssen uns an die Regeln des Datenschutzes und der Datenschutz-Grundverordnung halten!
Accounts, die über 2 Jahre nicht genutzt werden, betrachten wir als inaktiv und löschen somit die Benutzerdaten.

---

Moin,
ich wüsste nun nicht, dass in der DSGVO ein Passus steht, der die "Verbleibdauer länger inaktiver User in Internetforen" betrifft

Nichtsdestotrotz:
ab einer bestimmten Zeitspanne der Abwesenheit ist wohl wirklich mit "Desinteresse" eines Users zu rechnen.
Dem Forum nützen keine Karteileichen, und wenn ich irgendwen per PN anschreibe und Derjenige hat sich längst von der Moba abgewendet und spielt heute Hallenhalma, dann nützt mir das auch nichts.

@"oli4":

nach mindestens (siehe den Hinweis von "stummilein" auf die Verweildauer) zwei Jahren habe ich üblicherweise fast jede Herztransplantations-Reha geschafft, oder einen Hütchentausch (neue Frau ) oder eine Weltreise...
Du siehst vielleicht ein, dass das "automatische Deaktivieren" bei einer derartig großzügig eingestellten Zeitspanne für das Forum oder die Gemeinschaft der User (sowas soll es geben) eher dienlich ist.
Da würde ich nun nicht von "Rauswurf" sprechen und dahinter eine Kohorte von Ausrufezeichen hängen

Klar, das ist für dich nun ärgerlich. Oder nicht? Bist ja wieder da und die alten Beiträge sind es nach deinem Bekunden auch.
Wo genau ist nun das Problem?

Viele Grüße,
Oliver

hallo zäme,
die antwort von stummilein ist für mich völlig ok und nachvollziehbar. somit möchte ich dieses thema beenden, klammer geschlossen... und zurück zum fachlichen.

wie weiter oben geschrieben, möchte ich einen technologie-upgrade von zbus machen. als kandidat sehe ich zum beispiel die ESP32 module. diese sind zwar etwas grösser als die alten atmel zigbit-module mit 802.15.4 funk, dafür haben sie enorm viel mehr rechenleistung. meine hoffnung ist, dass dies eine feinere motoren-regulation erlaubt, und vielleicht auch generell mehr "intelligenz" in der motorensteuerung erlaubt. mal sehen. sich in das zeugs einzuarbeiten und ist immer eine riesenzeitaufwendige sache... vor ende dieses jahr glaube ich nicht etwas präsentieren zu können.

hallo stummis!
ganz nach dem motto "totgesagte leben länger" hat nun doch die zweite runde für zbus eingeläutet... eine kleine revolution!!!

seit ende sommer 2020 habe ich an einer portierung auf ESP32 (einem leistungsfähigeren, wifi-basierten 32bit mikrokontroller-modul) und an der weiterentwicklung der lok-decoder firmware gearbeitet. ein technologie-upgrade der in die jahre gekommenen zbus-elektronik. hmm, ist ja auch schon 10 jahre her, dass die erste zbus-lok ihre runden zog. (tja, man wird nicht jünger...)

die kommunikation basiert nun auf wifi, tcp/ip und mqtt. die befürchteten langen latenzen im vergleich zum 802.15.4-basierten funkprotokoll haben sich nicht bewahrheitet. respektive die broker-basierte kommunikations-architektur entschärft das ganze: die kommunikation runter zur lok ist dank dem broker auf ein minimum reduziert. das stupide polling entfällt. die lok sendet daten nur bei änderung.

das interessante am ganzen ist, dass es nun ausser dem lok-decoder keine weitere spezielle modellbahn-elektronik mehr braucht!

die motorsteuerung brauchte dann doch noch einiges, bis sie zufriedenstellend funktionierte. die miserable ADC-qualität des esp32 musste durch exzessives oversampling kompensiert werden. nachdem monatelang mit diesem prototyp-ungetüm zuerst aufgebockt und dann auf der küchentisch-teststrecke einige kilometer abgeklopft wurden, läuft das ganze nun sanft und stabil. es fängt an richtig spass zu machen.

un hier eine kurze show (nicht erschrecken, die komisch tönende sprache da ist "schwitzerdütsch", musste die auszusterben drohende sprache ein wenig promoten... )

Ich staune und bin begeistert!
Gratuliere, Olli

Ich habe zwar keine Anlage mehr, aber bin immer noch interessiert .

Hallo Oli,

auch von mir kommt große Begeisterung

Hallo Oli

Daumen hoch - Die Portation auf WLAN ist nicht ohne, auch wenn der ESP sich hier besonders anbietet. Wir haben den in unserer Zentrale
als Sender verbaut und können vom schlechten Analog-Digital-Converter (ADC) ein Lied singen - Wie mußt Du erst mit der Motorsteuerung
gekämpft haben !!!

Mir gefällt auch Deine Art, erst etwas zu präsentieren wenn es funktioniert ==> Also nochmals Daumen hoch.

In diesem Sinne ein gesundes und erfolgreiches Neues


viele Grüße aus Franken

Michael Müller

Hallo Oli

Daumen hoch - Die Portation auf WLAN ist nicht ohne, auch wenn der ESP sich hier besonders anbietet. Wir haben den in unserer Zentrale
als Sender verbaut und können vom schlechten Analog-Digital-Converter (ADC) ein Lied singen - Wie mußt Du erst mit der Motorsteuerung
gekämpft haben !!!

Mir gefällt auch Deine Art, erst etwas zu präsentieren wenn es funktioniert ==> Also nochmals Daumen hoch.

In diesem Sinne ein gesundes und erfolgreiches Neues


viele Grüße aus Franken

Michael Müller

Hi Oli

Sehr cool was du da am bauen bist! Gratulation.
Hast du auch schon darüber nachgedacht weitere Sensorik wie eine IMU (Beschleunigungs- und Gyrosensoren) einzubauen, um z.B. Steigungen zu messen oder automatisch zu kalibrieren wenn du bergauf mit hoher Last fährst oder auch die Beschaffenheit der Gleise zwecks Wartung zu überprüfen?
Da gibt es ja sehr handliche Boards wie mpu6050 (du wirst wahrscheindlich gleich den Chip auf deinem Print wollen, da gibt es gute von Bosch z.B.).

PS. Und Daumen hoch für schwiizerdütsch, wir müssen hier auf .de etwas Balance bringen

vielen dank für euer feedback. hier ein paar antworten:

@michael:

Zitat

---

Wir haben den in unserer Zentrale
als Sender verbaut und können vom schlechten Analog-Digital-Converter (ADC) ein Lied singen - Wie mußt Du erst mit der Motorsteuerung
gekämpft haben !!!

---

beim ADC habe ich zwei strategien verfolgt: erstens massiv übersamplen (20 bis 30 samples pro messung), und zweitens den spannungsbereich einengen, also per widerstand etwas anheben, um sich ein bisschen von 0V zu distanzieren (denn dort sättigte das signal). der hierdurch resultierende offset wird dann von der software automatisch kompensiert.

@thewifimaster:

Zitat

---

Hast du auch schon darüber nachgedacht weitere Sensorik wie eine IMU (Beschleunigungs- und Gyrosensoren) einzubauen, um z.B. Steigungen zu messen oder automatisch zu kalibrieren wenn du bergauf mit hoher Last fährst oder auch die Beschaffenheit der Gleise zwecks Wartung zu überprüfen?

---

die steigung versuche ich mit dem motor zu messen (kraftmessung), in dem die software die "übliche" last kennt, und wenn diese höher wird, dann nimmt diese an es sei eine steigung. analog dazu, wenn diese niedriger wird, dann ein gefälle. diese information wird in der führerstandsimulation verwendet, um den anteil an zug durch die gravitation zu simulieren. sprich, wenn die bremsen nicht angezogen sind, dann rollt der zug langsam davon, oder bei steigungen braucht man mehr fahrleistung und bei gefälle muss mehr gebremst werden... so wie bei der grossen bahn.

eine IMU wäre sicher präziser, und würde auch mehr informationen liefern. das stelle ich mir dann eher in einem speziellen messfahrzeug vor, als in jeder lok.

hallo leute,
und hier noch einen beitrag zur reibungskompensation, welche "sanfte" doppeltraktionen zweier lokomotiven erlauben, ohne dass diese gegeneinander kämpfen, und jede seine geschwindigkeit vorgeben will. dies würde unweigerlich zu hohen kräfte zwischen den loks am zughaken führen, mit den konsequenzen, dass die haftreifen langfristig einen enormen abrieb erfahren, und bei einsatz einer lok am zugschluss durch die hohen kräften entgleisungsgefahr der leichten wagen in den kurven besteht.


der trick hier ist, dass nur eine lok geschwindigkeitsgeregelt wird (sozusagen der master). hingegen die andere lok wird kraft-geregelt (der slave). das heisst, diese toleriert geschwindigkeitsabweichungen des zuges, versucht aber die zug- oder stosskraft einigermassen in den griff zu bekommen, indem sie diese begrenzt und versucht konstant zu halten.


das ganze ist nicht so einfach, da die lok selber mit getriebe und räder einen grossen reibungsanteil aufweist, und so eine klassische drehmomentregelung des motors nicht ausreicht. die lok muss seine eigene reibung kennenlernen, und diese dann kompensieren. das kennenlernen geschieht während kalibrierungsfahrten, und die kompensation dann im betrieb im zbus-lokdecoder.

es hat also noch einige nerven, schweissperlen und lange abende gebraucht, bis die doppeltraktion dann einigermassen sanft funktionierte. im folgenden video wird die kraft zwischen den beiden loks mit hilfe einer "papierfeder" mit hilfe eines aufgerollten post-its bildlich veranschaulicht. ausserdem wird die zauberei des heissluftlötens gezeigt. viel spass!

Hallo Olli,

schön, dass es mit diesem genialen Projekt weitergeht.
Im Vergleich mit herkömmlichen Decodern ist das Ferrari gegen Lada.
Der Muss-ich-unbdingt-haben-Faktor ist bei mir gigantisch. Erstaunlich, dass Du hier bei den Stummis so wenig feedback erhälst.

schönen Sonntag,
Michael

hallo michael,
danke für dein feedback!
wenn ich so die letzten zehn jahre beobachte, muss ich gestehen, dass die herkömmlichen decoder sich vom lada zum skoda weiterentwickelt haben ... zum beispiel das langsamfahrverhalten von neuen H0-dampfloks ist zum teil fantastisch.

hingegen wo heute noch alles beim alten stehen geblieben ist, ist die vorbildsgerechte führerstandsteuerung. klar, viele wollen dies vielleicht auch nicht, hmm, aber nicht so sicher: zum beispiel beim flugsimulator ist man weit fortgeschritten, und hat sowas demokratisiert. wo hingegen die bahn immer noch mit diesen langweiligen sliders am handy oder tablet bedient werden, fast ohne jegliche simulation der physik (ausser vielleicht die beschleunigungsbegrenzung). aber genau da würde doch der spass beginnen: schleudern der räder, überstromabschaltung, langsames reagieren der zugbremse (sprich frühzeitiges überlegen), berg- und talfahrten mit ihren tücken... und und und...

Zitat

---

Erstaunlich, dass Du hier bei den Stummis so wenig feedback erhälst.

---

das liegt vielleicht daran , dass "public relation" nie so mein ding war

gruss
oli4

Zitat

---

Erstaunlich, dass Du hier bei den Stummis so wenig feedback erhälst.

---

Moin,
vielleicht will man ja gar nicht in einer "originalen" Lok mit allen ihren Anforderungen sitzen (zumindest, solange man kein gelernter Lokführer ist), sondern nur einfach seine Bahn über die Gleise fahren lassen.
Mein 4-jähriger Enkel hat noch keine Ahnung, wie man überhaupt eine E-Lok oder eine Dampflok in der Realität fährt, aber meine Gartenbahnloks bewegt er mit Digitalsteuerung und Funkhandregler sicher und sehr zu seiner Zufriedenheit über meine Anlage.

Damit will ich nicht ausschließen, das dieses Projekt einige Freaks sehr entzücken kann, aber die große Masse wird wohl die gebotenen Fähigkeiten nie Nutzen wollen / können.
Auch am Beispiel Flugsimulator wage ich die Frage zu stellen, wie viele der PC-Besitzer fliegen eine Maschine in echter Simulation (d.h. nach allen Flugvorschriften etc.) im Flugsimulator?

Schöne Grüße
Johannes

Hallo oli4,

irgendwann bin ich mal zufällig über deinen Bericht gestossen, ich habe alles mehrmals gelesen, weil es total spannend ist was du da machst. Ich habe keine Modellbahn und deshalb kann ich zu Digitalsteuerungen auch kein Urteil bilden - das was du da aber auf die Beine gestellt hast ist schon eine große Nummer (vielleicht sind die Modellbahner noch nicht soweit um sich auch mit den Bremsvorgängen langer Züge zu befassen).
Ich habe mit staunen das Video angesehen, bei dem der Anker vom Motor sich mit ca. einer Umdrehung pro Sekunde dreht !
Weil es mich schon stark interessiert würde gerne wissen, wie du die Drehzahl vom Motor misst.
Ich würde mich sehr über eine Antwort freuen.

Viele Grüße MM

hallo MM,
die drehzahl des motors wird folgendermassen gemessen:

der motor wird per elektronik gespiesen, genauer, per pulsweitenmodulation (PWM)

die drehzahl des motors wird "sensorlos" gemessen (also ohne spezifischen drehzahl-sensor)

das heisst, der motor wird ca. 100 mal pro sekunde ganz kurz vollständig ausgeschalten (also grössenordnung eine bis zwei millisekunden lang)

während dieser zeit läuft der rotor dank seiner massenträgheit seelenruhig weiter

und somit wirkt er nun wie ein generator, und generiert eine elektrische spannung

diese spannung ist bei generatoren proportional zur drehzahl

die elektronik misst genau zu diesem zeitpunkt jeweils die spannung des motors

Hallo oli4,

danke für deine ausführliche Antwort !

Mir war nicht klar ob man die Messung der Generatorspannung zwischen 2 PWM Pulsen macht (da bleibt ja nicht viel Zeit für) oder ob die Pulse während der Messung komplett aus bleiben.
Jetzt weiss ich ja bescheid.

Ich werden deine Berichte weiterhin "aufsaugen" (total spannend was du da so machst!).

Danke & Gruß MM

Hallo @oli4,

ich setze ebenfalls den ESP-8266 in Form des ESP-01-Boards für meine Selbstbauschaltungen (Zubehör-Decoder, Fahrregler) ein. Nur die Lokdecoder sind noch kommerzielle Produkte. Nachdem ich das zuerst kategorisch ausgeschlossen hatte bin ich inzwischen langsam soweit dass ich mir auch schon über DIY-Lokdekoder Gedanken mache. Daher an dieser Stelle ein Dankeschön an Dich für die Ausführungen zur Motorregelung!

Ob ich den ESP auch für Lokdecoder einsetze weiß ich noch nicht - der ist mir eigentlich viel zu groß und da die Loks eh Strom brauchen kann ich den auch zyklisch umpolen und zur Signalübertragung nutzen. Aber egal welcher Controller zum Einsatz kommt helfen mir Deine Aussagen weiter. Ist halt immer gut wenn jemand schonmal bestätigen kann dass es auf eine bestimmte Art und Weise wirklich funktioniert.

Gruß,
Coder

hallo zäme,
danke für euer feedback! hier ein paar antworten und kommentare:

@Johannes:
ist ganz klar. je komplexer die angelegenheit, desto kleiner der benutzerkreis. idealerweise ist der "schwierigkeitsgrad" bei so einer steuerung konfigurierbar, vom einfachen geschwindigkeitsgesteuerten mode bis hin zur realistischen simulation des vorbildes in allen aspekten.

@MM:
was noch zu sagen ist, der motor muss, wenn die generierte spannung gemessen wird, wirklich komplett ausgeschalten sein, also PWM off, strom unterbrechen, beide pole völlig offen. im gegensatz zum PWM betrieb, wo entweder speisespannung an den motor angelegt wird, oder die beiden motorpole kurzgeschlossen werden, also null-spannung, damit der strom weiter fliesst.

@Coder:
der grosse challenge beim lokdecoder ist sicherlich die motorregelung. bis diese stabil und robust läuft braucht es einiges an schweissarbeit. aber hauptsache es macht spass...

gruss
oli4

Hallo oli4,

danke für deine Zusatzinfos, ich probiere mal mit einem Arduino aus (was anderes habe, kann und will ich nicht) ob ich das irgendwie hin kriege.
Eine konktrte Anwendung dafür habe ich nicht, ich möchte nur wissen ob und wie es geht mit der "Drehzahlmessung".

Gruß MM

Hallo oli4,

ich habe mit einem Spielzeugmotor und einem Arduino / H-Brücke eine PID geregelte Motoransteuerung aufgebaut. Das Messen der Generatorspannung ging einfacher umzusetzen als ich mir das jahrelang vorgestellt hatte. Das schöne an der SoftwareRegelung ist, dass die PID Parameter / PWM Frequenz beim Motoranlauf und bei "erhöhter" Drehzahl einfach angepasst werden können.
Die Übertragung der Steuerdaten zwischen Sender und Empfänger erfolgt bei mir via RS232 (entweder verwende ich bei ortsfestem Aufbau ein 3adriges Kabel zwischen Sender und Empfänger oder wenn ich mobil sein will 2 Bluetooth HM-10 Module).
Mal sehen was ich damit jetzt mache, vielleicht baue ich das dann mal in ein kleines Modellauto ein.

Vielen Dank nochmal für deine Infos (und die damit verbundene Motivation das Thema mal anzugehen).

Viele Grüße MM

hallo MM,
schön! somit willkommen in der sensorless motor control welt !

Zitat von tmmtmm im Beitrag #120

---

Das schöne an der SoftwareRegelung ist, dass die PID Parameter / PWM Frequenz beim Motoranlauf und bei "erhöhter" Drehzahl einfach angepasst werden können.

---

Hallo Oli,
bin ja nach wie vor begeistert von deinem zbus-Projekt und jetzt mit dem EPS32 wird das ganze noch sensationeller und universeller einsetzbar. Wir hatten ja hier letztes Jahr kurz geschrieben.
Wie sehen den deine weiteren Pläne aus mit deinem Projekt? Willst du das irgendwann mal veröffentlichen? Der ganze Ansatz hat schon so einige Vorteile: keine zusätzliche Hardware mehr notwendig, vor allem kein Steuersignal mehr auf der Schiene. Dazu müsste doch genügend allgemeines Interesse bestehen.

Mit meinem Projekt bin ich jetzt nicht wirklich weiter gekommen. Hab mein Board mit dem ESP32 nochmals angepasst und hab noch einen anderen IC für die Motorregelung eingesetzt und ich möchte nach wie vor eine Regelung mit der Gegen-EMK-Messung einbauen für den Allstrommotor von Märklin (Elektromagneten als Stator, kein Dauermagnet) aber der Nachwuchs geht zur Zeit vor
So wie es aussieht sollte ich auch zukünftig auf das Heißluft-Löten umsteigen. Manuell so kleine Bauteile zu löten ist eine einzige Katastrophe. Was für eine Heißluft-Lötstation verwendest du?
Schöne Grüße

Hallo Oli,

vielen Dank für Dein Angebot, einige Details aus Deinem Projekt mit der Modellbahngemeinschaft zu teilen.

Nur zur Einleitung schnell ein paar Worte zu dem Projekt, an dem ich mitarbeite: Es ist ein auf den Espressif-Chips basierendes Framework, das mit mit unterschiedlichen Steuerungen zusammenarbeitet und in unterschiedlichen Anwendungen genutzt werden kann. Das Projekt ist im GitHub unter "littleyoda-DCC-Decoder" zu finden. Ich setze es zur Steuerung meiner Gartenbahnloks ein - aber es gibt auch Anwender bis herunter zur Spur-Z.
Mein Part in dem Projekt ist die Erweiterung der Motorsteuerung mit PWM auf eine Motor-Drehzahlregelung über Back-EMF. Genau an dieser Stelle treffen sich die Projekte - nur das Du Oli schon sehr, sehr viel weiter bist.

Meine Fragen (sorry Modellbahner, jetzt geht es ins Eingemachte)
- Ist es zur Spannungsmessung des DC-Motors erforderlich im Interrupt beide Motoranschlüsse zu messen? Über die Freilaufdiode der H-Brücke ist doch die Spannung auf der Low-Seite immer nur 0,7V?
- Leidet die Spannungsmessung des ohnehin nicht besondern tollen ADC, wenn man zwei Spannungen mißt und darum den Multiplexer ständig aktiv hat?
- Hast Du die Versorgungsspannung direkt gemessen - oder wäre auch eine Messung in der On-Phase des PWM ausreichend?
- Würdest Du den Schaltplan und die Dimensionierung mit uns teilen?

- Zu den Tasks: Ich habe meine Hauptapplikation auf Core1 laufen. Der Drehzahlregler läuft auf Core0, wie auch die ISR von Core0 bedient wird. Kann ich nachprüfen, ob Teile einer Bibliothek, z.B. WiFi, aus dem Core1 auf dem Core0 gestartet werden? Deine Software läuft doch vermutlich auch auf beiden Cores, richtig?
- Der Compiler meckert, wenn ich keine Loop() anlege, sondern nur die beiden Tasks für die Cores. Was packe ich sinnvoll in die Loop()-Routine hinein? Ein "Dummy" Statement?

- Zum Regler: Wie ist Deine Erfahrung: Reicht PI oder muss man PID implementieren? Ich denke, wenn man ohnehin Anfahr- und Bremsverzögerung haben will, kann man sich den D-Teil sparen.
- Wie oft läuft Dein Regler? Alle paar Millisekunden oder mit maximaler Geschwindigkeit des Tasks? Und was wäre dann die Zeitkonstante?
- An die automatische Optimierung der Reglerparameter wage ich mich noch nicht heran. Hast Du vielleicht Literatur zu dem Thema?

Hoffentlich ist die Liste der Fragen nicht zu lang. Ich werde in den kommenden Wochen meinen Testaufbau vom Steckbrett auf eine Versuchsplatine umbauen, damit ich "stabiler" werde und auch den JTAG nutzen kann. Bis ich also wieder in die Software gucken kann, werden bestimmt wieder einige Wochen vergehen.

Ich sage schon einmal DANKE und würde mich freuen, wenn Du einige meiner Fragen beantworten würdest.

Grüße von Düsselklaus
Klaus

hallo klaus,
hier ein paar antworten zu den meisten deiner fragen.

Zitat

---

Ist es zur Spannungsmessung des DC-Motors erforderlich im Interrupt beide Motoranschlüsse zu messen? Über die Freilaufdiode der H-Brücke ist doch die Spannung auf der Low-Seite immer nur 0,7V?

---

also ich mache die back-EMF steuerung beim ESP32 nicht in interrupts, sondern in einem task. der grund ist folgender: beim ESP32 können interrupt routinen nur aus dem RAM ausgeführt werden. du kannst zwar deine funktionen ins RAM mappen, aber sobald du von dort aus ESP-library funktionen aufrufen willst (z.B. PWM steuern), crasht das ding. scheinbar kann er nicht alle library funktionen ins RAM mappen.

der ESP32 ist nunmal keine hard-realtime-fähige maschine, sondern eher eine "kommunikationsmaschine" fürs IOT und so... das merkt man auch daran, dass zum beispiel der ADC von miserabler qualität ist, oder dass die hardware-peripherie-funktionalität verglichen mit üblichen mikrokontroller (wie z.B. ARM Cortex-M) sehr beschränkt ist.

aber nun zurück zu deiner frage: ja, ich würde immer beide motoranschlüsse messen. dies führt zu genaueren und somit stabileren resultaten als die andere motorpol-spannung nur anzunehmen. und vorallem wenn du auch wert auf langsamfahrt setzt, wo die BEMF-spannung um 0V herum tanzt, hättest du sonst eine sättigung und somit einen drift.

Zitat

---

Leidet die Spannungsmessung des ohnehin nicht besondern tollen ADC, wenn man zwei Spannungen mißt und darum den Multiplexer ständig aktiv hat?

---

der wurde ja dafür gemacht :-)... wegen des schlechten ADCs habe ich ein glaub ich 12-faches oversampling pro motorpol gemacht, aperioidisch, einfach aneinanderfolgend, jeweils abwechslungsweise beide motorpole (also total 24 ADC messungen), und bei jedem wechsel die differenz zum vorigen wert berechnet und aufsummiert.

Zitat

---

Hast Du die Versorgungsspannung direkt gemessen - oder wäre auch eine Messung in der On-Phase des PWM ausreichend?

---

die versorgungsspannung messe ich separat. starke variationen der versorgungsspannung kann man beim regler als feed-forward einfliessen lassen, um die drehzahlvariation (wegen versorgungsspannungsvariation) zu kompensieren.

Zitat

---

Würdest Du den Schaltplan und die Dimensionierung mit uns teilen?

---

hier die BEMF-motortreiber-schaltung mit anschluss zum ESP32. der rest der schaltung ist glaub ich nicht relevant...

Zitat

---

Zu den Tasks: Ich habe meine Hauptapplikation auf Core1 laufen. Der Drehzahlregler läuft auf Core0, wie auch die ISR von Core0 bedient wird. Kann ich nachprüfen, ob Teile einer Bibliothek, z.B. WiFi, aus dem Core1 auf dem Core0 gestartet werden? Deine Software läuft doch vermutlich auch auf beiden Cores, richtig?

---

ich habe mich auf die voreingestellte konfiguration beschränkt: wifi in einem core, applikation im anderen.

Zitat

---

Zum Regler: Wie ist Deine Erfahrung: Reicht PI oder muss man PID implementieren? Ich denke, wenn man ohnehin Anfahr- und Bremsverzögerung haben will, kann man sich den D-Teil sparen.

---

aus meiner sicht hat dies keinen zusammenhang. man muss sich das in zwei stufen vorstellen:
1) der empfangene sollwert ändert sich sprunghaft. dieser führt in ein "rampenmodul", welcher die sprünge in lineare rampen umwandelt.
2) dieses rampenbehaftetes signal geht zum eingang des PID-reglers. der regler versucht mit seinen PID-parameter so gut wie möglich dieses signal zu folgen. und dies in einem um magnituden schnelleren zeitrahmen als die anfahr- und bremsverzögerung selber.

somit dienen die PID-werte zur akkuraten "verfolgung" des rampensignals, ganz unabhängig wie steil oder flach die nnfahr- und bremsverzögerungsrampen sind.

also ich würde den D-teil trotzdem implementieren, auch wenn er später auf 0 gesetzt wird.

Zitat

---

Wie oft läuft Dein Regler? Alle paar Millisekunden oder mit maximaler Geschwindigkeit des Tasks? Und was wäre dann die Zeitkonstante?

---

bei mir läuft er periodisch alle 10ms. ich denke der PID-regler wird viel einfacher, als wenn dieser variable samplerate unterstützen soll.

Zitat

---

An die automatische Optimierung der Reglerparameter wage ich mich noch nicht heran. Hast Du vielleicht Literatur zu dem Thema?

---

ich bin da sehr pragmatisch und weniger akademisch vorgegangen: mit P wert langsam hoch, bis es instabil wird, dann 50% zurück, dann dasselbe mit I wert...

nun ja, der regler ist eins, aber dann gibt es noch tausend andere parameter zum tunen und justieren, von feed-forward, über variables PID-parameter-morphen in funktion der geschwindigkeit, PWM frequenz, timing für die BEMF-abtastung... und und und... und vorsicht, du bewegst dich da in eine eigene kleine welt... das ganze wird schnell mal zu einem lebenswerk. hauptsache es macht spass .

gruss
oli4

Hallo Oli4,

Du hast über die Jahre nicht kontinuierlich, aber immer wieder engagiert am Projekt gearbeitet.
Alle Achtung, für die Ausdauer und natürlich das Ergebnis!

Bist Du noch aktiv am Projekt? Was steht im Fokus, wenn ja?
Nur Interessehalber: ein schlechter ADC ist ja eigentlich selten, wie hast Du diese Eigenschaft ermittelt?

Mein Dauerbrenner ist ein RFID Leser für die Ableitung von Besetztmeldung und Zugverfolgung, der die NFC Frequenzen nutzt. Der hat bereits viel Kraft und Geld, fast 4 Jahre insgesamt gekostet, daher nehme ich beruhigt zur Kenntnis, dass auch Du Dir Zeit lässt.
Ist Dir bewusst, dass es das CTC Projekt, Produkt gibt, welches ein ähnliches Grundkonzept verfolgt? Falls Du es nicht kennst, CTC steht für Clever Train Control, das solltest Du leicht finden.

Viele Grüße,
Joachim