Bad Vibrations through printer

samlogan87

Here is a video. Basically the very start of it is how the print will start no matter the F value. I then change the two steppers to a different value and it stops making the noise and goes quiet. I was extruding into thin air when I did this but it is the same when it is printing.

https://youtube.com/shorts/_EP5Q8Ma0PQ

Cheers
Sam

A Former User

This post is deleted!

dc42

@samlogan87 I suggest you try using individual motor moves (G91 followed by G1 H2 Xxx or G1 H2 Ynn) to see whether the vibrations are associated with just one of the motors.

deckingman

@dc42 said in Bad Vibrations through printer:

@samlogan87 I suggest you try using individual motor moves (G91 followed by G1 H2 Xxx or G1 H2 Ynn) to see whether the vibrations are associated with just one of the motors.

David. Looking at Sam's video it seems the part is 45 degrees from rear right towards front left, then another 45 degree move at 90 degrees in the opposite direction and the harsh vibration is present during both moves. So the machine being a CoreXY, I'd say it looks like both motors are equally affected.

deckingman

@samlogan87 Sam. I don't have much of an idea but watching your video, it seems to me as if the motors resort to full steps rather than micro-stepping when the harshness is apparent. I could be wrong but it might be a clue???

Phaedrux

How much tension is there from the tubing going to the print head? Seems to vibrate more as the tubes are bent more.

o_lampe

@Phaedrux The noise is gone, after the tool changed direction, even with the tubes still stretched out.
My shot from the hip: It's a belt walking up or down an idler until it rubs on something while moving left. When the tool moves right , the belt walks in the opposite direction.

samlogan87

Hey everyone,

Thank you for your input thus far. @dc42 as @deckingman mentioned, it is doing it with both motors. @Phaedrux as @o_lampe said, I don't think it is the water cooling pipes as the fittings on the hot end swivel.
@o_lampe I don't think it is that as when I make an adjustment as below, it stops for the entire rest of the print

To elaborate more I guess. If I run the print normally, it will make that sound throughout the entire print. If I change the F parameter in the M569 for the two motors on the fly while printing via the console(eg both to 10), it instantly stops. After I finish a print and I add that value I sent via the console while printing to the config.g file and print again it will make that noise even though it stopped it the first time. Changing the value to something else via the console while printing fixes the issue( eg 11). If I repeat above with this new value it still does it again.
It is something to do either with the motors or the drivers as I can not see how it could be mechanical when by making that adjustment it stops it for the entire rest of the print. I am running the motors on 1HCL boards and I am wondering whether maybe there is something strange going on there. I will try and get the encoders sorted this week, however, I am not wanting to spend too much time on it just in case it causes me issues trying to tune them as well.

Pretty stumped with where to go from here.

Cheers
Sam

deckingman

@samlogan87 To test my theory about the motors sounding like the drivers are reverting to full step mode, try a print with micro stepping set to 1. If my theory is right, then it should sound harsh throughout and changing the F parameter should have no effect. I could be miles off, but it's a quick test and might provide another data point as to the cause.

o_lampe

@samlogan87 With the new information at hand, I think the settings in config.g are ignored, maybe because the communication between main controller and 1HCL isn't established at that time.
That's why sending the M569 line again via DWC works.
There was a bug regarding 'steppers run wrong way' popping up regularly, which was also caused by missed coms between boards.

One workaround could be to put these M569 lines in the start code of the slicer or wait and see, what the devs will suggest. ( eg. G4 dwell time in config to give more time for controllers to establish coms?)

samlogan87

So I played around again with it. Changing the dwell at the start to 10 seconds did not fix it and I also tried single micro stepping and it was unbelievably noisy so I am still at a loss. @dc42 Is there anything else I could try? I tried not defining the F parameter at all in the config.g file and it is still the same behaviour.

Cheers
Sam

Phaedrux

Do you have the specs of the motors?

samlogan87

@Phaedrux they are the LDO 2504AC motors. The specs can be found here. Mine have extended shafts for encoders

https://caribou3d.com/en/stepper-motors/843-18-stepper-motor-ldo-42sth48-2504ac.html

Basically max current is 2.5A, phase resistance is 1.2ohm, inductance is 1.5mH, torque is 55n-cm

Cheers
Sam

mrehorstdmd

@samlogan87 I watched the video. Is it accurate to say that the noise occurs mainly/only when the extruder is near the corner of the bed?

Can you post more photos of the printer, especially the belt layout of the XY mechanism?

samlogan87

@mrehorstdmd unfortunately it has nothing to do with the position on the bed or the belts. If you read a couple of replies above, by changing the f parameter in the M569 for the two motors the problem stops and it is quiet throughout the rest of the print no matter where it is on the bed. I only put a short video up to show how changing the parameter fixes the issue and it seems to only be applied when there is a direction change which is why I think people think it has to do with the area on the bed or the belts.

Cheers
Sam

Phaedrux

From DC42: we know that some motors are unpleasantly noisy with the 1HCL and we have significant improvements in the works for 3.5beta4.

Meanwhile, here are some tips on reducing noise in such cases:

Use a much lower P value than the auto tune suggests, e.g. 1/3 as much. You may have to accept slightly larger error bounds (M569.1 E parameter).
If running firmware 3.5.0beta2 or later, there is a new V parameter in the M569.1 command. A V value of a few hundred may help a lot to allow good speeds even with a lower P value.
Don't use the step function or the auto tune function to tune the P value. Instead, set the axis acceleration (M201) to quite a high value e.g. 5000, and tune using an explicit GCode move with acceleration, steady speed and deceleration segments; for example G91 G1 H2 X40 F12000 (assuming your machine can move at 200mm/sec).
Having selected a P value, re-tune I and especially D.
Re-test at the highest travel speed that you want to use, to make sure that the new P value is sufficient.

dc42

@samlogan87 I would add that the noise/vibration issue referred to by @Phaedrux is specific to closed loop mode. If you are also getting these bad vibrations when you run the motor in open loop mode, then the problem is mechanical.

samlogan87

@Phaedrux i am not running in closed loop at the moment. @dc42 hi David, how would changing a value for the F parameter in my M569 declaration stop the noise all together for the entire rest of the print? It doesn’t matter what I change it to, just that it is changed while printing and the problem disappears

dc42

@samlogan87 the only explanation I can think of for why changing the F parameter would resolve the issue regardless of what you change it to is if the TMC driver register that holds that F value (the chopper control register) is getting corrupted somehow, and rewriting that register restores the correct value. If it was just one of the motors that was affected, then I would suspect a faulty driver chip.

The default value for F is 3. You can read the value in the chopper control register using this command:

M569.2 P#.0 R{0x6c}

replacing # by the CAN address of the board. If you haven't changed that F parameter, and assuming you are using x16 microstepping with interpolation, the value returned should be 0x14008053 if the driver has been enabled. The final digit will change with the F parameter, and will be zero if the drive is disabled (e.g. using M18).

samlogan87

@dc42 hmm interesting, what could be causing that. I did check what the response was when I sent M569 P10.0 and P11.0 and it gave the valve as per what was set