Fahrtregler auf Arduino Basis

  • Zitat

    Original von IBF


    *Neugierig* Wie hätte das funktionieren sollen? Meine Erfahrung mit der Bremserei sagt, dass man die Bremspulse (Länge eines Bremspulses und Anzahl der Bremspulse) abhängig von dem Bot machen muss. Ein vierrädiger Bot bleibt schneller stehen als ein Zweirädiger. Ebenso spielt die Masse des Bots eine Rolle, wie lange die noch "nachschiebt", bevor die Bremse gelöst und die Gegenrichtung aktiviert werden kann. (Augenblicklich stelle ich die Bremse anhand des blauen Funkenflugs der Motor-Kollektoren ein. Wenn's zu viel der blauen Funken sind, wird die Pulslänge verringert, ...) Wie wolltest Du das "intelligent" lösen? (Auch wenn's nicht funktioniert, ware die "Vision" ganz interessant zu wissen.)


    Ein sehr interessantes Thema!
    Zunächst einmal um Missverständnisse zu vermeiden eine Rückfrage. Unter "Bremsen" ist hier gemeint:

    a) das Kurzschließen eines unbestromten, drehenden Motors (dann Generator) über dessen Anschlußdrähte maximal bis zum Stillstand, wobei es egal sein sollte, ob es sich um einen Bürstenmotor handelt oder dieser bürstenlos ist (BLDC).

    oder

    b) das Bestromen des drehenden Motors ENTGEGEN dem gegenwärtigen Drehsinn, wobei der Bremsvorgang dann spätestens ab Stillstand in eine Beschleunigung in die Gegenrichtung übergeht.

    Ohne die Rekuperation zu betrachten (beim Bot egal): Wo liegen die Vor- u. Nachteile der jeweiligen Methode?

    • Offizieller Beitrag

    Ich kann jetzt nur die Methode a) anführen.
    Früher wurde eiskalt der drehende Motor für eine gewisse Zeit (z.B. 300ms) kurzgeschlossen. Das führte zum Stillstand des Bots. Aber das Feuerwerk an den Kollektoren war doch etwas beunruhigend.

    Die Methode b) war für mich nie ein Thema. Das ist der Effekt, als wenn man mit dem Auto etwas sportlich rückwärts aus einem Parkplatz herausfährt und dann noch, wenn das Auto noch rückwärts rollt, den 1.Gang hineingrätscht und vorwärts wegfahren will. Da muss die Kupplung dann Qualen ertragen.... Insofern wollte ich den MOSFET-Stufen bei den Fahtreglern nie zumuten, neben dem hohen Anlaufstrom auch noch die Generatorspannung überwinden zu müssen.

  • OK, heißt also hier wird Methode a) diskutiert und Krümmel's "Intelligenzbremse" bezieht sich auf eben diese Methode.

    Da kann ich etwas zu beisteuern: Bei meinem Elektro-Quad (Projekt eQuad2009) hatte ich zu dieser Methode a) genau zwei Varianten bei meinem 4kW-Selbstbau-Controller im praktischem Fahrbetrieb ausprobiert:

    Variante 1: der 2kW-BLDC-Motor wird (vereinfacht beschrieben ohne Betrachtung der Ströme innerhalb der H-Brücke) beim Gasgeben normal bestromt und beim Gas-Wegnehmen (oder Betätigung der Betriebsbremse) wird die Bestromung unterbrochen und der Motor dreht frei (Freewheel) ggf. bis zum Stillstand od. erneuter Bestromung.

    Diese Variante dürfte auch der "Rollervariante" entsprechen, es wird i.d.R. nicht rekuperiert (keine Energierückgewinnung) und der Motor dreht nach und nach aus...

    Variante 2: bei dieser Variante wird der Motor eher wie ein Schrittmotor betrieben, was bedeutet, dass beim Gas-Wegnehmen der Motor eben nicht ausläuft sondern (durch Kurzschluß) gebremst wird, wobei die Bremswirkung (Verzögerungsmoment) umso stärker ist, je höher die Drehzahl (= Generatorleistung) ist.

    Diese Variante finde ich für einen Bot als Motorbremse genau richtig. Ich habe das technisch in meinen (u.a. hier im Forum beschriebenen) H-Brücken wie folgt gelöst: Beim Bestromen (Hochtouren) wird bekanntermaßen mit einer PWM gearbeitet, vereinfacht gibt es H-Pulse (= Bestromen) und L-Pulse (= Pause/keine Bestromung). Vom Stillstand des Motors fängt man also mit kleinen H-Pulsen an, die dann von der Pulsdauer her immer größer werden. Nun mache ich folgendes, was möglicherweise nicht unbedingt dem Standardverfahren entspricht: Bei den L-Pulsen schließe ich in dieser Variante den Motor IMMER kurz (über den Low-FET der Halbbrücke, die den H-Pulse liefert!). Auftouren bedeutet also bildlich gesprochen: 1% Bestromen 99% Kurzschluß, 2% Bestromen 98% Kurzschluß, usw... Wenn man dabei (Motorabhängig!) die richtige Frequenz auswählt, dann erwärmt sich der Motor beim gesamten Betrieb marginal stärker, als bei der Variante 1., und auch die Batterie-Stromaufnahme ist unwesentlich höher.
    Der Vorteil entsteht beim Abtouren: Der Motor hängt "hart" an der PWM und bleibt auf dem Punkt stehen (lastabhängig!) wenn die PWM= 0 ist. Der Clou: Der Motor bleibt mit PWM= 0 einfach kurzgeschlossen (und damit gebremst) bis wieder Aufgetourt wird; das Fahrzeug (Bot) kann also nicht od. nur erschwert rollen / geschoben werden.

    Diese Variante hatte ich bei meinem eQuad sogar im praktischen Fahrbetrieb getestet, jedoch war das Abtouren sehr unkomfortabel, da der 16kg schwere BLDC-Motor extreme Vibrationen auf den Fahrzeugrahmen übertragen hatte.
    ABER: Bei einem Bot würde ich erwarten, dass immer nach diesem Verfahren gearbeitet wird, da es doch m.E. überhaupt keinen Sinn macht den Bot langsam ausrollen zu lassen.
    Meine H-Brücke, die ich hier ausführlich vorgestellt habe, arbeitet exakt nach diesem Prinzip (PWM-L-Puls= 100% Kurzschluß für diese Pulsdauer). In meinem Video sieht man sehr deutlich, dass die (zugegeben unbelasteten) Bürstenmotoren exakt reagieren und sehr schnell abtouren: http://www.youtube.com/watch?v=EBkdO6Ccq_g

    Wenn also von einem "intelligentem Bremsen" geschrieben wird dann ist vermutlich damit gemeint, dass zu diesem Zeitpunkt die PWM völlig abgeschaltet wird und dafür punktuell (IBF's Brems-Pulse) der Motor kurzgeschlossen wird. Die Intelligenz dabei soll offenbar die Anzahl / Pulsweite dieser Brems-Pulse steuern, möglicherweise lastabhängig oder (intelligenter) in dem Maß, wie schnell der Kreuzknüppel betätigt wird. Ist das richtig so? Falls ja, warum nicht wie in meiner Variante die PWM anliegen lassen (mit zunehmenden L= Kurzschluß) und lediglich die Zeitspanne, in der die PWM runtergefahren wird, "intelligent" variieren? Dies könnte doch proportional zur Kreuzknüppelstellung umgesetzt werden.

    Nach meinem Verständnis bräuchte es keine Brems-Intelligenz, sondern eine stets anliegende und aktive PWM, welche mit einer zeitlich variablen Rampe (Kreuzknüppel-Position + Betätigungsgeschwindigkeit) hoch- bzw. runtergefahren wird.
    Gibt es möglicherweise ein Problem damit (außer das die Temperatur am "Bremstransistor" ansteigt), speziell beim Einsatz von Bürstenmotoren?
    Oder begrenzt der Temperaturanstieg an den Transistoren sogar die Brems-Dauer/Wirkung?
    Ich vermute eher, dass die betreffenden Personen Probleme mit der SW-Adaption haben, immerhin müssen ja die Signale der Funke in hammerharte-MOSFET-PWM umgesetzt werden; ist vielleicht nicht jedermanns Sache...
    .

    2 Mal editiert, zuletzt von Lars (22. Oktober 2014 um 17:08)

    • Offizieller Beitrag
    Zitat

    Nach meinem Verständnis bräuchte es keine Brems-Intelligenz, sondern eine stets anliegende und aktive PWM, welche mit einer zeitlich variablen Rampe (Kreuzknüppel-Position + Betätigungsgeschwindigkeit) hoch- bzw. runtergefahren wird.

    Wenn man darunter (wie oben beschrieben) versteht, dass immer einer der beiden FET's (also entweder High-Side ODER Lowe-Side) leitet, dann ist das ein Ansteuer-Schema, das bei einer normalen H-Brücke "Synchronous Rectification" genannt wird. Das ist ein sehr brauchbares Ansteuerschema, und man bekommt die Recuperation gratis dazu! ;)
    Die angesprochene Rampe für die PWM begrenzt ausserdem sehr effektiv den Motorstrom, gerade, wenn ein hohes Trägheitsmoment "am Motor hängt".

    Dieses Ansteuerschema hat übrigens (auch wenn man es erstmal meint) GARNIX mit Kurzschluss-Bremsen zu tun! ;)


    Kurzschluss-Bremsen:
    a. Beide High-side (oder beide Low-Side)-FET's sind permanent leitend (harte Kurzschluss-Bremse), die Energie wird in den Fet's und im Motor "verbraten"
    b. Beide High-side (oder beide Low-Side)-FET's sind getaktet gleichzeitig leitend oder nicht leitend ("Weiche" Kurzschluss-Bremse), die Energie wird aber immer noch in den Fet's und im Motor "verbraten"

    - Es findet bei beiden Varianten keine Recuperation statt!
    - Es tritt eine starke Erwärmung von Motor und FET's auf, wenn ein hohes Trägheitsmoment "am Motor hängt" (dazu gehört auch ein Bot, der aus voller Fahrt auf Null abgebremst wird!)

    Meine persönliche Meinung: "beidet nich verwenden tun!!!" *grins*


    Lars? Du müsstest eigentlich mit Deinem Ansteuerschema eine Rückspeisung sehen (messen) können...

    Zitat

    Gibt es möglicherweise ein Problem damit

    nur, wenn der Batteriestrom beim gegenerieren den maximalen Ladestrom der Akkus übersteigt oder die Zellenspannung über die Ladeschlussspannung steigt...

  • Nein, nein, es gibt bei meiner Variante keine Rückspeisung. Und ich bremse doch....!
    Ist doch klar: Wenn (bildlich) auf der linken Seite meiner H-Brücke der H-FET zum Auftouren hochgepulst wird dann ist ZEITGLEICH auf der rechten Seite der L-FET vollens durchgesteuert - für die gesamte Dauer des Fahrens, beim Stillstand und bis zum Richtungswechsel! Damit habe ich beim Abtouren sehr wohl eine starke Bremswirkung, da dann kurzfristig BEIDE L-FET's leitend sind - die gemäß Deiner Definition weiche Bremsung also. Aaaaber: Diese "weiche" Bremsung kann unvermittelt (quasi sofort) in eine "harte" überführt werden, eben dann, wenn die PWM wie von mir vorgeschlagen schlagartig runtergefahren wird; kann ja im ms-Bereich passieren: Dann sind sofort BEIDE L-FET dauerhaft aktiv und bleiben das auch (PWM= 0)!

    Ich habe keine Rekuperation, jedenfalls nicht geplant bzw. aktiv innerhalb der Brücke gesteuert - somit auch nicht verifiziert. Eine Spannungsüberhöhung am Fahrakku hatte ich tatsächlich mal festgestellt, meine Vermutung war via Bodydioden-Rückfluß...

    Einzig die Masse der Bots kann tatsächlich zu einem Problem bei VOLLEM Kurzschluß und hoher Drehzahl werden; deratiges hatte ich aber auch nicht empfohlen.

    edit: Nochmal zum Thema Rekuperation/Rückspeisung: Nach meinem Verständnis immer dann, wenn der ABTOURENDE Motor als Generator mit einem Generatorstrom belastet wird, welcher DURCH DIE BATTERIE fließt (= Ladestrom). Nur fließt außer in den FET-Umschaltmomenten bei mir nichts in die Batterie, da innerhalb der H-Brücke ein L-FET permanent und der andere L-FET zeitweise immer dann leitend ist, wenn innerhalb dieser HALB-Brücke der H-FET nicht leitend ist. Anders: Ein wirksamer Strom fließt AUS der Batterie via H-FET in den Motor (und via permaleitenden L-FET u. Masse zurück zur Batterie) ODER aus dem Motor via zeitweise leitenden L-FET / Masse / permaleitendem L-FET in den Motor zurück - aber nicht in die Batterie; somit auch keine Gefahr von Überspannung etc. (hoffe die technisch etwas unkorrekte Ausdrucksweise verdeutlicht den Stromfluß).

    Also begrenzen die Verluste (Temperaturerhöhung) die wirksame Brems-Kennlinie.
    Die von Krümmel angestrebte Brems-Intelligenz könnte also darin bestehen, möglichst stark via Motor-Kurzschluß bremsen zu können, ohne dabei ein Bauteil thermisch oder mechanisch zu überlasten...

    Oje, oje - nochmals edit: Es gibt TATSÄCHLICH in meiner Variante einen möglichen Rückfluß zur Batterie, würde ich nicht als (gewollte) Rekuperation bezeichnen aber immerhin, nämlich dann, wenn zwei Bedingungen erfüllt sind: a) der H-FET leitet (vermutete Bodydiode dann irrelevant) UND b) die Generatorspannung des abtourenden Motors GRÖßER als die Batteriespannung ist. LOL, ich kapier' meine eigene Brücke bald nicht mehr... Zu meiner Entlasutung ist mir das bislang garnicht aufgefallen, weil: a) ich in diesem Bereich soviele Versuche & Messungen gemacht habe, dass ich garnicht mehr weiß was ich wann gemessen habe und b) ich zur Absicherung der FET's immer ein paar fette Schutzdioden spendiere, die offensichtlich die folgende Spannungsüberhöhung verdauen ohne die weiße Fahne zu schwenken...
    Es war UnskilledWorker der mich auf die Idee brachte... Danke!
    .

    3 Mal editiert, zuletzt von Lars (22. Oktober 2014 um 19:24)

    • Offizieller Beitrag

    *grins* ich WUSSTE doch (oder besser hoffte), dass Du da drauf anspringst... ;)

    Zitat

    Nein, nein, es gibt bei meiner Variante keine Rückspeisung.

    Doch, doch, die gibt es... ;-)))
    Jedenfalls, wenn wir über das gleiche Ansteuerschema sprechen!

    Nur nochmal zur Sicherheit, Dein Ansteuerschema ist folgendes:
    - Die Namen der FET's seien mal LH/LL für die linke und RH/RL für die rechte Halbbrücke
    - RL sei dauerhaft leitend (solange die Drehrichtung des Motors nicht geändert wird und es keinen Freilauf "Coasten" des Motors gibt)
    - LH und LL werden ABWECHSELND leitend (nur von einer kleinen Totzeit im µs-Bereich getrennt)
    - Die Frequenz der PWM liege im Bereich von 8kHz bis 15kHz
    - Die Induktivität des Motors sei so hoch, dass der Motorstrom bei der oben genannten PWM-Frequenz und der abwechselnden Ansteuerung von LH/LL zwischen zwei PWM-Perioden nicht auf Null sinken kann. (wir betrachten also mal keine Scheibenläufer wie LEM, PERM, LYNCH usw und keine Motoren mit extrem wenig Turns)
    Soweit richtig?

    Unter diesen Voraussetzung ist richtig:

    Zitat

    da dann kurzfristig BEIDE L-FET's leitend sind

    Nicht ganz richtig ist:

    Zitat

    - die gemäß Deiner Definition weiche Bremsung also


    Meine Definition der "weichen KURZSCHLUSS-Bremsung" ist z.B.
    - RL leitend
    - LH nicht leitend (das ist der Unterschied zu Deiner Ansteuerung!)
    - LL getaktet
    Das habe ich oben missverständlich geschrieben!


    Nur noch ganz mal deutlich gesagt:
    Ich finde Dein Ansteuerschema gut, die harte oder weiche Kurzschlussbremse eher schlecht! (für Ants OK, für richtige Drehzahlsteller/ESC's/Speedos nicht optimal)


    Zitat

    Ich habe keine Rekuperation, jedenfalls nicht geplant

    Dann hast Du sie ganz umsonst dazu bekommen ;)

    Zitat

    Eine Spannungsüberhöhung am Fahrakku habe ich gelegentlich festgestellt, meine Vermutung via Bodydioden-Rückfluß...


    Über die Body-Dioden fliesst der Strom bei Deinem Ansteuerschema eigentlich nur in der Totzeit. (oder wenn Du extrem schnell einen Berg hinabrollst und der Motor mehr als Batteriespannung generiert)
    Wie gut die Rekuperation funktioniert hängt vom Fahrzeug (in Bewegung befindliche Masse, also die dort gespeicherte kinetische Energie), vom Motor(Induktivität), der Drehzahl des Motors, der Taktfrequenz der PWM und der "Runterlauframpe" der PWM ab...
    Wenn die Runterlauframpe langsam genug ist, siehst Du fast keine Rückspeisung. Ebenso wenn die Drehzahl des Motors zu gering ( <20% der Nenndrehzahl) ist.


    Kleine Erläuterung, warum die Rückspeisung mit Deinem Ansteuerschema funktioniert:

    Man kann den Mittelpunkt der abwechselnd angesteuerten FET's LH/LL als gesteuerte Spannungsquelle ansehen.
    Duty-Cycle der PWM: DT = Zeit LH_ON / Zeit LL_ON)

    Der !!!zeitliche Mittelwert!!! der Spannung zwischen GND und dem Mittelpunkt von LH/LL beträgt ca.: U_Batterie * DT

    - Ist diese Spannung höher als die vom Motor generierte Spannung, fließt Strom von der Batterie zum Motor, der Motor arbeitet als Motor.
    - Ist diese Spannung kleiner als die vom Motor generierte Spannung, fließt Strom von Motor zur Batterie, der Motor arbeitet als Generator.

    Damit das gut funktioniert, ist es Wichtig, dass der Strom dreieckförmig bleibt und nicht sägezahnförmig ist (also zwischen den PWM-Perioden nicht auf Null fällt)

    *Klugschei...ss...erModusAus* *zwinker*

    EDIT:
    Während ich hier getipselt und telefoniert habe, hast Du Deinen Post editiert... ;)
    Kann man meine "Erläuterung" verstehen?

  • Zitat

    Original von UnskilledWorker
    Kann man meine "Erläuterung" verstehen?


    LOL...! Also ich verstehe das schon, was kein Wunder ist, da ich mir die Controller für manntragende und seit Jahren im Einsatz befindliche Elektrofahrzeuge selbst erfolgreich aufbaue und teste. Aaaaber ob alle anderen wissbegierigen User aus dem Geschreibsel noch schlau werden - wer weiß....

    • Offizieller Beitrag
    Zitat

    Aaaaber ob alle anderen wissbegierigen User aus dem Geschreibsel noch schlau werden - wer weiß....


    Mit Sicherheit nicht... *Schenkelklopf*

    Sehen wir es mal so: wenn sich jemand für die Materie interessiert, versucht er auch solche "Monsterposts" zu verstehen... und fragt gegebenenfalls nach...
    Wenn nicht: Dann ist sowieso Hopfen und Malz (Gott erhalt's!) verloren... ;)


    Ups... lese gerade Dein EDIT-EDIT ;)

    Zitat

    b) die Generatorspannung des abtourenden Motors GRÖßER als die Batteriespannung ist.

    "b) die Generatorspannung des abtourenden Motors GRÖßER als die virtuelle Spannung zwischen den taktenden FET's LH/LL ist" wäre richtig ;)

  • So heute einen kleinen Programmierfehler behoben.
    Und zwar beim ersten einschalten. Sobald ich mein Unterprogramme Motor1 und Motor2 das erste mal aufrufe sagt die Bremse bremsen. In BEIDE Richtungen. Das das nicht so gut ist brauche ich ja nicht erklären. Das ist jetzt behoben und ich habe mir die ersten Gedanken zur Kanalzuordnung mit der Fernsteuerung gemacht. Wird komplizierter als ich dachte.

    Erfahrungen sind was sehr nützliches, leider macht man sie erst kurz nachdem man sie gebraucht hätte...

  • Zitat

    Original von Krümmel
    Wird komplizierter als ich dachte.


    Das wird es meistens....
    In meinem (hier ausführlich vorgestellten) H-Brücken-Bauprojekt hatte ich testweise eine Pistolen-FB nebst 2,4GHz-Empfänger adaptiert. Soweit ich mich erinnere war die SW nach Aufbau der HW innerhalb von 1 bis 2 Tagen erstellt, die beiden Motoren liefen bei FB-Betätigung wie erwünscht. Aber es gab jede Menge Störungen, welche z.T. zu erheblicher Fehlfunktion führten, u.a. zuckten die Motoren bei Betrieb einer Mikrowelle, welche auch auf 2,4GHz "sendet". So habe ich weitere Tage benötigt, um die SW mühevoll zu entstören, damit die gesamte Steuerung an DIESER Pistolen-FB einwandfrei läuft; nun auch mit Mikrowelle und 2,4GHz-Funkkamera. Bei der nächsten FB (und entsprechendem Timing) kann natürlich alles wieder ganz anders sein!

    Übrigens würde ich nie mit Compiler-Befehlen wie PulsIn o.ä. arbeiten, weil die Gefahr besteht, dass die Abfrage der Port-Eingänge (welche die FB-Empfängersignale verarbeiten) im Polling erfolgt, dass Hauptprogramm also auf den nächsten Impuls "wartet". Das ist für Anfänger zwar erstmal leichter, aber technisch leider keine schöne Methode, da der Programmierer ein Stück weit die Kontrolle über das Timing verliert (= zusätzliche Fehlerquelle).

    Viel geschickter finde ich folgendes Verfahren, welches ich auch konsequent umsetze:

    Die Signale vom Empfänger laufen (für 2 Kanäle) auf 2 interruptfähige I/O-Ports, beim ATMEL z.B. INT0 und INT1, wobei JEDE Flanken-ÄNDERUNG einen Interrupt auslöst - den sog. IRQ-Handler (Interrupt-Serviceroutine). Der IRQ-Handler wird von mir aus Gründen möglichst schneller Programm-Abarbeitung konsequent in Assembler geschrieben, dass Hauptprogramm dagegen in einer beliebigen Hochsprache (C, BASCOM, o.ä.).

    Der IRQ-Handler wertet also die Signale der FB vollständig aus (inkl. SW-Filter), aber NUR DANN, wenn diese auch tatsächlich auftreten (Flankengetriggert). Ansonsten läuft das Hauptprogramm und macht andere (hoffentlich sinnvolle) Dinge. Innerhalb des Hauptprogramms werden nun 2 Variablen definiert, z.B. Kanal1 und Kanal2 für die beiden FB-Kanäle, wobei der Byte-Wert Kanal1= Kanal2= 128 bedeuten würde, dass bei der Pistolen-FB Gas & Lenkung auf Mitte stehen (nicht betätigt) - soweit ganz einfach.
    Der Clou ist nun folgender: Da sich die IRQ's völlig um die Empfänger-Signale kümmern, kann das Hauptprogramm nach Belieben auf die beiden Variablen Kanal1/Kanal2 zurückgreifen und dabei sicher sein, dass diese stets aktuell sind. Für einen Failsafe ist dann ein weiterer Timer-IRQ nötig, welcher solange nicht auslöst, wie eingehende und als plausibel interpretierte Empfänger-Signale (keine Störungen) den Timer periodisch zurücksetzen.

    Wenn die IRQ's sauber programmiert werden, braucht sich das Hauptprogramm nicht mehr um die Erfassung der Empfänger-Signale zu kümmern und kann stattdessen die Variablen auswerten und die Motoren entsprechend ansteuern.

  • Die Idee mit der Pulsauswertung über ISR's finde ich ansich auch gut und habe ich sonst auch gerne so gemacht. Aber gibt es da leider folgendes Problem -> Beispiel mein selbstentwickelter Copter (aktuell auf Eis gelegt) -> Dort habe ich ja sechs Kanäle, die ich auch mittels Interrupt-Eingänge abfrage. Nur bei den sechs Kanälen, die alle mit ihrem Interrupt dazwischen funken, wird die ganze Steuerung ziemlich träge...

    Gibt es da nicht eine Alternative? Nimmt man die MultiWii (überlicher Flight-Controller -> Mein Hexa fliegt damit) werten die ja zehn Kanäle aus und die Steuerung ist absolut verzugsfrei...

  • Zitat

    Original von Replikator
    Aber gibt es da leider folgendes Problem -> Beispiel mein selbstentwickelter Copter (aktuell auf Eis gelegt) -> Dort habe ich ja sechs Kanäle, die ich auch mittels Interrupt-Eingänge abfrage. Nur bei den sechs Kanälen, die alle mit ihrem Interrupt dazwischen funken, wird die ganze Steuerung ziemlich träge...

    Gibt es da nicht eine Alternative?


    Gibt es.
    Beispiel IRQ-Handler/ISR: Es gibt Compiler-Anweisungen, die ALLE 32 Register des Controllers beim IRQ pushen und am Ende der IRQ-/ISR-Routine wieder popen. Ist (speziell auch für weniger geübte Programmierer) die sichere Methode, man kann dann kein Register vergessen u. kommt auch mit der LIFO-Reihenfolge nicht durcheinander. Kostet aber Laufzeit: Wenn z.B. nur 2 Reg. im IRQ-Handler benötigt werden, dann werden für die restlichen 30 völlig unnötig kostbare Taktzyklen verschwendet...
    Lösung: Im IRQ-Handler möglichst wenige Reg. nutzen u. manuell PUSHen u. POPen = Laufzeitgewinn!

    Beispiel Hardware: Controller kosten kaum Geld. Das es wohl ein Selbstbauprojekt ist wird einfach ein weiterer Slave-Controller eingesetzt, welcher sich ausschließlich um diese 6 IRQ/ISR kümmert und die (gesiebten!) Ergebnisse der 6 Kanäle z.B. via I²C periodisch an den Master-Controller überträgt. Da ist der Failsafe dann auch umsonst: Ausbleiben der Daten = Failsafe.

    Weiters käme noch Prüfung der eigenen Programmiersystematik zu tragen, also Optimierung des Programmcodes. Da lassen sich meisten Routinen optimieren sodass 10...20% Laufzeitgewinn schnell zusammen sind.

    Wenn das auch nicht reicht: Controller übertakten (nur Test, nicht im Sicherheitsbereich) und ggf. nächst höhere Controllergeneration einsetzen.... viel Erfolg!

  • Gut das ich kein PulseIn oder so verwenden muss. Ich bekomme meine Signale schon Digital :). Aber so lange der auf seinen Datensatz wartet steht das Programm erstmal. Aber maximal 100ms dann reagiert der Failsafe.
    Aber es wäre schön wenn es Multithreding geben würde. Das würde vieles vereinfachen und efektiver machen.

    Bei dem Sat Empfänger ist das so. Jeder "Frame" dauert 22ms. Davon wird eine Zeit lang die daten übertragen der rest ist Pause. In dieser Pause werden dann die Werte verarbeitet und die Motoren angesteuert. Leider auch der Nachteil für die Bremse. Ich kann 1-2ms einstellen und 22ms-x. Weil wenn ich bremse und gerade ein neuer Frame erkannt wird, wird der erstmal gelesen. So lange hängt das Programm. Mal gucken wo ich das Programm noch Geschwindigkeit rausholen kann.
    Die Motoren werden alle 22ms mit neuen Werten gefüttert. Also etwa eine Aktualisierungsrate von 45Hz.

    Erfahrungen sind was sehr nützliches, leider macht man sie erst kurz nachdem man sie gebraucht hätte...

    • Offizieller Beitrag
    Zitat

    Aber so lange der auf seinen Datensatz wartet steht das Programm erstmal.


    Kannst Du den Datensatz nicht byteweise (aus dem Empfangsregister) abrufen und dann selber zusammensetzen? Dann kannst Du in der Zwischenzeit (=Warten auf das nächste Byte) wieder was im Programm tun.

    Zu der o.g. Methode, die Empfängersignale über Interrupt abzufangen:
    Ihr seid durch die 2.4GHz-Technik natürlich etwas verwöhnt. :D Wer noch mit 40Mhz arbeitet, dem sei dringend davon abgeraten, mit der Interrupt-Methode zu arbeiten. => Viele Fahrtregler-Entwickler in unserem Verein sind im Prinzip daran gescheitert (=Umwandlung von Elektronik-Equipment in Rauch und Gestank), dass die Empfänger sehr viele "Fehlpulse" weitergegeben hatten. Bei jedem Flankenwechsel wurde die Hauptroutine unterbrochen. Wenn dann noch ohne Absicherung gearbeitet wird (und das ist bei den ersten Software-Test-Version natürlich der Fall), dann kommen die Anlauf-, Stop-, und Bremszeiten natürlich durcheinander.

    Auch wenn's archäologisch klingt: Ich frage in der Hauptroutine immer alle paar -zig Mikrosekunden den Status von ALLEN Porteingängen ab, auf denen ein Empfängerausgang hängt. Der Byte-Wert (also maximal 8 Eingänge möglich) wird gespeichert. Beim nächsten Abfragen wird wieder eingelesen und dieser aktuelle Wert mit dem vorherigen Wert über eine EXOR-Funktion verknüpft. Hat sich was geändert, ist das Ergebnis-Register > 0. Wenn sich nichts geändert hat, dann die Abfrageroutine verlassen, um Zeit zu sparen und sich im Fahrtregler um wichtigere Sachen kümmern.
    Wenn sich was geändert hat, über das betreffende Bit des EXOR-Ergebnisses auf den betreffenden Flankenwechsel reagieren und dann den zugehörigen Timer starten, oder stoppen, oder die Zeitdifferenz ausrechnen, oder auf Gültigkeit prüfen, oder mit den vorherigen drei berechneten Timer-Werten eine Glättung zu bilden, oder das "Ready-Flag" setzen, um dem PWM zu sagen, dass jetzt eine neue gültige Zeitvorgabe anliegt.... ;)

    Wenn der Empfänger zuviel Blödsinn liefert (=ständiger Flankenwechsel), dann brauche ich zwar in der (Porteinlesen-)Subroutine u.U. die maximale Durchlaufzeit, aber zumindest intressieren mich irgendwelche kurz aufeinanderfolgenden Flankenwechsel nicht, weil ich gerade bei der Auswertung des bisherigen Timerwertes bin. ("... alles schön der Reihe nach.... " ;) )

  • Zitat

    Original von IBF
    Zu der o.g. Methode, die Empfängersignale über Interrupt abzufangen: Ihr seid durch die 2.4GHz-Technik natürlich etwas verwöhnt. :D Wer noch mit 40Mhz arbeitet, dem sei dringend davon abgeraten, mit der Interrupt-Methode zu arbeiten.


    @ IBF: Natürlich kennst Du die Fertigkeiten der Fragesteller hier wesentlich besser als ich, dennoch bin ich ein glühender Verfechter der Interrupt-Techniken. Folglich ist es nie zu spät, sich damit eingehend zu beschäftigen. Bei Hochgeschwindigkeitsanwendungen (hier im 22ms-Frame sind wir natürlich weit davon entfernt) setze ich auch schonmal rekursive Interrupts ein und verzichte ggf. zu Gunsten eines Laufzeitgewinn auf den Register-Push/Pop, sofern das Reg. NUR in dieser speziellen ISR genutzt wird. Verschachtelte Interrups OHNE Register-Rettung ist natürlich was für Vollprofis und wird von mir auch keinesfalls empfohlen (= Haftungsausschlußerklärung).

    Zitat

    Original von IBF
    Wenn der Empfänger zuviel Blödsinn liefert (=ständiger Flankenwechsel), dann brauche ich zwar in der (Porteinlesen-)Subroutine u.U. die maximale Durchlaufzeit, aber zumindest intressieren mich irgendwelche kurz aufeinanderfolgenden Flankenwechsel nicht, weil ich gerade bei der Auswertung des bisherigen Timerwertes bin.


    Mir erschließt sich hierbei nicht, weshalb die konsequente Anwendung der Interrupt-Technik im Störungsfall ggü. dem Hauptprogramm-Polling ein Nachteil darstellen soll. Denn wenn die 100 Flanken/s korrekten / nutzbaren FB-IRQs durch 1000 Störimpulsen/s überlagert werden, dann ist die gesamte Funktionalität infrage gestellt. Das ist m.E. unabhängig davon, ob nun 1000 IRQ's zuviel sind und ggf. das Hauptpgm. nicht mehr abgearbeitet wird oder gleich das Hauptprogramm im Polling hängen bleibt. Verschachtelung mal außen vor, der Stack kann auch dann nicht überlaufen, wenn 100% Nutzsignal durch 1000% Störgröße überlagert wird. Auch ein IRQ bzw. dessen ISR läßt sich übrigens wirksam mit einem Timer verschränken, sodass in einem vorgegebenen Zeitfenster durchaus auf den (zeitlich unerwarteten!) Störimpuls-IRQ angemessen reagiert werden kann (sagen wir innert 2 µs bei 16MHz-ATMEL), OHNE das das System kollabiert: Bei ISR-Einsprung wird zunächst simpel das Timer-Overflowflag abgefragt und im negativen Fall (= Störung, zu früher IRQ) die ISR mit RET sofort wieder verlassen; schneller gehts nicht. Außer die globalen Statusflags (und max. 1 Register) braucht auch nichts gepusht/gepopt werden.

    Bezüglich der "dauerhaft abgerauchten" Anwendungen der o.g. User verfängt mein ernstgemeinter Tipp: Bei derartigem Prototyping IMMER ein (einstellbares) strombegrenzendes Netzteil einsetzen und mit dem kleinsten Strom beginnen, welcher gerade für die Prüfung einer neu programmierten / grundsätzlichen Funktion nötig ist (also Motoren im Leerlauf betreiben und NICHT als erstes den Blockadestrom prüfen!) - dann halten auch die Schaltungen länger....

    • Offizieller Beitrag

    Lars: natürlich ist die Interrupt-Technik ganz genial, um schnell und vor allem übersichtlich seine Ziele zu erreichen.
    Aber gerade die Grenzfälle (Störungen, Triggersignal an der Schaltschwelle, ....) sorgen dann für Ernüchterungen. Mit meiner o.g. Bemerkung über die abgerauchten Schaltung wollte ich auch niemand die Kompetenz zum Fahrtreglerbau absprechen. Aber beim Erstgebrauch mit Steckernetzteil und kleinen Testmotörchen ist die Welt noch in Ordnung. Wenn dann ein kräftigerer Motor zum Einsatz kommt, um z.B. mal das Anfahrverhalten zu probieren, dann brauchts auch stärkere Akkus. Und schon sind wir beim Thema "EMV", die dann urplötzlich dafür sorgt, dass der Prozessor durch den Reset geht oder (worüber wir gerade diskutieren) irgendwo ein paar Flankenwechsel zuviel auftreten.

    Wenn jemand die Interrupts benutzen will, dann kann ich ihn nicht davon abhalten. Aber meine Warnung sollte darauf hinauslaufen, nicht "blind" in eine Störeinkopplungs-Falle zu tappen.

  • Zitat

    Original von IBF
    Wenn jemand die Interrupts benutzen will, dann kann ich ihn nicht davon abhalten. Aber meine Warnung sollte darauf hinauslaufen, nicht "blind" in eine Störeinkopplungs-Falle zu tappen.


    Eigen- und Fremdstörungen sind natürlich immer wieder ein Thema, woran selbst erfahrene Entwickler verzweifeln können. Normalerweise muß dann der gesamte Aufbau ins Labor, um die Fehlerwirkung verlässlich reproduzieren zu können - sonst können die Gegenmaßnahmen kaum untersucht & programmiert werden. Ein eher unerfahrener Entwickler / Programmierer wird dann möglicherweise völlig überfordert sein, dann helfen auch die gutgemeinten Tipps nicht wirklich weiter.

    So fände ich es auch nicht verwunderlich, wenn 20% vom Programmieraufwand / Speicherplatz / Laufzeit für das Einlesen / Verarbeiten der eigentlichen (im Idealfall ungestörten) FB-Signale draufgehen, und 80% für Signal-Verifikation / ausgeklügelte Entstörungsmaßnahmen fällig werden. Das ist oftmals die bittere Realität der E-Technik, man sollte als Schaltungsentwickler jederzeit mit einigen "netten Effekten" rechnen...