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!)
Thanks for your reply. I have edited my post and uploaded the system bundle.
I tried octoprint in safe mode, but that resulted in the same problem unfortunately.
Frequent readers always get the newest posts at first to see. It can be quite tedious to scroll back with every thread. Also, the chronological sequence is disturbed.
The gcode file you posted contains a M605 S0 (see Multi Nozzle Mode | Marlin Firmware for details) which means that parking the non-active extruder is the responsibility of the generated gcode. If you added the M605 S1 manually or at the beginning of the gcode without removing the M605 S0, then that would explain why it didn't work.
As @Ewald_Ikemann partially suggested, you can use the OctoPrint Terminal window to enter some gcode commands to verify that the firmware responds correctly.
Enter M105 S0
Enter T0
Enter T1
This sequence should not move either extruder.
Enter M105 S1
Enter T0
The second extruder should move to the park position.
Enter T1
The first extruder should move to the park position.
You may need to add some G0 X100 (I'm not sure what the dimensions are for the printer so pick a value for X that is somewhere in the printing area) commands to move the selected extruder away from its park position.
Once we know that the firmware is responding correctly, then we can move on to configuring the slicers to output the correct commands at the appropriate times.
It looks like Luban doesn't let me edit the standard G-code order/construction. So i tried Cura.
M605 S0 in the G-code before starting the print job (via Octoprint) doesn't work either with a G-code generated with Cura. It results in colliding extruders also. SJ1_corner cable guide.gcode (418.0 KB)
I don't own one of these printers so I'm depending on you to perform any experiments needed to help figure this out. What version of Cura and what OS is the machine it is installed on running? If the answer is Ultimaker Cura 5.7.1 then what printer did you install because Snapmaker J1 isn't in the list.
The new gcode file you posted doesn't contain any M605 commands.
Let's try this:
Enter G28
Enter M605 S1
Enter T0
Enter M114
What is the output?
Enter T1
Enter M114
What is the output?
Enter G0 X100
Enter M114
Did the second extruder move? What is the output?
Enter T0
Did the second extruder go back to the park position? If it did...
Here is the output:
A1) all axed homed
A2) received OK in terminal, no movement
A3) received OK and Extruder 0 as active in terminal, no movement
A4) received in terminal: X:-13.00 Y:0.00 Z:205.70 E:17.59 Count X:-1040 Y:0 Z:344000, no movement
B1) right extruder rammed into the left extruder
B2) received in terminal: X:0.00 Y:0.00 Z:205.70 E:17.59 Count X:0 Y:0 Z:344000, no movement
C1) right extruder moved to x100
C2) received from terminal: X:100.00 Y:0.00 Z:205.70 E:17.59 Count X:8000 Y:0 Z:344000
D1) right-extruder went to home position and the left-extruder left the home position (like getting ready to extrude), to position X100?
E1) received OK in terminal, no movement (I think left-extruder already was at X100)
E2) X:100.00 Y:0.00 Z:205.70 E:17.59 Count X:8000 Y:0 Z:344000
BTW, using the same G-code via a USB-stick results in good prints, so it looks like it really is an octoprint issue?
A1) all axes homed
A2) received OK in terminal, no movement
A3) received OK in terminal, no movement
A4) right extruder rammed into the left extruder (which was still at home position)
A5) parked the right extruder at home and moved the left extruder ready to extrude
A6) received in terminal: X:0.00 Y:0.00 Z:205.70 E:11.15 Count X:0 Y:0 Z:344000
A7) left extruder moved to home position and right extruder rammed into the left extruder
A8) received in terminal: X:0.00 Y:0.00 Z:205.70 E:11.15 Count X:0 Y:0 Z:344000
It looks like the right extruder wants to move to the location of the left extruder.
B1) parked the right extruder at home and moved the left extruder ready to extrude
B2) moved the left extruder to X100
B3) received in terminal: X:100.00 Y:0.00 Z:205.70 E:11.15 Count X:8000 Y:0 Z:344000
C1) moved the left extruder to home and moved the right extruder to X100
D1) no movement, the right extruder was already at that location (see previous)
D2) received in terminal: X:100.00 Y:0.00 Z:205.70 E:11.15 Count X:8000 Y:0 Z:344000
You are calling the extruders right and left and I'm selecting T0 and T1. Can you tell from the experiments we have done so far is T0 left or right? I expect the X axis to have 0 on the left and 300 on the right and the Y axis should run from front to back, i.e. 0,0 is on the left front.
If the extruders both start in the park position, then I don't understand how the experiments we have performed ever cause them to collide. The only thing I can think of is that M605 S1 doesn't do what the Marlin documentation says it does.
I also don't understand why the M114 output never shows X at around 300 (plus something for the park position).
Perhaps it is time to contact Snapmaker support and ask them for some documentation on the M605 command so we can make sure it complies with the Marlin documentation.
Did the printer come with any example gcode files? If so, can you zip them up and post them here, please.
How have you defined the printer in OctoPrint? Unless you have done something out of the ordinary, a gcode file printed directly from a USB-stick and uploaded to OctoPrint and printed from there should result in identical results. OctoPrint by default doesn't add (or subtract) any gcode commands.
Those are indeed the dimensions.
I added the custom bounding box though. I based it on the profile for Cura i mentioned earlier. (when the extruders are homed they are not above the 300x200 printbed)
I just now disabled the custom bounding box but that let to exactly the same behaviour.
Then I tried a new Cura Gcode again (with M605 S1 before printjob): SJ1_corner cable guide (2).gcode (513.1 KB) and immediately when starting the print job, the right extruder then rams into the left extruder again.., 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..
Now I need a solution for warming up before moving to the printlocation, that's the right behaviour, right?
We are getting closer with every step.
Using Gcode from Luban: corner cable guide_1729418656572.gcode (487.4 KB)
and the M605 S1 command in octoprint before printjob still results in the same problem. I think that is due to the M605 S0 command in the Luban Gcode, you mentioned earlier. Why does Luban choose that command when I am configuring a IDEX (1 extruder for the object and 1 extruder for the support) print in Luban? And is there any way to override that?
I believe you should enable the Custom bounding box (and I believe the X max should be 320). I would not put anything in the OctoPrint Before Print Job Starts script. IMO, the right place for this would be in the slicer's Start G-Code script and if executing that command causes the ramming, then it should go after the G28.
In Ultimaker Cura, there is Start G-Code and End G-Code for each extruder. The warmup and standby temperature gcode commands would go there if necessary. Ultimaker Cura has a standby temperature for each extruder and it appears to me that gcode is being generated for raising and lowering the temperature of each nozzle. I can't easily tell where the nozzle is when these commands are sent.
I'm not going to be much help with Luban specifics. I'd check with Snapmaker support or check if they have community forums frequented with other Snapmaker J1 users. You might want to ask them about the two extruders ramming into each other.
Just to chime in on this, no, that just means that the code used for interpreting stuff stored on provided USB sticks and stuff coming in over serial is not the same. Files loaded from USB probably cause some internal initialization to take place which simply doesn't happen in case of stuff sent through the serial connection, and that makes things misbehave.
This would be something that would show up in testing, if printer vendor actually bothered to test the serial interfaces of their fiddled with firmware forks. Alas, this usually doesn't seem to be the case at all, and their customers are forced to do the testing for them.
I just discovered this thread, and will jump in here. My setup is pretty similar to xboxhooah's, and I have already done some of this troubleshooting already. Here's the situation I have found:
The Snapmaker J1s (the IDEX printer we are both using) handles incoming gcodes differently if they are coming in over the USB-B connector in the back, where my Raspberry Pi/Octoprint connects, versus the USB-A connector in the front, where gcodes on a USB stick would be loaded. I have not tried the Wifi connection, which is a third way of getting gcodes into the printer.
When using the front USB connection, everything works without conflict. When using Octoprint over the back USB connection, the print heads don't always play nicely with each other.
Specifically, if no M605 commands are included in the gcode, when it is time for a tool change, the tool that has just finished does not park. It stays wherever it was when it finished its last command. When the newly activated tool tries to move into position, it can't because the inactive tool is in the way.
This problem is remedied by putting "M605 S1" in the startup Gcode. BUT, if T1 is the first tool to be active a new problem appears: when G28 is given, T1 tries to home to T0's side. When it can't get all the way to X0, subsequent G0 commands are off by about 10 or 20 mm on the X axis.
Cura often puts a "T1" in the code before the user-supplied "Starting Gcode" is inserted. So, "M605 S0" has to be given in the user-supplied "Starting Gcode" BEFORE G28, THEN "M605 S1" before the printing starts.
At the end of printing, G28 is given. Again, if "M605 S0" is not given before that, T1 will try to park on T0's side.
So, there's a subtle set of interactions between G28, M605, and which extruder is active when the G28 is given.
On a tangentially related topic, I have just discovered that my J1s has a "filament runout sensor", but apparently it doesn't do anything when the gcode has come in over the Octoprint connection. ANOTHER case of the firmware behaving differently depending on the source of the gcode.
I have been using Cura as my slicer, but will start experimenting with Luban, to see if any of these issues are related to how the gcode is being generated.