Schrittmotor und Arduino

[Elektro-Bastler]

Hallo zusammen,

vor langer Zeit hatte ich mal versucht einen Stepper mit einem Arduino anzusteuern. Die Endstufe möchte mit Step und Dir Signalen gefüttert werden, doch selbst die einfachste Form bereitete derbe Schwierigkeiten. Da mich einfach mal interessieren würde, wie man es besser machen könnte, erläutere ich mal die damalige Situation:

Arduino mit Poti am Analogeingang, paar Knöpfe zum Umschalten der Richtung, Eingabe von Werten
Step und Dir an 2 Digitalpins
Display zur Anzeige von Richtung und Geschwindigkeit + Verfahrstrategie

Versuch 1: Poti auslesen, in U/min umrechnen, entsprechende Frequenz für passende Drehzahl herausgeben.
Versuch 2: Festen Wert für Drehzahl und Richtung in die Steuerung übergeben, Start drücken, ab geht's bis Stop gedrückt wird.

Beide versuche klappten, ABER: Bei Versuch 1 lief der Motor deutlich langsamer als bei Versuch 2! Der (die) Schuldigen waren schnell ausgemacht, das analogRead ist einfach unglaublich lahm und macht deswegen das Timing kaputt. Darauf hin habe ich, wenn ich mich recht entsinne, das Auslesen in einen Interrupt gesteckt, damit es nicht mehr 1x pro Loop ausgelesen wird. Das Schreiben des LCD spielte aber wohl auch mit hinein, habe leider kein Oszi deswegen kann ich da nur raten.

Wie kann man das eleganter lösen, dass das Poti regelmäßig ausgelesen wird, damit die Geschwindigkeit beim Lauf des Motors verändert werden kann? Externen Interrupt bei Veränderung geht ja leider nicht, da die Unos das nur auf 2 digitalen Pins können. Wie machen das Steuerungen von 3D Druckern eigentlich, wenn sie 3 Achsen simultan bewegen?? Beschleunigungs- und Bremsrampen ist auch so ein Thema - der Stepper lief zwar, aber beim Starten und Stoppen ist mir das 19Nm Gerät fast auf dem Tisch umher gehüpft und die Endstufe findet solche Stromstöße bestimmt auch nicht so gut... Gibt es irgendwo Beispielcodes von fertigen Steuerungen mit Rampen? Wahrscheinlich hilft in dem Fall nur weg vom Arduino-Code und in C programmieren, damit die Sache schneller läuft? Ob ich das Projekt noch mal aufnehme weiß ich nicht, ich möchte die Thematik gerne trotzdem verstehen.

Viele Grüße
Julian

[gamerpaddy]

es gibt eine lib, die diese probleme löst. der "eigene" weg wäre viel mathematik und logik, ohne dabei den code zu verlangsamen.
http://www.airspayce.com/mikem/arduino/AccelStepper/

marlin, grbl und co haben viele hundert zeilen code die nur dafür zuständig sind, trotz der kompatibilität werden noch register und timer benutzt. so brauch man für jeden µC eine spezielle config.
Dadurch können die kompatibilitäts befehle wie analogRead, digitalWrite usw. umgehen und direkt die register benutzen, das ist mehr als 10x so schnell. für delay befehle und berechnungen wird auch assembler genutzt.
In der grbl stepper.c wird auch ausführlich erklärt was und wie alles funktioniert, sehr komplex.
https://github.com/grbl/grbl/blob/master/grbl/stepper.c


Du könntest den Poti sporadisch auslesen und das display dann beschreiben, statt es im mikrosekunden-takt vollzuballern zb.

Code: Alles auswählen

int delay = 10; //ms
int aVal = 0;

long timer = 0;
void loop(){
if(millis() > (timer+delay)){
  timer = millis();

  aVal = analogRead(0);  
  displaykram();
}

so sparst du dir jegliche delays welche den kompletten arduino anhalten würden.

[Elektro-Bastler]

Hey,

danke für deine Antwort, ich habe mal rein geschaut... der Ansatz mit den Interrupts war ja scheinbar gar nicht so verkehrt. Meine Programmierkenntnisse reichen allerdings bei weitem nicht aus um alle zu verstehen, geschweige denn selber etwas in der Richtung von Grund auf zu programmieren. Fertige Bibliotheken verwenden macht wohl doch am meisten Sinn, mit AccelStepper habe ich danach auch mal rumprobiert in Kombination mit diesen China-JMC-Servos bei einem Bekannten. Aber auch mit mäßigem Erfolg. Später hat es dann irgendwann doch geklappt, aber das war nur ein Stepper bewegen ohne weitere Programmierung wie Display oder Poti auslesen dazwischen. Den Vorschlag mit dem "nur alle x ms auslesen" werde ich da mal mit rein nehmen und schauen was passiert. Vielleicht sollte ich doch mal in so ein PC-Oszi investieren, ohne stochert man manchmal doch im Dunkeln, wenn man nur erahnen kann, was da am Step-Output tatsächlich raus kommt^^

Mich würde mal interessieren wie man sowas programmiertechnisch angehen könnte:



Da muss ja doch eine Vielzahl von Steppern(?) oder anderen Aktoren angesteuert werden. Dachte vielleicht könnte man die Steps zuerst seriell in Schieberegister senden und somit die Steps immer gleichzeitig ausführen.

Viele Grüße
Julian

[gamerpaddy]

die stepper in dem video würde ich wie ws2812b led's ansteuern, alle in reihe und nach und nach befehle weitergeben, dabei hat jeder stepper sein eigenen mcu. aber nicht schritte senden, sondern die soll-position und geschwindigkeit.

[SeriousD]

ADC auslesen und nen Stepper zugleich steuern ist absolut kein Problem für nen Atmega32.
Wahrscheinlich kann der µC dabei sogar noch ein wenig schlafen.

Grundsätzlich brauchts dafür 2 Interrupt Routinen
1. TimerX
2. ADC Conversion Complete

Als Pseudocode:

Code: Alles auswählen

Timer_Interruptroutine(){
ToggleStepPin()
startADCConversion()
}
ADC_Conversion_Complete_Routine(){
ADCResult = ADCRegister
//Richtung nach PotiStellung setzen
if ADCResult > 128{
setDirPin(1)
}else{
setDirPin(0)
}
//Timerfrequenz aus ADCWert berechnen
TimerCompareValue = BlackMagixMath(ADCResult)
}
main(){
TimerSetup()
ADCSetup()

while(1){
HurrDurr()
HerpaDerp()
}
}

Der Trick daran ist halt, dass nirgends gewartet wird bzw dass es keine blockierenden Programmteile gibt.

Die SetupRoutinen sind dabei wahrscheinlich das komplexeste, muss man im Datenblatt schauen, welche Register man wie konfigurieren will.
http://ww1.microchip.com/downloads/en/D ... asheet.pdf

Hier ein Codebeispiel für den ADC: http://www.avr-tutorials.com/adc/utiliz ... pt-feature
Hier ein Tutorial zum Timer: https://rn-wissen.de/wiki/index.php?tit ... nter_(Avr)

Ich denke mit dem Pseudocode und den anderen Codebeispielen wirst Du sicher eine gute Lösung zusammengebastelt bekommen ^^

Grüße
SeriousD

[VDX]

... kommt darauf an, was du nebenher noch alles laufen hast - bei den 32Bit-ArduinoDue geht's als CNC mehrachsig mit bis zu 400kHz ... bei einem Testaufbau mit 1 Achse Encoder + Analogport einlesen + SD-Karte einlesen habe ich aber auch mal nur 60kHz hinbekommen (die SD-Karte hat viel Zeit gekostet) ...

Viktor

[Elektro-Bastler]

Hallo SeriousD,

das Poti soll nicht für die Richtungsänderung zuständig sein, dafür waren zusätzliche Knöpfe. Wobei die Idee eigentlich gar nicht so dumm ist, da fallen die auch weg. Ich habe bei YT ein gutes Video gefunden, wo das erklärt wird und er steuert sogar 6 Stepper simultan und koordiniert. Möglich macht es die Tatsache, dass er die Bewegungen alle in Interrupts packt. Mit einem Stepper sollte ich das also locker schaffen. Ich habe einfach nur den Fehler gemacht die Interrupts falsch zu nutzen! Zumindest die Erkenntnis habe ich nun schon mal

Wie es in dem Video oben gemacht werden kann, wenn man wirklich ein oder mehrere Dutzend Stepper ansteuern muss würde mich trotzdem weiterhin interessieren. Ich denke mal da sind µC schon fast raus? Der Ansatz von gamerpaddy klingt interessant mit einem "Master-µC" der seriell kleine Tinys ansteuert und jeder Stepper so einen eigenen µC bekommt. Nur wie man auf dem Master die "Figuren" berechnet... ? Und welche Werte man am besten sendet... Weg, Zeit, Geschwindigkeit, Beschleunigungs-/Bremsrampen muss ja alles mit einbezogen werden. Vielleicht denke ich auch einfach zu kompliziert.

Viele Grüße

[MaxZ]

Moin,


Der allgemeine Trick ist wohl, so viel der Arbeit wie möglich der Hardware zu überlassen. Wenn ich an den uC auf meinem TI Board hier denke (Cortex M4 basiert), der hat nicht weniger als 12 Timer (die auch für PWM genutzt werden können) und 8 PWM Module mit 16 Ausgängen. Damit lässt sich schon reichlich anstellen (z.B. bis zu 28 Schrittmotoren steuern ) ohne die CPU überhaupt mit der eigentlichen Signalerzeugung zu belasten - auch nicht mit Interrupts. Und das ist deren kleinster ARM uC.

Konkret für das Video: das sind 16 Reihen mit je 38 Tropfen. In dem Video werden die scheinbar "reihenweise" angesteuert: Jede Reihe stellt irgendwas wellenartiges dar. Ich brauch also eine Steuerung, die mir 16 Wellen generieren und ein paar mal pro Sekunde an 38 Punkten abtasten kann, sowie 1-2 uC pro Reihe, die an die entsprechenden Positionen fahren. Selbst diese "Steuerung" könnte wohl auf nem uC umgesetzt werden, denke ich. Sagen wir die Positionen müssen 10 Mal pro Sekunde aktualisiert werden (sollte locker für die gezeigte Geschwindigkeit reichen), dann hat das Ding gute 160us zum Bestimmen jeder einzelnen Position.
Wenn man ne gescheitere Kommunikation hinbekommt, kann man bestimmt noch einiges an Rechenaufwand an die "Reihen-uCs" auslagern; die müssen ja nur 10x pro Sekunde nen PWM Wert setzen. Man könnte auf denen z.B. ne Art Glättungsfunktion laufen lassen, so dass die Hauptsteuerung nur 3x pro Sekunde neue Werte raushauen muss, ohne dass es ruckelt.

Schließlich pappst du noch nen ESP dran, bastelst ein hübsches Webinterface mit Standardpasswort und schon hast du deine "smarte" Beleuchtung.


Liebe Grüße,
Max

[Thunderbolt]

Man kann auf so 'nem Controller auch 'ne Echtzeitberiebssystem (z.B. FreeRTOS) laufen lassen, dann kann man mehrere Tasks parallel laufen lassen (z.B. daten empfangen, bahnberechnung und Stepper-steuerung)

oder du machst die Bahnberechnung in der IDLE-Zeit und lässt die Steppersteuerung im Timer-Interrupt laufen lassen

[VDX]

... apropos "Wellen" und gaaanz viele Microcontroller -- ich stelle mir da sowas vor, wo jeweils ein Motor von einem Mini-Arduino nach einer Analogspannung von 0-5V entsprechend über den Min-Max-Weg verfahren wird (oder auch ein Arduino mit mehreren Analogeingängen für genausoviele Motoren).

Zur "Erzeugung" der Wellenmuster-Bilder würde sich z.B. ein Bündel aus vielen Kunststoff-Lichtleitfasern anbieten, die alle zusammen auf eine opake/diffuse Platte ausgerichtet sind, wo von Hinten mit Licht Helligkeitsmuster draufprojiziet werden - je "heller" bzw. mehr Licht pro Lichtleiter ... umso höhere Spannung am Analogeingang ... umso höher der "Tropfen" ...

Das könnte auch über ein LCD-Display mit direkt draufgesetzten Lichtleitfasern gemacht werden -- idealerweise jeweils eine Lichtleifaser pro Pixel ... dann können "gaaanz viele" Pixel auch genausoviele Motoren über die jewelige Pixel-Helligkeit (zeichenbar/programmierbar) steuern

Viktor

[MaxZ]

Zur "Erzeugung" der Wellenmuster-Bilder würde sich z.B. ein Bündel aus vielen Kunststoff-Lichtleitfasern anbieten, die alle zusammen auf eine opake/diffuse Platte ausgerichtet sind, wo von Hinten mit Licht Helligkeitsmuster draufprojiziet werden - je "heller" bzw. mehr Licht pro Lichtleiter ... umso höhere Spannung am Analogeingang ... umso höher der "Tropfen" ...

Du schaffst es aber echt in jedem Projekt eine Verwendung für einen Laser (oder etwas das damit zu tun hat) zu finden

Sofern deine Lichtmuster nicht aus ner "schwierig simulierbaren" analogen Quelle wie nem Rad mit Mustern und ner Lampe - sorry, Laser - kommen, ist es doch ein ziemlich aufwändiger Umweg? Berechnen, ausgeben, ansteuern, "haufenweise" Optik-Zeug, messen, zurückrechnen - und wozu? Für die Diffusion? Was sonst nix ist als den benachbarten Feldern/Lampen/Positionen x Prozent deines aktuellen Wertes hinzuzugeben. Ich denk, da würd ich lieber 3 Zeilen Quellcode für's +x schreiben, und den Wert einfach digital ohne Umformungen weitergeben


Grüße,
Max

[VDX]

Hi Max,

bei meinem Vorschlag mit den "diffusen Lichtfeldern" gings weniger um Laser, als um die Möglichkeit, ein "Helligkeitsmusterfeld" über bewegte Lichtquellen hinter der diffusen Scheibe zu erzeugen - sowas ginge z.B. im Rahmen einer Messe-Präsentation mit Taschenlampen (oder eben auch Laserpointern), mit welchen die Leute dann "Bewegungsmuster" in die Tropfen-Installation zaubern

Deutlich einfacher ist sowas natürlich mit Lichtleitfasern direkt auf ein LCD-Display -- dann einfach mit der Maus in einem Zeichenprogramm ein paar Hell-Dunkel-Muster mit einem "unscharf"-Filter malen und gleichzeitig ausgeben/abfahren lassen ... ginge auch schön in "Echtzeit" über einen Touch-Screen o.ä. ...

Wo ich sowas wie diese "Helligkeistmusterfelder" für 3D-Oberflächen schonmal gesehen hatte, waren holografische (sorry! - auch Laser) Helligkeitsraster zum Belichten und Ätzen von Silizium-Oberflächen nach Interferenz-Figuren

Viktor

[Korni]

In der professionellen Veranstaltungstechnik gibt es einiges an Software, die solche komplexen Bewegungsmuster erzeugen können. An die Geräte ausgegeben werden die Daten häufig über Protokolle wie DMX oder Art-Net. DMX kann 512 8bit Werte mit 44fps übertragen.




In dem Video ab 0:35 wird die Bewegung des Sängers über Infrarotkameras erfasst und an der entsprechenden Stelle die Kugeln nach oben gezogen.


Der Arduino muss eigentlich nur über DMX einen Wert 0-255 empfangen und entsprechend mit gewisser Beschleunigung die neue Position anfahren. Die Bewegungsmuster sind dann kein Problem.
Eine Möglichkeit wäre, eine Matrix aus Pixeln zu erstellen, deren Helligkeit beeinflusst wird. Über diese Fläche legt man einen Sinus Helligkeitsverlauf, der sich in eine bestimmte Richtung bewegt. Anstatt der Helligkeit von Lampen, wird mit dem Wert des jeweiligen Pixels die Höhe der Leuchtkugel am Motor angesteuert.
MADRIX ist da eine sehr Mächtige Software für Farb-und Helligkeitseffekte für große 2D und 3D Anordnungen.
Mit geeigneter Hardware würde ich das gerne mal auf einer meiner Veranstaltungen machen.

[MaxZ]

@VDX:
Die eigentliche Frage bleibt nach wie vor, nur ist sie jetzt etwas anders gestellt.
Ich habe als Quelle einen Mauszeiger, und als Ziel irgend eine digitale Steuerung, die was mit der Mauszeigerposition machen soll. Mein Ansatz wär gewesen: geb einfach die Position an die Steuerung weiter. Serial.print(mouseX) )so in etwa. Oooder das Bild aus deinem Zeichenprogramm weitergeben. Kein Spezialdisplay mit Lichtwellenleiter (ich versteh sogar ehrlich gesagt nicht wie ein (Touch)display mit LWL funktionieren soll Displays leuchten nur in eine Richtung, und da ist entweder ein Finger oder ein LWL). Die Frage also: wozu?


Grüße,
Max

[VDX]

... das ist Alles eine Frage des "Inputs" und der Verarbeitung - das Touch-Display wäre angedacht als Eingabe mit einem optischen Feedback, um z.B. das auszugebende 3D-Flächen-Objekt als "Lichtfeld" mit Graustufen für die Höhe (z.B. Schwarz ganz unten, Weiß ganz Oben, Grau = 1-254 irgendwo dazwischen) zu sehen und über "Zeichenwerkzeuge" erzeugen oder verändern zu können.

Das gleiche Hell/Grau/Dunkel-Bild wird woanders nochmal ausgegeben -- und da drauf "sitzen" dann die vielen Glasfasern zu den Analogsensoren für die "Helligkeit->Position"-Umsetzung.

Wie das jetzt im Einzelnen dann umzusetzen wäre, ist auf vielfältige Art und Weise machbar ...

Viktor