@Charlie one other thing to verify relating to you homing/motor stalling issue is the actual current that is being applied to the motors. Can you send the response from M569 P{driver_num} and M906 please. Make sure that M569 is sent soon after a move so that the current has not been reduced by the M906 idle current reduction

@Notepad @Charlie this is the equation that uses the acceleration & velocity constants

float PhaseStep::CalculateCurrentFraction() noexcept
{
	// Driver is in assisted open loop mode
	// In this mode the PID terms are not used and the A and V terms are independent of the loop time.
	constexpr float scalingFactor = 100.0;
	constexpr float scalingFactorSqr = scalingFactor * scalingFactor;
	PIDVTerm = mParams.speed * Kv * scalingFactor;
	PIDATerm = mParams.acceleration * Ka * scalingFactorSqr;
	PIDControlSignal = min<float>(fabsf(PIDVTerm) + fabsf(PIDATerm), 256.0);

	currentFraction = holdCurrentFraction + (1.0 - holdCurrentFraction) * min<float>(PIDControlSignal * (1.0/256.0), 1.0);
	if (reprap.GetDebugFlags(Module::Move).IsBitSet(MoveDebugFlags::PhaseStep))
	{
		debugPrintf("v=%f, a=%f, cf=%f\n", (double)(mParams.speed * scalingFactor), (double)(mParams.acceleration * scalingFactorSqr), (double)currentFraction);
	}
	return currentFraction;
}

The units, calculation, and tuning are almost identical to assisted open loop on the 1HCL board with the main difference being it does not have the encoder to warn about skipped steps (stall detect also does not work when phase stepping), and the Kp & Kd terms are not used.

In YAT make sure that you have enabled DTR if you are running the latest firmware as the USB code was changed recently. I don't know if there are other difference connecting to the Duet on MacOS

@Notepad @Charlie this is the equation that uses the acceleration & velocity constants

float PhaseStep::CalculateCurrentFraction() noexcept
{
	// Driver is in assisted open loop mode
	// In this mode the PID terms are not used and the A and V terms are independent of the loop time.
	constexpr float scalingFactor = 100.0;
	constexpr float scalingFactorSqr = scalingFactor * scalingFactor;
	PIDVTerm = mParams.speed * Kv * scalingFactor;
	PIDATerm = mParams.acceleration * Ka * scalingFactorSqr;
	PIDControlSignal = min<float>(fabsf(PIDVTerm) + fabsf(PIDATerm), 256.0);

	currentFraction = holdCurrentFraction + (1.0 - holdCurrentFraction) * min<float>(PIDControlSignal * (1.0/256.0), 1.0);
	if (reprap.GetDebugFlags(Module::Move).IsBitSet(MoveDebugFlags::PhaseStep))
	{
		debugPrintf("v=%f, a=%f, cf=%f\n", (double)(mParams.speed * scalingFactor), (double)(mParams.acceleration * scalingFactorSqr), (double)currentFraction);
	}
	return currentFraction;
}

The units, calculation, and tuning are almost identical to assisted open loop on the 1HCL board with the main difference being it does not have the encoder to warn about skipped steps (stall detect also does not work when phase stepping), and the Kp & Kd terms are not used.

In YAT make sure that you have enabled DTR if you are running the latest firmware as the USB code was changed recently. I don't know if there are other difference connecting to the Duet on MacOS

@Charlie one other thing to verify relating to you homing/motor stalling issue is the actual current that is being applied to the motors. Can you send the response from M569 P{driver_num} and M906 please. Make sure that M569 is sent soon after a move so that the current has not been reduced by the M906 idle current reduction

@Charlie the easiest way to tune the phase step parameters is to connect a USB cable to the Duet with a program like YAT or Putty and enable debugging with M111 P4 S1 (disable it again after you are done). Then do a move with a phase stepped axis and it will print an output like this:

The v is velocity, a is acceleration, and cf is current fraction (what the M906 value will be multiplied by for that point in the move.

You can tweak the M970.1, M970.2 & M917 parameters untill you are happy with the max speed/acceleration and noise that the motors are making

Hi @Charlie, I added the new phase stepping feature but it is still experimental. Phase stepping is disabled by default unless you run M970 {axis letter}1 (note that it is currently only supported on 6HC mainboard drivers).

One of the benefits of phase stepping is lower motor noise. In the 3.6.0-beta1 release this is done my controlling the motor current based on speed and acceleration.
M970.1, M970.2 & M917 allow setting the scaling factors for this equation. For example, you may find that you want higher current when accelerating/decelerating to prevent stalling but a lower current when moving at steady speed to reduce noise. M917 sets the minimum current percentage based on the M906 value. The current will never exceed the M906 value.

If you want to use phase stepping then please do give feedback on how you find it performs. It should be safe to use but limited print comparisons have been done at this point.

As for your issue, it sounds like increasing the motor current fixes it? If so my guess would be the new input shaper is causing a move to achieve slightly higher accelerations/speeds than it did in 3.5 which could have caused a motor stall.

@leone Can you share the user manual you are using as "microstepping look-up table" also isn't in the one I have from the software
.

I also don't have an evaluation board so I might need you to try and change the sliders and share with me what each one does if you are happy to help me with that?

@leone I am trying to understand what the phase modulation settings in TMCL-IDE are doing exactly but I can't see any reference to it in the user manual.

• What steps did you take to get that window in TMCL-IDE?
• Are you using a physical dev board (if so which one), or are you simulating the board with a virtual module in the IDE (again which one)?

@Leonard03 said in M574 can't disable pin:

tpostX.g -> /errorAction.g -> /loadToFinda.g -> /loadToBondtech.g -> /loadToNozzle.g

Since you have a lot of nested macros, I think the actual control flow is more complex than you have shown here. Try adding an echo command to the start of each macro in the MMU Control folder to help find what file the error is actually in.

This error Error: G1: Failed to enable endstops can only occur with a G1 H1/3/4 command which is not present in loadToNozzle.g, which implies (at least part of) the issue is in some other macro

Can you send the full console output of the macro calls that: a) work, b) do not work

@Leonard03 I think I have found your issue.

I file sys\MMU Control\getBondtechStatus.g you have

M574 V0 P"^!e0stop" S1 ; use bondtech sensor as V endstop

if sensors.endstops[4].triggered
	set global.statusBondtech = 1
else
	set global.statusBondtech = 0

M574 U0 P"nil"         ; free up exp.e2stop pin

I think the final line should be M574 V0 P"nil"

In errorAction.g, getBondtechStatus.g is called before loadToFinda.g which is probably what is causing the Duet to get into the mess

elif global.errID = "FSENSOR_DIDNT_TRIGGER"
	while iterations < 2
		M98 P"0:/sys/MMU Control/getBondtechStatus.g"
		if global.statusBondtech = 0
			M98 P"0:/sys/MMU Control/unloadToFinda.g"
			M98 P"0:/sys/MMU Control/getFindaStatus.g"
			if global.statusFinda = 0
				M98 P"0:/sys/MMU Control/unloadToPTFE.g"
				M98 P"0:/sys/MMU Control/getFindaStatus.g"
				if global.statusFinda = 0
					M98 P"0:/sys/MMU Control/loadToFinda.g"
					if global.errID = null
						M98 P"0:/sys/MMU Control/loadToBondtech.g"
						if global.errID = null
							M98 P"0:/sys/MMU Control/idlerMove.g" S5
							M98 P"0:/sys/MMU Control/loadToNozzle.g"
			else
				M99

Please let me know if it is a typo or intentional. And if my suggestion fixes the issue.

@Leonard03 Are you able to change the endstop pin from duex.e2stop to one on the Duet 2 and see if the issue is still present?

@Leonard03 I'm having a look at your config to see if I can reproduce the issue.

Something probably not related but worth fixing that I noticed scrolling through, is on line 146 in config.g, I think you have a typo G10 P3 X0 4Y0 Z0 ; set tool 3 axis offsets