Nachteil von Schrittmotoren beim Programieren

Hi,
ich hab mich bei meinem ersten Bot, wegen der Präzision für Schrittmotoren entschieden. Auch dass man keine Wegstreckensensoren braucht hat mich überzeugt.
In der Praxis bin ich jetzt aber beim Programieren auf einen Nachteil gestossen, der mir so nicht klar war:
Bei einem Getriebemotor braucht der Prozessor nur Drehrichtung und Geschwindigkeit zu setzen. Der Motor dreht dann "von alleine" und der Prozessor hat Zeit sich um Sensorik etc. zu kümmern.
Beim Schrittmotor ist der Prozessor beschäftigt solange der Bot sich bewegt, also sieht der Bot nichts (keine Zeit für Sensoren) und kann auch sonst nichts tun was Prozessorleistung braucht. Damit der Bot grössere Strecken zurücklegen kann ohne währendessen total blind zu sein muss er alle paar Zentimeter kurz gucken. Für das Gucken steht nur sehr wenig Zeit zur verfügung wenn der Bot nicht ruckelig fahren soll.
Ich habe vor das Problem zu entschärfen indem ich den CoProz auf dem Roboterboard möglichst viel der Sensorik machen lassen will.
Hat jemand noch Anregungen zu dem Thema?
Als absoluter Neuling beim Programmieren von AVRs und Bots kann ich jeden Tip gebrauchen.

Grüsse, Marvin

P.S Ich Programiere mit Bascom.

Hallo Marvin,

dazu hat kürzlich schon jemand gefragt, schau mal hier https://www.roboternetz.de/phpBB2/viewtopic.php?t=1614

Also im Grunde kannst du zwischen den einzelen Schritten noch ne ganze Ecke machen. In der Regel reicht die Zeit aus um Sensoren abzufragen. Du mußt es nur recht gleichmäßig machen. z.B. bei jedem Schritt oder bei höherer Geschwindigkeit bei jedem zweiten Schritt etc., sonst kanns etwas ruckeln.

Bequemer dürfte ein Timer sein. Du kann in Basom einen Timer so konfigurieren, das alle x Millisekunden eine Unterfunktion aufruft. In dieser Unterfunktion kannst Du dann immer einen Schritt machen.

Im Hauptprogramm kannst dU nebenbei ganz normal programmieren und deine Sensoren abfragen. Finden diese Hinderniss, dann setzt du eine bestimmte Variable auf High. In der Timerunteroutine kannst du die Variable abfragen und gegebenenfalls keine Schritte mehr machen.

Das mit der Timerfunktion ist denkbar einfach, schau mal in Doku und in die Beispielprogramme. Beim Kühnel Buch wird das sogar anstelle des berühmten "Hello World" Demo ganz am Anfang gezeigt.

Gruß Frank

Ahh, alles klar!
Vielen Dank für den Tip. :)


Grüsse, Marvin

man kann auch mit einem 2. controller oder ein paar TLL-ICs den schrittmotortreiber ansteuern und diese steuerung dann mit der eigentlichen steuerung komunizieren lassen. eigentlich kann man mit einem timer-ic den takt vorgeben und muss dann meit dem controller nur die drehrichtung einstellen

Genau, einfach nen Vorwärts/Rückwärts-Zähler nehmen und nen BCD zu Dezimal decoder dahinter. Man gibt die drehrichtung und Takt vor und alles geht von alleine. Indem der µC die Carries im Timer zählt, kann er dann sagen, wie weit er gefahren ist.

Wie wäre es die Sache mit dem Schrittmotor zeitunkritisch in Assembler zu programmieren? Dann hat der Rest genug Zeit um sich um die Sensorik zu kümmern. Um einen Motor drehen zu lassen reicht es völlig einen 16-Bit Integerwert zu nehmen und die Bits 0 und 1 auszumaskieren und diese beiden Bits auf 4 Ports aufzulösen. Damit hat man als Wort die Ist-Position die man vergleichen kann per CC-Basic um die Drehrichtung zu bestimmen in die er drehen muss. Bei jedem Schritt positiv plus 1 zählen und bei jeden Schritt negativ eben -1 zählen in der Ist-Wert Variablen. Der Rest ergibt sich dann von alleine. Wenn das alles in Assembler geschrieben ist kann man das sogar als Interrupt programmieren und den Interrupt extern takten durch einen NE555, mit dem man dann einfach die Routinenaufrufe steuern kann. Den Interrupt kann man ins Assembler-Programm verbiegen und spart sich den Sys-Aufruf im CC-Basic was Zeit spart für die Routine.

Zitat:

---

Wie wäre es die Sache mit dem Schrittmotor zeitunkritisch in Assembler zu programmieren?
. ..........
Damit hat man als Wort die Ist-Position die man vergleichen kann per CC-Basic um die Drehrichtung zu bestimmen in die er drehen muss.

---

CC-Basic hört sich für mich irgendwie nach C-Basic und damit nach C-Control an.

Marvin schreibt von AVRs, und dass er in Bascom programmiert.

Bascom erstellt beim compilieren sowieso Assembler-Code. Wenn man den Assembler Code selber schreibt, kann man vielleicht noch ein bischen optimieren, ich glaube aber nicht, dass das sehr viel ausmacht.

Ja das ist richtig. Bascom ist mir gut bekannt und eine nette Hochsprache zum Erstellen von Programmen bei AVR's. Ich hab das nur am Beispiel der lahmen C-Control gesagt weil es damit auch möglich ist bei richtiger Anwendung. Gilt aber auch für schnellere Systeme. Man braucht auf jedenfall wenn man zwei Aufgaben erledigen will eine Zeitscheibe die man programmieren muss. Aber allgemein macht ein Schrittmotor immer mehr rechnerischen Aufwand aus als ein normaler Gleichstrom-Motor (wenn dieser nur ein/aus gesteuert wird, nicht geregelt). Wollte man dies nicht haben dann müsste man die Positionierung und Logik in einen anderen kleinen Controler / AVR packen. Gleichstrom-Motoren haben aber ausserdem noch einen gravierenden Nachteil, die laufen nach. D.h. man muss die noch besser regeln als einen Schrittmotor. Also ist eine frühe Abschaltung und notfalls auch eine Geschwindigkeitsregelung aufbauen. Allegemein sehe ich bei Schrittmotoren in der Summe aber die einfachste und präziseste Art eine Drehbewegung auszuführen mit wenig Rechenaufwand, auch wenn es auf den ersten Blick unsinnig erscheint.

Achja. Hab vieleicht noch ne gute Anregung für alle Extrem-Bastler. In EPSON-Druckern (zu 100% in einem 690er) sind meist zwei Schrittmotorentreiber für bipolare Schrittmotoren (4W) enthalten. Wenn man die herausnimmt hat man eine Sinus-Ansteuerung. Besser kann man wohl nicht einen Schrittmotor ansteuern mit variabler Stromkennlinie und PWM. Der Typ ist "LB11847" bei diesem Treiber-Logik-IC und das Datenblatt ist sogar im Internet zu finden.