Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #212974 > unrolled thread

Schrittmotoren

Back to article view | Back to de.sci.electronics

Contents

  Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-25 09:53 +0200
    Re: Schrittmotoren Matthias Weingart <mwnews@pentax.boerde.de> - 2016-08-25 08:40 +0000
    Re: Schrittmotoren Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-08-25 11:53 +0200
      Re: Schrittmotoren Matthias Weingart <mwnews@pentax.boerde.de> - 2016-08-25 09:59 +0000
      Re: Schrittmotoren w-buechsenschuetz@web.de - 2016-09-02 02:04 -0700
        Re: Schrittmotoren Bernd Nebendahl <Bernd_Nebendahl@web.de> - 2016-09-02 15:51 +0200
    Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-25 14:13 +0200
      Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 14:06 +0200
        Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-26 17:50 +0200
          Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 21:28 +0200
            Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-29 15:14 +0200
              Re: Schrittmotoren Matthias Weingart <mwnews@pentax.boerde.de> - 2016-08-30 06:12 +0000
                Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-30 09:06 +0200
              Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 11:16 +0200
                Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-30 12:33 +0200
    Re: Schrittmotoren "MaWin" <me@private.net> - 2016-08-25 14:40 +0200
      Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 14:13 +0200
        Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-30 10:00 +0200
          Re: Schrittmotoren Stefan <df9bi@arcor.de> - 2016-08-30 11:53 +0200
            Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-30 13:12 +0200
              Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 13:53 +0200
                Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-30 14:09 +0200
                  Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 17:59 +0200
                    Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-31 08:10 +0200
              Re: Schrittmotoren Stefan <df9bi@arcor.de> - 2016-08-31 09:12 +0200
                Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-31 09:53 +0200
                  Re: Schrittmotoren Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2016-08-31 12:16 +0200
                    Re: Schrittmotoren Stefan <df9bi@arcor.de> - 2016-09-02 15:59 +0200
          Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 11:31 +0200
    Re: Schrittmotoren Rafael Deliano <rafael_deliano@arcor.de> - 2016-08-26 20:18 +0200
      Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 22:04 +0200

Page 2 of 2 — ← Prev page 1 [2]

#213175

Edzard Egberts schrieb:

> Mein Ansatz war eher, dass der Arduino zu klein ist, um ein vernünftiges
> Display mit Tastatur zu betreiben - mit 2 Zeilen LCD kommt man bei der
> Anforderung wohl kaum hin. Also die Programme besser am PC mit
> Bildschirm, Maus und Tastatur eingeben und mit dem Arduino ausführen.

CAD Software braucht eine andere Umgebung als einen 3D Drucker. 
Andersrum ist so eine Maschine eher weniger geeignet, den Drucker in 
real-time zu steuern. Daraus ergibt sich eine natürliche Trennung in 
Arbeitsvorbereitung/-überwachung (front-end) und Durchführung 
(back-end), mit entsprechend unterschiedlicher Hardware, OS/Firmware und 
Entwicklungswerkzeugen.

Bei den Kosten für die Hardware von (Industrie-)Robotern kann man 
etliche kleine Controller für die Steuerung solcher Hardware einsetzen, 
womit die Anforderung an Speicherplatz etc. kein Thema mehr sind. 
Während man für die Vorbereitung auf Standardprogramme zurückgreifen 
kann, müssen die kleinen Controller individuell programmiert werden, mit 
Bibliotheken für Standard-Komponenten wie Schrittmotoren. Und mir geht 
es speziell um diese Bibliotheken, welche eine brauchbare Schnittstelle 
sowohl zur übergeordneten Steuerung als auch zur Hardware haben sollten. 
Die Schnittstelle zur Hardware ist dabei ziemlich übersichtlich, aber 
wie soll die andere Seite aussehen?

DoDi

[toc] | [prev] | [next] | [standalone]

#213176

Hans-Peter Diettrich wrote:
> Bei den Kosten für die Hardware von (Industrie-)Robotern kann man
> etliche kleine Controller für die Steuerung solcher Hardware einsetzen,
> womit die Anforderung an Speicherplatz etc. kein Thema mehr sind.
> Während man für die Vorbereitung auf Standardprogramme zurückgreifen
> kann, müssen die kleinen Controller individuell programmiert werden, mit
> Bibliotheken für Standard-Komponenten wie Schrittmotoren. Und mir geht
> es speziell um diese Bibliotheken, welche eine brauchbare Schnittstelle
> sowohl zur übergeordneten Steuerung als auch zur Hardware haben sollten.
> Die Schnittstelle zur Hardware ist dabei ziemlich übersichtlich, aber
> wie soll die andere Seite aussehen?

Die Arduinos haben eine serielle Schnittstelle über USB und melden sich
unter Linux z.B. als "/dev/ttyACM0" oder unter Windows als irgend ein
"COM#" an (dafür gibt es einen Treiber). Auf der Arduino-Seite ist das
recht komfortabel, da sind Befehle vorhanden, um die Baudrate
einzustellen und zu schreiben, z.B. "Serial.print("Hallo")".

Das Protokoll muss man sich zwar selber ausdenken, aber eine
textbasierte Befehlsliste lässt sich einfach realisieren, so etwas wie
"MOV 10, 10, 10\r\n". '\r' immer verwerfen (wird nur von Windows
verwendet), bei '\n' den Eingabepuffer auswerten. Auf der PC-Seite
könnte man dann sogar ein Terminal verwenden.

[toc] | [prev] | [next] | [standalone]

#213191

Edzard Egberts schrieb:

> Das Protokoll muss man sich zwar selber ausdenken, aber eine
> textbasierte Befehlsliste lässt sich einfach realisieren, so etwas wie
> "MOV 10, 10, 10\r\n".

Schaut man sich G-Code an, dann laufen da viel mehr Parameter drüber. 
Das  Problem ist aber nicht deren Anzahl, sondern was mit den Werten 
anzufangen ist.

DoDi

[toc] | [prev] | [next] | [standalone]

#213197

Hans-Peter Diettrich wrote:
> Edzard Egberts schrieb:
> 
>> Das Protokoll muss man sich zwar selber ausdenken, aber eine
>> textbasierte Befehlsliste lässt sich einfach realisieren, so etwas wie
>> "MOV 10, 10, 10\r\n".
> 
> Schaut man sich G-Code an, dann laufen da viel mehr Parameter drüber.
> Das  Problem ist aber nicht deren Anzahl, sondern was mit den Werten
> anzufangen ist.

Das ist kein Problem, sondern Arbeit.

[toc] | [prev] | [next] | [standalone]

#213200

Am 30.08.2016 um 13:12 schrieb Edzard Egberts:
> Stefan wrote:
>> Am 30.08.2016 um 10:00 schrieb Edzard Egberts:
>>> Hans-Peter Diettrich wrote:
>>>> Frage: kann ein Arduino neben grbl noch mehr tun (Speicher?
>>>> Rechenzeit?), oder wäre das lediglich ein back-end für die
>>>> ausschließliche Programmierung via G-Code?
>
>>> "ein Arduino" ist nichts anderes als ein Atmel-Prozessor mit
>>> Das ist für die Erstellung und Verwaltung von XYZ-Programmen also etwas
>>> eng, deshalb würde ich sagen, dass das wirklich eher als Backend zu
>>> gebrauchen ist.
>>
>> Es gibt aber auch die Möglichkeit, am Arduino eine SD-Karte zu
>> betreiben. Ich hab hier an meinem 3D Drucker ein 4GB Karte auf die ich
>> die Druckdateien speichere.
>
> Warum wird das nicht per USB übertragen? Oder warst Du der mit den Störern?

Richtig, aber da steh ich nicht alleine. Seidem ich per SD-Karte drucke, 
hab ich da keine Probleme mehr gehabt, komischerweise auch nicht mit der 
USB Schnittstelle, weil oft läuft der PC nebenher mit.

> Mein Ansatz war eher, dass der Arduino zu klein ist, um ein vernünftiges
> Display mit Tastatur zu betreiben - mit 2 Zeilen LCD kommt man bei der
> Anforderung wohl kaum hin. Also die Programme besser am PC mit
> Bildschirm, Maus und Tastatur eingeben und mit dem Arduino ausführen.

Klar,

> Man kann mit dem Arduino auch vollständige Geräte mit (numerischer)
> Tastatur/ (LCD-) Display bauen, aber das entsprechende Gerät war bei mir
> ruckzuck vollprogrammiert - um die letzten Zeilen reinzuquetschen musste
> ich woanders optimieren. Und das Display musste auch in einen
> Timer-Interrupt, weil das alles sonst zu langsam geworden wäre.

Alternative wäre ESP8266. Kann man auch über Arduino programmieren und 
hat WLan. Userinterface geht dann per Smartphone oder PC im Browser. Der 
ESP hat dann auch einiges mehr als Flash als der AVR.

Gruß

Stefan


>

[toc] | [prev] | [next] | [standalone]

#213203

Stefan wrote:
> Am 30.08.2016 um 13:12 schrieb Edzard Egberts:
>> Man kann mit dem Arduino auch vollständige Geräte mit (numerischer)
>> Tastatur/ (LCD-) Display bauen, aber das entsprechende Gerät war bei mir
>> ruckzuck vollprogrammiert - um die letzten Zeilen reinzuquetschen musste
>> ich woanders optimieren. Und das Display musste auch in einen
>> Timer-Interrupt, weil das alles sonst zu langsam geworden wäre.
> 
> Alternative wäre ESP8266. Kann man auch über Arduino programmieren und
> hat WLan. Userinterface geht dann per Smartphone oder PC im Browser. Der
> ESP hat dann auch einiges mehr als Flash als der AVR.

Bist Du Dir mit der Bezeichnung sicher, ich finde unter "ESP8266" nur
WLAN-Module.

[toc] | [prev] | [next] | [standalone]

#213209

Am 31.08.2016 um 09:53 schrieb Edzard Egberts:

>> Alternative wäre ESP8266. Kann man auch über Arduino programmieren und
>> hat WLan. Userinterface geht dann per Smartphone oder PC im Browser. Der
>> ESP hat dann auch einiges mehr als Flash als der AVR.
>
> Bist Du Dir mit der Bezeichnung sicher, ich finde unter "ESP8266" nur
> WLAN-Module.

Die Dinger haben einen frei programmierbaren, MIPS-basierten Prozessor.

Als Alternative zum AVR (Arduino) taugen sie aber eher nicht, weil nur 
sehr wenige IO-Leitungen verfügbar sind, welche zudem nur über ein sehr 
eingeschränktes API ansteuerbar sind. Keine Spur von den vielfältigen 
Schnittstellen-, Timer-, Interrupt-Funktionen der AVRs.
Auch von dem vielen Flash ist das Meiste bereits durch die 
Firmware-BLOBs belegt.

Hergen

[toc] | [prev] | [next] | [standalone]

#213295

Am 31.08.2016 um 12:16 schrieb Hergen Lehmann:
> Am 31.08.2016 um 09:53 schrieb Edzard Egberts:
>
>>> Alternative wäre ESP8266. Kann man auch über Arduino programmieren und
>>> hat WLan. Userinterface geht dann per Smartphone oder PC im Browser. Der
>>> ESP hat dann auch einiges mehr als Flash als der AVR.
>>
>> Bist Du Dir mit der Bezeichnung sicher, ich finde unter "ESP8266" nur
>> WLAN-Module.
>
> Die Dinger haben einen frei programmierbaren, MIPS-basierten Prozessor.
>
> Als Alternative zum AVR (Arduino) taugen sie aber eher nicht, weil nur
> sehr wenige IO-Leitungen verfügbar sind, welche zudem nur über ein sehr
> eingeschränktes API ansteuerbar sind. Keine Spur von den vielfältigen
> Schnittstellen-, Timer-, Interrupt-Funktionen der AVRs.
> Auch von dem vielen Flash ist das Meiste bereits durch die
> Firmware-BLOBs belegt.
>
> Hergen

Es bleibt trotzdem noch einiges an Flash übrig.

Man kann den ESP8266 auch mit einem AVR kombinieren, also AVR per 
seriell anschließen, IOs über den AVR abfragen und Daten auf dem ESP 
speichern bzw. per WLan zum Server schicken oder vom Server holen.

Gruß

Stefan

[toc] | [prev] | [next] | [standalone]

#213174

Edzard Egberts schrieb:
> Hans-Peter Diettrich wrote:
>> Frage: kann ein Arduino neben grbl noch mehr tun (Speicher?
>> Rechenzeit?), oder wäre das lediglich ein back-end für die
>> ausschließliche Programmierung via G-Code?
> 
> "ein Arduino" ist nichts anderes als ein Atmel-Prozessor mit
> USB-Schnittstelle, Stromversorgung und Bootloader, z.B. ATmega328
> https://www.arduino.cc/en/Main/ArduinoBoardUno:
> 
> 2 kB SRAM; 32 kB Flash Memory; 1 kB EEPROM; 16 MHz Clock Speed

"Arduino" bezeichnet eher eine Entwicklungsumgebung, die inzwischen 
nicht mehr auf die kleinen 8-Bitter und AVR beschränkt ist.


> Das ist für die Erstellung und Verwaltung von XYZ-Programmen also etwas
> eng, deshalb würde ich sagen, dass das wirklich eher als Backend zu
> gebrauchen ist.

Das ist derzeit auch meine Zielrichtung. Die übergeordnete 
Steuerung/Regelung interessiert mich nur insoweit, als sie die 
Schnittstelle zu den Backends beeinflußt.

DoDi

[toc] | [prev] | [next] | [standalone]

#213044

Es ist nicht gesagt ob closed loop ( d.h. mit zusätzlichem
Sensor ) oder open loop.
Bei open loop hat man hinreichend Probleme keine
Schritte zu verlieren. Wehwechen sind ja in der
Literatur dargestellt:
http://www.embeddedFORTH.de/temp/stepper-bugs.pdf
Ich vermute Drucker usw. hatten ihre Mechanik sehr
genau optimiert.

Das Buch
https://www.amazon.com/Stepping-Motors-Their-Microprocessor-Controls/dp/0198593856
hat auch einen Vorschlag für Software, aber
müsste man sich aus Z80 Code rausklauben:
http://www.embeddedFORTH.de/temp/stepper-Z80.pdf

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#213046

Rafael Deliano schrieb:
> Es ist nicht gesagt ob closed loop ( d.h. mit zusätzlichem
> Sensor ) oder open loop.
> Bei open loop hat man hinreichend Probleme keine
> Schritte zu verlieren.

Eigentlich denke ich bei Schrittmotoren an open-loop. Bei closed-loop 
kann man beliebige Aktoren einsetzen.

Man kann ziemlich jedes System so überlasten, daß es seine Aufgabe nicht 
mehr erfüllen kann, egal ob mit oder ohne Rückmeldung. Für meine ersten 
Gehversuche würde mir sowas wie die AccelStepper Bibliothek ausreichen, 
um die Grenzen beim Einsatz von Schrittmotoren auszuloten. Dabei bin ich 
auf programmtechnische Probleme gestoßen, für die ich eine Lösung suche, 
und dann auf die zusätzlichen Probleme beim synchronen Einsatz mehrerer 
Schrittmotoren. Von da kam die Frage auf, wie sich komplexe Bewegungen 
planen lassen, und wie eine universelle Schnittstelle zu den 
eigentlichen Motor-Treibern aussehen müßte.

DoDi

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.sci.electronics

csiph-web