CNC mit Gleichstrommotoren

[Osser]

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

[Osser]

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.

[Peter1060]

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

[Osser]

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.

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.

[Peter1060]

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

[hellobello]

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

[Yossarian]

Hallo
Bresenham

Mit freundlichen Grüßen
Benno

[Osser]

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.

[hellobello]

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 )

[Osser]

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.