delta Z motor goes clunk, regardless of motor or driver
-
@droftarts thanks. I'm out of reach of the machine for a couple of days, so it will be a little while. I don't think you'd miss the clunk if it occurred - it's enough to make the print head visibly quiver on my printer.
-
@droftarts I've tried playing with accelerations, and there's a clear correlation, but not a helpful one (not one that lets me avoid the clunk).
To recap: with accelerations = 1200, at Y=-65, it doesn't clunk for movements to X=12 to X=26 inclusive, but does for all other coordinates.
I've tried various other accelerations and there is clearly a correlation. This is maximum (orange) clunk-free movement and minimum (blue) clunk-free movement against acceleration. So no clunk between the lines, but clunks outside them.
(at A = 300 I can't detect any movement at all at the lower limit, clunking or not)I note that you refer to bearings sticking - I have none, the motor clunks with nothing connected, so I'm confident it's not mechanics-related (i.e. not bearings, belts, interference, etc).
I've taken a video to show the difference between clunk and noclunk - there's no mistaking whether it clunks or not, the video is playing a move to 26, then one to 27, then one to 26, then one to 27. This is with the original 1200 acceleration where 27 clunks and 26 does not: https://vimeo.com/955477735
; test clunking for varying coordinates G1 X0.00 Y-65 F9000 G4 P100 G1 X26 Y-65 G4 S3 G1 X0.00 Y-65 F9000 G4 P100 G1 X27 Y-65 G4 S3 G1 X0.00 Y-65 F9000 G4 P100 G1 X26 Y-65 G4 S3 G1 X0.00 Y-65 F9000 G4 P100 G1 X27 Y-65 G4 S3
-
If you swap the motors around does it follow the motor or the driver?
-
I remember I had a similar problem with 3.4b6. It was fixed in 3.4b7. It was something with calculations of steps for deltas.
-
@Phaedrux it's on the Z-tower motor, regardless of which physical motor or which driver that is. I've tried three different motors and four of the drivers on the 6HC board, in various combinations, whatever is defined as Z-tower motor clunks. The motors and drivers that clunk when they are Z do not clunk when they are X or Y.
-
@achrn I'll set up a bench test with a 6HC and generic NEMA17 motors, and test standalone and SBC, using your config.g. Do you have a config-override.g as well?
Ian
-
@droftarts no, no config-override.
I've tried taking teh test case that clunks and rotating it 120 degrees about the global z-axis, and running taht to see if teh X tower motor then clunks. All teh moves are then teh same relative to X tower as teh clunking case were relative to Z tower. However, when I do that, nothing clunks.
This is my rotated test case:
; test clunking for varying coordinates ; rotated 120 degrees about Z G1 X56.292 Y32.500 F9000 G4 P100 G1 X43.292 Y55.017 G4 S3 G1 X56.292 Y32.500 F9000 G4 P100 G1 X42.792 Y55.883 G4 S3 G1 X56.292 Y32.500 F9000 G4 P100 G1 X43.292 Y55.017 G4 S3 G1 X56.292 Y32.500 F9000 G4 P100 G1 X42.792 Y55.883 G4 S3
-
@achrn said in delta Z motor goes clunk, regardless of motor or driver:
It's MB6HC (with toolboard) in SBC mode (Pi 4) running bookworm DuetPi and 3.5.1 firmware. It also clunks with 3.4.2 firmware and an older DuetPi.
Have you tried in standalone mode? Would you be able to go back through firmware versions to see if there is one were it doesn't happen? Totally understand if that's too much testing to try.
-
@achrn Okay, I set up a bench test with a 6HC on 3.5.1 with 3 large NEMA stepper motors, running standalone. I ran the clunking test from your post here https://forum.duet3d.com/post/340420
I get the rough/clunking Z move on the 4th and 8th move of that macro, just like your video. I noticed you were running input shaping, and the clunk disappears as soon as I turn this off withM593 P"none"
and rerun the test. So looks like an input shaping issue. I didn't try any other changes to your config.g. I'll report it to @dc42 for investigation.Ian
-
@droftarts Aha! Excellent, thank you. I was just about to figure out how to try it standalone, following @Phaedrux 's request. I confirm that if I run mine SBC mode without input shaping I have no clunks. Since the cause has been narrowed this far and repeated by someone else, I'm not inclined to work back through old firmware versions, unless really likely to make teh difference between solving it and never resolving it, but I could try some older versions if it will make a big difference to tracking down the problem - please let me know.
Input shaping as the 'cause' stacks up because I only relatively recently put on a toolboard, and it's only when I got the toolboard (with the accelerometer) that I enabled input shaping. So although I hadn't made the connection that that's when clunks started, with hindsight it's very credible it was at about that time. I don't run it fast enough to really need input shaping anyway - the quality enhancement is debatable, and it's more a case of enabling it because it's there, so disabling it is not a hardship.
Thanks everyone for input, I'm now clunk free (though I also have a printer in pieces, so I need to spend some time re-assembling).
-
It occurred to me to check some other input shapinng:
M593 P"zvd" F37
clunks more softly and at different movements: in the 1200 acceleration case (which clunks under zvddd other than 12-26) it clunks for movements above xval=22M593 P"zvdd" F37
clunks intermediately loudly, but at different movements: in the 1200 acceleration case (which clunks under zvddd other than 12-26) it clunks other than xval=8-24So I also tried varying teh frequency
M593 P"zvddd" F74
andM593 P"zvddd" F18
both clunk and not-clunks differently toF37
-
@achrn Thanks. I've raised an issue for this on Github: https://github.com/Duet3D/RepRapFirmware/issues/1015
Ian
-
Hello. I have a duet2Wifi Delta. Have the same problem after update on 3.5.2, 3.5.3 Release Candidate 1 problem too. When I switch off input shaping M593 P"none" all axis moving without clunk.
Do you have solve for this bug? -
@SPAX thanks for your report.
TBH although it appears that there is a bug in this area, we might not fix it for the following reasons:
- Input shaping has been completely reimplemented 3.6 than in 3.5 and works much better. We have no reports of a similar bug in 3.6.
- It's likely that tracking this bug down would require substantial effort, which ultimately would be wasted because the 3.6 code is completely different.
- Delta printers typically have little or no need for input shaping because their resonant frequencies tend to be higher.
Of course, if anyone else tracks this down and supplies a fix that we can validate, we will gladly include it in a future 3.5.x release.
If you are brave enough then I suggest you try RRF 3.6.0-alpha.5 on your machine. Or you can wait for 3.6.0-beta.1 which I estimate is 2 weeks away.