CraftWare, eine Alternative?

[Digibike]

Da wird also der Hase im Pfeffer liegen... ;-)
Da hilft nur, Erfahrungswerte sammeln - mit Genau wird das nichts werden, zumal die Frage ist, inwieweit man
so genaue Zeiten bräuchte... Oder denkst du da Gewerblich (Kostenkalkulation? In dem Fall würde ich auf
eine Mischkalkulation setzen und erstmal, bis ich Erfahrungswerte habe ca. 20 % drauf schlagen, kannst du
ja beobachten und entsprechend dann korrigieren...)

Gruß, Digibike

 

[09er]

Ja mir war halt unbegreiflich warum das so daneben liegt jetzt leuchtet es ja ein
Brauchen tut man eine genaue zeit nicht unbedingt aber es gibt soviel was man eigentlich nicht bräuchte im leben und doch ist es schöner mit ....

 

[fridde]

Moin,

das mit der Beschleunigung finde ich nur teilweise einleuchtend... Ich muss gestehen ich weiß nicht wirklich wie die Beschleunigungen berechnet werden. Findet das in der Hardware statt oder ist das schon im G-Code umgesetzt. Die Hardware ansich ist ja dumm. Das heißt, es dürfte nicht passieren dass die Motoren nicht hinterher kommen, da die Hardware ihnen eine genaue Anzahl an Schritten vorgibt. Kommen die Motoren da mal nicht hinterher, verlieren sie Schritte und der Druck ist versaut. Steht im Code jedoch nur fahre hier eine Rampe, dann kann Digibikes Erklärung passen. Aber selbst in dem Fall müsste die Software ja irgendwelche Zeiten für die Beschleunigung annehmen, um sie in die Zeitberechnung einzubeziehen. Sollte somit, meiner Meinung nach, anpassbar sein.

Gruß Fridde

 

[Digibike]

Hi @fridde,

Jein! In der Slicer-Software sind ja nur Optimal-Werte hinterlegt! Woher sollte Sie aber a) die Umgebungstemperatur kennen, Lager-zustand, Motoren-Toleranzen?
Wenn du es per USB druckst, könnte das ja noch einigermaßen klappen - einigermaßen deshalb, weil ja noch ein gewisser Puffer im Drucker ist, in den er die
Daten lädt und er ja zurück meldet, wann er den/die nächsten Befehle empfangen kann - sonst würde es bei der Übertragung ja einen Overflow geben und die
Daten wären verloren - wenig sinnvoll...!
Bei Druck von der Karte hat der Slicer aber überhaupt keine Rückmeldung, wann welcher Verfahrbefehl abgeschlossen ist - bin mir aber auch nicht sicher, ob
der Slicer, selbst bei USB, egal welcher, die Daten während des Drucks abgleicht und die Zeiten korrigiert...

Stell dir das einfach wie einen Sportwagen vor: von 0 auf 100 in 4 Sekunden, Höchstgeschwindigkeit 200 Km/h (eher Sprinter als Endgeschwindigkeitsgeil...)
wird in 8 sec. (einfacher da Linear, was aber so nicht einmal Elektroautos hin bekommen...)...
Und du sollst nun ausrechnen, wielange er für 200 Km strecke braucht!
Theoretisch brauchst du nur ausrechnen, welche Strecke er in 8 Sekunden zurücklegt, bis er auf 200 beschleunigt hat und von den 200 Km abziehen und dann
die Zeit für die Verbleibende Strecke zu berechnen!
Soviel zur Theorie, die der Hersteller dir liefert! Und nun zur Praxis: Unter deinen Reifen ist Sand - Beschleunigung also Suboptimal... Reifen sind nicht mehr die
besten, somit Grip ebenfalls nicht gerade Optimal aber noch Ausreichend - Plötzlich bist du bei 15 Sekunden statt bei 8 - dazu kommt noch, daß der Fahrer
die Umstände zu spät regestriert und die Räder durch drehen läßt - 18 sekunden... Es geht Bergauf, 21 Sekunden bis Höchsttempo...
Unterwegs muß er 3 mal Überholen, also Tempo drosseln und wieder Beschleunigen... usw. usw. usw...
Na, wielange braucht er Theoretisch und wielange braucht er Praktisch? ;-)
Er hat keinen Meter Weg verloren (also Steps), aber bei der Reiseplanung des Navis (also Slicer) für die Strecke konnte das alles noch nicht berücksichtigt
werden - Ergebnis ist halt die sich aufaddierende Abweichung! Da muß nichts verloren gehen - es werden halt nur keine äußeren Einflüsse erfaßt und mit
einberechnet - ansonsten müßte der Drucker bei jedem (USB) druck die Rückmeldungen erfaßen und für zukünftige Berechnungen in ein Profil mit einfließen
lassen... Damit würde es irgendwann eine relativ genaue Annäherung geben, aber das setzt voraus, daß man immer mit USB-Verbindung (unsicher und Rechner
blockiert) druckt und es wäre ein immenser Aufwand...
Sowas sehe ich momentan nicht als sinnvoll an, aber würde schon sinn machen, wenn der Drucker irgendwann die Druckzeiten speichert und an den Rechner
und somit Slicer zurück melden kann - dann brauch ich keine direkte USB-Verbindung mehr und hab trotzdem eine Rückmeldung zu einem späteren Zeitpunkt...

Die Berechnung macht der Slicer übrigens, anhand der ihm bekannten Werte, aber das sind Optimal-Werte - Lager und Führungen sowie Motoren ändern aber Ihr Spiel und Ihre Toleranzen bereits bei Temperatur-Änderungen! Materialien dehnen sich unter Wärme aus oder ziehen sich zusammen bei Kälte, entsprechend ändert sich die Reibung, Gleiches gilt auch für die Leitfähigkeit der Wicklungen des Motors (Widerstand) - macht zwar nur Minimal was aus, aber hochgerechnet auf z.b. ein 10 h Druck läppert sich sowas ganz schnell ganz schön...

Hoffe, ich konnte es etwas besser erklären...!

Gruß

Digibike

 

[09er]

Die Software sagt im Gcode ja nur "fahre von Punkt A nach Punkt B mit einem Vorschub von X mm/s"

Also wird die (dumme) Software davon ausgehen das der Drucker mit x mm/s diesen weg bestreitet
Dies ist aber technisch gar nicht möglich weil die Motoren ja "langsamer" anlaufen und stoppen.

Also müsste man der Software sagen die anfahrt/stoppen der Motoren dauert etwas länger ...... das wiederum wäre glaube ich viel zu aufwendig für die Berechnung

 

[Rob_3D]

Der G-Code gibt nur den Weg und die Geschwindigkeit vor. Der Drucker muss aber die Masse von Extruder usw erst auf diese Geschwindigkeit beschleunigen. Ein Auto kann auch nicht von 0 auf 100 in 0,001µs beschleunigen. Je nach Kraft des Motors, Gewicht des Autos usw dauert es eine Weile.
Und je höher die Beschleunigung, um so größer müssen die Kräfte sein.
Ich habe meinen Drucker gestern von 1.000mm/s² (das ist die Einheit für Beschleunigung) auf 500mm/s² gestellt. Seitdem druckt er viel sanfter und ich kann höhere Geschwindigkeiten fahren, ohne dass er bei kleinen Details gleich vom Tisch ruckelt. Ja, bei gleicher Geschwindigkeit druckt er dann etwas langsamer, weil er mit jeder Richtungsänderung länger braucht, bis er auf Geschwindigkeit ist und auch früher wieder abbremst.

Übrigens, wenn du deinen Drucker aus dem Fenster hältst und dann los lässt, beschleunigt er mit 9.806,65mm/s²

Noch ein Beispiel:
Ich drucke mit 50mm/s. Die Beschleunigung liegt bei 1000mm/s², dann ist die Zeit, in der der Druck zur Endgeschwindigkeit beschleunigt:
50mm/s / 1000mm/s² = 0,05s
Also der Drucker beschleunigt in 0,05s auf 50mm/s.

 

[fridde]

Das Ding ist doch aber das, dass die Software keine Rückmeldung bekommt, ob der Motor nun bei der gewünschten Geschwindigkeit angekommen ist. Somit schmeißt sie ja einfach Schritte aus und geht davon aus, dass der Motor da 1:1 hinterher kommt. Wenn man den Druckkopf also mit der Hand festhält, so dass die Motoren gerade keine Schritte verlieren, müsste der Drucker genau so schnell sein, wie ohne die zusätzliche Belastung. Ich denke die Motoren der Drucker sind so ausgelegt, dass man davon ausgehen kann, dass sie ein so großes Moment aufbringen, dass sie die Masse stark genug beschleunigen können.

Was den Datenpuffer im Drucker angeht, ist dieser ja nach dem fifo-Prinzip geleert, sprich first in first out. Sind die Befehle im Puffer abgearbeitet, kann der PC neue Daten schicken. Da dürfte ja nur die Verarbeitungsgeschwindigkeit der Software eine Rolle spielen.

Eigentlich müsste man das ganze mal ohne die ganze Mechanik austesten. Sprich einfach die Motoren frei drehen lassen und schauen, wie lange das ganze dann dauert.

 

[Digibike]

Hi Fridde,

die Slicer berücksichtigen soweit ich weiß dieses auch gar nicht... Schrieb ich schon! Es ist nur eine Annäherungsrechnung bei Erstellung, die von Optimal-zuständen
ausgeht... Würdest du es genauer wollen, so würde eine eingehende Analyse erforderlich werden und selbst die würde das Ergebnis nur verbessern, aber nicht die
tatsächliche Zeit wiederspiegeln! Mit Schrittverlusten an sich hat das noch nichts zu tun!
Der Datenpuffer hat bei USB schon eine Auswirkung: Der Slicer weiß ja, welche Befehle er geschickt hat und wann der Drucker vollzug meldet, sprich neue Daten
anfordert - daraus kann man ableiten, wie schnell der Drucker bei Abarbeitung der Befehle war - was Rückschlüsse für die weitere Analyse und Berechnung erlauben
würde...
Was willst du ohne Mechanik also ohne Masseträgheit den testen? Wenn ich ´nen 45 PS Polo aufbocke und den Motor starte und vollgas gebe, wird er bei eingelegtem Gang
jeden Ferrari oder Porsche blass aussehen lassen - stell ich Ihn aber auf die Räder...

Gruß, Digibike

 

[fridde]

Klar ist das nur eine Annäherungsrechnung, da gibt es ja von Hardware zu Hardware unterschiede. Jedoch glaube ich, dass beim Drucken über USB auch der aktuelle Status berücksichtigt wird, zumindest bei S3D. Wenn ich mich jetz nicht täusche, hatte ich es mal, dass er die letzten 30 Sekunden über 5 Minuten langsam runter gezählt hat (dafür lege ich aber lieber nicht die Hand ins feuer).

Du kannst in diesem Zusammenhang aber keine Autos mit den Stepper-Motoren vergleichen. Wenn ich einem Stepper Motor sage, drehe dich in 5 Sekunden 20mal, dann dreht er sich in 5 Sekunden 20 mal, egal ob er belastet wird oder nicht. Nimmst du das Auto, schafft es bei gleicher Stellung des Gaspedals in der Luft eine weitaus größere Strecke als bei normaler Fahrt auf Asphalt.

Was ich damit sage will ist, dass in der Software die Beschleunigung und das Abbremsen in der Zeitberechung berücksichtigt sein muss, wenn diese Befehle im G-Code stehen. Die Frage ist nur, ob man an den Parametern stellen kann, um die Zeit zu korrigieren. Ansonsten muss man die von dir vorgeschlagene Methode nehmen und aus den Erfahrungswerten die ermittelten 20% o.ä. draufschlagen.

 

[Digibike]

Habe zwar Simplify 3d, aber drucke wie gesagt nie über USB... Daher kann ich dazu nichts sagen...
Aber deine Aussage wiederspricht sich etwas für mich: Drehe dich 5 Sekunden 20 mal - wie nun? 20 mal oder 5 Sekunden?
Der Gcode gibt doch nur die Steps, in dem Fall also 20 aus. Die 5 Sekunden interessieren nur in Bezug auf die Dauer des Drucks
pro Schicht, da geb ich dir recht.. Wenn ich schneller fertig werde, soll er die verbleibende Zeit warten, aber ansonsten interessiert
es den Drucker doch gar nicht. Hat was damit zu tun, daß er nicht zu früh mit dem nächsten Layer anfängt, da er sonst in die
noch zu weiche Vorgängerschicht drucken würde... Um bei dem Vergleich Auto zu bleiben, wäre das so, als ob ich sagen würde,
fahre die 200 Km und sei genau in 1h und 2 min. da... - er kann es Theoretisch locker schaffen und müßte dann die verbleibenden
Rest sekunden am Ziel warten, vermutlich wird er aber nicht warten müssen... ;-)

Oder meinst du hier was ganz anderes?

 

[Rob_3D]

Der G-Code gibt die Entfernung und die Geschwindigkeit (man spricht auch von Vorschub) .
Beispiel:

G1 F600.000
G1 X90.234 Y90.234 E1.00437

G1 sagt, gehe in direkte Linie
F600.000 gibt die Vorschubgeschwindigkeit vor,
X90 Y90 sind die Zielkoordinaten
E1.00437 ist der Weg für den Filamentvorschub.

Die Beschleunigung auf die Geschwindigkeit F600 (600mm/minute) bestimmt die Firmeware auf dem Board des Druckers. Beim CTC kann ich die Parameter mit ReplicatorG anpassen. Sie werden ins EEPROM des Prozessors geschrieben. Ob jetzt die Stepper der Beschleunigung folgen können, hängt auch von dem Strom ab, den sie maximal bekommen. Diesen wiederum stellt man an den Stepper-Treibern (auch gerne Pololus genannt).

Natürlich kann man im G-Code eine Folge von Fxxxx absetzen und so die Beschleunigung beeinflussen. Aber das Maximum bestimmt das Board im Drucker, welches den G-Code umsetzt und die Motoren steuert.

Die Kommunikation läuft über eine serielle Schnittstelle, welche per USB emuliert wird. Wie jetzt die Übertragung genau abläuft, kann ich ahnen. Der Drucker wird vermutlich immer ein paar Befehle zwischen speichern. Firmware, wie Sailfisch, gucken im Code vorraus, was als nächstes kommt und können so die Beschleunigung etwas anpassen, damit der Drucker sich nicht zu sehr schüttelt, wenn der Kopf 90° um die Ecke fährt. Vermutlich läuft da ein Handshake, der dem PC mitteilt, wenn der Puffer voll ist und der PC wartet mit der Sendung, bis der Puffer wieder Platz bietet. Diese Lieferung bring aber die Motoren nicht aus dem Tritt.

 

[09er]

Oh es gibt wieder ein Update und jetzt gibt es auch endlich die direkt Drucken Funktion
Ich habe es zwar noch nicht geschafft mich zu verbinden aber hier mal ein Bild der Oberfläche
https://www.dropbox.com/s/j3o0dprngu55m8o/20140908_110859.jpg?dl=0

 

[Rob_3D]

Verbinden klappt, aber CraftWare spricht offensichtlich kein s3g, sondern nur GCODE mit dem Drucker. Das MightyBoard hat da eine andere "Sprache".

 

[09er]

Ah ok das kann sein bei mir steht zumindest immer warten im status naja kommt vielleicht noch Rom wurde ja auch nicht an einem Tag erbaut
Von der Oberfläche her haben die es ja recht schön gemacht ... mal abwarten was noch kommt

 

[Rob_3D]

Hier ist übrigens die Beschreibung des s3g-Protokoll: https://github.com/makerbot/s3g/blob/master/doc/s3gProtocol.md

 

[Freak]

Hat schon jemand erfolgreich mit dem Freesculpt EX1 und Craftware gedruckt?

danke

gruß Freak