[FR] PRUSA_MMU2_S_MODE enhacement, spin the BMG gears while C0 command

[trocololo]

Hi,

As talked in these topics:
#17523
#17886

The PRUSA_MMU2_S_MODE is really hard to get it working. The bondtech gears from the extruder are not spining while MMU2 is executing C0 command and the MMU2 has no enough torque to push the filament into the gears, so the sensor is never triggered.

It would be nice if the extruder could spin slowly while the C0 command is executed and until the filament sensor on the bondtech gears is triggered.

@tonihoang, I mention you here just because maybe you can help with that :-)

Thanks a lot

[trocololo]

I'm trying to do something with that, but I need some help. Maybe someone is able to give me some tips.

Is there any way to spin the extruder until I say it should stop? I'm seeing what "execute_extruder_sequence" function does:

      current_position.e += <EXTRUDE_DISTANCE>;
      line_to_current_position(MMM_TO_MMS(fr_mm_m));
      planner.synchronize();

If I define an <EXTRUDE_DISTANCE> to a really high value, is there any function to cancel that movement at some moment?

[ellensp]

No on both questions. The concept of just rotating a stepper motor is not part of marlin, its always move distance X so send stepper calculated number of steps.

[trocololo]

Thanks @ellensp ,

Anyway, I figured out a way to do that. In the first tests it seems to work (I'm still testing it). I'm cleaning up a little bit the code and then I will share the changes.

I'm looping while C0 command is in progress and, as soon the sensor is triggered, I stop the loop and I call the "planner.quick_stop()" function. This clears all pending moves and also stops the current moves... so it seems to be perfect for this purpose.

Does anyone knows if there is some downside of using "planner.quick_stop()" method?

[trocololo]

Could someone check if there is something nasty in my PR, please? I didn't created a formal PR yet, I'm not used to do it, so it would be nice if someone could check the changes here.

The .custom files are my config files. I made it in that way to avoid pushing in the PR my config... not sure what's the best way to do that.

[trocololo]

The code is working, but when I'm managing some kind of timeout (C0 timeout for example), Marlin reboots by itself. It's like there is some bug. In original bugfix code the same is happening... so this is not something specific to my modifications.

Could someone help me with the debugging, please? Is there anyway to debug code in runtime? I'm just printing things through the serial, but it's really difficult and slow debugging like that.

Thanks

[thinkyhead]

The concept of just rotating a stepper motor is not part of marlin

I could try to design some motion.* routine that attempts to do this, by adding small (e.g., 0.25mm) moves to the planner each time a space in the planner buffer opens up, with up to -say- 4 concurrent blocks permitted in total, so the biggest overshoot would be 1mm. But, it would need to have a modest feedrate to be reliable, and would be best only applied to the extruder stepper.

[thinkyhead]

Marlin reboots by itself

If you go more than 4 seconds without calling one of manage_heater, idle, or watchdog_refresh the watchdog timer will expire and reboot the board as a safety measure against an infinite loop.

[trocololo]

Thanks a lot @thinkyhead , the 4 seconds without calling is a good tip for me. I think this is what happening, I will check it carefully.

Regarding to the function in motion, that sounds great. If this function could have somekind of parameter that stops the motion as soon as the filament sensor is triggered, that would be perfect for this purpose.

By now, I implemented something similar in the MMU code but with a different approach. I'm looking for movements pending in the planner, as soon there is no movements in the queue, I add one long movement. I do that until I detect the filament sensor is triggered. Once it's detected, I flush the planner queue and I also call "planner.quick_stop()" function in order to stop the current movement. I really don't know the consequences of that neither this is the best option to do that.

For me, with the motion function you said but adding a parameter to stop this movements as soon the filament sensor is triggered would be perfect.

Thanks for your help again

[thinkyhead]

Hmm, well we have the concept of homing with the other axes, where the move is killed as soon as an endstop is hit. So, perhaps we can treat the filament sensor in the same way, as "homing E." It might be a bit of a paradigm shift for E in the planner / stepper, in part because extrusion is not just a single axis operation. Something to explore…

[Legired]

Hello,

i currently have the same problem, did you find a solution ?

[BastR]

I've just upgraded to MK3S extruder, I've the same problem too. I'll try to separate the MMU mode into 2 separate files to have a better visibility for the code. I'll take this opportunity to include the extruder movement when loading the filament.

[trocololo]

Hello,

i currently have the same problem, did you find a solution ?

Yes, I implemented it in my branch, the link is in my previous reply.