Posts made by JayT

@dc42 :
Hi David, I still see enough ringing despite using ZVDD& ZVDDD modes, but none reduce the ringing much. What am I missing here? The best frequency that works 20Hz with EI2 mode. But i still see lines on the plane Y facet.
Can you suggest what can be optimized in Settings or the design to eliminate this ringing in Y direction?
With cartesian i was able to solve ringing but could never attain acceleration > 800mm/s2 & speed >100. Same is the case with coreXY as well. I am not able to move to higher acceleration or speed.

P.S.:

1. I tried 0.9 degree double stack as well
2. ZVD ZVDDD modes with 20Hz frequency.

@jay_s_uk
@dc42 :

Below is result at 20-22Hz frequency, where many lines reduce, speed is 60mm/s, so the lines are closer. However, I am not able to remove these lines in the picture.
How do I capture this frequency in input shaping method?
This is with damping factor 0.05 though, with 0.01 lines are more prominent i felt.

@jay_s_uk :

Hi Jay, I tried 20Hz, result was better. And I used following accelerometer curve to detect the exact frequency. as per this 27.4 shaper frequency, but that does not remove ringing for me like 20Hz. Can you suggest further on how to proceed here or how to analyze this graph?
Also What is the role of damping factor ? At 20Hz with 0.05 i get better result I feel. but I need to find proper frequency & damping factor to make its smooth.

Damping factor 0.01
EI2
Mounted above BLtouch mount.

@jay_s_uk :
@dc42 :
Thank you for suggestions. I used EI2 & EI3 methods input shaping modes with 20Hz, and it indeed reduced ringing, also with reduced print speed, it further goes down. I am reading on connecting accelerometer to find exact frequency.

Can you suggest where should I fit my accelerometer for Y-Axis? (on the extruder ? ) , NOTE: The accelerometer doesn't have axis marked.
Can you mark in the picture above to suggest?

@dc42 @jay_s_uk :

• Based on suggestion, I tried latest firmware 3.6 RC3.
  NOTE: Tool head is Biqu. (not much heavy, with 3dpinted ducts for part cooling).
• Attached is an image with the top one printed using DAA & bottom one is how base printing without DAA appears. There is absolutely no difference after input shaping. (I manually calculated distance between 2 lines using vernier (except the corner one) ).
  

1. Jerk is 5.
2. DAA: speed is 120mm/s, acceleration 800mm/s2, and distance is 2mm between 2 lines, so that 60Hz for DAA. We used ZVD mode.
3. In the top cube, I also modified acceleration to 1500 mm/s2, but no difference.

Can you suggest here further?

@mrehorstdmd :

YEs, we initially used 2000mA, reduced it down to 1600mA.

• Tried to use Pulse dir pins with external driver as well. no luck.
• I am using 0.9deg motors (as with 1.8degree there was vertical ribbing in Y axis).
• I had built cartesian system, even then Y always had ringing. this wasn't the problem with 300bed side. Then we moved to Corexy for 500 bed size, but ringing appear despite slow speeds.

@jay_s_uk : Ok Let me try that. Meanwhile can you tell me if this is common in Linear guide systems? Any suggestion to check on design side?

@jay_s_uk said in Ringing in Y axis (Linear guide system, coreXY design):

3.6-RC3

Motion shaping as in acceleration profile ? (I am not using input shaping, as it didn't give much results).
Do you see this problem arising from acceleration/deceleration profile ?

@jay_s_uk : RRF3.5.0 RC3.

NOTE: I use the same in 300 bed sized machine. It's not giving any problems.

Hi,

I am using Duet2 board, with corexy system of 500*500 build size. When I print, I see ringing effect only on Y-axis. Tried following solutions, but none worked.

1. Tried with jerk values 1, 2, 3... upto 10 (acceleration 500, speed 60mm/s)
2. Tried Different acceleration values from 500mm/s2 to 2500mm/s2 (speed 60mm/s & jerk 2)
3. **Tightened the belts.
4. Tried to double check alignment.
5. Also tried DAA, but in vain.**
6. Tried to use extra channels of Pulse & dir & use external drivers.

a) Can you suggest what can be done to find root cause of ringing & resolve problem here?
X axis is fine, its the Yaxis with the problem. Both on Linear guides, & Biqu extruder mounted.
b) If it is vibrations, How do I root down the problem.

NOTE: I am also using ssame board on a smaller bed size, with guide rod mechanism & cartesian system, it worked fine.
Iin bigger size, rods induced vibrations, so I tried with corexy build to get better speeds.

@jay_s_uk , @Phaedrux

Images of ringing in XYZ cube: (ringing is always during breaking as per my observation)

Image of setup (top view)

@droftarts @dc42 :

I further checked the setup & realize that the PT1000 sensor is 30mm in length with 4mm diameter. But the Biqu extruder slot for hotend & sensor is of 15mm.
This means half the sensor is outside sensor slot & not in contact with hotend.

Shouldn't this affect the PID learning & heater behaviour?

@droftarts : I understand your suggestion; for abs I might need 260degC.However, if I want to claim 300degC of extruder, I must tune it to that max limit. If I just tune to 210degC, then at times it will struggle to even reach 280/290degC . I plan to include chamber heater too.
My only concern is to understand this tuning well, so that there are not heater warnings/faults ., other wise on power up this predicted warning generates a doubt to user.
(I don't face this with bondtech set up, but with biqu extruder only).

• Does the position of heater & sensor matter?, Is it supposed to be completely inline with heater/sensor boundaries or a little protruding ? (I have used borosilica paste to fit the sensor well.)

NOTE: I user Duet 2 wifi board.

@dc42 :

Increasing R parameter, in my case, does not change the overshoot problem.
I tried decreasing R parameter, by 20-40%, then overshoot only reduces by 2 degC. i.e. earlier overshoot was 14degC, then it changed to 12degC, but cooling rate reduced.
What to do further , any suggestion?

Printer1:
M307 H1 R1.991 K0.759:0.048 D11.88 S1 B0 V23.9 E1.35 P7.5 I0.120 D44
This printer, does not give any warning on power up pf prediction, though overshoots at first by 14degC, but settles & then on fan on, temperature drop seen is just 4-5degC but manages reach target.

Printer2, same extruder, Biqu.
M307 H1 R2.457 K0.290:0.132 D11.88 S1 B0 V24.1 E1.35 P5.1 I0.0.085 D43.8

This printer, on power on, gives predicted temperature warning (511degC), temperature overshoots only by 6degC, but settles & on fan on, temperature drop behaviour is same as that of printer 1.

Why same sensor & heater type in same extruder type, behave so differently ? One overshoots only by 6degC, but other overshoots by 14degC.

note: Both tuned at same ambient, using "M303 T0 S300".

@Phaedrux :

For manual adjustment, it brings me back to the 1st post in this thread. Can you answer the following for me to try :
following links,
David suggests to increase 'R' paramater.
https://forum.duet3d.com/topic/31038/overshoot-and-really-unstable-hotend-temperature/2?=1721909615387
https://forum.duet3d.com/topic/31038/overshoot-and-really-unstable-hotend-temperature/2?=1721909615382

But literature says, to decrease in case of overshoot:
https://docs.duet3d.com/User_manual/Connecting_hardware/Heaters_tuning

Can you please confirm whether to increase or decrease "R" value ?

• Should I reduce P value ?
• Should I try tuning to 90% PWM?

@jay_s_uk :

Thanks.
I tried this "M303 T0 S300".
values after tune : M307 H1 R1.991 K0.759:0.048 D11.88 S1 B0 V23.9 E1.35.

On power up, prediction warning no longer appears.
On setting 210degC for PLA, temperature still, at first overshoots by 14degC but stabilizes after 2 mins. And on switching on Cooling fan, temperature drops by 5degC but heater manages to pick up. (in a nutshell, the I no longer get any heater warnings.

The question I have is :

• What does this feedforward method really does in the code to tune different than M303 H1 command?
• I have saved values in config-override.g, If I re-tune will the values be same or will it optimize further?
• Is this overshoot of 14degC due to thermal mass & sensor being little farther from heater area?

@jay_s_uk :

M303 H1 S300 P1

If I keep cooling fan at 0% fan during autotune, then I get the learned values as below & temperature with these values overshoots only by 6degC. BUT, the moment FAN starts, temperature drops by 5degC & I get a warning that predicted temperature can go beyond 500degC/700degC at times.
The values I get are:
M307 H1 R2.876 C238.464:338.464 D10.36 S1.00 V23.4 B0 I0

• If I auto-tune with FAN on in 2 phases & off in last two as per the procedure, Then the learned values cause an effect of overshooting by 15degC.

Image of hotend:

Hi,
I am using a 50W heater with Biqu H2 extruder. I am able to auto-tune heater at different part cooling fan speeds. (tried from 20% to 100% fan speed). But when I set temperature, even with 100% fan ON, I see extruder overshoots the target temperature by >15degC .
I found few links, but there is some ambiguity in the documentation literature & the forum link.

following links, David asks to increase 'R' paramater.
https://forum.duet3d.com/topic/31038/overshoot-and-really-unstable-hotend-temperature/2?=1721909615387
https://forum.duet3d.com/topic/31038/overshoot-and-really-unstable-hotend-temperature/2?=1721909615382

But literature says, to decrease in case of overshoot:
https://docs.duet3d.com/User_manual/Connecting_hardware/Heaters_tuning

1. Can you please confirm whether to increase or decrease?

2. I have tried increasing R parameter, still the problem of overshoot persists.

3. Should I try tuning to 90% PWM?

@droftarts , @dc42 : What do you suggest?

NOTE: I am using latest firmware & didn't face such problem with Bondtech extruders & slice engineering heaters.

@dc42 : Heater fault in my case was due to some interference from BLtouch wire., not due to RRF 3.5.1.. There was a change in wiring in addition to RR3.5.1 upgrade, but when I debugged further, the root cause was as stated.

@droftarts :
I see this is happening only with 1/2 versions of cura generated Gcode. If I use latest Cura version gcode, I don't see this problem much. However, I will see if stopping the log , helps anyway.
Also, I do see that this problem does not appear in previous versions of RRF. May be something is changed w.r.t certain gcode interpretation.

@Phaedrux : Please mark this as solved.