Y axis moving when trying to move Z axis with multiple Z motors
-
Dont know why I didnt think of this before using the M584 command on its own spits out the drive mapping in the console. I never got around to actually testing the extruders but looks like those are mapped wrong as well. You can see in this photo I tried entering the M584 with the mapping command as well and the report after is also screwed up.
The first info from the M584 shows 0.0 and 0.1 mapped into the first two spots on the z axis followed by 0.5 and 0.4 this is using the last config line I was using which was "M584 X1.0 Y0.0:0.1 Z0.5:0.4:0.3:0.2 E1.1:1.2"
Then in the console I tried entering my original config of "M584 X1.0 Y0.0:0.1 Z0.2:0.3:0.4:0.5 E1.1:1.2" and it again results in 0.0 and 0.1 in the first two spots with 0.2 and 0.3 filling the last two.
And in both cases the extruders are mapped to 0.0 and 0.1 which I never noticed before as well
-
Try defining those connected to main board without 0. on front.
Ian
-
@droftarts No change in the result from removing the explicit board number, I also went ahead and threw in my other test of assigning all the Z motors to the Y axis to confirm that entering the mapping into the console was changing things and you can see the strange result from that as well. The Y axis is mapped correctly but both Z and E are incorrect.
-
Can you try mapping all drives individually in order, eg
M584 X0.0 Y0.1 Z0.2 U0.3 V0.4 W0.5 A1.0 B1.1 C1.2 P9
And see what it reports?The only other thing I notice is that in the RRF 3 overview notes, a comma is used to delimit the second board. Might be a typo, though? https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_M584
Ian
-
@droftarts Assigning them all individually like that they mapped correctly, the drive map report matched the mapping command.
I played around with it a bit more and I think whats happening has something to do with having multiple motors on two axis
I tried M584 X0.0 Y0.1:0.2 Z0.3 U0.4 V0.5 W1.0 A1.1 B1.2 P8 and that mapped correctly
However when I tried M584 X0.0 Y0.1:0.2 Z0.3:0.4 U0.5 V1.0 W1.1 A1.2 P7
the resulting map was X0.0 Y0.1:0.2 Z0.1:0.2 U0.5 V1.0 W1.1 A1.2
Also in all cases the extruders were mapped to 0:0 and 0:1 which I think is a default value since no E parameter was in the mapping
-
Yeah look at this one
M584 X0.0:0.1 Y0.2:0.3 Z0.4:0.5 E1.0:1.1
results in a reported drive map of
X0.0:0.1 Y0.0:0.1 Z0.0:0.1 E0.0:0.1 -
Yep. I just tried two axis with two motors each. Reproduced the issue.
12/21/2019, 7:02:51 PM M584 X0.0 Y0.1:0.3 Z0.4:0.5 U0.2 E0.3:0.4 12/21/2019, 7:02:58 PM M584 Driver assignments: X0.0 Y0.1:0.3 Z0.1:0.3 U0.2 E0.1:0.3, 4 axes visible
Z should be 4 5, instead it is repeat of Y's 1 3. E is wrong as well, again, a repeat of 1 3
Interestingly enough, it is OK to have multiple motors on Z and E. This is my day-to-day configuration on a tool changer:
12/21/2019, 7:06:11 PM M584 Driver assignments: X0.0 Y0.1 Z0.3:0.4:0.5 U0.2 E1.0:1.1, 4 axes visible
-
So, bug? One for @dc42? Thanks for getting to the bottom of it!
Ian
-
Certainly looks like a bug.
And I'm running what I believe to be the very latest:
Board: Duet 3 MB6HC (MB6HC) DSF Version: 1.1.0.5 Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta12+1 (2019-12-02b2)
-
Same thing happens if X has more than one motor, it "overlays" all later multimotor axis mappings.
12/21/2019, 7:12:02 PM M584 X0.0:0.3 Y0.1 Z0.4:0.5 U0.2 E1.0:1.1 12/21/2019, 7:12:08 PM M584 Driver assignments: X0.0:0.3 Y0.1 Z0.0:0.3 U0.2 E0.0:0.3, 4 axes visible
TRIPLE motor Z seems to work fine:
12/21/2019, 7:13:29 PM M584 X0.0 Y0.1 Z0.3:0.4:0.5 U0.2 E1.0:1.1 12/21/2019, 7:13:42 PM M584 Driver assignments: X0.0 Y0.1 Z0.3:0.4:0.5 U0.2 E0.3:0.4, 4 axes visible
However, DUAL motor Z overlays E:
12/21/2019, 7:14:39 PM M584 X0.0 Y0.1 Z0.4:0.5 U0.2 E1.0:1.1 12/21/2019, 7:14:45 PM M584 Driver assignments: X0.0 Y0.1 Z0.4:0.5 U0.2 E0.4:0.5, 4 axes visible
-
@Danal Triple motor Z also overwrote the E mapping
My best guess is that whatever values are getting used for multi motor mapping are not reset or filled or something between cycles of the code loop running
-
Yep, and it looks like it is the "single line parser" loop. Specifying each axis on a separate line yields proper results. For example, with this sequence, E never gets overlaid:
12/21/2019, 7:17:40 PM M584 Driver assignments: X0.0 Y0.1 Z0.3:0.4:0.5 U0.2 E1.0:1.1, 4 axes visible 12/21/2019, 7:17:45 PM M584 X0.0 12/21/2019, 7:17:58 PM M584 Y0.1:0.3 12/21/2019, 7:18:16 PM M584 Driver assignments: X0.0 Y0.1:0.3 Z0.3:0.4:0.5 U0.2 E1.0:1.1, 4 axes visible 12/21/2019, 7:18:34 PM M584 Z0.4:0.5 12/21/2019, 7:18:41 PM M584 Driver assignments: X0.0 Y0.1:0.3 Z0.4:0.5 U0.2 E1.0:1.1, 4 axes visible 12/21/2019, 7:18:54 PM M584 E1.0:1.1 12/21/2019, 7:18:59 PM M584 Driver assignments: X0.0 Y0.1:0.3 Z0.4:0.5 U0.2 E1.0:1.1, 4 axes visible
This also provides a bypass until this is fixed.
-
@Danal A workaround solution until things get a proper fix!! Fantastic. I was just about to ask what your day to day config looks like since in the example from before it E got overwritten but you had a working readout from your day to day.
-
@HWW said in Y axis moving when trying to move Z axis with multiple Z motors:
@Danal Triple motor Z also overwrote the E mapping
You are correct!!!
And I just looked in my actual config.g, and I'd separated the extruders because this is a toolchanger and I'm adding tools one at a time:
; Axis to driver mapping M584 X0 Y1 U2 Z3:4:5 ; X and Y for CoreXY. U for toolchanger lock. Z has three drivers for kinematic bed suspension. M584 E1.0:1.1 ; Extruders for four tools.
Man, a bullet dodged a few weeks back. That would have been VERY frustrating when I was trying to figure out a bunch of other stuff as well...!
-
I have added this as an issue to the github tracker
https://github.com/dc42/RepRapFirmware/issues/345 -
@HWW said in Y axis moving when trying to move Z axis with multiple Z motors:
I have added this as an issue to the github tracker
https://github.com/dc42/RepRapFirmware/issues/345It's probably a DSF issue not a RRF issue, because it doesn't happen when the Duet 3 is run in standalone mode.
-
It was an issue in RRF code that is only used when communicating with the SBC. Will be fixed in RRF3.0RC2.