G92 doc disparity and a M584 feature request

ampex_fhm

Hi,
I recently played around with dynamically mapping around my 4-drive z axis to give me individual control over the steppers. I ran into two things:

The documentation for G92 states "A G92 without coordinates will reset all axes to zero." This is not true for the current stable release (1.21) as far as I can tell from the behavior and the source code on github.
When doing drive mapping, all sorts of funky things happened to me when remapping the 4 drives mapped to the z axis back and forth (i.e., I go back and forth between having 4 drivers assigned to Z and then having them assigned to U V W A). This behavior included some of the steppers trying to travel huge distances when I swapped to the UVWA configuration, made small adjustments, swapped back to quad-Z and then tried to perform a small movement. I suspect this was due to the fact that I did not properly "unmap" the Z axis drivers, which caused the drivers to be assigned to multiple axis and doing all kinds of weird stuff.

Here's a braindump of suggestions regarding point 2:

Allow to unmap a certain axis (a workaround to this is currently to map the axis to an unused driver, which may be infeasible for a setup that uses all drivers) by being able to pass a "-1" as the drive number. This axis then does not track any changes made to the drivers that were previously assigned to it.
Unmap all axis that are not mentioned in the M584 call (this adds some overhead because one has to mention i.e. the X and Y axis everytime even if the mapping doesn't change.
Reset all axis that have received new mappings to zero upon remapping, as well as the underlying movement housekeeping to avoid that a newly created drive mapping carries any previous state into the motion system.

Thanks for your consideration. If the issues I am seing are due to me not using the provided facilities correctly please forgive me.

FHM

dc42

Thanks for that, I have corrected the documentation of G92.
I plan to make the following changes to M584:

Allow an axis to be mapped to drive -1 as you suggest;
When mapping an axis or extruder to a driver, remove that driver from any existing mapping.

ampex_fhm

@dc42 thanks for the swift response. Some input regarding the second bullet of your second list point:

As I mentioned, I use a quad-z setup on my printer to lift my gantry. When powering off the printer, the gantry drops by inequal amounts (due to unbalanced weights and print head position during power down) which is why I have been using drive remapping to temporarily create a (FRONT_PAIR, LEFT_PAIR, REAR_PAIR, RIGHT_PAIR) driver mapping to bring the gantry into sufficient alignment before performing precise leveling using G32.

According to your description, this will not be possible anymore after you make those changes, since one driver can then only be mapped to one axis (my example requires one driver to be assigned to two axis simultaneously). I am not sure if this is the way to go as there may be some upcoming machines that make use of the fact that two axis can share a driver.

dc42

If you are trying to drive e.g. front pair and left pair simultaneously (with a common front left motor shared by them), that is not going to work properly. But assuming you are not trying to do that, surely you can use M584 to switch between front/back pairs and left/right pairs?

ampex_fhm

true, but wouldn't that also require a separate M584 call everytime I want to jog a different axis?

right now I'm using a workflow like

M584 ... (set up all four pairs with overlapping drive assignments)
G0 FRONT_PAIR 
G0 RIGHT_PAIR 
G0 REAR_PAIR
M584 ... (restore drive mapping for normal operation)
<normal operation>

If I understand correctly, your suggestion would require to change this to:

M584 ... (set up mapping for FRONT_PAIR movement)
G0 FRONT_PAIR
M584 ... (set up mapping for RIGHT_PAIR movement)
G0 RIGHT_PAIR
M584 ... (set up mapping for REAR_PAIR movement)
G0 REAR_PAIR
M584 ... (restore drive mapping for normal operation)
<normal operation>