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.
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.
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.
(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.)
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.)
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.
did you manage to get octoprint fully functional? i require putting my printer in a remote location to print noxious plastics like abs. it cant stay in my main living area.
We ended up talking more about it here, @jbot.
I aim to give it a try just for fun, but not until after the new year. Dunno if Mark did though.
I have an instance going for my ender, and I might just add another instance for my snapmaker
Youāve surely seen elsewhere, but as highlighted here and in the other thread, the usefulness of what it can do via Octoprint right now is pretty limited.
If you only want to add a camera for monitoring, and have something that lets you send commands between prints, itās great.
But full function remote printing doesnāt quite work due to the lack of HACs discussed in the other thread. And we dunno yet to what extent the Android firmware will play nice with them.
@Wombley if you would like to explore the android firmware see my new post
i tried to tag you in the above comment but failed
did you ever resolve this? I just set up an octoprint instance with simplyprint and I cant home the x and y axes. it also only shows controls for one extruder