Octoprint and IDEX problem: extruders run into each other

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.

Indeed. The benefits of Octoprint for me is remote control. Using Wifi and Luban you are only able to stop a print (but not monitor with a camera for e.g.) locally and not remotely.

USB-A is only for usb thumb-drive, USB-Mini-B is for serial connection, as it is at the 2.0.

1 Like

I would imagine that I will be able to watch a print using my Octoprint, as the camera functions whether it is printing or not. Right now, Iā€™m getting Luban set up to use as a slicer instead of Cura, to see what differences there are in the gcodes in generates. Iā€™m sure Iā€™ll still have to add M605 Sx commands to get it working thru the back USB port, but I want to see if Wifi works.

Well, THAT was informativeā€¦

I spent some time playing with Luban. It is not the latest version, as my Linux distro on my laptop is not up-to-date, and versions of Luban later than 4.6 wonā€™t work. So, thereā€™s that.

Luban seems to generate G-code well enough, but I cannot find a way to insert custom starting and ending gcodes, as I can with Cura. As discussed in this thread, some massaging of the gcode is necessary to get IDEX to work correctly when gcode is fed in thru USB-B. I suppose I could put the custom gcodes in Octoprint to get around this.

I also looked at using Luban without Octoprint. No go. I can upload the gcode to the printer over Wifi, but have to go to the printer and use the touchscreen to start printing. My printer and laptop are far apart, so thatā€™s a deal breaker. There seems to be a way to print the gcode directly from Luban, but the code keeps stopping, without telling me why. Perhaps it is feuding with Octoprint? I use Octoprint to watch the printing on video, and to control the lights. Again, it appears that Snapmaker doesnā€™t like letting USB-B control the print. I have yet to try unplugging USB-B, and seeing if Luban works better that way.

It is disappointing that Snapmaker no longer supports the open source version of its IDEX firmware on github. So, I will continue with my current workflow for now: slice with Cura, upload gcode to Octoprint, and print from there over USB-B.

Maybe smuploader helps you transfering and starting wireless, there should be a terminus of ā€œsend and start the printā€:

I shared this post and my other post Octoprint and IDEX problem: extruders run into each other - #24 by MarkA121 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.

Thanks for trying. I wonder if they would consider making the IDEX firmware open source, as it used to be? For now, putting the M605 commands in the right places seems to have things working well. Iā€™m working through some issues with Cura compatibility with IDEX printers, on the Cura community forum. Iā€™ll post an update here when I get it all sorted out.

After trying Luban for a bit, Iā€™m going to focus on fine-tuning Cura, instead. The inability to include custom starting and ending gcodes in Luban is a deal-breaker for me.

1 Like

Donā€™t know if yā€™all got this above in the thread, already a lot of discussion.

By now you know Luban and the Cura Snapmaker plugin for the J1 use the M2000 fast tool change command?

This code is interpreted by the Android firmware and not the low-level mcu. So if the code is sent directly to the mcu (via the rear USB), itā€™s skipped.

Thatā€™d be why support just says, ā€œPrint via the screen.ā€ So that the M2000 command is parsed and interpreted by the macros encoded in the Android firmware.

I seem to recall others writing other custom tool changes. But using a basic T0/T1, etc, will leave the other head abandoned in place and lead to a crash.

1 Like

(Other things that only happen via screen macros include intervening with the Adjust menu, etc, and I think also the filament runout process. The screen is not aware of anything sent via the serial connection to the mcu, and vice versa, other than the displayed sensor readings. Iā€™ve personally skipped trying to initiate prints through octoprint. It cannot be done in a way the local control is aware.)

1 Like

This is good to know. I was not aware of the M2000 command, but I see it is showing up in my gcode generated by Cura 5.8 with the Snapmaker J1 plugin. However, if M2000 relies on going thru the front panel, it is a no-go for me. My printer is in a detached garage, and I usually start prints from my laptop in my living room.
Looking at https://wiki.snapmaker.com/en/Snapmaker_Luban/manual/j1_j1s_supported_gcode_references, ā€œM2000ā€ isnā€™t listed. It is listed under SM2, where it is a status inquiry command, and under Artisan, where it is used to control the laser. Looking at the source code, SnapmakerController-IDEX/snapmaker/gcode/contorl/M2000.cpp at ba60aace13038b46cb349f5b7a80076fe8de3ce2 Ā· Snapmaker/SnapmakerController-IDEX Ā· GitHub (hopelessly out of date, but itā€™s all we have), it does many things, none of which are very clearly documented. I see references to it in other threads on this forum, but can find no official documentation of it for the J1s.

That file just hasnā€™t changed in a while. The repo was updated a few months ago after the most recent firmware update. (I did a pull last week and it has all the most recent changes.)

1 Like

Hmmmā€¦my J1 front panel says version 2.7.2. The github repo is 2.2.11. Not a huge difference, but still. Perhaps ā€œhopelessly out of dateā€ was a bit of an exaggeration.

2.7.2 is the major version of the J1 firmware including the screen. 2.2.14* is the current version of the Marlin portion.

1 Like