CNC mit Gleichstrommotoren

Hi Olli,

anbei die EagleDateien. sieh Dir das mal an. Zur Sicherheit sind die CL-Leitungen, 24V und Fräsmotorspannung alle jeweils im geschirmten Kabel geführt.
MOSI und Clock sind in Reihe, MISO ist parallel geschaltet. Der MISO arbeitet als "verdrahtetes Oder". Die AchsenMCs geben da an richtiger Bitposition Endlagen und Referenz zurück. Der Referenzschalter liegt vor dem Endlagenschalter. Bei Nullanfahrt kann also bis zum Referenzschalter im Eilgang gefahren werden, dann langsam bis zum Endlagenschalter.

Mit Gruß
Peter

Hi,

@magic33:
Ob ich damit 1.4401 fräsen kann, also flächig, weiss ich nicht sicher. Gravieren sollte wohl gehen, hab da auch schon einen Auftrag von meiner besseren Hälfte erhalten ;-)
Wenns mal soweit ist gibts von mir auch ein Vidscho.

@Peter:
Thanks, das hilft mir weiter. Hab gestern noch ein bischen rumprobiert -- kanns halt nicht lassen -- und habe festgestellt dass die Verbindung mit einem Y-Achsencoder ohne Fehler abläuft aber sobalt ich den Z-Achsencoder anschliesse gibts massive Fehler. Jeder Encoder hat eine Fehler-LED die ungültige Kommandos signalisiert.
Dann hab ich mal zum Spass die Schaltung auf meinem Breadboard angeschlossen und siehe da -- NULL FEHLER!! Hab dann wieder den Z-Achsencoder angeschlossen mit dem selbem schlechten Resultat.
Ok -- also muss ja wohl was auf dem PCB falsch sein dacht ich so ... Eben mal mit einem Skalpell die Fädeldrähte etwas auseinandergezogen und kam dabei an den unbelegten Reset PIN der via internem pullup auf Vcc liegt. Siehe da, auf einmal geht alles ohne Fehler!!!!
Toll, scheinbar funktioniert der eine Prozessor nur mit externem Pullup am Resetpin, die anderen Schaltungen brauchen den Pullup nicht.
Ach ja..... der Teufel steckt im Detail..... :-|
ERGO: Pullups an alle Resetpins.

Wenn ich später mein Bedienpanel anschliesse kann ich evtl deine Schaltung adaptieren, da ich das Panel mit I2C anbinden will.

Stay tuned.

Gruss,

Olli

Hi Olli,

denk aber dran: SPI ist uni- und I2C ist bi-direktional...

Mit Gruß
Peter

Faltenbälge kannst Du aus Kunstleder (Skai) machen. Falten und die Falten mit einem Tacker am Ende zumachen.
Das Zeug kostet beim Tedox 7 Euro je Meter und ist 1,4 m breit.

Wie meinst du das mit dem "am Ende zumachen" ?

Am Knick, an der Seite, oder wie?

Hi,

so, das Wochenende war wieder fruchtbar, nicht furchtbar %-)

Status Encoder:
Endlich funktioniert die Kommunikation mit den Achsencodern reibungslos. Um die Komminikationskanäle (Leitungen) zu entstören habe ich jetzt 1K Widerstände auf den bidirektionalen Datenleitungen des Datenbusses in Serie geschaltet und die unidirektionalen Signalleitungen WR und RDY auf der jeweiligen Empfängerseite mit 10K seriell terminiert (10K ergaben die beste Terminierung).
Auf den Datenleitungen hatte ich eine Störungskaskade auflaufend von LSB zu MSB (die MSB Datenleitung liegt neben WR/RDY auf dem Flachbandkabel). Beim Messen der einzelnen Datenleitungen mit dem Oszi ergab sich ein stets höherer Uss Wert um so näher ich Richtung MSB Leitung kam.
Also hab ich die MSB Leitung versuchsweise mit einem 560pF Kondensator terminiert und siehe da, das Signal-Rauschverhältnis geht so weit zurück, dass aller Datenverkehr ohne Fehler abläuft.

Pfuhhhhhh.. endlich!

Leider hab ich jetzt noch Probleme mit dem GP1A038RBK. Die Position von Aufnehmer zu Encoderscheibe ist enorm kritisch und nur sehr schwer einzustellen, weil eine Veränderung von 0.1mm über Gut oder Schlecht entscheiden kann.
Zur Information, ich benutze den hier robotikhardware GP1A038RBK
Die Artikel über das DING, die ich finden konnte sprechen alle die selbe Sprache -- sehr fehleranfällig!

Bei einer Achse (Z-Achse) hab ich die Position scheinbar exact gefunden und die Reglung läuft dementsprechend perfekt.


Status NC-Prozessor, Integrator, Editor, DNC:
Die ersten 3-Achs NC-Programme habe ich laufen lassen und abgesehen von den Fehlern in der Positionierung in X und Y läuft das schon ganz ordentlich. Die Z-Achse positioniert wie erwartet 1A, da der Bleistift auf der exact gleichen Stelle wieder aufsetzt wie zuvor, gemessen hab ich bis jetzt noch nicht -- nur Augenmass.

Die neu implementierten G-Funktionen:
G00 Schnellvorschub
G90 Absolutmass
G91 Inkrementalmass
G52 Absolute Nullpunktverschiebung 1

Laden und speichern via VT525 Link ist Terminalseitig komplett implementiert, es ist ein Kommando eingebaut um Dateien zu uploaden oder zu downloaden, Verzeichnisinhalte zu lesen etc.
Auf der mC Seite geht laden und speichern auch einigermassen, aber beim Laden sind die Daten ab Zeilenummer 15 nicht mehr i.O. was ich aber auf einen Fehler im dynamischen Speicherallokieren zurückführe. Da werd ich wohl auf statisch angelegte Arrays ausweichen um das erst mal ausschliessen zu können.
Der DNC Betrieb het einen eigenen Menupunkt bekommen im AUTOMATISCH-Menu und läd die Daten von der eingegebenen Datei via VT525 Link auch komplett nach, bei der Ausführung hapert es aber noch, da ich hier wohl noch einen Fehler drin hab.


Langer Rede, kurzer Sinn...
Wenn die Encoder sauber funktionieren oder vielleicht sogar 1A und DNC so arbeitet wie ich dass will, steht der ersten Fräsarbeit nichts mehr im Weg.


Gruss,

O.

Hi,

hab die Encoder gestern noch ein bischen besser ausrichten können, jetzt laufen die X- und Y-Achse schon besser.
Das Problem mit den Programmzeilen die nach dem einlesen Korrupt sind hab ich noch nicht im Griff. Scheinbar klappt bei höheren Programmzeilennummern irgent etwas nicht so wie ich das erwarte. Wenn ich das Programm per Hand eingebe hab ich gestern festgestellt dass der gleiche Fehler auftritt -- hat dann also wohl nichts mit dem Downloadvorgang zu tun.

Naja, ich bleib dran und werd das auch noch auf die Rehie bekommen!

Bis zum nächsten Post.

Gruss,

Olli

Hi Olli, habe Stress, mal auf die Schnelle, baue für die Dehgeberscheiben Abdeckungen damit die im Dunkeln arbeiten. Und variiere den LED-Strom, eventuell sind die LEDs zu hell.
Mit Gruß
Peter

Hi,

@Peter:
Werd mal testen ob die Encoder mit anderem Vorwiderstand besser functionieren.


Vidscho 1: Grafische Simulation mit Integrator-Testproggi
http://secius.com/fileadmin/AsuroFla...terDNC-Sim.mp4

Vidscho 2: Grafische Simulation (DNC Modus!!) auf dem VT525 Terminal
Der erste Test der DNC-Logik!!!!
http://secius.com/fileadmin/AsuroFla...C-Testlauf.mp4

Die Fehler in der Grafik kommen nicht vom mC sondern vom Terminal selbst, da der Dispatcher noch nicht 100 Pro funktioniert.


Vidschos von der Maschine in Aktion folgen....


Die fertige Leistungsplatine:
Anhang 35720

Gruss,

O.

Hi,


DNC funtioniert jetzt wie es soll.

..und hier das versprochene Video:
http://secius.com/fileadmin/AsuroFla...rockenlauf.mp4

Die Erste Gravur:
Bild hier  


Hab leider nicht mehr Zeit um ausführlicher zu schreiben.


Gruss,

O.

Hi,


für den ersten Versuch liefert die Maschine schon ganz zufriedenstellende Resultate. Das Proggi zum gravieren hat ca. 8000 Zeilen NC-Code der via DNC eingespielt wird.

Dabei ergaben sich ein paar Probleme/Herausforderungen:
Nach ca. 10 Zeilen Kode lief der Stack über.
Die Datenübertragung haperte nach etwa 100 Zeilen und lief nicht mehr weiter.
Die Achsen verfahren nicht exact syncron.
Nach der Abarbeitung eines kürzeren NC-Programms war das UI eingefroren.
Daraufhin hab ich die Logikpfade des Kodes noch einmal genauer unter die Lupe genommen um die Zeitlichen Abfolgen besser abschätzen zu können.
Dabei fiel mir auf dass zwei Strukturen, die aktuelle Zustände des NC-Dispatchers und der seriellen Nachladelogik halten, nicht "volatile" deklariert waren. Das muss natürlich so deklariert werden, da bei DNC Nachladebetrieb massiv parallel gearbeitet wird. Es werden gleichzeitig Daten in den seriellen Puffer geladen, die ASCII Daten werden dann Geparst und in interne strukturen überführt und danach abgearbeitet.
Um mehr SRAM frei zu bekommen habe ich dann noch eine Optimaliserungsrunde auf den Kode losgelassen und ca 250 Byte SRAM Speicher eingespart durch auslagern aller Textkonstanten ins FLASH.
Der NC-Dispatcher syncronisiert die Achsen noch nicht tollerierbar genau miteinender da noch keine Endlagenkontrolle vorgesehen war.

Der Erfolg der Oprtimalisierung ist jetzt:
Bis auf die Fehler beim Anzeigen auf dem Terminal geht die Chose jetzt ganz ordentlich, kein Hängen mehr, kein Stack überlauf mehr.

Bei der Gravur liefen alle 8000 Zeilen ohne weitere Probleme durch.


Gruss,

Olli

Hi,


hab am Wochenende wieder mal etwas Zeit in die Optimalisierung der Maschine gesteckt.
Ich habe der Steuerung noch eine Validator verpasst der die integrator Position prüft und auf Encoderfehler checkt. Mit drei neuen Parametern lege ich fest wie genau die syncronisation sein soll und wie viele Fehler auf den Encodern tollerierbar sind.
Die Positionskontrolle arbeitet mit zwei Parametern; PAR_SA und PAR_TS womit der Schleppabstand (PAR_SA) und der Regeltimeout (PAR_TS) festgelegt werden. Der eigentliche Grund war aber nicht um bei Positionierfehlern auf NOT-AUS zu schalten, sondern die Achsen miteinander sauber zu syncronisieren. Der Vorteil liegt jetzt aber auch in der Erkennung von Stalled Zuständen, d.H. wenn ich z.B. einen Motor fest halte schaltet die Steuerung auf NOT-AUS nach dem PAR_TS verlaufen ist.

@Peter:
Die Encoder machen leider immer noch Probleme. Hab einen Kallibrierpoti eingelötet und auf 330 Ohm eingestellt, aber leider nicht mit durchschlagendem Erfolg.
Nur mal interessehalber, hast Du Widerstände in den Leitungen vom Drehgeber zum mC?


Gruss,

O.

Hi Olli,

der 1. Satz in der Doku zum Sensor:

1. Linear encoder for reading linear scale.

sagt doch alles.

Habe mir aus der Bucht für 1€ einen Haidenheimgeber (1000cpr) geangelt, da sind die Fotodioden leicht im Kreisbogen angeordnet.

Bei einem DC-Servomotor steht auf dem Sensor kein Typ drauf, der macht aber schon mit 25mm Durchmesser 400 cpr.

Das ein Shop Scheibe+Sensor verkauft bedeutet ja noch lange nicht, daß das auch passt.
Meine Leitungen vom Geber zum MC sind doch nur 10cm lang, daher keine Widerstände.

Mit Gruß
Peter

Hi Peter,


ja ich weis, die sind eigentlich für Linearmasstäbe gedacht....
Die Heidenhain Geber für 1€ sind schon ein Glücksgriff, hab auch interessehalber gleich selber mal in der Bay geschaut aber keine drei gleichen Geber finden können.

Zitat:

---

Das ein Shop Scheibe+Sensor verkauft bedeutet ja noch lange nicht, daß das auch passt.

---

q.e.d. ;-)

Meine Aufnehmer funktionieren zwar alle, aber sind halt leider so positionskritisch in Bezug auf Encoderscheibe--Aufnehmer Position, dass es immer wieder mal Ausreiser gibt.
Ich werd wohl nicht drum rum kommen eine Positionierhilfe zu bauen die auf die Welle zentriert.
Sorry für das gejammer über meine Encoder. Manchmal muss der Frust halt raus um platz für neue Ideen zu schaffen... :?


cu

O.

moin Olli,

habe nochmal TIEF in die Tasche gegriffen und aus der Bucht einen Drehgeber mit 4096cpr geangelt, für 3,15€ :-))))
Bei der Auswertung geht nur noch im Timerinterrupt (alle20µs) richtig, bei pollen nur Mist.

>>Encoderscheibe--Aufnehmer Position
der Fehler ist doch immer derselbe, daher würde ich auf die Auswertung als Fehlerquelle tippen. Die Signalübertragung sollte als RS485 erfolgen.

Gleiche Drehgeber sind zwar schön, müssen doch aber nicht sein.

Mit Gruß
Peter

Hallo,
ich habe schon mal vor Jahren eine funktionierende CNC Fräse mit Steppern gebaut. Allerdings waren hochwertige Motoren sowie eine gescheite Stepperkarte damals für mich unerschwinglich (ich benutzte die Stepperkarte vom großen C mit 800mA Leistung) darum musste ich die Stepper untersetzen, und alle Verfahrwege waren quälend langsam. Deshalb verschwand das Projekt für nunmehr 7 Jahre im Keller. Damals hatte ich auch noch keine Ahnung von µC, PWM, Servomotoren...

Nun habe ich praktischerweise diesen Fred gefunden, und möchte mich gleich mal beteiligen.

Vor einiger Zeit dachte ich nämlich daran die Fräse zu reaktivieren, und auf Servos umzubauen, was in meinem Kopf bereits fertig ist :-)

Allerdings macht mir die Syncronisation der Achsen noch Kopfschmerzen.
Ich dachte an folgende Vorgehensweise:
z.B. Möchte ich eine 45° Diagonale fräsen.
Also sagt der µC dem Servo X: "Fahre du mit 100% PWM soundsoviel Einheiten vor, stoppe dann." zum Servo Y: "Fahre du gleichzeitig mit 100% PWM gleichviel Einheiten vor, stoppe dann."

Also fahren beide los, aber aus welchen Gründen auch immer ist einer der Motore etwas langsamer. Das Ergebnis würde dann irgendwie so aussehen:

Bild hier  

Rot= gewünschte Gerade
Grün= tatsächlich gefahrene Strecke

Meine Lösung wäre es wenn alle Motore in regelmäßigen Abständen auf deren Position abgefragt werden, und entsprechende Korrekturwerte an sie gesendet würden.
Also: "Motor X ist etwas langsamer als Motor Y, deshalb sollte Motor Y bis zur nächsten Abfrage mit 10% weniger Leistung fahren, also Motor Y = 90% PWM, Motor X 100% PWM". Diese Werte werden dann immer wieder Aktualisiert, und Korrigiert. Dann würde das Ergebnis in etwa so aussehen:

Bild hier  

Wenn man nun dies sehr fein einstellen Würde könnte man eine ausreichend genaue Gerade erzeugen.
Eine weitere Achse kann man ja auf das gleiche Prinzip einflechten.

Hast du eine Lösung für dieses Problem?

MfG, Michael

Hallo
Bresenham

Mit freundlichen Grüßen
Benno

Hi,

@hellobello:
mach dich bitte erst mit den Grundlagen der Regelungstechnik vertraut:
siehe PID-Regler
siehe Regelungstechnik

Früher im Thread (nicht Fred! obwohl es ja tatsächlich so ähnlich klingt :) ) hab ich den Aufbau meiner Servosteuerung angerissen. Lies da bitte erst mal nach, vorher machen weitere Erläuterungen keinen Sinn.


@Yossarian:
Für ein "Roboter Genie" finde ich deine Antwort etwas seltsam!


Gruss,

O.

Ich musste bei Yossarians Antwort auch ein paar Sekunden überlegen was damit gemeint ist. Den Algorithmus kannte ich zwar, aber der Name war mir kein Begriff. Wiki half.

Damit kann ich schonmal ein paar Experimente fahren. Die dritte Achse einbinden ist ja kein problem gewesen.

Danke schonmal (beiden ;-) )

Hi,


endlich hab ich den Fehler auf den Encodern eliminiert. Es war ein Zusammenspiel verschiedener Fehler die zu den Aussetzern geführt haben.

1) Der Trimpotti zum einstellen der LED-Vorwiderstände war zu hoch eingestellt.
2) Der mC hat mit einer zu niedrigen Tastfrequenz gearbeitet (45KHz) weshalb manchmal einige Flanken verloren gegangen sind.

Die neue Version der Firmware benutzt jetzt den Pin-Change-Interrupt und "übersieht" seitdem keine Flanken mehr und die Reduktion des Vorwiderstands der Diode auf weniger als 330 Ohm hat zur Folge das auch der Sensor keine Flanken mehr "übersieht".
Der Grund für die ursprünglich angedachte Tastfrequenz von 45KHz war meine Annahme, dass der Sensor 480 Flankenwechsel pro Umdrehung ausgibt. Es sind aber in Wirklichkeit 2400 was eine 5-fach höhere Tastfrequenz bedingt. Deshalb habe ich die Firmware auf die Benutzung des Pin-Change-Interrupt umgebaut, die Schaltung prellt ja nicht weshalb das auch problemlos geht.

Warum 2400 Impulse kommen ist mir immernoch unklar, aber es ist auf allen Encodern so und kommt letztendlich nur der Regelgüte zugute.


Projekt Bedienpanel
Mein neues/nächstes Projekt ist ein Bedienpanel für die manuelle Bedienung der Maschine.
Dazu wollte ich erst einen Apem 3D-Joystick benutzen, habe mich aber anders entschieden weil mir der Anschaffungswiderstand von 150E zu hoch war. Das Panel steuert bei manuellen Bewegungen die X/Y-Achsen mittels Joystick (ein alter Potentiometer Joystick der bei mir rumgelegen hat) und hat einen Modus um von X-/Y-Achse auf Z-Achse umzuschalten. Zusätzlich kann von Geschwindigkeitsvorsteuerung auf Wegvorsteuerung umgeschaltet werden um nicht die Verfahrgeschwindigkeit mit dem Joystick festzulegen sondern den Weg der Achsen. Das ist dann der Handradmodus, da sich die Achsen verhalten als ob ein Handrad gedreht wird.
Auf dem Panel ist ein 16x2 Zeichen Display das in der ersten Zeile Infos wie Speedoverride und Feedoverride anzeigt womit die programmierten Werte mit zwei Tasten in 10% Schritten erhöht und verringert werden können.
In der zweiten Displayzeile will ich Werkzeugwechsel Texte anzeigen lassen oder sonstige Kommentare aus dem NC-Programm.
Zwei weitere Tasten sind für NC-Start/NC-Pause und NC-Stop vorgesehen mit einer LED im NC-Start/Pause schalter die Leuchtet wenn ein Proggi läuft, blinkt bei Pause und ist aus wenn kein Programm aktiv ist.
Auf das Panel kommt auch noch der NOT-AUS Schalter damit ich da schnell draufhaun kann wenns mal schief geht ;)
Die Anbindung an den Hauptprozessor erfolgt mit 6 Leitungen, 2x Spannungsversorgung, 2x I2C und die Sicherheitskette (NOT-AUS). Das ganze läuft auf einem ATtiny26 der jetzt gerade mal noch 20 Byte Flash frei hat.


Auf dem Breadboard ist die Schaltung bereits funktionstüchtig.


Werd demnächst mal Bilder oder ein Vidscho davon einstellen.


Gruss,

O.

Hi,


hier mal eben das Layout des Bedienpanel PCB's in der Draufsicht.
Das wird dann auf eine doppelseitige Karte gefräst wovon die eine Seite seit gestern fertig ist. Hierbei hat sich herausgestellt, dass die Genauigkeit der Regelung in Ordnung ist, die Führungen aber nicht ausreichend genau eingestellt sind. Die Folge ist ein Versatz, bzw. kleine Fehler in den gefrästen Konturen.

Anhang 35721
Abb 1: Layout


Sobald das doppelseitige PCB fertig ist gibts wieder Fotos.


Gruss,

O.

Ich hätte einen Verbesserungsvorschlag für deine PCB. Ist C1 der Entstörkondensator für den µC? Wenn ja ist er falsch. Der müsste so nah als möglich an den µC. Wenn du SMD verarbeiten kannst würde ich einen SMD Kondensator nehmen. SMD ist aber nicht unbedingt nötig.
Im Anhang ist die PCB von dir. Im gelb eingezeichneten Bereich würde ich die Leiterbahnen so ändern wie die hellblauen Leitungen sind. Die restliche Kupferfläche würde ich als GND Fläche nehmen (weniger abzutragen und gelichzeitig etwas für EMV getan).

Bei JP1-JP3 würde ich die Leiterbahnen nur auf einem Layer hingeben. Ist leichter zu löten. Kenne ich aus eigener Erfahrung. Oder du verwendest Kupfernieten (z.B. Bungard) Hier ist die Presse http://www.bungard.de/index2.php?opt...do_pdf=1&id=48
Bei Reichelt gibt es die Nieten. Die Presse benötigst du nicht unbedingt.

MfG Hannes

WOW ich sehe nur Banhof :-s

Hat von euch einer einen guten link wo man sich ein wenig wissen über das ganze zeugs (Platinen, mC, usw.) aneignen kann?
Mich würde die ganze Elektroniksachen schon lange mal interresieren wie das hinhaut, den als Industeriemechanicker lernt man darüber nicht besonders viel.
Im voraus schon mal danke 8-[

Gruß Michael

@Michael_238

http://www.rn-wissen.de/index.php/Hauptseite

Hi @all,

@021aet04
Danke, war aber leider schon fertig gefräst. Der Kondensator sollte immer so nah wie möglich an den mC, irgentwas muss man halt immer falsch machen. #-o Geht aber zum Glück trotzdem.

@Peter

Zitat:

---

Bin auf erste Fräsbilder gespannt... (29.03.2010, 06:04)

---

=;

Die Fräsmaschine beim Fräsen der unteren Platinenseite für das obige Bedienpanel.


3x Zeitraffer
https://secius.com/fileadmin/media/cnc_MOV06298.mp4

So siehts zusammengebaut aus...
Bild hier  

Noch auf dem Breadboard...
Bild hier  


Gruss,

Olli

Hi,

habe mal wieder was zu Melden ;)


Das Bedienpanel ist schon einige Zeit fertig. Habe aber ganz vergessen mal wieder was zu dokumentieren, so dass ihr das auch sehen/lesesen könnt.

Also hier das Bedienpanel noch ohne Abschlussplatten vorne und hinten.
Bild hier  
Bild hier  

Hoffe es gefällt.

Ach ja....
Die Fräsfehler bei den Tastern sind nur unschwer zu übersehen und rühren von dem Y-Encoder der etwas verstellt war nach einer unsanfte Handbewegung meinerseits. Hätte ich das vor dem fräsen korrigiert, wäre das Resultat fehlerfrei gewesen.
Der Fehler beim Display kam zu Stande durch einen Konstruktionsfehler. Eagle hatte falsche Geometriedaten für mein Display gespeichert und da Computer alles machen was man Ihnen sagt, auch ist das unsinnig, sie machen das halt trotzdem ohne zu überlegen.
In der Hinsicht sind Menschen halt noch weit voraus....lediglich nachdenken müssen sie dann schon noch...

Genau das hatte ich vergessen zu tun -- nachdenken.

Shit happens :Haue


Gruss,

Olli

Gefällt mir . Sieht wirklich gut aus. Fräsfehler sind normal. Habe auch schon genug Fehler gemacht (speziell beim Platinen fräsen)

MfG Hannes

Hey Hannes,

bist ja noch spät auf.


Gruss nach Österreich,

Olli

Ich weiß das Thema war vor 2 jahren aktiv aber bin zufällig darauf gestoßen und wollte wissen was das eigentlich für ein Projekt war und was dabei zu programmieren war, denn ich bin auf dem Gebiet der Programmierun ein "Newbie" :)

Zitat:

---

Zitat von ActiveRobo

...wollte wissen was das eigentlich für ein Projekt war...

---

Steht im Threadnamen

Zitat:

---

Zitat von ActiveRobo

...und was dabei zu programmieren war, denn ich bin auf dem Gebiet der Programmierun ein "Newbie"

---

Thread durchlesen

MfG Hannes

Moin.
Der neue in diesem Forum, aber nicht so ganz neu in der Materie... Darüber später mal mehr. Hierher bin ich über die Suche nach Selbstbau-Konzepten mit dem Suchbegriff Gleichstrom-Servomotor gekommen. Auf jeden Fall, das kann ich aus langer Erfahrung sagen, das Richtige, wenn es um Laufruhe, Vermeidung von Schrittfehlern etc. geht - im Gegenteil, man muß aufpassen, daß man sich mit den kraftvolleren Servomotoren nicht die Maschine verbeult.

Nun aber zum Aufhänger, warum ich mich an diesem Beitrag einklinke: Ich bau mir gerade privat eine neue 3-achsige, mit Optionen zu mehr als 4, 5, ... - schließlich heißt das hier Roboternetz.

Bei den Recherchen zur Bauelementebeschaffung fiel mir auf, daß es von den wenigsten Anbietern Angaben zur Linearität und vor allem zur absoluten Genauigkeit von Antriebsspindeln gibt. Besonders bei Kugelumlaufspindeln gibt es den Unterschied zwischn gerollt und geschliffen, und den merkt man dann natürlich im Preis. Wobei auch der noch nichts über die tatsächliche Genauigkeit aussagt. Ein ausgewiesener Experte aus meinem Bekanntenkreis (er ist wirklich einer) stellte bei Kugelumlaufspindeln, deren Mutter nach Steigung und Drehwinkel um exakt 500mm bewegt worden sein sollte, Fehler von bis zu 0.75 mm fest. Dafür gibt es bei Azubis schon im ersten Lehrjahr mahnende Worte... Gewindestangen sind hinsichtlich der Genauigkeit noch einmal ne Nummer vergnügungssteuerpflichtiger - dafür werden sie ja weder hergestellt noch spezifiziert.

Daher hab ich mal weitergesucht und bin auf lineare Weggeber gekommen. Da gibt es nicht nur die linearen Glasmeßstäbe, sondern auch elektromagnetisch arbeitende - ähnlich einem Tonband, auf das kalibriert S/N-Wechsel geschrieben sind, die dann mit zwei um einige Bogenminuten versetzten Sensoren mit großer Präzision ausgelesen werden können. Das ganze wird antriebsnah an / in den Linearantrieben eingebaut, sodaß man nicht den angenommenen, sondern den tatsächlichen Ist-Wert der Achse messen kann.

Hast Du mal die absolute Genauigkeit Deines Aufbaus gemessen? Und wie bringst Du ggf. die mechanische Kennlinie Deines Antriebs, soweit bekannt, in die Positionierung ein?

Gruß,
U.

Hi Langkieler,
kaum ist ein Monat vergangen schon kommt die Antwort. Irgentwie hab ich keine Benachrichtigung erhalten das eine neue Antwort im Thread eingegangen ist....

Zitat:

---

...wie bringst Du ggf. die mechanische Kennlinie Deines Antriebs, soweit bekannt, in die Positionierung ein?

---

Ich habe einfach Quadrate gefräst mit bekannten Abmaßen und mit einer Schieblehre nachgemessen. Die Maße waren so weit ich mich erinnere nahe am SOLL, aber natürlich nicht völlig Exakt.
Die Kenngrößen werden über Parameter der Steuerung im UI (User Interface) via VT525 Terminal eingegeben. Das UI was Du hier siehst läuft auf dem PC und emuliert einen VT525 Terminal.
Die Steuerung sendet dann die Escape-Sequenzen via RS232 im Digital Equipment VT525 Dialekt an das Terminal und rendert so das UI.
Das Terminal ist natürlich auch selbst geschrieben wie alles in/an der CNC-Maschine.


Eingabe von Achsparametern via VT525 Terminal (Threadbeitrag)
https://www.roboternetz.de/community...l=1#post437161

Für jede Achse gibt es ein Parameterset:
Anhang 25210
Kp, Ki, Kd, Kv das ist denke ich klar
PWM MIN F minimale PWM Frequenz "forward"; 0=ignorieren
PWM MIN B minimal PWM Frequenz "backward"; 0=ignorieren
AXE DIR Positive Richtung der Achse (vorwärts +1/rückwärts -1)
UKS Umkehrspiel der Achse (Spiel im Spindel/Mutter Verbund)

und in den globalen Parametern wird das Folgende eingestellt:
Anhang 25211
SA Schleppabstand; Vorlaufwert der programmierten NC-Programm Position zur wirklichen Verfahrposition
TS Timeout Schleppabstand; Legt den Schwellenwert fest bis ein Fehler erkannt wird
EF Error Flag; Counter der angibt wann die Steuerung mit einem Regelfehler aussteigen soll.
PWM_MAX Der obere Grenzfrequenz für PWM; War wegen den Optokopplern nötig, da die bei einer bestimmten Frequenz aussteigen.
SPI WRD SPI write delay; Der zweite Atmega kontrolliert die Achspositionenen und braucht halt etwas bis er fertig ist.
SPI SPEED Damit wird die Übertragungsfrequenz zum zweiten ATMega eingestellt (0=Max Speed)
EENC SNAPD External Encoder Snapshot Delay; Finetuning beim lesen der einzelnen Koordinatendaten (X,Y,Z)

Die µC sind mit meiner selbstgeschriebenen IDE programmiert und geflasht(Mein Blog):
http://www.secius.com/AsuroFlash/archives/28


Der Blog zur IDE
https://www.roboternetz.de/community...u-Flashnnn-exe


Gruss,
Osser

Hallo, Osser,
danke für die Antwort - sie zeigt, daß Du die aus nicht ganz perfekter Mechanik herrührenden Fehler berücksichtigst und korrigierst. Das läßt sich ja leider nicht von jeder Steuerung behaupten.

Gruß,
- der Langkieler -

Es ist schon ein Weilchern her

das ich meine CNC Fräsmaschine gebaut habe. Ursprünglich war mein Ziel eine Machine zu bauen die von mit komplett selbst hergestellt ist, das bedeutet also alle mechanische Bauteile aus Standardwerkstoffen (in meinem Fall Stahl) selbst herstellen mit den mir zur Verfügung stehenden Maschinen. Dann sollten die Antriebe aus gewöhnlichen DC Motoren mit angekoppelter Positionsgebern erstellt werden wodurch ein selbst aufgebauter Servo entsteht. Schliesslich war mein Ziel die Steuerung der Servos, des Interpolators und des Positionsintegrators in einem kleinen! ATMega mit gerade einmal 4096 Byte Arbeitspeicher zu implementieren.

Das habe ich 2014 fertiggestellt und das Resultat ist auf der Seite "Meine CNC Fräsmaschine" zu sehen.




Vor Kurzem war ich dann mal wieder im Keller und sah die Maschine dort stehen. Sie war leider schon leicht angerostet in der Zwischenzeit -- ojeh.
Da ich am liebsten mit neuen Entwicklungen beschäftige und mein interesse am fertigen Proidukt ziemlich schnell schwindet, stand die Maschine leider aus diesem Grund in einem etwas traurigen Zustand auf ihrem Tisch.

Ich dachte mir im vorbeigehen das ich doch das Projekt in die jetzige Zeit transformieren könnte und die Steuerung die bislang in einem ATMega64 werkelte auf eine neuere Plattform migrieren könnte.
Die alte ATMega Platform hat zwar einigermaßen funktioniert, aber das Entwickeln der Software als Monolith ist schon ziemlich aufwändig.
Das Arbeiten auf dem µC war einigermaßen performant, aber es gibt schon noch einiges an Potential nach oben.

Ihr könnt euch ja vielleicht schon denken wofür ich mich entschieden habe :)

Ich werde also in der nächsten Zeit hier Berichten welche Fortschritte ich gemacht habe.

Stay Tuned

Zitat:

---

Zitat von Osser

Es ist schon ein Weilchern her
...
Stay Tuned

---

Schlappe noch nicht mal neun Jahre.... :) Das Leben saust so wuuuusch durch. Bin gespannt.

Ja manchmal geht das Schneller als man denkt.

:cool:

Hi,

ich habe die Maschine schon in ihre Bestandteile zerlegt und mir drei neue Drehgeber besorgt.
Da ich zuvor einen ziemlich bunten Mix an Drehgebern hatte
X-Achse; ROQ425; 2048 Schritte; EnDat; 5V
Y-Achse; ROQ425; 2048 Schtitte; EnDat; 5V
Z-Achse; ROQ424; 512 Schritte; SSI; 10-30V
will ich bei der neuen Steuerung mal Hardwareseitig mit einheitlichen Bedingungen starten.

Ehrlich gesagt waren die beiden alten Drehgeber defekt seit ich aus versehen 12V auf die 5V Drehgeber gegeben habe.

-- Toast -- ;)

Naja, wie dem auch sei. Ich habe mir bereits drei neue Drehgeber besorgt die jetzt alle die gleichen Parameter aufweisen.
Anhang 35705
Alle SSI
Alle 10-30V
Alle von einer Dumpfbacke einfach 20cm hinter dem Drehgeber abgezwickt. :confused:

Dafür haben sie aber auch nur 40€ gekostet, was für einen Heidenhain Drehgeber schon ein top Preis ist.
Ich hab einen Drehgeber an die ausgebaute Achse angeflanscht um dann die ersten Tests zu fahren zu können. Als Rechner Hardware habe ich mir einen Raspi 4 gehohlt mit 1GiB Arbeitspeicher der für die Zwecke mehr als ausreichend sein sollte.
Anhang 35706

Ich habe im Netz viel gelesen das es mit einem regulären Linux nicht möglich wäre eine CNC Steuerung zu bauen. Dort war dann zum Beispiel die Rede von z.B. RTOS als Betriebsystem der Wahl.
Ich bezweifle eigentlich sehr stark das mir das "normale" Linux derart Probleme bereitet wenn ich damit einen Regelzyklus aufbaue.
Wie ihr ja vielleicht noch wißt ist meine alte Steuerung in einem 8 Bit µC mit 4KiB Arbeitspeicher und 64Kib Flash gelaufen bei 16MHz Takt.

Da hat der kleine Raspi doch extrem viel mehr zu bieten! Wäre gelacht wenn der das nicht wuppt.

Okay, so viel für heute.

Zitat:

---

Zitat von Osser

Hi,

Ich bezweifle eigentlich sehr stark das mir das "normale" Linux derart Probleme bereitet wenn ich damit einen Regelzyklus aufbaue.
Wie ihr ja vielleicht noch wißt ist meine alte Steuerung in einem 8 Bit µC mit 4KiB Arbeitspeicher und 64Kib Flash gelaufen bei 16MHz Takt.

Da hat der kleine Raspi doch extrem viel mehr zu bieten! Wäre gelacht wenn der das nicht wuppt.

Okay, so viel für heute.

---

Du übersiehst da ne Kleinigkeit: im Gegensatz zu nem kleinen 8bitter ist Linux bzw, ein Raspi mit Linux kein Echtzeit-System.
Für Ubuntu Linux gab es mal nen Echtzeit-Kernel, glaub aber, der wurde eingestellt. Das war bei Ubuntu Studio, bis 16 oder so.
Ich glaub aber nicht, dass man den auf den Raspi bekäme.
Sachen, die ein Atmel mit links macht (wie z.B. an mehreren Pins gleichzeitig ne PWM auszugeben) kann ein Raspi nicht.
Aber versuchs mal (und berichte drüber), ich halts durchas für möglich, dass sich diese Probleme mit der wesentlich höheren Arbeitsgeschwindigkeit grösstenteils überspielen lassen, so dass man es praktisch nicht mehr merkt.

Hi Sly,

nein nein, das ist mir schon bewust.
Ich gehe einfach nur davon aus das die Zeit die mir durch den Scheduler geklaut wird, im Verhältnis zu der zusammenhängenden, nicht ins Gewicht fällt.

Ich habe mir vorgenommen die Steuerung in C zu realisieren, die Kommunikation mit SSI erst mal auch in C direkt zu programmieren. Pins hab ich ja ausreichend zur Verfügung.
Da ich nur 5V RS485 Treiber vorrätig habe brauchts dann noch ein Pegelwandlerchen oder einfach einen Spannungsteiler.
Mal sehen.

Als erstes entwickel ich mir eine Bibliothek damit ich ein Interface habe um die Pins schnell ansteuern. Damit soll dann SSI implementiert werden und ein Testproggi das mir anzeigt was da raus kommt.
Die Hardware baue ich mir dann mal schnell auf einem Breadboard auf und da ich unter einem MHz bleibe dürfte ich wenig Phasen und Amplitudenprobleme bekommen, hoffe ich zumindestens.

Für die, die nicht mehr wissen wie mein Maschinchen aussieht. Das ist ein Foto das ich von der fertigen Machine aufgenommen hatte mit der Steuerung basierend auf den ATmega64.
Anhang 35707
Hier sind sogar noch meine selbst gebauten Wegaufnehmer/Drehgeber verbaut die -- wie soll ich sagen -- Charaktervoll gemessen haben.
Ich habe dann später doch auf Zukaufteile gesetzt weil man sowas einfach nicht selbst bauen muß.



Gruß
Osser

Schönes Projekt; ich lese schon ne Zeitlang mit.

Zitat:

---

Zitat von Osser

.. Ich gehe einfach nur davon aus das die Zeit die mir durch den Scheduler geklaut wird .. nicht ins Gewicht fällt ..

---

Ach, nun muss ich mal meine Bedenken (nach eigenen Erfahrungen) vorlegen.

ABER: das ist etwas langatmig >> also lieber nicht wirklich alles lesen << (Punkt 6 reicht *gg*). Warum schreib ich es trotzdem? Ne CNC muss bei Schrägen oder Kurven möglichst die theoretisch gewünschte Synchronizität der verschiedenen Achsen gewährleisten um messbare Abweichungen von der gewünschten Kontur zu vermeiden. WENN da ein Motor auch nur Millisekunden (vermutlich eben sogar Mikrosekunden) anders reagiert als ein anderer - ist das, zumindest bei meinen Antriebsmotoren des Minid0, messbar.

Ich hatte die Motorregelung meiner rollenden Coladose mit zwei UNabhängigen, zeitlich versetzten Regelungsroutinen (Taktung 100 Hz für JEDE der beiden Routinen, die aber gegeneinander versetzt laufen) überprüft, weil ich keinen einwandfreien Geradlauf erreichen konnte. Insbes. der Anlauf zeigte einen Versatz. Hintergrund sind die steilen Beschleunigungen der DC-Motoren bei Geschwindigkeitssprüngen.
Hardware: ATmega1284p, Minimotörchen aus Billigstservo, Software: C.

Und so war - etwas gerafft - mein Weg zur Erkenntnis:

1. der Wunsch

2. noch immer Wunsch

3. erste Be-merkungen

4. im Rahmen des Möglichen gleichzeitig (also ein paar µs-Bruchteile hintereinander)

5. Stochern im Sprung-Nebel

6. erste Klarheit/en

Wie erwähnt - es geht hier nur um die bestmögliche "Gleichzeitigkeit" der Motörchen bei meinem MiniD0. Das zeigte eben schon deutliche Probleme beim Beschleunigen, obwohl - wenn weitgehend unbeschleunigt - ein guter Geradauslauf möglich ist.

Vielleicht nützt Dir der Hinweis etwas? Und - sorry für die Langatmigkeit.