3.6.0-beta.1 Breaking Homing Sequence

adrian

@Charlie Does the iterations variable used in bed.g need to be defined?

oliof

@adrian iterations is a builtin keyword for loops.

Charlie

Its looking like more of a stepper motor/driver issue. Increasing the X/Y stepper motor current to 2380 mA allows me to run the homing sequence and have 600mm/s travel speeds with 7000mm/s^2 accels.

I think my biggest question now is what all the new parameters do. Im using the Forum, GCode Dictionary and the github changelogs to get most of my info.

Any more info on what M970.1 and .2 do? My assumption is that the speed and accel "constant" is like the slope "m" on a y=mx+b style graph, where "b" is min stepper current (motor idle current set by M906?), and the actual current set is the maximum of either the 970.1 and 970.2 lookup values. Im really in the dark regarding this stuff though, so please let me know if I'm completely wrong.

AndyE3D

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.

AndyE3D

@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

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.

Charlie

@AndyE3D And yes, making sure that DTR was enabled solved my issue with connection! Thank you so much. I can now use YAT on the PC to send and receive commands using a direct USB connection to the Duet.

Now my issue is that, although I can connect and send an M122 command and get an output, once I send M111 P4 S1, every time I send a move command (like G91 G1 H2 X10 F3000) I get a "Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)", and then a "Warning: SPI connection has been reset". Then it seems to restart, as the machine is no longer homed.