3.6.0-beta.1 Breaking Homing Sequence

AndyE3D

@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

@AndyE3D First of all, thank you so much for your work on implementing this feature! Its been awesome for decreasing motor noise, as well as decreasing VFAs (especially below 100mm/s print speeds).

When I get the time, Ill be sure to do that. Im assuming that I would be able to run Serial Tools app from mac to do the same stuff on a Mac.

Im also getting one of the Vector 3D stepper motor analyzers. I don’t know if anyone has used that and has any input, but Ill be sure to report my findings.

Charlie

@AndyE3D This may sound simple, but how do I get the "v, a, cf" display in SBC mode? I enabled debugging using the M111 P4 S1 in dwc, plugged my computer into the USB port on the Duet, and I tried Serial Tools on a Mac, but I dont get any response. Im assuming that this may be correct for standalone mode, but not for SBC. Is this correct?

Charlie

@AndyE3D I also tried using YAT on a PC, and was unable to get a response from any commands that I made (like M122 or M115). Im assuming that this may have something to do with SBC mode, or Im making some other error in the setup.

Notepad

@AndyE3D Do we know what the M970.1 default 1000 and the M970.2 5000 values are relative to?
The documentation is a bit sparse on how the math is calculated.

Charlie

@Notepad I completely agree. "Acceleration/Velocity constant." Does not help much when trying to tune settings. I was hoping to be able to report back how the calculations are made after doing some testing (and reverse calculating the current factor), but without being able to get a debugging output Im unable to help.

Charlie

Does anyone have references to how this is implemented?

The only link I currently have is M970. Others with more info (particularly regarding how its calculated and tuned) would be greatly appreciated.

gloomyandy

@Charlie I don't think SBC mode will impact the USB interface to the Duet. You may need to try a different USB cable as for reasons I've never understood the Duet boards seem very sensitive to this. When you plug the cable into a windows PC do you see a new COM port being created (and hear the windows "new device" sound)? If you do you should see the device come and go in the windows device manager. I'd try opening that port using putty (rather than YAT as I've found YAT to be a little fussy with the terminal settings). If you use putty you will probably need to enable local echo (to see what you type) and also adjust the handling of newline to also perform a carriage return. See: https://teamgloomy.github.io/putty.html for more details (this is for the stm32 port of RRF firmware but pretty much all of it applies to the Duet).

AndyE3D

@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

@AndyE3D Thank you so much for posting this code. Im pretty new to code in general, but it looks like makes sense (unless im completely mistaken which is also possible). Looks like this is in GitHub: ReprapFirmware/src/Movement/PhaseStep.cpp, line 132 for others that may be looking.

After trying to put some of this in a spreadsheet (which Im sure is not the best way to go about this, but its what I kinda know), and putting in some velocity and acceleration values, Im struggling to get the PIDControlSignal value to be anything other than the 256 max value, which will in turn set the currentFraction to the max of 1.

Im not sure what Im missing here. Could be that the mParams arent actually as simple as the speed and accel in mm/sec(^2), I may have calculated holdCurrentFraction wrong (in PhaseStep.h as 0.71), or the default values are really conservative. Or something else that I cant think of.