Welche SW (Freeware) zur Steuerung v. Robot Arm

Hallo Michael, grüß Dich.

Das hört sich nicht schlecht an und ist auch so in meinem Sinne. Gleiche Armlänge ist für die Funktion voll i.O. und ausreichend.
Da auch in dem Fall Fahrwegsbegrenzung der Anschlag über Endschalter erfolgen und der Weg in der FW festgelegt werden kann, sehe ich dort kein Problem.
Somit ist eine Kollision mit dem Heizbett nicht wahrscheinlicher als bis jetzt bei Druckern herkömmlicher Bauart.
Die Ermittlung des Nullpunktes erfolgt nicht anders als bisher auch.
Wie du schon richtig erwähntest ist die Stellung der Hotendaufnahme ja immer parallel zur Grundebene (Heizbett).

Das einzige was ich als komplizierter ansehe ( was "repetier" auch schon bemerkt hat ), ist durch die Umsetzung der Kreisbewegung in den rechteckigen Bauraum,
ergeben sich unweigerlich Geschwindigkeitsunterschiede im Verfahrweg einer Achse. Es muss also um eine generelle gleichbleibende Druckgeschwindigkeit erreicht zu werden,
eine Drehzahl Anpassung erfolgen. Diese ist wiederum abhängig von den Bauraummaßen. Diese können aber wiederum als Variablen vom Benutzer in der Firmware wie bisher
auch eingegeben werden.
So wie ich das sehe sind das ein-zwei *.h Dateien mehr in der FW als jetzt, der Rest müsste so wie die "Delta-Routinen" jetzt schon, als dritte Variante integriert werden.

Ich habe vor einen Versuchsaufbau zu erstellen, den sich jeder einfach nachbauen kann, um die Steuerung auszuprobieren.
Einfach 4 Stepper Nema17, Endschalter, ein paar einfache Bauteile und dann kann jeder mit seiner Elektronik und der geänderten SW das ganze testen.
Die Weiterentwicklung ist dann schon wie vorprogrammiert, von ganz alleine durch unsere kreativer Usergemeinde. Das ist "ansteckend", da bin ich mir sicher.

Des weiteren gehe ich davon aus, das sich auch noch der ein oder andere finden wird, der noch ein wenig mehr Zeit zu Verfügung hat und gerne mit macht.

Bis später Didi

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Hallo zusammen,

es ist doch so, dass tausende cnc-Eigenbaufräsen wundervoll ohne Encoder laufen und die tollsten Sachen fabrizieren.
Lediglich Überlastung führt zu Schrittverlusten im Falle der Stepper, so dass Encoder keine prinzipielle Notwendigkeit sind.
Eine Koordinaten-Nullstellung ("Homing") zu Beginn wie bei den cnc-Fräsen kann doch mit dem Roboterarm manuell bzw. per "Gamepad" erfolgen, womöglich wie bei einer cnc mit einem Drucktaster, so dass ein neues Hotend direkt "genullt" ist.
Da das dann noch nicht die endgültige Position ergibt müsste man noch die definierte Länge des Hotends, bzw. der Abstand der Düse zum äußersten Gelenk entweder eingegeben oder halt auch per Anschlag und Taster gemessen werden. Die 3D-realtime Erkennung finde ich ein wenig "durch die Brust ins Auge"...ist vll. auch nicht so direkt umzusetzen und führt zu Fehlern --> [sinkhacks.com]

Geschwindigkeit finde ich ist erst mal kein Argument, da es ja autonom abläuft / ablaufen sollte. Somit ist Rechenzeit erst mal untergeordnet.

Am wichtigsten wäre erst mal eine direkte gcode Umsetzung. EMC2 bzw. LinuxCNC sowie Mach3 und Konsorten machen ja nix anderes als die vorgegebenen Bahnkurven "abzutakten". Im hier vorliegenden Fall soll ja die direkte/inverse Kinematik direkt integriert sein, korrekt? Dann ist aber das Problem, dass die Bewegung von Ist-Koordinate zu Soll-Koordinate immer eine direkte lineare Bewegung ist. Somit müsste man in einem CAM die Bahnkurve von Ist-Koordinate zu Soll-Koordinate vorgeben (z.B. eine Stufe über einen Schraubstock o.ä.). Wobei, so gesehen für einen 3D-Drucker der jede Layer mit z=const. abfährt OK, läuft dann auch ohne CAM...
Was dann auch nahelegen könnte, dass der Druckkopf allein mechanisch immer vertikal verfahren wird...somit wären es erst mal nur 3 Achsen, welche benötigt werden (Armrotation um z-Achse, Schultergelenk, Ellbogengelenk ).

Finde das ganze jedenfalls auch sehr interessant und hatte auch immer bei den bisherigen Recherchen das Problem der Steuerung. Muss aber auch gestehen, dass ich innerhalb der bestehenden Firmwares nicht verstehe, was die jeweiligen Codeblöcke so machen.

Nu dann, hoffe obiges kommt nicht zu wirr rüber..
Grüße
Mike

So mal nen grober Hinweis wie aktuelle Firmwares funktionieren.

Jeder Weg von xy nach XY wird in Schritte unterteilt. Der Motor der am meisten zu tun hat dominiert. Die anderen Schritte werden in den dominierenden Schrittverlauf gleichmäßig aufgeteilt.

Was heißt das?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
y--y--y--y--y--y--y--y--y--y--y-

Wenn ich jetzt eine Kurve fahren möchte, dann wird diese Kurve in Segmente unterteilt.

xxxxxx | xxxxxxxx | ...
y--y-- | y---y--- | ...

Das ist auch der Grund, warum Deltas so viel mehr Rechenpower brauchen. Hier fahren die Motoren quasi immer Kurven damit am Ende eine Gerade bei rumkommt.

Wenn man jetzt noch beachtet, dass ein Delta sehr genau aufgebaut werden muss, sodass dieser dann später ordentliche Geraden fahren kann, frage ich mich gerade wie man diesen Roboter überhaupt auf 0 fahren will?!? Einige Arme drehen sich ja nur und haben daher ja nicht einmal einen normalen Nullpunkt, wie man es bei normalen Druckern her kennt.

Nur mal so am Rande Viel Spaß aber bei dem Projekt.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hallo, grüßt Euch.

Während ich gerade so meine ersten Bauteile für die Planetengetriebe drucke (PLA-HT),
habe ich mir ein wenig Gedanken zur Armgestaltung gemacht.



So ungefähr sollte "Er" aussehen und auch recht stabil werden. Bei einer Schenkellänge von je ca. 220 - 250mm,
dürfte die Dimensionierung für eine Normale Druckbettgröße von ca. 200x200mm ausreichen.
Die Hotend-Aufnahme-Plattform wird zwangsgeführt zur Grundebene (Druckbett).

Die Einzelteile erstelle ich mit Creo und die Stl-Dateien werde ich selbstverständlich (nur bei funktionstüchtigem Arm),
hier einstellen.

Ich denke das solch eine Konstruktion wohl nicht so schwierig zu steuern sein wird.

Bis später Didi

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Moin moin aus HU.
Bei Deinem Konstruck ist mir wieder eine Idee gekommen. Es gibt doch Toröffner, die mit einem Motor und Gewinde laufen. So etwas hatte ich auch mal in meiner Klimaanlage meiner Telefonanlage. Mit so einem Motor wurden die Klappen der Klimaanlage gesteuert. Wenn man so einen Antrieb auch mit Schrittmotorenantrieb bekommen könnte, hätte man ein sehr stabiles Gebilde, was nur in der Längsachse belastet wird. Das sieht aus wie ein Stosdämpfer mit Gewindestange oder so.

PS: Habe mal gegoogelt. Sowas nennt sich
Elektrische Hub- und Linearantriebe

1-mal bearbeitet. Zuletzt am 14.05.15 19:50.

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Irgendwie hat mich das Fieber hier doch ein wenig mehr gepackt, obwohl hier noch ein anderes Projekt auf Fertigstellung wartet.

Die Grundfunktonen bzw. wie was gemacht wird kenne ich wohl ähnlich schon von einem sehr alten Projekt von mir. Einen selbstgebauten Plotter an einem NKC 68008 der per Befehlszeile mit ner Art Vectorgrafik gefüttert wurde. Die Software hatte ich glaube ich in COBOL oder Pascal/s geschrieben bin mir da nicht mehr so ganz sicher. Ergebnis war ein Ratterndes etwas, was in vergleichsweise Schnekentempo, Linien und Keise auf ein Blatt Papier gemahlt hat.
Die Anforderungen hier sind natürlich ein vielfaches höher, dafür hab ich damals alles von Grund auf Kompl. selbst geschrieben und gebaut.

Die Haupprobleme die ich hätte, falls ich mich dazu entschließe hier richtig loszulegen, welche der Firmware wär überhaupt die geeignetste für dieses "Projekt".
Oder genauer gesagt wo ist die bessere Dokumentation vorhanden, weniger Stolpersteine aufgrund wirr ineinander greifender Funktionen und wo bessere Hilfestellung oder sogar etwas Mitarbeit von den damit vertrauten Programmierern zu erwarten sind.
Oft ist durch die "Handschrift" der Programierer und die Herangehensweise an Lösungswegen, nicht immer auf den Ersten und Zweiten Blick ersichtlich, was da im Programm gerade überhaupt gerade abläuft. Auch wird durch einbetten von z.B. Assembler oder Extrem langen und komplexen Berechnungen das "Lesen" der Software ohne fremde Hilfe nahezu unmöglich.


Auch ist meiner Meinung eine feste oder halbwegs Modulare Einbindung sinnvoll (würde das ja nicht "nur" für mich Schreiben).
Wenn man sich schon eine solche Arbeit macht, sollte man das nicht nach dem nächsten Update alles komplett neu einbinden und umschreiben müssen. Bei Marlin bzw. Marlin4due ist ja z.B. momentan einiges los, der Code wird ja gerade anscheinend nahezu nochmal komplett Überarbeitet. Bei den anderen sieht es glaube ich auch nicht so viel anders aus.
Was auch trotz Interesses, die etwas zurückhaltenden Angebote und Hilfestellungen von z.B. Repetier und Wurstnase erklärt.

Daher lieber noch ne weile abwarten, bis das erstmal Abgeschlossen ist? Vorbereiten kann man sich ja schon.

Wie weit ist ein solch gravierendes eingreifen in die Firmware überhaupt erwünscht/moglich und mit wem sollte man dann in Kontakt treten wenn es später fest mit eingebunden und gepflegt und erweitert werden soll?
Antworten hier gerne auch vertraulich per PN.

Außerdem hätte ich noch dazu das Problem, das ich momentan gar keinen DUE + weiterer Hardware und zum testen zur Verfügung habe.
Und meine Liebste mir den Kopf umdreht, falls ich mir so ein Teil zum nur so zum Spielen und Probieren kaufe.
Gibt es daher eine empfehlenswerten DUE Simulator um überhaut erstmal zu schauen wie ich mit der Firmware und deren erforderlichen Änderungen überhaupt klar komme?

Habe mal in Marlin4DUE mal eine ganze weile reingeschnuppert ist auf alle fälle sehr komplex, so das ich auf den ersten Blick nur einen kleinen Bruchteil verstanden habe, die vielen Einstellmöglichkeiten und Optionen versperren einem ganz schön die Sicht auf das Wesentliche, die Sprachkenntnisse tun ihr übriges. Diese Firmware ist aber erstaunlich gut Dokumentiert wenn man erstmal verstanden hat was wie gemeint ist (mein Englisch könnte auch einiges besser sein).
Habe aber schon mal ganz, ganz grob verstanden was wo wie in welcher Reinfolge gemacht wird.
Am Wochenende werde ich mir auch mal Repetiers Firmware grob anschauen und mal schauen wie weit ich da mit klar kommen könnte.

@vw-styler die 4. Achse kommt auf alle Fälle mit rein falls ich das mit der Firmware machen sollte. Nur um die neidischen Blicke zu erahnen, wenn man sein Hotend zum Düsenwechsel in eine bessere Position hochklappen lässt und sich dabei auch noch Vorstellt, wie andere dabei halb auf dem Druckbett liegen.
Ob und wie sich das über den Host bzw. die Befehlszeile überhaupt steuern lassen würde hab ich aber noch nicht näher betrachtet.
auch die spätere Erweiterung zu einer echten 4. + 5. Achse könnte ich mir vorstellen, falls der Prozessor das her gibt und die Slicer da mitziehen.
Ein Echtes Einbetten von Objekten wie Schrauben und Muttern und evtl sogar Werkzeugwechsel, Heben und Positionieren wär möglich und ne nette Spielerei, so wie das ganze Projekt.

Ach so, und Sorry nochmals an alle, für die Länge des Textes. Aber mir fallen momentan gefühlt 1000 Dinge ein die zu Beachten oder noch zu Erfragen oder zu Klären sind.

LG Michael

Hallo Michael,

Marlin und Repetier sind die gängigsten und verbreitesten FW, wobei wir bei Repetier die größten Chancen haben
das ganze vernünftig umzusetzten.
Aus zwei offensichtlichen Gründen:
1. "Er versteht uns" ,
2. "Er" hat ´nen Plan von der Materie ,
3. womöglich relativ kurzer Weg bei Problemen ,
und 4. ohne jemanden zu nahe treten zu wollen, die ganze Aktion ist ja auch,
wenn es gut funktioniert, ein großes Plus für "Alle"

Mach dir mal nicht zu viel Gedanken die dich selber bremsen das ist schon ganz i.O..
Tu ich ja auch und wie wir ja schon von "Frithjof" gehört haben, gibt es ja genug die da selber schon einmal drann waren.
Das bedeutet ja nicht das diese Spezialisten alle, für immer verlohren wären. Ganz im Gegenteil. Ich gehe davon aus,
das die schon auf glühenden Kohlen sitzen und warten auf den geeigneten Zeitpunkt um auf den Zug wieder aufzuspringen.
Dafür reizt das Projekt einfach zu sehr. Im Übrigen sobald die Frage der Steuerung/Software u. Firmware geklärt ist
werde ich einen neuen Beitrag in "Projekte" aufmachen, wo es dann auch hingehört.

@ Frithjof - hab da von IGUS soetwas noch hier rumliegen, soetwas meintest du doch, oder?



Diese hier hat eine Gewindestange M5 mit einem Hub von ca. 90mm + . Das wird wohl genau richtig sein für den Zweck.
Wenn nicht, die Schine ist ein Standard-Profil von IGUS und kostet auch nicht viel. Nr. 3607688 002 023 steht auf dem Teil.


Bis später Didi

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Ich gebe zu bedenken:

1. Dieser Arm hat nur 3 Freiheitsgrade und bietet keine (für mich?) ersichtlichen Vorteile.
2. Die Hebelumlenkungen beeinträchtigen die Wiederholgenauigkeit.
3. Der Bauraum hat eine ungünstige Form (ist in etwa eine schräg abgeschnittene Halbkugel).
4. Gibt's schon: [ufactory.cc]

Herzl. Grüße

Der "UARM" kann 3D-Drucken??
Ist es nicht eher so, dass er angelernt wird in dem der Bewegungsablauf abgespeichert wird?


Der Bauraum bezogen auf die Grundfläche ist doch immens, ordentliche Hardware macht das Ding nicht weniger genau als die konventionellen Maschinen...vor allem, wenn die gcode-Unterstützung firmwareseitig läuft, kann (nein, wird) das ein total geniales Arbeitspferd werden...

Grüße
Mike

Hallo @ "Alter Bastler"

> 3. Der Bauraum hat eine ungünstige Form < na und?

ist doch genug Platz ! Muss doch nur definiert werden.
Das es einfacher ist wenn man im rechten Winkel fährt, das ist schon klar, darum geht es aber nicht.

> 4. Gibt's schon: < und soll´n wir deswegen aufhören? Was ist das denn, das geht doch garnicht.

Software erweitern, das ist Thema und nicht Grundsatz zweifeln. Das bringt nicht weiter.

Bis später Didi

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Bei Deiner Größenbetrachtung fehlt die dritte Dimension. Ich zweifle überhaupt nicht, aber
man sollte bereits bestehende Konstruktionen nicht außer Acht lassen.
Ebenso bereits durchdiskutierte Aspekte einer solchen Lösung, z.B. hier:
[forums.reprap.org]
Um nur mal einen grundsätzlichen Eindruck vom Verhalten der Konstruktion zu haben:
[youtu.be]
[youtu.be]
[youtu.be]

Herzl. Grüße

AlterBastler...nicht böse nehmen...: was sollen die Beispiele zeigen?
Dass eine bereits bestehende Konstruktion in Form des UARM eine gewisse Reproduzierbarkeit hat? OK.
Dass dies die hier zu erwartende Reproduzierbarkeit sein wird? Nein.

Das sind zwei paar Schuhe und der Fehler durch die Software kann rein theoretisch beliebig klein gemacht werden (Auf Kosten der Geschwindigkeit, u.a...). Der mechanische Rest ist das Problem eines jeden Budgets.

Außerdem, Didi will es gerne so.

Mal wieder zum Thema...wie sieht es eigentlich mit Smoothieware aus? Das schaut für mich nicht-Programmierer relativ aufgeräumt und kommentiert aus...

Hallo grüßt Euch.

> Außerdem, Didi will es gerne so. < . . . es geht nicht um mich, es geht um die Sache.

Nicht falsch verstehen, jedem "Sein Ding".

Aber alle benötigen wir doch dafür eine SW-Basis das war/ist doch mit unseren jetztigen Druckern nicht anders.
Egal wieviel drei Arme dein Kossel oder wie die Konstruktion auch immer genannt und aussehen wird, es bleibt ein Delta.
Genau so ist/wird das mit den "Einarm-Drucker-Lösungen" auch werden/sein, endscheidend ist nur die Anzahl der Achsen.
Wenn´s erst einmal funktioniert, will es nachher geiner mehr missen.

Bis später Didi.

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Hallo,

gibt es denn schon eine kinematikberechnung und Definition des Koordinatensystems/Winkel/Längenbezeichnungen/z-offset/Tool-Länge/ usw. ??
Da die Firmwares wie ich finde sowas meist auslassen, wäre es vll. hilfreich hier eine Zeichnung und Rechnung festzulegen??

Grüße
Mike

PS:
[www.tu-chemnitz.de]
[homepages.thm.de]
[wiki.ifs-tud.de]

Hallo Mike, grüß Dich.

> ... gibt es denn schon eine kinematikberechnung und Definition des Koordinatensystems . . . < nein, noch nicht.

Das hat logischerweise auch einen ganz betimmten Grund. Keiner macht sich vor Aussicht auf Erfolg mehr Arbeit als erforderlich.
So in diesem Fall: meine Frage - Welche SW (Freeware) zur Steuerung v. Robot Arm - vorrangig war, denn ohne eine Aussicht
auf eine vernünftige Steuerung, ist jede Energie in ein Projekt - überflüssig.

Meine Aktivitäten sind wie immer ungebremst , ich entwickle immer was.
Übrigens, wider aller "Unkenrufe" das offene Enden nicht funktionieren beim 3D-Drucker.


. . . und das funzt super, auch bei Z von 0,1mm


Mir gefällt dein Interesse und deine Art, vorab dich in das Projekt einzubringen. Danke für deine Links und Hinweise,
die für sehr viele bestimmt sehr hilfreich sind.

Mehr von dir, und es geht voran.

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

hi didi, hier was zur motivationsverstärkung .
[www.3ders.org]
gruss hd

1-mal bearbeitet. Zuletzt am 16.05.15 08:27.

Damit keiner denkt, ich mosere nur...
Habe was gezeichnet. Das Einsetzen habe ich mir erspart.

Herzl. Grüße

edit: Klammer vergessen

1-mal bearbeitet. Zuletzt am 16.05.15 12:37.

Cool !
Habs noch nicht vollständig nachgerechnet, aber müsste es nicht heißen:
Z(C)=Z(D)+L3

Vielleicht ist es aber auch noch sinnvoll den Absolut-Nullpunkt tiefer zu legen? Die Rotation (alpha) wird ja überhalb der Arbeitsplatte erfolgen, damit müste "A" und damit der ganze Rest auf der z-Achse nach oben rutschen, sagen wir mal um "L0" ?

Grüße
Mike

Ja, Du hast Recht, hab's korrigiert. Kartesische Verschiebungen sollte man besser später über die Koordinateneingabe einfließen lassen.
Ging mir nur um die Darstellung der Berechnung.

Herzl. Grüße

Hi,

hatte parallel auch mal den Stift geschwungen...nicht ganz so stilvoll dargestellt wie AlterBastler aber...:


AlterBastler, kann es sein dass dein Winkel "y" nur "Pi/2" benötigt..?
Deckt sich aber glaub so weit.
Erst mal wichtiger aber, wieso ist es sinnvoller die Koordinatenverschiebung erst später zu machen?
Ich habe das mal mit reingenommen, machts nicht wirklich heftiger.

Grüße
Mike

PS: Sehe grad..der Koordinatenursprung (0;0;0) ist in der Zeichnung der Schnittpunkt der Z_quer - Q_quer- bzw, X_quer - Y_quer-Achsen.

Rein vom programmiertechnischen Standpunkt aus.

edit: Nicht später, sondern früher, so in der Art: x' = x-Extruderoffset, y'=y-Extruderoffset, z'=z-L0

Herzl. Grüße

1-mal bearbeitet. Zuletzt am 16.05.15 17:06.

Moin moin aus HU.
Ich bin sehr stark beeindruckt von den Formeln. die ihr so aus dem Hut zeubert. Habt ihr die immer im Kopf oder doch nur irgendwo abkopiert?. Ich kriege momentan nicht einmal die Widerstndsformel
Rg= R1 x R2 / R1 + R2 auf R2 umgestellt.
Bei Vorschlägen bitte nicht googeln, sondern selbst umstellen.

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Ach...ein wenig nachdenken müssen wir da auch...vor allem beim Winkel "y"... *g*
Aber meinst du
Rg= (R1 x R2 / R1) + R2
oder
Rg= (R1 x R2) / (R1 + R2)

??

2-mal bearbeitet. Zuletzt am 16.05.15 17:27.

R2 = Rg*R1/(R1-Rg)

Herzl. Grüße

BTW:
[www.cncecke.de]

Quote
theothermike
Ach...ein wenig nachdenken müssen wir da auch...vor allem beim Winkel "y"... *g*
Aber meinst du
Rg= (R1 x R2 / R1) + R2
oder
Rg= (R1 x R2) / (R1 + R2)

??

Rg= (R1 x R2) / (R1 + R2)
Sorry, mein Ansatz war mathematisch nicht richtig

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Quote
vw-styler
Mach dir mal nicht zu viel Gedanken die dich selber bremsen smiling smiley das ist schon ganz i.O..

Kein Problem das Projekt wird ja nur etwas aufgeschoben. Finde das hier momentan Interessanter. Und ich kann durch eine Vernünftige Einarbeitung in die Firmware eh nur gewinnen.

Quote
vw-styler
Das einzige was ich als komplizierter ansehe ( was "repetier" auch schon bemerkt hat ), ist durch die Umsetzung der Kreisbewegung in den rechteckigen Bauraum,
ergeben sich unweigerlich Geschwindigkeitsunterschiede im Verfahrweg einer Achse. Es muss also um eine generelle gleichbleibende Druckgeschwindigkeit erreicht zu werden,
eine Drehzahl Anpassung erfolgen. Diese ist wiederum abhängig von den Bauraummaßen. Diese können aber wiederum als Variablen vom Benutzer in der Firmware wie bisher
auch eingegeben werden.
So wie ich das sehe sind das ein-zwei *.h Dateien mehr in der FW als jetzt, der Rest müsste so wie die "Delta-Routinen" jetzt schon, als dritte Variante integriert werden.

Das ist alles schon in der Firmware drin. Ich sehe momentan glaube ich keinen Grund, das wir da wirklich etwas groß ändern müssen.
Und solange wir erstmal im ersten Schritt bei der Mechanischen Lösung für 4 Achse bleiben fallen die von Repetier erwähnten Änderungen fast alle weg.
Die Haupt sorge die ich in Sachen Beschleunigung sehe ist je weiter das Hotend (Masse) von der Achse "A" weg ist desto sanfter muß beschleunigt werden. Schrittverluste sind also im Randbereich am Wahrscheinlichsten. Evtl. ist das aber zu vernachlässigen, da der "A" Motor da eh einiger langsamer für gleiche Geschwindigkeit drehen muß.



@Alter Bastler und theothermike: Schaut auf den ersten Blick schon klasse aus, wollte auch gerade mal ein wenig in Geometrie loslegen, Ihr wart aber einiges schneller.
Passt mir aber ganz gut. Die meißten Formeln in Sachen Geometrie hab ich seit der Schule nicht mehr gesehen.
Wie ich aber glaube, seit ihr schon einen schritt weiter gegangen und habt gleich beide Schenkel mit unterschiedlichen Längen mit drin. Was ich allerdings nicht so schlimm finde. Bin mir momentan eh nicht so sicher ob Winkelberechnungen in einem gleichschenkliges Dreieck so viel Rechenleistung Sparen würden.

Eine spätere Kordinatenverschiebung von D in Richtung Q sollten wir aber auch noch (zumindest später) in Betracht ziehen, das Hotend wird sich bestimmt nur Wiederwillig direkt unter Gelenk C Platzieren lassen.

Quote
theothemike
Erst mal wichtiger aber, wieso ist es sinnvoller die Koordinatenverschiebung erst später zu machen?

wie du vielleicht in deinen Formel siehst taucht die Verschiebung in nahezu allen deinen Formeln auf. Das heißt sie müßte bei jeder Formel extra neu erneut berechnet werden, was aber jedes mal ein wenig Zeit in Anspruch nimmt. Wenn du dann auch noch bedenkst das eine gerade in etliche Teilsegmente aufgeteilt und jede neu Berechnet werden muß ist es eine enorme Zeitersparnis, wenn du das vorher schon machst.
Da beim Drucken ja auch meistens Z Konstant ist, braucht man sie Eigendlich auch nur dann neu berechnen, falls Z sich ändert, was aber bei der simplen +- Rechnung wohl eh nicht auffällt

Vor- und Nachteil gleicher Schenkel siehe Skizze

Herzl. Grüße

Hallo,

den Vorteil die Koordinatenverschiebung außerhalb der Berechnung zu machen verstehe ich noch nicht.
In meinen Rechnungen wird ja exakt bezüglich des Absolutkoordinatensystems die Armstellung berechnet. Es ist ja erst mal eine Addition bzw. Subtraktion. Die muss mit jeder Programmschleife doch so oder so vollführt werden, oder?
Da wir hier ja ein gekoppeltes System haben wird selbst bei z=const. der Wert z immer für jedes verfahrene Linienelement mit eingerechnet.
Damit haben wir den "Rechenaufwand" ja so oder so..

Achso, konstruktiv lässt sich das Hotend doch perfekt unter das äußere Gelenk platzieren...zur Not halt mit einer seitlichen/exzentrischen Filamentzuführung.

Z(D) geht nur einmal in die Berechnung ein. Bei einem seitlichen Versatz des Extruders kommen auch noch 1-2
weitere (einmalige) Winkelberechnung(en) für Delta und/oder L2 hinzu.
Die Art und Weise der Berechnung ist aber eher Geschmackssache, die Anzahl der Winkelfunktionen ist eigentlich das Problem.

Herzl. Grüße