Is your feature request related to a problem? Please describe.

Closed loop control needs to know how the encoder is mounted relative to the motor (i.e. is it on forward or backward)
To find this, it runs a tuning move.
If the encoder is found to be on backwards, the motor is set to run in reverse when in closed loop mode
This means that the 'forward' direction may not be the same in closed and open loop mode

Describe the solution you propose.

Describe alternatives you've considered

N/A

Provide any additional context or information.

N/A

Is your feature request related to a problem? Please describe.

Currently the TMCs are limited to 4.5A. However, we should allow a 'peak current' of 6.3A.
Setting a motor current higher than 4.5A is currently not supported.

Describe the solution you propose.

Support setting a current higher than 4.5A, but don't let this current run continuously. Further discussion is required around the limits here.

Describe alternatives you've considered

N/A

Provide any additional context or information.

See

Is your feature request related to a problem? Please describe.

Currently some tuning moves are greyed out and unavailable

Describe the solution you propose.

These tuning moves need writing 🎉

Describe alternatives you've considered

N/A

Provide any additional context or information.

The names & nature of each unimplemented tuning move can be found in src/ClosedLoop/Tuning.cpp

Is your feature request related to a problem? Please describe.

PID tuning is difficult and can lead to unstable oscillations

Describe the solution you propose.

An automated PID tuning routine, similar to that we already have for heaters

Describe alternatives you've considered

Currently we have manual tuning, but that has the issues outlined above

Provide any additional context or information.

A basic zeiger-nichols manoeuvre was implemented, but is currently not working so is #if falsed out

I want to know the speed of a motor thats configured to be in constant torque mode via M569.4

Sending a M569.4 command without the T parameter present should report back the currently applied torque of the driver

Is your feature request related to a problem? Please describe.

When in closed loop mode, the most error is introduced when changing acceleration.

Describe the solution you propose.

Given that we know when we're going to be changing acceleration, we could add in a feed-forward term to try to account for this, and hopefully reduce our error on acceleration change

Describe alternatives you've considered

N/A

Provide any additional context or information.

N/A

M569.4 will let us configure a speedlimit for closed loop stepper motors opperated in constant torque mode. It would be nice if a driver- warning event is raised when this happens. This would allow us to react to such a condition in the driver-warning macro

If a Roto MFM is configured using M591 but the magnet is too weak then the network interface to the main board becomes slow and disconnects frequently, making it unusable. Probably the MFM is sending continuous filament error notifications over CAN.

Is your feature request related to a problem? Please describe.

When tuning closed loop motors, only a single drive can be tuned at a time.
This means that multiple-driver axes may be put under strain/misaligned as only one drive moves.

Describe the solution you propose.

Synchronised tuning - where both motors move at the same time.

Describe alternatives you've considered

Disconnecting the drivers from the axes - but this isn't great for tuning purposes and is a lot of faff

Provide any additional context or information.

N/A

From Andy: I've been running a lot of tests on beta 3 and toolboards and I noticed that I was getting a lot of "other" out of sequence movement messages reported. Digging into the code it looks like the handling of the new movementLinearShaped message in the expansion board CanInterface.cpp file was a copy/paste of the older movementLinear message. Unfortunately this has left code that references the msg.moveLinear part of the message union rather than the CanMessageMovementLinearShaped part. In general this seems not to cause problems (as the two structures match the first few fields), however it does impact the seq number member (which is a different size) which then causes the large number of errors I have been seeing reported. I'm not 100% sure that this is the only problem, but I think it is.

Anyway I thought I'd message you about it before I forget and in case anyone else reports the large numbers of errors:
dup 0, oos 0/0/0/2760, bm 0, wbm 0, rxMotionDelay 768, adv 35269/107771

Remote filament monitor status goes from noData to OK to noData when the filament monitor is configured. Temporary fix done in RRF but the status changes are coming from the 1LC boards.

In Duet3Expansion/src/ClosedLoop/Tuning.cpp in line 80/81 iterationMultipler and PhaseIncrement are set, but they cancel out in line 83/84.

iterationMultipler can be 1 or 4, and PhaseIncrement can therefore be either 4 or 16. Either way, NumDummySteps is always 256/4 and NumSamples ia always 4096/4.