Hello All.
I have an SM2 in an enclosure and I’m using the color blending tool as shown in the link.
That tool, without markers, is about a centimeter from the enclosure when the 3D printing module is homed. I need a way to ensure that when a 3D print is complete–and I’m using that tool-- that it does not home. Otherwise the markers collide with the enclosure and havoc ensues.
I’m using Luban 4.1.4 generated G-code and have included the end of a sample file that was produced.
End of Generated G-Code file
;End GCode begin
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
G90 ;absolute positioning
G92 E0
G1 E-1 F300 ;retract the filament a bit before lifting the nozzle, to release some of the pressure
G1 Z330 E-1 F3000 ;move Z up a bit and retract filament even more
G1 X0 F3000 ;move X to min endstops, so the head is out of the way
G1 Y350 F3000 ;so the head is out of the way and Plate is moved forward
;End GCode end
M82 ;absolute extrusion mode
M104 S0
;End of Gcode
I’ve changed the Z value in that 3rd-to-last line from 330 to 30 just to see if that would make any difference and the module returns home when I check on a completed print.
Is this achievable? Thank you.
Is there a G28 at the end of the file? This is the homing command. Removing it should keep it from auto-homing at the end.
I printed all of the “end code” and sadly, G28 is not there.
G28 only appears once in the entire code file near the start of the file.
I’m wondering if there’s some “default” homing code that makes it happen automatically after each print?
It does seem like that’s where you’re headed, however in the past at least there was no indication the touchscreen does such a thing. Maybe post on Github and ask the developers of the touchscreen firmware if they added such a feature to the touchscreen.
I had to add a G28 Z to my end code in Cura to get that behavior I wanted, it was not present in the firmware version I’m using (not current).
Perhaps experiment with running a simple gcode file with no or minimal commands in it and verify it goes up at the end to confirm or falsify the hypothesis the touchscreen is doing things on its own.
I’ve done a few prints at this point removing all of the end code, and it still homes.
Sounds like the next step would be to create an issue on Github to ask the developers what is going on. Or reach out to support.
I reached out to support and they confirmed that this seems to be a setting… and they denied my adding this as a potential backlog item.
1 Like
A workaround would be just ditch the touchscreen and use a raspberry pi running octoprint. The machine runs just fine without it plugged in at all.