Octoprint and IDEX problem: extruders run into each other

Snapmaker J1/J1s
1

When using octoprint (on RPI 3B+) the exported G-code (from Luban or Cura) let the extruders run into each other. For example: a print with PETG as support (right extruder) and PLA for the object (left extruder). When the right extruder printed the first layer it stops moving and stays at the last print position above the printbed, when in should have moved out of the way to the oozing shield (all the way to the right of the printbed). When the left extruder moves in to the printbed in runs into the rightextruder and prints in the wrong place.

Using the G-code directly from luban to the Snapmaker J1 results in correct moving and printing.

What do I have to do to print ā€˜normallyā€™ via Octoprint with my IDEX machine?
1 other question: What is the safest en eadiest way to enable Host action commands?

What did you already try to solve it?

I read some fora about the same problem and using M605 S1 as standard G-code before the start of a printjob did not fix it.

Have you tried running in safe mode?

Yes

Did running in [safe mode] solve the problem?

No

Systeminfo Bundle

You can download this in OctoPrintā€™s System Information dialog ā€¦ no bundle, no support!)

I am not able to upload the system bundle, because I am a new user.

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ā€¦ as much data as possible

OctoPrint version 1.10.2
OctoPi version 1.0
Snapmaker J1
Marlin
Chrome
Windows 10
Luban (or Cura)

2

I used to run octoprint on my ender but the SD card got corrupted. Iā€™m going to re flash the card and make an instance for my J1s.

Is octoprint homing both tool heads when it receives G28?

3

Thanks for your reply. Okay!:slight_smile: Iā€™m curious what your snapmaker J1 will do.

Yes, G28 did a propper home for all axes.

4

Does it collide on single extension prints with one tool head?

5

No, because only one extruder is active in a single extruder object print. The other one sits at home.

6

It could be ignoring the XY offset made in the firmware.

7

I had problems with extruder positioning when printing a gcode file sent to Octoprint running on a Pi3 connected to the J1s by the USB-B connection in the back of the printer. It appears that you have seen my posts about it. I never filed a support request about it, though. It would appear that the J1s firmware processes files differently if they are coming in from the USB-B plug in back or the USB-A plug in front. Another possibility is that Octoprint is manipulating the G-code before it is sent to the printer.

Once I figured out the M605 S[01] commands to work around the problem, I didnā€™t really look into it any farther. Note that the placement of the M605 commands is important in the start-up code.

8

Hi Mark,

Good idea. I tried using the other USB port (front side) and that gave indeed the same result. Using G-code from a USB-stick in the front and back gave the same good results.

Is the placement of the M605 command in the start-up code the same as the GCODE scripts location ā€œBefore print job startsā€ in octoprint?

9

I use Cura to generate G-code from STL models, and put my M605 commands in the Cura printer profile start-up commands. Once the G-code is generated by Cura, the file gets uploaded to Octoprint. I did recently add the ā€œArc Welderā€ plugin to Octoprint, but that is the only processing I have Octoprint doing.

10

Hmm okay. I tried that and that works for me as well, but immediately when starting the print job, the right extruder then rams into the left extruderā€¦, after that itā€™s homing before actually printing though.
After this, itā€™s actually behaving more properly, but everytime the with the tool switch it already moves to the print location before warming upā€¦
Does your Snapmaker J1 do the same?

11

BTW what is your reason to use Cura over Luban?
And are you able to normally print a Luban Gcode via Octoprint?

12

Cura does everything Luban does but has better features and a library of plugins

1 Like
13

When i asked snapmaker about this they only said to load prints through the flash at the front, not very helpful. toolchanges dont work when being controlled direct by USB which is a bummer since i happen to like using Pronterface to connect to printers without having to get up and the command macros are easier to get to

14

I think so to, but honestly I like Luban to and it does really work well together with the Snapmaker J1 (except for using it with Octoprint).
Have you yet gotten around to connecting your Snapmaker j1 with Octoprint?

15

No, I lost the SD card for my pi, but when I find it I will

16

I had been using Cura for a few years before I got my J1. I looked at Luban, and donā€™t have any objections to it; Iā€™m just used to using Cura.

17

Iā€™ve been having issues with Luban where when I upload a print, it doesnā€™t show up

18

I re-read my 2 previous posts on the extruder heads issue. The first one, on May 12, is ā€œPrinter not working for 2 color printsā€. This was posted after successfully printing the ā€œ2 color sharkā€ that comes already loaded into the J1sā€™s memory, after the initial setup and calibration of the new printer. However, when I tried a 2 color print for an object that I had sliced and fed in thru Octoprint/back USB-B connector, I found that the print heads would not return to their home positions when it was time to change extruders. This led to the discovery that the M605 S1 command had to be issued before printing started. However, if M605 S1 is given when T1 is active, followed by G28 (home), T1 tries to home on T0ā€™s side, crashes into T0, the belt slips a few notches as the stepper tries to move T1 to where T0 already is, and after that, the X coordinate for T1 is not correct for the rest of the print. Also, a ā€œG28 X Yā€ command is issued at the end of the print job. To prevent T1 from homing to the wrong side, the M605 S0 command has to be given before the G28 command.

The post, ā€œR extruder prints in the wrong placeā€¦ā€, on May 15, is about the parking problem if M605 S1 is issued when T1 is the active extruder.

According to the May 12 post, I put a ā€œM605 S1ā€ in the Octoprint profile, while other M605 commands are in the Slicer (Cura) profile. I will have to check to see if the Octoprint profile command is still there. It could be another confounding variable.

I then later discovered that the gcode generated by Cura will sometimes heat T1, but, if it isnā€™t used during the print, never issues a command to turn it off. I found that out after I had not been using the printer for about a week, and, when getting ready to use it again for another project, found that T1 had been kept heated the whole time since my last print!

I am going to look again at using Luban to generate the gcode, and possibly control the printer, if I can get the same functionality out of it that I can with Octoprint. I donā€™t understand why the printer behaves differently when the gcode comes in over the back USB connector, versus the front USB or Wifi. I just found out that the J1s has a filament runout sensor, that appears not to work with gcode loaded thru the back USB. My printer is in my garage, and I usually load and start print jobs remotely, so plugging a USB stick into the front USB slot is a sub-optimal workflow for me. I have to look at whether Luban gives the same control over printing that Octoprint does, or, if Octoprint can send the files over Wifi instead of the USB-B (back) connector.

19

Thank you for your detailed explanation, thats cleared a lot of things for me.
Are you saying that if I connect octoprint via the front USB it will listen to the gcode like itā€™s reading it from a usb from the front?

20

I donā€™t think that I have ever tried connecting Octo to the front USB port. It would be interesting to see what happens! The other thing yet to try is using Luban to upload gcode over Wifi. I havenā€™t done much with Luban. It looks as though it may work well for slicing, but doesnā€™t seem to have all the functionality that I know and love with Octoprint.

With any luck, we can shame the Snapmaker firmware developers into figuring out why using the back and front USB ports results in different behavior, and fixing it!