Simplify3D und 0.91.48 verstehen sich NICHT

S3D ist ein sehr komplexer und für den RFx000 ausgelegter Slicer. Es können viele Einstellungen sogar auf Layerbereiche begrenzt, gemacht werden. Das Programm ist jedoch nicht kostenlos.
Benutzeravatar
gilby56
Gelegenheitsdrucker
Gelegenheitsdrucker
Beiträge: 20
Registriert: Di 30. Dez 2014, 15:43
Danksagung erhalten: 1 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #21 von gilby56 » Sa 10. Jan 2015, 19:15

Ahmm,

wie kannst Du denn mit den Tasten neben dem LCD Bildschirm die X- und Y- Wege verstellen. Da gibt es doch nur die Tasten für die Z-Achse, sowie für die Filamentzufuhr?
Oder habe ich da was falsch verstanden?

Gruß Gilbert

Benutzeravatar
Cyco
3D-Drucker
3D-Drucker
Beiträge: 79
Registriert: Do 18. Sep 2014, 18:10
Danksagung erhalten: 7 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #22 von Cyco » Sa 10. Jan 2015, 19:15

Holla Beta-Tester-Kollege - ähh shaddi, ;)

werde wohl auch erstmal wieder auf die 48er zurück-switchen und weiter die in S3d gesliceten Objekte über RepetierHost ausdrucken. Bin nur mal gespannt, wie lange dann wieder der HBS dauert...

Joe :popcorn:

Benutzeravatar
gilby56
Gelegenheitsdrucker
Gelegenheitsdrucker
Beiträge: 20
Registriert: Di 30. Dez 2014, 15:43
Danksagung erhalten: 1 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #23 von gilby56 » Sa 10. Jan 2015, 19:20

Alles klar, geht doch. Mein Unwissen!
Nichts für ungut.
Gilbert

Benutzeravatar
shaddi
3D-Drucker
3D-Drucker
Beiträge: 64
Registriert: Fr 7. Nov 2014, 13:18
Hat sich bedankt: 10 Mal
Danksagung erhalten: 4 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #24 von shaddi » Sa 10. Jan 2015, 19:43

Im Menue unter dem Punkt "Position" kann man alle Achsen per Tasten rumschieben :)

Neuste Erkenntnis: Wenn man die gleichen Kommandos per SD-Karte absetzt, passt alles perfekt. Denn auch die .48 schiebt das Bett zu nahe an die Oberfläche und darüber hinaus, wenn man per USB die Kommandos per Hand absetzt.

Bin jetzt wieder auf der .49, da damit die erste Schicht bei mir perfekt wird. Nur M3001 und der Druck per SD-Karte klappt super. Die erste Schicht ist perfekt 0.2mm dick, genau was im Gcode drin steht.

Lustigerweise ist im Conrad Repetier-Host in jeder Config die erste Schicht mit 0.35 angegeben, wo die .49 nur noch Delta-Angleichung macht und die echte Höhe dann sonstwo ist...

Wieso druckt ihr nicht per SD-Karte? Per USB wäre mir das immer viel zu riskant, dass da irgendwo die Kommunikation anfängt zu spinnen.

Benutzeravatar
gilby56
Gelegenheitsdrucker
Gelegenheitsdrucker
Beiträge: 20
Registriert: Di 30. Dez 2014, 15:43
Danksagung erhalten: 1 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #25 von gilby56 » Sa 10. Jan 2015, 21:26

Hi,
Ich drucke auch nur über die SD Karte, eben wegen der unsauberen Kommunikation.
Hatte mir den Z-Enschalter eben genau über USB Druck zerschossen, warum weiß ich auch nicht.
Gruß Gilbert

RF1000
Developer
Developer
Beiträge: 340
Registriert: Fr 10. Okt 2014, 16:31
Hat sich bedankt: 40 Mal
Danksagung erhalten: 78 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #26 von RF1000 » Di 13. Jan 2015, 09:01

Hallo shaddi,

Wenn ich jetzt im Menue per LCD und Tasten an den Positionen rumdrehe (X oder Y) fährt bei jedem Tastendruck die Z-Achse noch ein Stück nach oben. Hätte ich den Z-Schalter nicht schon ausgetauscht, wäre er jetzt definitiv ab.


Fährt das Heizbett tatsächlich immer nach oben oder fährt es auch nach unten (wenn du z.B. in y-Richtung nach hinten fährst und das Heizbett dabei nach oben korrigiert wird dann sollte es umgekehrt auch wieder nach unten korrigiert werden wenn du in y-Richtung die selbe Strecke zurück nach vorne fährst)? Die Bewegung in Z-Richtung nach jeder Bewegung in x- bzw. y-Richtung wäre ja erst einmal korrekt, weil der Abstand zwischen Heizbett und Extruder an jeder x/y-Position ein anderer ist. Wir konnten bis jetzt keinen Fall rekonstruieren, bei dem das Heizbett mit "deinen" Schritten immer nur nach oben gefahren wäre. Es ist uns auch nicht möglich einen Unterschied zwischen dem Senden der Kommandos vom Repetier-Host und dem Abarbeiten der Kommandos von der SD-Karte zu erkennen - was genau muss man da tun, um ein unterschiedliches Verhalten zu bekommen?

Bin jetzt wieder auf der .49, da damit die erste Schicht bei mir perfekt wird. Nur M3001 und der Druck per SD-Karte klappt super. Die erste Schicht ist perfekt 0.2mm dick, genau was im Gcode drin steht.

Lustigerweise ist im Conrad Repetier-Host in jeder Config die erste Schicht mit 0.35 angegeben, wo die .49 nur noch Delta-Angleichung macht und die echte Höhe dann sonstwo ist...


Wie meinst du das, dass "die echte Höhe dann sonstwo ist"? Die Höhe der ersten Schicht sollte so sein wie in deinem vorherigen Absatz beschrieben, nämlich exakt so wie es der G-Code will (unter der Annahme, dass M3006 S0 eingestellt ist, was ja der Defaultwert ist). Dazu kommt eventuell die Z-Kompensation, je nachdem ob die Höhe der 1. Schicht kleiner ist als HEAT_BED_Z_COMPENSATION_MIN_MM oder nicht.


mfG
RF1000

Benutzeravatar
shaddi
3D-Drucker
3D-Drucker
Beiträge: 64
Registriert: Fr 7. Nov 2014, 13:18
Hat sich bedankt: 10 Mal
Danksagung erhalten: 4 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #27 von shaddi » Di 13. Jan 2015, 15:01

RF1000 hat geschrieben:Fährt das Heizbett tatsächlich immer nach oben oder fährt es auch nach unten (wenn du z.B. in y-Richtung nach hinten fährst und das Heizbett dabei nach oben korrigiert wird dann sollte es umgekehrt auch wieder nach unten korrigiert werden wenn du in y-Richtung die selbe Strecke zurück nach vorne fährst)?


Er hat das nur gemacht, wenn ich davor die Z-Achse auf 0,2 mm eingestellt hatte.
Also: G28, M3001, G1 X100 Y100, G1 Z0.2 und dann per LCD und "Position-Menue" X oder Y verstellen. Bei jedem "klick" fuhr die Platte ein ganzes Stück hoch. Das selbe wenn ich statt den Tasten ein "G1 X110, G1 X100" gesendet hab.. nach jedem G1 fuhr die Z-Achse nur nach oben.

Ich habe die Sourcen noch nicht komplett verstanden, da die Z-Comp recht verstrickt im neuen .49 ist. (und ich eigentlich kein C kann :) )
Aber ich kann es mir nur so erklären, dass der Drucker irgend einen Timer hat und dann in einen "ich habe noch nichts getan" - Mode verfällt und dann den ursprünglichen Offset-Sprung aufs neue ausführt. Wenn man nämlich nur X und Y auf die Stelle fährt und dann NUR ein G1 Z0.2 macht, ist der Abstand in Wirklichkeit 0.5 (Abstand ab Z-Schalter-Trigger) + 0.2mm. Erst wenn man dann X oder Y verstellt, stringt er auf die genaue Z-Höhe. Die passt beim ersten Befehl dann auch perfekt!

RF1000 hat geschrieben: Es ist uns auch nicht möglich einen Unterschied zwischen dem Senden der Kommandos vom Repetier-Host und dem Abarbeiten der Kommandos von der SD-Karte zu erkennen - was genau muss man da tun, um ein unterschiedliches Verhalten zu bekommen?


Ich habe das ohne Software dazwischen gemacht. Direktes Terminal-Programm mit 25000 Baud und Zeilen-Nummern davor getippt.
Habe das auch per OctoPrint versucht (war mein erster Versuch) da der die Zeilnnummern und Checksummen gleich berechnet.

RF1000 hat geschrieben:Wie meinst du das, dass "die echte Höhe dann sonstwo ist"? Die Höhe der ersten Schicht sollte so sein wie in deinem vorherigen Absatz beschrieben, nämlich exakt so wie es der G-Code will (unter der Annahme, dass M3006 S0 eingestellt ist, was ja der Defaultwert ist).
Dazu kommt eventuell die Z-Kompensation, je nachdem ob die Höhe der 1. Schicht kleiner ist als HEAT_BED_Z_COMPENSATION_MIN_MM oder nicht.


Bei meinem letzten Versuch mit der .48 war der Abstand mit "M3001 und M3004 S0" in der ersten Schicht immer 0,5mm+(gcode-Z-Wert). Wahrscheinlich ein paar micrometer +-, weil das Delta hat er ja ausgeglichen. Ich habe dann nach einem Heatbed-Scan den Offset-Wert abgeschrieben und diesen dann ins M3004 Sxy" gekloppt. Dann hat er halbwegs geklappt. Allerdings ist meine Platte gefühlt eine Mondlandschaft und der Offset-Wert ist in der Mitte eine ganz andere... Also habe ich bei der ersten Schicht immer noch mit rauf runter nach-korrigiert...

Vielleicht mach ich auch was Grundsätzlich falsch. Die Anleitung ist da ja ein wenig dünn an der Stelle. Die Methode mit "Abstand auf Z-Schalter mit 0,50 mm zum Heatbed" habe ich gemacht. Aber den Schritt für die M3004-Angabe kann ich nicht machen, da man die Höhe nur bis maximal Z-Schalter machen kann und er dann nicht mehr weiter fahren lässt.

Schaut euch mal mein Heatbed als Grafik an.. Da kann ja nix draus werden, oder?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

RF1000
Developer
Developer
Beiträge: 340
Registriert: Fr 10. Okt 2014, 16:31
Hat sich bedankt: 40 Mal
Danksagung erhalten: 78 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #28 von RF1000 » Mi 14. Jan 2015, 07:36

Hallo shaddi,


Schaut euch mal mein Heatbed als Grafik an.. Da kann ja nix draus werden, oder?


Welche Einheit wird bei deiner Grafik angezeigt? Der maximale Unterschied ist "500", bei 32 Mikrosteps wären das in bei 500 [Steps] also ca. 0,2 mm - das sollte für die Z-Kompensation kein Problem darstellen. Auch wenn das 500 [µm] wären sollte die Z-Kompensation damit zurecht kommen. 500 [mm] wäre natürlich ein paar Ticks zuviel, aber diese Einheit halte ich für extrem unwahrscheinlich :-)

Ich denke wir konnten das mehrfache Anwenden des Z-Kompensationswertes jetzt reproduzieren und habe es auch schon gelöst - wenn die entsprechenden Tests bei uns erfolgreich verlaufen dann sollte es sehr bald eine V 0.91.51 geben welche dieses Verhalten korrigiert. Im "normalen Betrieb" (d.h. beim Drucken der G-Code Kommandos entweder vom PC oder von der SD-Karte) sollte dieses Verhalten unserer Erkenntnissen nach übrigens nicht auftreten, man muss die G-Codes einzeln und mit etwas zeitlichem Abstand absenden um dieses Verhalten zu bekommen.


mfG
RF1000

Benutzeravatar
shaddi
3D-Drucker
3D-Drucker
Beiträge: 64
Registriert: Fr 7. Nov 2014, 13:18
Hat sich bedankt: 10 Mal
Danksagung erhalten: 4 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #29 von shaddi » Mi 14. Jan 2015, 08:50

genial, danke!!!

RF1000 hat geschrieben:Welche Einheit wird bei deiner Grafik angezeigt? Der maximale Unterschied ist "500", bei 32 Mikrosteps wären das in bei 500 [Steps] also ca. 0,2 mm - das sollte für die Z-Kompensation kein Problem darstellen. Auch wenn das 500 [µm] wären sollte die Z-Kompensation damit zurecht kommen. 500 [mm] wäre natürlich ein paar Ticks zuviel, aber diese Einheit halte ich für extrem unwahrscheinlich :-)


das waren die Zahlen aus dem Heatbed-scan mit der .48er Firmware. Da waren die Microsteps glaube ich noch nicht reingerechnet.
sollte also glaube ich Faktor "642" sein, oder? 500 sollten also 0,78mm sein, ca?

Ich habe mal ein aktuelles Bild mit dem Scan der .49er Firmware mit angehängt. Da sind die Werte entsprechend höher.

RF1000 hat geschrieben:Ich denke wir konnten das mehrfache Anwenden des Z-Kompensationswertes jetzt reproduzieren und habe es auch schon gelöst - wenn die entsprechenden Tests bei uns erfolgreich verlaufen dann sollte es sehr bald eine V 0.91.51 geben welche dieses Verhalten korrigiert. Im "normalen Betrieb" (d.h. beim Drucken der G-Code Kommandos entweder vom PC oder von der SD-Karte) sollte dieses Verhalten unserer Erkenntnissen nach übrigens nicht auftreten, man muss die G-Codes einzeln und mit etwas zeitlichem Abstand absenden um dieses Verhalten zu bekommen.


genial! Dann waren meine Beobachtungen doch nicht falsch. Wollte das heute Abend schon wiederholen :) Woran lag es? Ach, ich werde es dann in den Sourcen schon sehen... :)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

RF1000
Developer
Developer
Beiträge: 340
Registriert: Fr 10. Okt 2014, 16:31
Hat sich bedankt: 40 Mal
Danksagung erhalten: 78 Mal

Re: Simplify3D und 0.91.48 verstehen sich NICHT

Beitrag #30 von RF1000 » Mi 14. Jan 2015, 14:05

Hallo shaddi,


ich denke dass auch dein neues Bild in etwa eine Differenz von 500 anzeigt. Mit 32 Mikrosteps bleiben das also 0,2 mm, was für die Z-Kompensation kein Problem darstellt.

Das von dir beobachtete mehrfache hochfahren in Z-Richtung ist daher gekommen, dass die Anweisung TASK_INIT_Z_COMPENSATION unter Umständen (= wenn sehr viel Zeit zwischen den eingegebenen G-Codes vergangen ist, wie z.B. bei der manuellen Eingabe der G-Codes) mehrfach ausgeführt werden konnte.

Das ist nun in der V 0.91.51 korrigiert, die sich ab sofort auf GitHub findet.


mfG
RF1000


Zurück zu „Simplify 3D“