Having Problems With M600

Hi Gents. I was attempting to print one of the EVA 3 shrouds on my V-Minion, and in the slicer I used two M600 insertions to do color changes on two different layers. The first 6 layers or so would be black, followed by 3 layers of green, then the rest of the shroud is black. This allows the green background of the EVA logo to show through the front. I tried this twice, and the print failed at the first color change each time. The first time, the first 6 layers completed in black, then the printer paused, parked the print head in front, and automatically ran the UNLOAD_FILAMENT macro to back out the black filament. I removed the black filament and inserted the green. I then manually extruded about 100mm of the green filament to purge the remaining black out of the nozzle. I then hit resume, and that's where things went south. The print head crashed into the print and dislodged it from the bed, and crashed hard enough to bump the bed probe enough so that the Z-offset was changed. I cancelled the print and re-set the Z-offset. I tried this again, and virtually the same thing happened, except the probe wasn't hit. However, the print wsa dislodged. I could also see that it attempted to start printing the green layer, and it was shifted in X by over 25 mm and wasn't in line with the previous location of the print at all. What could be the reason here for why the M600 macro isn't working? Am I not doing the proper steps to change the filament? Is there a step I'm missing. Unfortunately, the proper procedure for how to use the M600 macro doesn't seem to be documented in the RatOS documentation. Thanks in advance for any information.
3 Replies
miklschmidt
miklschmidt•12mo ago
I don't think the M600 macro is at fault here, i think this might be a mechanical cause such as Z axis binding or a loose coupler etc. The m600 macro is quite widely used and there's been no reports of problems for as long as i can remember. The only way i can think of that would cause the printer to loose track of where it is software wise is if you ran SET_CENTER_KINEMATIC_POSITION (which is why it throws a fat warning 😄 ).
united-yellow
united-yellow•12mo ago
I don't think this is mechanical, as I've done several other prints without M600 and they're all coming out very nice and high quality, much higher quality that the prints from my other (non-RatRig) printer. Only when the M600 macro is introduced am I having issues. I do have a BTT Smart Filament Runout sensor installed on the Minion, and I'm using the following code in the config file for it: [filament_motion_sensor runout_sensor] detection_length: 10.0 extruder: extruder switch_pin: PF4 pause_on_runout: true runout_gcode: PAUSE On my other printer, in the M600 macro that I developed for it, there is code to disable the filament runout sensor within the M600 macro so that the sensor doesn't feed false input to the system while the user is changing filament. Do I need something similar here? What I might do is temporarily remove the filament runout sensor code from the config file so that the sensor is ignored, and then try the print again. The BTT Smart sensor is a bit different than some other sensors, it's not just a "filament present" or "filament empty" signal, it actually sends pulses to the system as the filament is traveling so that jams can be detected. Since I manually extrude filament to purge the nozzle, if the sensor is active during the filament change, the system will receive many pulses that it may queue or act on after it resumes (not sure, just guessing here). If you have thoughts on this, please share, thanks.
miklschmidt
miklschmidt•12mo ago
Do I need something similar here?
I doubt it, the PAUSE macro already returns if the printer is already paused, so it shouldn't matter. If you don't trust the M600 macro, you can write your own in USER OVERRIDES. Same goes for all the other macro's, if you want to try stuff out. You can also just copy the existing M600 macro from RatOS/macros.cfg and modify to your liking in USER OVERRIDES. I used the M600 macro recently on my V-Core 400 actually. Just a couple weeks ago (and it hasn't changed since it was introduce back in v1). I would find out what causes your steppers to skip steps in the case of M600 and thus confuse the kinematics (only way it can crash). If you could film it that would help me troubleshoot