Open wakass opened 1 year ago
One of the things that comes to mind is implementing per-axis seek/feed rates for homing.
I guess this is only relevant for Trinamic drivers and would require only one axis to be homed per cycle unless axes share the same feed rate. To implement this in the least disruptive way I could add the per axis settings to the Trinamic driver and fetch the feed rates via the HAL from there. What do you think?
I have commited an update with per axis feed rates available for the Trinamic plugin. Note that this change needs verification.
Thanks! This is working pretty well. Separate homing also work nicely. I'm still getting some issues with my third axis using $H though..
e.g. with $43=1: $44=7 --> gives no homing and blocks presumably on the third axis. $44=3 --> homes correctly (but doesnt home the third axis)
with $43=2:
$44=3
$45=4
==> Homes the first two axes correctly in the first pass, and then appears to do 3! homing passes (2 seek, and 1 feed --> deduced from different sg_thresh set in $122)
Is this your issue? https://github.com/grblHAL/Plugins_motor/blob/45235049622cddf139f6c13cbfdfbcce612e9f49/trinamic.c#L1346-L1347
Try with homing each axis separately with e.g. $44 = 4, $45 = 2 and $46 = 1. $H
will then home each axis in sequence.
Yes (partially). This is also why i approached the 2-stage solution with $43. I think there's a funny bug where the amount of feed-homing cycles is dependent on $43. Moving from $43=2 to $43=3 and configuration as per your advice, also the x and y-axis now exhibit 3 feed-cycles (and the z-axis as well).
As a sanity-check I also set the trinamic feed/seek different from eachother.
trinamic_get_homing_rate()
makes too many assumptions about settings beeing valid.
Try this version:
static float trinamic_get_homing_rate (axes_signals_t axes, homing_mode_t mode)
{
axes.mask &= (driver_enabled.mask & trinamic.homing_enable.mask);
if(!axes.mask /*?? || mode == HomingMode_Pulloff*/)
return mode == HomingMode_Locate ? settings.homing.feed_rate : settings.homing.seek_rate;
uint_fast8_t motor = n_motors, axis;
float feed_rate = 0.0f, seek_rate = 0.0f;
do {
axis = motor_map[--motor].axis;
if(bit_istrue(axes.mask, bit(axis))) {
float feed_rate_cfg = trinamic.driver[axis].homing_feed_rate,
seek_rate_cfg = trinamic.driver[axis].homing_seek_rate;
if(feed_rate == 0.0f) {
feed_rate = feed_rate_cfg;
seek_rate = seek_rate_cfg;
} else if(!(feed_rate == feed_rate_cfg && seek_rate == seek_rate_cfg)) {
feed_rate = seek_rate = 0.0f;
break;
}
} else {
if(feed_rate == 0.0f) {
feed_rate = settings.homing.feed_rate;
seek_rate = settings.homing.seek_rate;
} else if(!(feed_rate == settings.homing.feed_rate && seek_rate == settings.homing.seek_rate)) {
feed_rate = seek_rate = 0.0f;
break;
}
}
} while(motor);
return mode == HomingMode_Locate ? feed_rate : seek_rate;
}
I wonder if an alarm should be raised or a new error code returned if homing is attempted with invalid settings values.
Didn't work for me unfortunately. When I get time i'll have to test/debug out a little more. For now the 3x homing is at least reliable :)
When homing specific axes, which have their max rate set lower than the locate/seek homing rate, the TCOOLTHRS is set according to the locate/seek homing rate. This leads to TCOOLTHRS being too low to trigger DIAG/stallguard output for the actual speed the motor is planned/run at.
I've implemented a fix for per-axis homing here but this could probably be done more elegantly: https://github.com/grblHAL/Plugins_motor/commit/fc04c058f3cc745183b9adfa3fd705ff89c07632
One of the things that comes to mind is implementing per-axis seek/feed rates for homing. Since also now I am limited also to seeking at the maximum speed of the axis.
(full homing $H still seems to be somewhat problematic for me. Running too slow? But this might be a separate issue.)