R extruder prints in the wrong place when it is the first extruder to print

Snapmaker J1/J1s
1

I’m having a new issue with my J1s. I use Cura 5.5 to slice 2 stl models, to be printed with 2 different extruders. If the R extruder (T1) is the first one to print, it homes over to where the L extruder is parked, bangs into it, then sits there while the bed heats. When T1 starts printing, the print is too far to the R, so that when T0 starts to print, the two prints are not lined up.

If I go into the gcode file and change the extruders so that T0 goes first, the problem disappears. T1 stays on the R, as it should, and both extruders print where they are supposed to.

I have not tried slicing with Luban. My laptop is running a version of Linux that is several years old, and the most recent version of Luban that will run is 4.6.3. That will be my next thing to try.

This seems as though it may be a firmware bug, as the only thing that changes in the gcode is changing “T1” to “T0” and vice-versa. Something seems to be wrong with homing when T1 is the first extruder to be active

2

Solved.

The problem is with the interaction of the M605 S# command an G28 (home). If the printer receives an M605 S1 (auto-park) command, followed by a G28, the T1 extruder parks where T0 lives. As it is not in the right place, later G1 commands put it in the wrong place. However, M605 S0 leaves T1 where it was when it finished its print command, and prevents T0 from moving where it needs to.

SO:

In the startup Gcode, give an M605 S0 at the very beginning of the startup code, and a M605 S1 at the very end. That way, the heads home properly, but get out of each others way when printing.

There is also a G28 command at the end-of-print, so, you must also put in a M605 S0 at the beginning of the End-of-print Gcode, so the heads don’t crash into each other when they try to home.

It is puzzling that nobody is having this issue but me?

3

I have no M605 commands in my gcode start or end scripts. When I slice a file with 2 models one for T1 and one for T0, there is no M605 in the resulting gcode. It does work as expected.
=> Wouldn’t removing the M605 commands from your start and end gcode scripts just work?

;— Start G-code Begin —
G28 ;Home
G1 Z0.8 F6000
M201 X10000 Y10000 Z500 E5000
M205 V5
G92 E0
G1 F200 E2
G92 E0
;— Start G-code End —

;— End G-code Begin —
M104 S0
M140 S0
G92 E0
G1 E-1 F300 ;retract the filament
G92 E0
G28 Z
G28 X0 Y0
M84
;— End G-code End —

4

It seems related to how the gcode gets to the printer. The TwoColorShark, the gcode for which is already in the J1’s memory, prints correctly without any M605 commands. However, I use Octoprint, running on a Raspberry Pi, connected to the J1s thru the USB port. When I send the TCS gcode to Octoprint, then print from there, T1 doesn’t move out of the way when it is done printing; it just sits there, unless the M605 S1 (command to auto-park print head) has been given. However, if the M605 S1 command is given, and T1 is active, and the G28 (home) command is given, T1 tries to home on T0’s side, crashes into T0, and thinks it is at X0, when it is actually about at about X10 or X20. So, when T1 prints, everything is 10-20 mm too far to the right, and doesn’t line up with what T0 prints.

So, after MUCH trial and error, I have found that giving the correct M605 commands is essential for successful printing with Octoprint over USB. I have not tried sending the gcode from Octoprint to J1s over Wifi, to see if that will print correctly without M605 commands. I will try that sometime, and report the results on this thread.

5

Thanks. That’s very insightful for people like me who are considering to use OctoPrint.

1 Like
6

Glad to help. If you do start using Octoprint, let us know how it goes. For completeness, here’s my Starting and Ending Gcodes for Cura 5.5 with the Snapmaker plugin:

;--- Start G-code Begin ---
M605 S0 ; dual extruder mode
M140 S{material_bed_temperature_layer_0} ;Set Bed Temperature
M104 S{material_standby_temperature}
G28 ;Home
G1 Z0.8
M109 S{material_print_temperature_layer_0}
M190 S{material_bed_temperature_layer_0}
G1 Z0.8 F6000
M201 X10000 Y10000 Z500 E5000
M205 V5
G92 E0
G1 F200 E2
G92 E0
M605 S1 ;auto-park IDEX
;--- Start G-code End ---

;--- End G-code Begin ---
M104 S0
M140 S0
G92 E0
G1 E-1 F300 ;retract the filament

G92 E0
G28 Z
M605 S0 ;IDEX - full control
G28 X0 Y0
M84
;--- End G-code End ---
1 Like
7

On my other thread, ‘Printer not working for 2 color prints’, Stelzer has provided a link to a command line tool for sending gcode files to the J1s over wifi. Another piece of the puzzle to explore!

8

A new issue has surfaced! The starting and ending Gcodes above work well for prints that use both print heads. However, when I am printing a model that only uses the Left print head (T0), T1 turns on at the beginning of the print, and never gets a command to turn off. I discovered, by accident, that T1 had been sitting at its standby temp for about a week after finishing a print! Fortunately, the HIPS in the printhead had not hardened in that time, and I was able to clean it out easily.

My “quick and dirty” workaround is to change the ending Gcode:

old:
M104 S0

new:
M104 T1 S0 ; turn off T1
M104 T0 S0 ; turn off T0

9

Why not turn off the right at the beginning of the gcode?