Page 1 of 1

Printrbot: starting gcode and y-axis issues

Posted: Sun Aug 07, 2016 5:02 pm
by andyelder
Hey all,

Just purchased Simplify3D today, and am so glad that I did! My first print cleaned up a number of issues I was having with Slic3r and Cura, and that's without changing any default settings!

I am using a Printrbot Simple Metal, and after reading the forums here, it appears that it is necessary to change some of the starting gcode. This seems necessary, because as the Printrbot runs through this initial gcode, it tries to run the Y-axis off of the front end of my printer. See video below at 0:29

https://www.youtube.com/watch?v=uxouCY4oHfY

Here are the first 20 or so lines from my gcode:

G90
M82
M106 S0
M104 S200 T0
M104 S0 T1
M109 S200 T0
G28 x0 y0; home X/Y axes
G28 z0 ; home Z axis
G29 ; probe Z
G92 E0
G1 E-1.0000 F1800
G1 Z0.180 F1000
; layer 1, Z = 0.18
T0
; tool H0.200 W0.400
; skirt
G1 X47.675 Y25.251 F3600
G1 E0.0000 F540
G92 E0
G1 X47.685 Y25.236 E0.0006 F1500
G1 X48.275 Y24.377 E0.0352

Any ideas 1) what the correct initial gcode should be and 2) how to get Simplify3D to not try to run off the y-axis?

Thanks!

Re: Printrbot: starting gcode and y-axis issues

Posted: Mon Aug 08, 2016 6:55 am
by CompoundCarl
I only see really 2 different moves that use the Y-axis

G28 X0 Y0
and
G1 X47.675 Y25.251 F3600

That first one just homes the printer. So if that's what's causing the problems, then your firmware is probably setup incorrectly or your motors are wired backwards (meaning it's moving away from the homing switch instead of towards it). You can easily test this. Just connect your printer, go to the machine control panel, and manually send "G28 X0 Y0" from the communication tab and watch what it does.

The second command just moves to a specific Y-coordinate which is well within the bounds of the printrbot bed, so I wouldn't foresee any issues there

Re: Printrbot: starting gcode and y-axis issues

Posted: Tue Aug 09, 2016 1:18 pm
by WizarDru
Do you have an entry with the M211 command? That sets the bed area. If that is set incorrectly, that might be the issue. It appears to be executing the G28 commands all right, but is going too far when doing the bed calibration. For the metal Simple, it should use these values:

M211 X152 Y152 Z152

(Although I think my printer may actually use 150s...I'll have to check tonight).

Re: Printrbot: starting gcode and y-axis issues

Posted: Sat Dec 03, 2016 4:40 pm
by shi
Had this exact same issue, fixed it by changing the starting script to

Code: Select all

G21 ;metric values
G28 X0 Y0 Z0 ;move X/Y to min endstops
G29 ; auto bed leveling
(the rest of the S3D generated GCode before actual toolpath moves is p much identical to what Cura outputs, and Cura doesn't try to ram the Y-axis into the Z axis rods so I just changed the parts that were different ;) )
It would be awesome to be able to save both a printer specific start script and a profile specific one, (so you could add custom Gcode for some profiles without always having to remember to include the script to not torture the Y-axis motor) but I doubt S3D would add that feature.

Re: Printrbot: starting gcode and y-axis issues

Posted: Sun Dec 04, 2016 7:25 am
by CompoundCarl
Hmm... well I'm not sure that G28 X0 Y0 Z0 is any different than G28 X0 Y0 then G28 Z0. I would think those would do the thing.

If you replace G28 X0 Y0 Z0 with 2 lines like it was before (G28 X0 Y0 then G28 Z0), does it still work? Maybe the G21 command is actually the one that was needed?

Re: Printrbot: starting gcode and y-axis issues

Posted: Sun Dec 04, 2016 11:48 pm
by dsegel
Take out the G29 and try it again. If it works without it, you're hitting a bug in the Marlin code. You can fix it by resetting the position post G29, like this:

G28 X0 Y0 ; home X and Y axes
G29 ; probe Z
G92 X183 Y20; reset actual position

Your X and Y positions will be different than mine because my bed is expanded (200x200).

Re: Printrbot: starting gcode and y-axis issues

Posted: Mon Dec 05, 2016 7:49 am
by CompoundCarl
Interesting... do you have any more info about this bug? seems like it would affect a lot of printers that use auto-leveling (or perhaps it was already patched so just older firmwares?)