INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
MobaTools Library: Stepper mit Rampe - Beta-Tester gesucht ;-)
13.07.2019, 12:56
Beitrag #1
MobaTools Library: Stepper mit Rampe - Beta-Tester gesucht ;-)
Hallo,
der eine oder andere hier kennt ja meine MobaTools. Bei der Ansteuerung von Steppermotoren wurde schon einige Male ( sicher zu Recht ) bemängelt, dass da keine Anfahr- und Bremsrampen möglich sind.
Das habe ich nun eingebaut.
Auch ist der Code intern aufgeteilt worden, was zu reduziertem Flash-Verbrauch führt, wenn nicht alle Features genutzt werden. Das ist für den Anwender aber transparent, er muss nichts dafür tun.

Ich habe schon möglichst gründlich getestet. Trotzdem wäre es schön, wenn sich jemand finden würde, der sich als Beta-Tester hergibt, und das Ganze auch nochmal ausprobiert. Man selbst ist ja manchmal etwas betriebsblind.
Es würde mich also freuen, wenn jemand das unabhängig testet, bevor ich das als neue Release für den Bibliotheksverwalter freigebe. Der aktuelle Source ist hier zu finden.
In den Beispielen ist auch ein Sketch dabei, mit dem man die Steppermethoden über den seriellen Monitor aufrufen kann.

Die neuen Aufrufe sind in der deutschen Doku V1.1 bereits enthalten ( die englische muss ich noch übersetzen ).
Die Rampe wird über ihre Länge in Steps und damit über die Beschleunigungs-/Bremsstrecke definiert ( Zahl der Steps von Stillstand bis zur vorgegebenen Geschwindigkeit ).

Fragen dazu oder Fehlermeldungen können hier, oder direkt in GitHub gestellt werden.

Ich werde auch im Parallelforum nachfragen, ob dort jemand Lust hat das zu testen Wink

Release Notes:
Zitat:V1.1.0
Funktionserweiterung:
Rampe für die Steppermotore. Die Länge der Rampe wird über die Anzahl Steps ( vom Stillstand bis zum Zieltempo ) definiert.
Die Zahl der Steppermotore ist per define auf 6 begrenzt. Dies ist jedoch keine harte Grenze mehr, sondern eher der Leistungsfähigkeit des verwendeten Prozessors angepasst um die IRQ-Belastung nicht zu groß werden zu lassen. Werden z.b. keine Softleds und Servos genutzt, kann dieser Wert in der MobaTools.h auch erhöht werden.

Fehlerberichtigung
moving() gab falsche Werte bei Strecken größer +/- 32768, da eine temporäre Variable mit int statt long definiert war.

Sonstiges:
Optimierter Flash-Verbrauch, wenn nur Teile der Funktionalität genutzt werden (z.B. nur Stepper-Motore amsteuern)
Dazu wurden die Softwarekomponenten auf mehrere .cpp Dateien verteilt, so dass der Linker optimieren kann. So werden jetzt nur die tatsächlich verwendeten Komponenten eingebunden. Dazu musste die ISR für Stepper und Softleds etwas umgeschrieben werden ( da beide den gleichen IRQ verwenden ). Stepper bzw Softled Funktionen sind als jeweils eigene Funktionen mit Attribut __weak__ definiert.
In 'libraries.properties' muss die Zeile
dot_a_linkage=true
hinzugefügt werden. Damit werden erst alle *.cpp.o - Files in ein Archiv zusammengebunden bevor es an den Linker übergeben wird. Nur dann optimiert der Linker und bindet nur die .o Komponenten ein, die zum Auflösen der verwendeten Referenzen benötigt werden.
Aus Sicht des Anwenders ist dies transparent - es muss weiterhin nur die MobaTools.h eingebunden werden.

Gruß, Franz-Peter
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
14.07.2019, 09:00
Beitrag #2
RE: MobaTools Library: Stepper mit Rampe - Beta-Tester gesucht ;-)
Aufgrund einer Frage, die im Parallelforum aufgetaucht ist, sollte ich vielleicht das Ganze doch noch etwas genauer erläutern, damit keine falschen Erwartungen/Vorstellungen an die MobaTools und und diese Erweiterung aufkommen.
Es geht nicht darum, eine vordefinierte Rampe exakt nachzufahren. Vielleicht war der Begriff 'Rampe' da auch etwas unglücklich, und man sollte besser von Bescheunigungs-/Bremsweg sprechen ( Rampe ist halt kürzer und 'griffiger' Wink ). Es geht darum, Schrittverluste zu vermeiden, wenn sich die Steprate sprunghaft ändert, und der Motor nicht mehr nachkommt. Oder er kann die gewünschte Steprate aus dem Stand gar nicht erreichen und vibriert nur, statt sich zu bewegen.

Die MobaTools sind nach wie vor mit dem Gedanken 'Modellbau' entwickelt und da ist oftmals schon rein aus optischen Gründen ( z.B. bei einer Schiebebühne ) eine weiches Anfahren und Bremsen gewünscht, selbst wenn der Motor der Steprate auch direkt folgen könnte. Natürlich schließt das Anwendungen in anderen Bereichen nicht aus, aber für z.B. CNC-Anwendungen sind die MobaTools definitiv nicht gemacht/geeignet.

Die Characteristik der 'Rampe' ist fest, und lässt sich nicht beeinflussen. Es geht nur darum, dass sich der Schrittabstand von Schritt zu Schritt nicht zu stark ändert. ( Nur die Charakteristik der ersten/letzten Schritte aus dem Stand ließe sich durch ein #define etwas anpassen ). Grundsätzlich geht es schon in Richtung 'S-Rampe'. D.h. die Beschleunigung ist nicht konstant, sondern aus dem Stand geht es erstmal langsam los, um dann mehr Fahrt aufzunehmen.

Der 'Standardablauf' ( Beschleunigung/max.Steprate vorgeben, und dann zum Zielpunkt fahren ) ist sicher kein Problem und dürfte fehlerfrei funktionieren. Die 'Gemeinheiten' sind Änderungen an den Parametern während einer solchen Bewegung.

Wenn sich z.B. während des Bremsens die Zielposition ändert, kann es sein, dass das neue Ziel gar nicht mehr direkt erreichbar ist, weil es jetzt zu nah ist. Oder es ist weiter weg, und das Bremsen muss abgebrochen werden. Auch wenn der Bremsweg während des Bremsens verlängert wird, treten ähnliche Effekte auf.
Da kann man sich noch allerhand 'Gemeinheiten' ausdenken, um einen oder mehrere der Parameter zu einem möglichst ungünstigen Zeitpunkt zu ändern. Und ich bin mir eben nicht 100%tig sicher, ob ich da an alle Szenarien gedacht habe. In keinem Fall darf sich die Steprate sprunghaft ändern, oder sich das Programm verhaspeln. Und das letzte eingestellte Ziel muss immer zuverlässig erreicht werden. Gegebenenfalls auch dadurch, dass es zunächst darüber hinausgeht, und dann wieder zurück zum Ziel.

Gruß, Franz-Peter
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
Question Automatisierung Düsen bohren. 8 Bohrungen auf 360grad mit 2 stepper cadcam88 2 1.301 03.06.2018 10:55
Letzter Beitrag: Hilgi
  Arduino - Freelancer gesucht! DrIngFLO 0 1.238 05.02.2018 14:18
Letzter Beitrag: DrIngFLO
  Hilfe zu Bibliotheken gesucht Bastel_Ronald 7 2.209 24.12.2017 14:04
Letzter Beitrag: Bastel_Ronald
  Lösbares Szenario? Profi gesucht! Thorsten_S 3 2.917 02.12.2016 19:31
Letzter Beitrag: Thorsten_S
  18650 Multichannel Tester Lavezzi 1 1.647 15.11.2016 21:07
Letzter Beitrag: ardu_arne
  Button Library Scheams 0 2.557 04.06.2016 01:05
Letzter Beitrag: Scheams
Information NIBO burger - Testpersonen für Roboterbausatz gesucht... workwind 12 5.461 12.10.2015 17:08
Letzter Beitrag: workwind
  Transceiver gesucht (für Telemetriedaten) Zealot 4 3.989 15.04.2015 16:05
Letzter Beitrag: MaHa1976
  Projekt gesucht prokonp 2 3.394 10.11.2014 19:26
Letzter Beitrag: marcus
Bug ARDUINO EXPERTE GESUCHT Jerome Daly 2 3.507 08.11.2014 15:41
Letzter Beitrag: volvodani

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste