As for this:
T0/T1 should work
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...
- Enter
G0 X100 - Enter
M114
Did the first extruder move? What is the output?
I understand. I used this for Cura 5.7.1: GitHub - Snapmaker/SnapmakerCuraPlugin: Snapmaker plugin for Cura 5
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
This already seems more promising, right?
After G28, where are both extruders? Is there a way to "park" both extruders?
G28M605 S1T0T1T0M114T1M114
I believe both extruders should be in their "park" locations and the output of each M114 should reflect that.
T0G0 X100M114
Should move one extruder to that location.
T1
Should park the previous extruder.
G0 X100- 'M114`
Should move this extruder to the same location as the other extruder was moved to. Neither extruder should run into the other extruder.
After G28 the extruders are at home. This is the way the extruders are parked at home:
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
I am very confused. According to the specifications at:
https://us.snapmaker.com/products/snapmaker-j1-independent-dual-extruder-3d-printer
the printer dimensions are 300mm x 200mm x 200mm.
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.
0 = left extruder and T1 = right extruder
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.
2 Likes
You are right
This helps so much, thank you!!
Tomorrow I will try to connect octoprint through the front. If that works, that will be my go to setup as second best option i guess.
1 Like
I just tried connecting my RPI with octopi to the front of the USB-A port of the Snapmaker J1, but I am not able to get connected, so I think only the USB-B port is compatible for this kind of communication.
After this I tried manually editing the G-code (M605 S1 after the G28, and using only the word TIME for enabling time left of printing) from luban and applying the right command order. That worked, but is not really convenient to must be doing this all the time.
Also: the extruders are warming up above the object, just like when using Cura Gcode.
About the filament runout sensor not working, I think that has to do with the printer's firmware not supporting host action command. See: OctoPrint tells me my firmware lacks support for "host action commands", what does this mean?
I now tried something new: duplication mode. This has the same behaviour. It prints normal via USB-stick in the front and via octoprint only T0 starts printing.
Luban test duplication.gcode (312.3 KB)
Do you see something unusual in the Gcode?
After reading the reply from @MarkA121 and interacting with @xboxhooah I have come to the conclusion that Snapmaker has purposely crippled the firmware when commands are being fed through the USB-B connector.
All is not lost, however, as Snapmaker has open-sourced the firmware. The Github repository is at https://github.com/Snapmaker/SnapmakerController-IDEX and there are some issues reported regarding OctoPrint.
If I understand the issue #30, then it looks like remedies for the problems seen in this topic will require learning how to build and modify the firmware if someone in the community that frequents that repository hasn't made a fixed version available.
@xboxhooah, I don't see anything unusual in that gcode but see issue #29 for a possible fix.
1 Like
You can add the M605 commands to the starting and ending gcode automatically. In Cura, there is a place to enter custom Gcodes for starting and ending a print under each printer's profile. Octoprint also has a place for custom gcodes. I would expect that Luban has the same functionality, but I'm not familiar enough with it just yet to know for sure.
Cura is not giving me the workaround I need, so I'm staying with Luban. If only I have a simple way to edit the Gcode that let's the Snapmaker J1 do what it's supposed to do, via the USB-B, it would be a second best altenative for me.
It looks like Luban has no functionality to editing Gcode. So i edited the Gcode myself and replaced 'M605 S2 X162 R0' with 'M605 S0' and after the G28 I placed the 'M605 S2 X162 R0', all for a proper homing result.
test copy.gcode (313.6 KB)
Unfortunately only the left extruder (T0) starts printing, while the right extruder (T1) warms up but does no go to print.
Anyone ever figured out how to use duplication and mirror mode via octoprint?
I shared this post and my other post Octoprint and IDEX problem: extruders run into each other - #24 by MarkA121 - Snapmaker J1/J1s - Snapmaker: where creation happens with Snapmaker support, after they told me to ask the community for help. This was their response: "We are sorry, due to the shortage of staff in the R&D development, we are temporarily unable to solve the problem of third-party modification of the machine for you. I hope you can understand."
I don't think we can expect any updates in the firmware at any time from Snapmaker itself.
Then they should put the source files into the open source community.