Fixed Time Motion: Fix switching on or off FTM when printing

[narno2202]

Description

Changing motion system during a print is a bad idea but a long time ago, switching on or off FTM was possible. Now it's broken and the printer freezes.
As we can't switch on or off FTM via the tune menu, we need to disable M493 S0 or M493 S1 when printing .

Requirements

Benefits

Configurations

Related Issues

[thisiskeithb]

Changing motion system during a print is a bad idea but a long time ago, switching on or off FTM was possible. Now it's broken and the printer freezes.

That should be fixed instead of using a workaround/disabling it.

cc: @ulendoalex

[narno2202]

I agree but actually you can't switch on or off FTM when you print via the tune menu (which is a good idea). Blocking M493 S function during a print does the same. I am currently investigating this issue, but some help will be fine.

[gudvinr]

How you define "during the print"?
In general, printer has no idea which state it's in.

From the human perspective, "print" is something that produces physical part. But:

• there are multi object prints
• you can concat gcode files together
• often people stream gcode to uart (octoprint/uart displays)
• you can do moves without extrusion/heating for testing purposes

I don't think you can clearly define concept of "print" given that it's just a stateless stream of commands. At least not without assumptions that will break in one or all of the cases I mentioned

[thisiskeithb]

How you define "during the print"?
In general, printer has no idea which state it's in.

The printer may not be sentient yet, but printer_busy(), it's defined as follows:

Marlin/Marlin/src/MarlinCore.cpp

Lines 327 to 329 in 0ec1a54

	bool printer_busy() {
	return planner.movesplanned() || printingIsActive();
	}

...and printingIsActive():

Marlin/Marlin/src/MarlinCore.cpp

Lines 336 to 339 in 0ec1a54

	/**
	* Printing is active when a job is underway but not paused
	*/
	bool printingIsActive() { return !did_pause_print && printJobOngoing(); }

So there are ways to tell if the machine is doing something.

[gudvinr]

printingIsActive():

From what I see, printJobOngoing relies on M76/M77 when not printing from SPI-attached SD. For that slicer needs to emit said gcodes and print job needs to be enabled (but it is enabled by default from what I see).

So, it is not a very reliable method which will only work for a subset of printers AND subset of printing sources.
If FTM requires printingIsActive to be false, then it won't work for octoprint users unless they also modify their setup to support print jobs.
If it's not necessary, then checking for movesplanned will be enough and won't introduce subtle issues when you change between sources.

[narno2202]

When I say during a print, it means when the effective print has begun.

1. Freeze is related to planner.synchronize() call in M493. This call also causes little gaps when you print the ringing tower. Removing it, solves freezing and has no other incidence.

2. The reset flag (flag.reset_ft) in M493 as also no effect with the new buffer management systetm and could be removed

3. ftMotion_syncPosition() call is useless with the new buffer system

Applying these changes allows enabling FT_MOTION during an ongoing printing job without freezing or layer shifting. Disabling FT_MOTION is still buggy.

[narno2202]

After some tests and searches, the call to stepper.ftMotion_syncPosition() must be done before the new FT_MOTION status affectation (ftMotion.cfg.active = active) in M493 function, planner.synchronize() is also called in stepper.ftMotion_syncPosition().
Now switching back and forth FT_MOTION when a print job has begun is again available.

[thinkyhead]

Are we certain that changing any of the above parameters does/will not require ftMotion.reset() to recalculate something/anything based on the updated parameter(s)?

[thinkyhead]

Seems like a smart idea to synchronize before modifying the parameters that ftMotion uses to do its motion. Are we certain it is / will always be safe to call update_shaping_params while a move is still ongoing?