Solved 4x Z motors moving different amounts for one Z command
-
We're almost there on my Duet 3 powered Voron 2.4. Everything is working, except I've got a weird issue where sometimes I get one of my 4x z motors to move a lot more than the other 3 for one Z command. I've got the Z probe setup now with sensorless homing on X and Y, but right now I can't figure out why my back left Z motor is moving way more than the others for a given Z command. It also seems to only do this in positive Z movements, not for negative ones. Here's my config file to look over, can anyone find an issue that would cause the Z motors to not all move the same amount for a given command? The Z motor that is behaving differently is connected to the HC6 mainboard, the other 3 are on the 3HC. Is there something else I need to do to define steps/mm or something like that?
; Configuration file for Duet 3 MB 6HC (firmware version 3.3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.3.16 on Tue May 16 2023 19:10:31 GMT-0500 (Central Daylight Time) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"Voron2" ; set printer name G4 S2 ; wait for expansion boards to start M669 K1 ; CoreXY M569 P0.0 S1 D2 ; driver 0.0 goes forwards (X axis) D2 - Spreadcycle M569 P0.3 S0 D2 ; Driver 0.3 goes forward (X axis, AWD) D2 - Spreadcycle M569 P0.1 S1 D2 ; Driver 0.1 goes forward (Y axis, AWD) D2 - Spreadcycle M569 P0.2 S1 D2 ; driver 0.2 goes forwards (Y axis) D2 - Spreadcycle M569 P0.5 S1 D2 ; Driver 0.5 goes forward (Z axis - 1) D2 - Spreadcycle M569 P1.0 S1 D2 ; Driver 1.0 goes forward (Z axis - 2) D2 - Spreadcycle M569 P1.1 S0 D2 ; Driver 1.1 goes forward (Z axis - 3) D2 - Spreadcycle M569 P1.2 S0 D2 ; Driver 1.2 goes forward (Z axis - 4) D2 - Spreadcycle M569 P121.0 S1 D2 ; Driver 121.0 goes forward (E axis on 1LC) D2 - Spreadcycle M584 X0.1:0.2 Y0.0:0.3 Z0.5:1.0:1.1:1.2 E121.0 ; set axis mapping M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X300 Y290 Z280 S0 ; set axis maxima M671 X-65:-65:320:320 Y-20:350:350:-20 S20 ; Define Z belts locations (Front_Left, Back_Left, Back_Right, Front_Right) M92 X80.00 Y80.00 Z400.00 E690.00 ; set steps per mm M566 X600 Y600 Z30 E600 ; set maximum instantaneous speed changes (jerk) (mm/min) M203 X60000 Y60000 Z6000 E7200 ; set maximum speeds (mm/min) M201 X8000 Y8000 Z1000 E3000 ; set accelerations (mm/s^2) M906 X1600 Y1600 Z800 E1200 I30 ; set motor currents (mA) and motor idle factor in per cent M84 X Y E S10 ; Set idle timeout ; Motor Idle Current Reduction M906 I30 ; set motor current idle factor M84 S30 ; set motor current idle timeout ; Fans M950 F0 C"121.out2+out2.tach" Q450 ; create fan 0 on pin out5 and set its frequency M106 P0 S1 H1 T45 ; set fan 1 value. Thermostatic control is turned on M950 F2 C"OUT_8" ; Create fan 2 - Chamber fan M106 F2 S0 M950 F3 C"OUT_7" ; Create Chamber lights M106 P3 S0 ;Heaters & Temp sensors M308 S1 P"121.TEMP_0" Y"PT1000" ; configure sensor 1 as thermistor on pin temp1 M950 H1 C"121.out0" T1 ; create nozzle heater output on out1 and map it to sensor 1 M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit M143 H1 S350 ; set temperature limit for heater 1 to 350C M308 S0 P"temp0" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin temp0 M950 H0 C"OUT_1" T0 ; create bed heater output on out1 and map it to sensor 0 M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 ; Tools M563 P0 D0 H1 F0 ; define tool 0 G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C ; Endstops M574 X1 S4 ; setting up sensorless homing M574 Y1 S4 ; setting up sensorless homing M915 X Y R0 F0 S3 ; https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection ; Z-probe - Klicky PCB M574 Z1 S2 M558 P8 C"121.io1.in" H3 F1000 T6000 ; Miscellaneous M501 ; load saved parameters from non-volatile memory -
@michaelr123 i guess it doesn't like Z being spread across boards.
My advice would be move all the Z to the 6HC and move either the X or Y to the 3HC -
Problem is that I’ve got 4x motors on the x and y for an awd setup. I don’t want to run into the same issue on my gentry system either.
Here’s an idea, what if I do 2x X motors on the 6HC and 2x Y motors on the 3HC? Then keep all the z motors together on the 6HC?
Any body that’s done an AWD setup have any input here?
-
@michaelr123 that's what I said. Move either the X or Y to the 3HC.
I've done 4WD but I was running a board with 8 driver sockets and only needed 1 z -
Seems to be working well now, thanks for the recommendation!
Unfortunately, sensorless homing isn't working now. I can home to Y no problem, but when I home to X it will not trigger as an endstop. If I turn on R1 parameter it's definitely reading that motors are stalling. Is there any chance I have the X and Y motors flipped and backwards or something like that and the sensorless endstop is looking for stalls on the wrong motors? Or does S4 on a corexy look at all the X and Y motors?
; Endstops
M574 X1 S4 ; setting up sensorless homing
M574 Y1 S4 ; setting up sensorless homing
M915 X Y R0 F0 S3 -
Firmware version?
Can you post your full config and homing file? -
-
@michaelr123 I don't think sensor less works with expansion boards yet
https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations#temporary-limitations -
ahhh that's definitely what it is. So the motors on the expansion board aren't being red as an endstop... Any chance 3.5 is adding that feature?
Might have to using one wire on the gantry for endstops after all...
-
@michaelr123 looks like it's planned for 3.6
Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is
-
Gotcha,
I tried moving 2 z motors back to the HC3 so I could get the 4 XY motors on the 6HC. Sensorless homing works great and after power cycling the board I'm not getting the weird behavior where one set of of Z motors moves at a different rate than the other two. It's definitely something going on over the CAN connection as I saw 2 motors display the weird behavior instead of just the one.
I'll keep running it this way so I can avoid the extra wire
-
Update on this, it seems like anytime you change config code that affects the endstops or the drive mapping you get this weird behavior when you just run the config file. If you completely reset the board or power cycle it everything behaves just fine.
Long story short you can run 4x Z motors split across a can connection, but you need to fully power cycle between config updates.
-
@michaelr123 Remember that running config.g does not reset things back to the default state before you run it. So anything that you do not explicitly set in the config.g will just keep whatever setting it may have had before you ran the config.g. Some commands may also not execute correctly (for instance if you had already assigned a pin in the old config.g, it may not be free if you try to use it for some other purpose in the new config.g). Personally I always reset things when making changes to config.g, just to be sure.
-
undefined Phaedrux marked this topic as a question
-
undefined Phaedrux has marked this topic as solved
