Extruderzahnräder ...
Manuel Dejonghe
u.g. Passage in der Mail von Dominik [Allerlei Software] hat mich
wachgerüttelt, ich muss dazu mal ganz dringend was schreiben:
2011/12/14 Dominik Schlütter <schl...@gmx.net>:
> Generell kann ich nur empfehlen, sich auch noch mal das "Dimension"-Plugin anzusehen. IMHO stimmt da irgendwas mit unseren Vorgaben beim Extruder nicht, ich muss nämlich bei einem Filament-Durchmesser von 3 mm den Faktor zur "Filament Packing Density" irgendwo bei 0.7 bis 0.8 einstellen. Ansonsten wird zu wenig Material extrudiert (das ist bei anderen Slicern ähnlich, dazu später mehr).
Die Packing Density sollte eigentlich nur ein Faktor sein, der sich
von Kunststofftyp zu Kunststofftyp verändert, weil sich aufgrund der
unterschiedlichen Härten die Extruder-Förderschraube unterschiedlich
tief in das Filament eingräbt, damit also genaugenommen
unterschiedliche Durchmesser/Radien für die Berechnungsgrundlage der
Vorschubgeschwindigkeit verwendet werden.
Am Wochenende ist allerdings ein ziemlich wichtige Sache (leider für
mich persönlich/privat nicht dringend genug) auf meine TODO-Liste
gekommen. Und zwar ist mir aufgefallen, dass es Unterschiede gibt,
sowohl im Durchmesser als auch in der Anzahl Zähne zwischen den
Extrudern des ersten Workshops und den Extrudern des zweiten
Workshops.
Ich muss mir das Thema mal genauer anschauen, aber wenn das in derart
geändert ist, dass sich die Übersetzung des Antriebs geändert hat, ist
das selbstverständlich Ursache dafür, dass die Teilnehmer des zweiten
Workshops hier am Packing Density Faktor schrauben müssen, damit die
Kalibrierung auf die Firmware (Sprinter, im Arduino Mega) passt.
Das können wir ja heute Abend uns mal genauer anschauen, da haben wir
ja auch vielleicht einen Maschbauer am Start, der da solide im Thema
steht.
Wenn ich das richtig in Erinnerung habe, zählt das kleine Antriebsrad
in beiden Fällen 12 Zähne, das große Zahnrad hatte "früher" 39 Zähne,
heute 42. Ein kleiner, subtiler Unterschied. Das "neue" große Zahnrad
ist aber auch im Durchmesser größer. Das macht meines Wissens aber -
wenn ich nicht völlig auf dem Schlauch stehe - den Fehler nicht wett.
Sehen wir heute Abend.
Die korrekteste Methode, diese Fehler dann auszubügeln wäre
allerdings, den Wert in der Firmware zu korrigieren, was zur Folge
hätte, dass sich jeder Teilnehmer des zweiten Workshops (sofern er
nicht vorbeikommen kann) sich jetzt mal damit auseinandersetzen muss,
Sprinter selber im Arduino zu konfigurieren und aufzuspielen. Das
wollte ich eigentlich so lange wie möglich rauszögern.
(Ich frage mich bis dahin dann nur noch, wie man auf das schmale Brett
kommen kann, solche Parameter so subtil zu verändern. Was war denn so
verkehrt an der "alten" Übersetzung? Muss hier in dem Umfeld jeder
alles selber machen ?)
ciao, Manuel
Manuel Dejonghe
2011/12/14 Manuel Dejonghe <man...@dejonghe.de>:
> Wenn ich das richtig in Erinnerung habe, zählt das kleine Antriebsrad
> in beiden Fällen 12 Zähne, das große Zahnrad hatte "früher" 39 Zähne,
> heute 42. Ein kleiner, subtiler Unterschied. Das "neue" große Zahnrad
> ist aber auch im Durchmesser größer. Das macht meines Wissens aber -
> wenn ich nicht völlig auf dem Schlauch stehe - den Fehler nicht wett.
> Sehen wir heute Abend.
>
> Die korrekteste Methode, diese Fehler dann auszubügeln wäre
> allerdings, den Wert in der Firmware zu korrigieren, was zur Folge
> hätte, dass sich jeder Teilnehmer des zweiten Workshops (sofern er
> nicht vorbeikommen kann) sich jetzt mal damit auseinandersetzen muss,
> Sprinter selber im Arduino zu konfigurieren und aufzuspielen. Das
> wollte ich eigentlich so lange wie möglich rauszögern.
Also, wie erwartet, wurde die These, das da etwas faul ist, nicht
widerlegt. Ich habe Euch mit dem Aufspielen der Firmware während des
Workshops einen Bärendienst erwiesen, weil die Kalibrierung der
E-Achse nur auf mein Zahnrad passt. Zum Glück ist mir aber noch eine
einfache Lösung für das Problem eingefallen.
Lösungen für das Problem gibt es nun mehrere:
- das alte Zahnrad wieder einbauen. Ist aber eher die Low-Tech-Lösung.
Ausserdem weiss ich nicht, wo ich das alte STL noch herbekommen
sollte.
- wie Dominik den Filament Density Factor im Skeinforge "missbrauchen"
um wieder auf das richtige Maß zu kommen.
- den Wert in der Konfiguration der Firmware anpassen und neu
einspielen. Damit machen wir hier ein neues Thema auf, was wir bisher
bewusst umgangen haben. Nicht um geizig mit Wissen umzugehen, sondern
um die Anzahl Einstellschrauben überschaubar zu halten.
- Den Wert per GCode-Anweisung umdefinieren.
Das mag nun für manche der Zeitpunkt sein, an dem man sich "endlich"
mit Arduino etc. auseinandersetzt. Das ist aber ein dickes Brett, und
das möchte und kann ich jetzt nicht mal eben so im vorbeigehen
abreissen. Für die, die sich auskennen, kommen hier ein paar harte
Informationen: Firmware kommt von https://github.com/kliment/Sprinter
ist aber selbstverständlich inzwischen weiterentwickelt worden. Von
der Configuration.h des Workshops habe ich inzwischen leider zwei
Versionen hier rumfliegen, die sich aber nur in den Richtungen der
Achsen X und E unterscheiden. Wer mir da mal gesicherte Informationen
mit einem echten Modell Workshop 2 liefern kann, ist gerne willkommen
:)
Die Configuration.h liegt nun sowohl im Read-Only bereich meiner
Dropbox als auch hier im Anhang:
http://dl.dropbox.com/u/18246311/Configuration_mail.h
http://dl.dropbox.com/u/18246311/Configuration_dropbox.h
Hier muss man in der folgenden Zeile den letzten Wert anpassen:
float axis_steps_per_unit[] = {80.376, 80.376, 3200/1.25, 33*16};
Zur oben genannten korrektesten Methode ist mir noch eine einfache
Alternative eingefallen: Bei Sprinter kann man diese Konfigurationen
temporär per GCode-Anweisung ändern, die gilt dann bis zum nächsten
Start der Elektronik (wenn also sowohl Strom als auch USB mal nicht
angeschlossen sind). Wenn man also nun den neuen Wert in die
start.gcode bzw. startMendel05l04PLA.gcode einträgt, kann man
gleichzeitig den getürkten Filament Packing Density wieder
zurücksetzen (0.85 für ABS und 1.0 für PLA) und die neu erstellten
GCodes funktionieren direkt wieder. Man sollte aber nach einem Druck
mit neuen Einstellungen nicht versuchen, ein altes GCode zu drucken.
Dieses würde ja nicht den Wert zurücksetzen. Da müsste man dann die
Elektronik mal neu starten, oder resetten mit dem Taster.
Diese Zeile wäre dann "M92 E528", wobei der Wert hier ja nur die auch
o.a. 33*16 darstellt, zur Berechnung kommen wir noch:
Im ersten Workshop wurde mit 39/11 Zähnen gearbeitet, das ist eine
Übersetzung von 3,54. Im zweiten Workshop sind das dann 42/10, also
4,2.
Wie wir im ersten Workshop auf den Wert 33*16 gekommen sind, kann man
hier nachlesen:
Ich wills kurz machen: Der neue Wert ist nun 39*16, also 629.
Entweder wäre also ins start-gcode M92 E629 einzutragen, oder aber der
Wert für E in der axis_steps_per_unit auf 39*16 zu setzen.
Viel Spaß,
Manuel
Manuel Dejonghe
> Im ersten Workshop wurde mit 39/11 Zähnen gearbeitet, das ist eine
> Übersetzung von 3,54. Im zweiten Workshop sind das dann 42/10, also
> 4,2.
> Wie wir im ersten Workshop auf den Wert 33*16 gekommen sind, kann man
> hier nachlesen:
>
> https://groups.google.com/group/ACPrusaMendel/browse_frm/thread/e766079a6a90ca0f/0851807bf156db94?lnk=gst&q=umfang#0851807bf156db94
>
> Ich wills kurz machen: Der neue Wert ist nun 39*16, also 629.
> Entweder wäre also ins start-gcode M92 E629 einzutragen, oder aber der
> Wert für E in der axis_steps_per_unit auf 39*16 zu setzen.
Ohmann.
Ich habe gestern Abend versucht, meinen Drucker mal flott auf die
Zahnräder des zweiten Workshops umzubauen, hat ja nur Vorteile. Geht
aber leider nicht, weil das neue Zahnrad (wie berichtet) auch im
Durchmesser größer ist (wo sonst sollen die zusätzlichen Zähne hin),
und damit ist es so groß, dass ich es gar nicht aufschieben kann, es
schlägt unten an den X-Carriage. Ich muss mir also erstmal einen neuen
Extruder Block ausdrucken, bevor ich das Zahnrad aufschieben kann.
Es wird also möglicherweise bis ins neue Jahr dauern, ehe ich den oben
genannten Wert selber überprüfen kann. Könnte mal bitte ein Teilnehmer
des zweiten Workshops nachzählen, wieviele Zähne wirklich an Euren
Zahnrädern des Extruders dran sind, damit wir sicher sein können, dass
ich auch die richtigen Dateien als Rechengrundlage hatte ?
danke, Manuel
heimadresse
also die Z�hnezahl an dem gro�en Zahnrad des Extruders vom zweiten Workshop
betr�t 43.
Die Z�hnezahl des Zahnrades am Schrittmotor betr�gt 10.
Das verwendetet Configuration.h vom zweiten Workshop h�ngt hier mit dran.
Wenn du mehr Info brauchst, dann lasse es mich wissen.
Gru�
Thomas Weidisch
----- Original Message -----
From: "Manuel Dejonghe" <man...@dejonghe.de>
To: "ACPrusaMendel" <ACPrus...@googlegroups.com>
Sent: Friday, December 16, 2011 1:09 PM
Subject: [ACPrusaMendel] Re: Extruderzahnr�der ...
2011/12/16 Manuel Dejonghe <man...@dejonghe.de>:
> Im ersten Workshop wurde mit 39/11 Z�hnen gearbeitet, das ist eine
> �bersetzung von 3,54. Im zweiten Workshop sind das dann 42/10, also
> 4,2.
> Wie wir im ersten Workshop auf den Wert 33*16 gekommen sind, kann man
> hier nachlesen:
>
> https://groups.google.com/group/ACPrusaMendel/browse_frm/thread/e766079a6a90ca0f/0851807bf156db94?lnk=gst&q=umfang#0851807bf156db94
>
> Ich wills kurz machen: Der neue Wert ist nun 39*16, also 629.
> Entweder w�re also ins start-gcode M92 E629 einzutragen, oder aber der
> Wert f�r E in der axis_steps_per_unit auf 39*16 zu setzen.
Ohmann.
Ich habe gestern Abend versucht, meinen Drucker mal flott auf die
Zahnr�der des zweiten Workshops umzubauen, hat ja nur Vorteile. Geht
aber leider nicht, weil das neue Zahnrad (wie berichtet) auch im
Durchmesser gr��er ist (wo sonst sollen die zus�tzlichen Z�hne hin),
und damit ist es so gro�, dass ich es gar nicht aufschieben kann, es
schl�gt unten an den X-Carriage. Ich muss mir also erstmal einen neuen
Extruder Block ausdrucken, bevor ich das Zahnrad aufschieben kann.
Es wird also m�glicherweise bis ins neue Jahr dauern, ehe ich den oben
genannten Wert selber �berpr�fen kann. K�nnte mal bitte ein Teilnehmer
des zweiten Workshops nachz�hlen, wieviele Z�hne wirklich an Euren
Zahnr�dern des Extruders dran sind, damit wir sicher sein k�nnen, dass
Manuel Dejonghe
Dank an Thomas für die Überprüfung (und damit Verhinderung von noch
schlimmerer Verwirrung)!
2011/12/16 heimadresse <heima...@t-online.de>:
> also die Zähnezahl an dem großen Zahnrad des Extruders vom zweiten Workshop
> beträt 43.
Klasse. Dann hab ich Torfnase mich also sogar noch verzählt...
Ich habe nun nochmal überprüft, das Zahnrad, auf das ich umrüsten
wollte hat ebenfalls 43 Zähne, es *ist* also die richtige Datei.
> Die Zähnezahl des Zahnrades am Schrittmotor beträgt 10.
Damit ist also meine vorherige Berechnung verkehrt.
Richtig wäre nun: 644 Mikroschritte (im 16tel) pro Millimeter.
Also "M92 E629" bzw. "float axis_steps_per_unit[] = {80.376, 80.376,
3200/1.25, 40.2527*16};"
> Das verwendetet Configuration.h vom zweiten Workshop hängt hier mit dran.
Okay, liegt nun hier:
http://dl.dropbox.com/u/18246311/Configuration_thomas.h
Sorry für die Verwirrungen :/
ciao, Manuel
> ----- Original Message ----- From: "Manuel Dejonghe" <man...@dejonghe.de>
> To: "ACPrusaMendel" <ACPrus...@googlegroups.com>
> Sent: Friday, December 16, 2011 1:09 PM
> Subject: [ACPrusaMendel] Re: Extruderzahnräder ...
>
>
>
> 2011/12/16 Manuel Dejonghe <man...@dejonghe.de>:
>>
>> Im ersten Workshop wurde mit 39/11 Zähnen gearbeitet, das ist eine
>> Übersetzung von 3,54. Im zweiten Workshop sind das dann 42/10, also
>> 4,2.
>> Wie wir im ersten Workshop auf den Wert 33*16 gekommen sind, kann man
>> hier nachlesen:
>>
>>
>> https://groups.google.com/group/ACPrusaMendel/browse_frm/thread/e766079a6a90ca0f/0851807bf156db94?lnk=gst&q=umfang#0851807bf156db94
>>
>> Ich wills kurz machen: Der neue Wert ist nun 39*16, also 629.
>> Entweder wäre also ins start-gcode M92 E629 einzutragen, oder aber der
>> Wert für E in der axis_steps_per_unit auf 39*16 zu setzen.
>
> Es wird also möglicherweise bis ins neue Jahr dauern, ehe ich den oben
> genannten Wert selber überprüfen kann. Könnte mal bitte ein Teilnehmer
> des zweiten Workshops nachzählen, wieviele Zähne wirklich an Euren
> Zahnrädern des Extruders dran sind, damit wir sicher sein können, dass
Verse, Stefan
Tel.: 01781979799
Stefan Verse
> -----Ursprüngliche Nachricht-----
> Von: acprus...@googlegroups.com
> [mailto:acprus...@googlegroups.com] Im Auftrag von Manuel Dejonghe
> Gesendet: Freitag, 16. Dezember 2011 13:10
> An: ACPrusaMendel
> Betreff: [ACPrusaMendel] Re: Extruderzahnräder ...
Verse, Stefan
habe mir hier gerade mal den Reprap-Host installiert und gestartet, das lief erstmal einwandfrei.
Auch mehrfacher Neustart. Dann habe ich die Schnittstelle auf COM1 geändert und mal neu gestartet, jetzt geht aber gar nichts mehr. Der Raprap-Java-Teil versucht anscheinend Kontakt zum Reprap aufzunehmen (zumindest flitzt was über die Schnittstelle), aber in Ermangelung der Elektronik, wird nichts gefunden und das Programm hängt sich auf. Weiß jemand, wo die Programmparameter abgelegt werden ? Registry ? File ?
Gruß,
Stefan
Dominik Schlütter
Am 05.01.2012 schrieb Verse, Stefan:
> habe mir hier gerade mal den Reprap-Host installiert und gestartet, das lief erstmal einwandfrei.
Warum macht man sowas?
> Auch mehrfacher Neustart. Dann habe ich die Schnittstelle auf COM1 geändert und mal neu gestartet, jetzt geht aber gar nichts mehr. Der Raprap-Java-Teil versucht anscheinend Kontakt zum Reprap aufzunehmen (zumindest flitzt was über die Schnittstelle), aber in Ermangelung der Elektronik, wird nichts gefunden und das Programm hängt sich auf.
Ich kann dir leider zu deinem konkreten Problem nix sagen - aber brauchst du die Software wirklich (und wenn ja, wozu)? In der Regel klappt das mit Printrun/Pronterface wesentlich besser, das wird auch regelmäßig aktualisiert und verbessert.
Gruß,
Dominik.
Verse, Stefan
das war nur Testweise - ich baue ja hier an einer eigenen Elektronik für den Reprap. Das ist jetzt soweit, das ich ans Testen komme.
Das Board hat auch Ethernet-Anschluß, und ich dachte ich mache mal nen Tool um die Controlsoftware an eine VCOM anzuschließen und das dann per UDP weiterzuleiten. Deswegen erste Versuche, wie sich so eine Software mit dem Interface verträgt.
Habe das Problem mit der Reprap-Hostsoftware selbst rausgefunden.
Werde mal Printrun/Pronterface daraufhin testen.
Ich habe mal com0com installiert, das macht nen Tunnel zwischen 2 VCOM-Interfaces. Mit meiner Applikation konnte ich immerhin die Kommandocodes von ReprapHost bekommen und per UDP weiterschicken. Antworten gibt es halt noch keine. Das Board kann dann per Serial, USB und Ethernet gesteuert werden.
Gruß,
Stefan
________________________________
Manuel Dejonghe
2012/1/5 Verse, Stefan <ve...@amo.de>:
> das war nur Testweise - ich baue ja hier an einer eigenen Elektronik für den Reprap.
Auf einem dorkbot-Treffen ist ab und zu jemand, der einen Sells Mendel
hat, der den auch mit dem RepRap-Host betreibt, er meinte aber "ich
glaube ordentlich funktioniert der RepRap-Host nur im Umkreis von
Bath" (der Uni, wo RepRap geschaffen wurde)
Das ist jetzt soweit, das ich ans Testen komme.
> Das Board hat auch Ethernet-Anschluß, und ich dachte ich mache mal nen Tool um die Controlsoftware an eine VCOM anzuschließen und das dann per UDP weiterzuleiten. Deswegen erste Versuche, wie sich so eine Software mit dem Interface verträgt.
> Habe das Problem mit der Reprap-Hostsoftware selbst rausgefunden.
> Werde mal Printrun/Pronterface daraufhin testen.
Schwer empfohlen, ja. Oder wenn das aus irgendeinem Grund nicht auf
Anhieb funktioniert kannst Du auch den ReplicatorG ausprobieren, den
Du unter replicat.org bekommst.
>
> Ich habe mal com0com installiert, das macht nen Tunnel zwischen 2 VCOM-Interfaces.
Uh, com0com klingt interessant, werde ich mal ausprobieren müssen, aus
ganz anderen Gründen :)
> Mit meiner Applikation konnte ich immerhin die Kommandocodes von ReprapHost bekommen und per UDP weiterschicken. Antworten gibt es halt noch keine. Das Board kann dann per Serial, USB und Ethernet gesteuert werden.
Das klingt sehr vielseitig :)
ciao, Manuel
René Bohne
Du weisst aber schon, dass Du am Ende einen eigenen Slicer (Ersatz für
Skeinforge) schreiben musst und einen neuen RepRap Client, der
pronterface ersetzt? Du schreibst ja eh eine echte Firmware, da sollte
auch echte Software auf dem PC mit ihr sprechen... und com0com ist
sicher nur ein erster Test, Du willst später Deinen Client und den 3D-
Drucker via UDP kommunizieren lassen, richtig?
Denn auch wenn pronterface hier sehr gelobt wird und technisch gesehen
scheinbar den Job erledigt ist das noch keine Software für den
täglichen Einsatz. Der RepRap Client gefällt mir eigentlich sehr gut,
aber er hat ähnlich wie ReplicatorG ein paar Schwierigkeiten, die
einem ebenfalls den Spaß verderben.
Kannst Du vielleicht nur fürs Protokoll mal notieren, was Du am RepRap
Client umstellen musstest, damit Dein ursprüngliches Problem gelöst
war?
Gruß,
René
Verse, Stefan
siehe unten.
Gruß,
Stefan Verse
> -----Ursprüngliche Nachricht-----
> Von: acprus...@googlegroups.com
> [mailto:acprus...@googlegroups.com] Im Auftrag von René Bohne
> Gesendet: Montag, 9. Januar 2012 17:13
> An: ACPrusaMendel
> Betreff: [ACPrusaMendel] Re: Hilfeeeee
>
> Hallo Stefan,
>
> Du weisst aber schon, dass Du am Ende einen eigenen Slicer (Ersatz für
> Skeinforge) schreiben musst und einen neuen RepRap Client, der
> pronterface ersetzt? Du schreibst ja eh eine echte Firmware, da sollte
> auch echte Software auf dem PC mit ihr sprechen... und com0com ist
> sicher nur ein erster Test, Du willst später Deinen Client und den 3D-
> Drucker via UDP kommunizieren lassen, richtig?
Nee, gerade das will ich erst mal nicht, ich kann ja nicht die ganze Welt im Alleingang neu machen. Ich habe jetzt erst mal einen Serial->UDP mapper (via com0com), damit kommen alle G-Codes von Pronterface bei mir an, sei es über serielle, USB-seriell oder UDP-Seriell.
Man könnte natürlich Pronterface direkt mit einem UDP-Interface erweitern, aber G-Code ist erstmal so anspruchslos, dass ich da nicht viel gewinne. Erstmal geht es darum, dass überhaupt etwas ankommt. Ich möchte letzten Endes nicht mit einem völlig proprietären Format mit dem Printer reden, das halte ich für eine Sackgasse. G-Code ist eigentlich ganz ordentlich dafür, wenn es richtig eingesetzt wird. Das Problem liegt vermutlich darin, dass alle Modelle in STL gespeichert werden und STL nur Dreiecke kennt. Openscad müsste direkt G-Code herausgeben können, inklusive Kreisen.
>
> Denn auch wenn pronterface hier sehr gelobt wird und technisch gesehen
> scheinbar den Job erledigt ist das noch keine Software für den
> täglichen Einsatz. Der RepRap Client gefällt mir eigentlich sehr gut,
> aber er hat ähnlich wie ReplicatorG ein paar Schwierigkeiten, die
> einem ebenfalls den Spaß verderben.
Die Macken habe ich noch nicht gesehen :-)
Pronterface ist aber ziemlich schlicht vom Maschinenprotokoll, dass es wirklich besser sein könnte - liegt aber auch an der Firmware.
Das Protokoll ist nicht abgesichert, verlorene G-Codes können nicht detektiert werden usw.
Aber alles selber neu machen, dazu habe ich die Zeit nicht.
>
> Kannst Du vielleicht nur fürs Protokoll mal notieren, was Du am RepRap
> Client umstellen musstest, damit Dein ursprüngliches Problem gelöst
> war?
Der Reprap Client speichert seine ini-Daten im User-Verzeichnis. Das Problem bei mir war, dass der Reprap eingefroren war, wenn man eine falsche Schnittstelle ausgewählt hatte (der hat versucht sich an den Printer zu connecten), aber deshalb konnte man in der Oberfläche die Einstellung nicht mehr rückgängig machen, sondern nur über die INI-Datei.
René Bohne
Wir haben openSCAD bereits mit VisiCut verheiratet. VisiCut ist zwar
eigentlich nur für Lasercutter entworfen worden, aber auch da mache
ich persönlich alles mit openSCAD. Deshalb mal ein Zitat vom Thomas,
der VisiCut entwickelt:
Dank dem neuen Command Line Interface (probier open
/path/to/VisiCut.app --args -h) kann man jetzt auch lustige sachen
machen, wie direkt von openSCAD lasern (open /path/to/openSCAD.app
- --args -o /tmp/tmp.dxf InputFile.scad && open /path/to/VisiCut.app
- --args --mapping Cut --execute)
Auch der FabScan wird gerade mit openSCAD verheiratet: die PointCloud,
die der 3D-Scanner erzeugt, wird als polyhedron in openSCAD angelegt.
Nun müsste man tief in die openSCAD Sourcen abtauchen und da vor allem
zwei Dinge tun: bei Objekten, die bereits Kreise kennen diese im 3D-
Format auch erhalten bevor man mit dem Slicing anfängt und bei allen
Objekten, die nicht mit openSCAD erzeugt wurden (Punktwolken, STL
Dateien) müssen Kreise usw. erst sinnvoll erkannt werden. Dann müsste
ein Slicer in openSCAD integriert werden, aber das dürfte gar nicht
sooo schwer sein, da ja bereits die 2D Projektion mit und ohne cut
bereits implementiert ist und ich so bereits slices im dxf Format
abgespeichert habe.
Und dann wieder zurück zu VisiCut: das erzeugt auch GCode... also ist
ja eigentlich alles fertig, denn wir können aus openSCAD slices im dxf
Format exportieren und diese mit VisiCut öffnen und damit wiederum
GCode erzeugen - bisher nur für die Mantis im 2D-Modus, aber den Code
haben wir voll unter Kontrolle und da wäre es doch ein Leichtes wenn
wir es auf 3D anheben würden... ich rede mit meinen Studenten sobald
ich aus dem Urlaub zurück bin.
Wer dazu noch gute Ideen hat darf sich gerne einbringen :)
Dominik Schlütter
Am 09.01.2012 schrieb René Bohne:
> "Openscad müsste direkt G-Code herausgeben können, inklusive Kreisen."
> genau das ist auch meine Meinung.
Das ist zwar spannend, noch besser fänd' ich aber einen Slicer, der auch "bessere" Formate als STL kennt. Diesen Wunsch gibts auch bei anderen Reprappern (die mit Maschinenbauhintergrund wollen z.B. IGES). Auch die Architekten möchten ihren aktuellen Workflow in der Regel nicht aufgeben und trotzdem saubere Kreise drucken.
> Nun müsste man tief in die openSCAD Sourcen abtauchen und da vor allem zwei Dinge tun: bei Objekten, die bereits Kreise kennen diese im 3D-Format auch erhalten bevor man mit dem Slicing anfängt und bei allen Objekten, die nicht mit openSCAD erzeugt wurden (Punktwolken, STL Dateien) müssen Kreise usw. erst sinnvoll erkannt werden. Dann müsste ein Slicer in openSCAD integriert werden, aber das dürfte gar nicht sooo schwer sein, da ja bereits die 2D Projektion mit und ohne cut bereits implementiert ist und ich so bereits slices im dxf Format abgespeichert habe.
Es gibt ja schon "Kreiserkenner" wie z.B. in Slic3r oder in der Marlin-Firmware (die ja inzwischen auch G-Code-Kreise kennt). Ganz generell wäre es spannend, wenn man den Schritt vom Slicen zum G-Code separat ansteuern könnte - es gibt ja diverse Programme, die z.B. auch Schichten ausgeben kann (Autodesk bastelt da gerade wieder was "anfängerfreundliches" <http://www.123dapp.com/make>).
Gruß,
Dominik.
Manuel Dejonghe
ich antworte Dir mal über die Liste, das macht mehr Sinn, das sind ja
durchaus Informationen, die von generellem Interesse sein können.
2012/1/19 Axel Ganz <ga...@polare.de>:
> Tatsächlich haben wir, warum auch immer, keinen Temperaturfühler zu unserem
> Heatpad bekommen.
> Kannst du mir erklären, was für ein Thermostat wir benötigen, wo man diesen
> kaufen kann,
Nee, Thermostat ist was anderes. Was Du brauchst ist ein Thermistor.
Das ist wie ein Widerstand, dessen Wert aber von der Temperatur
abhängt, leider nicht ganz linear.
Im Workshop hatten wir einen 100K-Thermistor (100 kilo-Ohm). Am besten
wäre es, dass Du doch noch genau den gleichen bekommst, damit die
Tabelle in Deiner Firmware auch passt. Ich werde da mal sehen, was
sich vielleicht machen lässt.
Ansonsten sind die Thermistoren so in der Preisspanne von 2-10 Euro
erhältlich, u.A. bei folgenden Anbietern:
http://www.reprapsource.com/en/show/6174
https://shop.grrf.de/thermistor-ntc100kohm-p-310.html
> und wie bzw. wo das Teil dann anzuschließen ist?
Anzuschließen sind diese zwei Drähte von dem Thermistor dann an T1,
gleich neben dem Anschluß vom Temperatursensor des HotEnds (T0)
ciao, Manuel
Axel Ganz
ich danke dir für die schnelle Antwort.
Ich bestelle mir einfach einen Thermistor bei reprasource.
Viele Grüße
Axel
Manuel Dejonghe
wie schonmal gesagt (inzwischen nervt es leider ein bisschen) solltest
Du diese Fragen besser an die Liste schreiben, wie nun geschehen.
Ich selber habe da, wie Du siehst, momentan nicht so die Zeit zu.
danke, Manuel
On Tue, Feb 14, 2012 at 2:11 PM, Axel Ganz <ga...@polare.de> wrote:
> Hallo Manuel,
>
> ich habe den 100K-Thermistor inzwischen gekauft.
> Wegen dessen Installation und noch wegen ein paar Fragen zur
> Softwareansteuerung,
> wollte ich dich fragen, ob du vielleicht noch mal Zeit hättest für ein
> Fernwartungsgespräch via Skype.
> Du hattest das ja mal vor einiger Zeit vorgeschlagen.
>
> Ginge es bei dir vielleicht am nächsten Mittwoch, 22.02. ab 19:00 Uhr oder
> etwas später?
> Wenn nicht, du aber zu einem anderen Zeitpunkt könntest,
> möchte ich dich bitten selbst einen Terminvorschlag zu machen.
>
> Viele Grüße aus Düsseldorf
> Axel