@Notepad said in uniform wave artifact on all prints:

WS16

ok so i loosened lead screws and waves got even woth so i think i need to work in makeing sure build plate is stable... 😞 before is did 3Z itwas perrry well i guess let me play with mechanincs and try that adapter too

tnx for leading me to right direction

@BartW22 Hmm I've had a quick look, but unfortunately it looks like it was not using a fixed sample rate, that makes it a little tricky to process the results with the online tools I could find. But even if you can work out the frequency I really doubt if the RRF input shaper is going to be able to handle that level of oscilation it is a bit more than your typical 3d printer ringing! But what do I know, maybe it can help.

@chrishamm That works, thanks!

@dc42 thanks it all worked.
Problem solved.

@dc42
hello
Do you have news
tks

@Fuzionline
hello
Do you have news
tks

Wattage is the result of voltage and current. The lower voltage heating rate would be more affected by the cooling rate of heat dissapating into the air, which is more easily overcome by the higher voltage.

@Tinchus said in Maximum Acceleration Calculator:

Hi all. Question: the calculator here https://wilriker.github.io/maximum-acceleration-calculator/ request some data but what is about the case where you dont use pulleys? (axis moved directly using ballscrews for example)

In case of using any kind of screw to directly drive the axis you can approximate the pulley radius by dividing the screw lead by 2π. Remember to before or after convert from whatever unit you used to centimeters (if necessary). The value will probably be a tad bit too large but not in the amount that matters - and you should anyways always remove a security margin.

Example
if your screw has a lead of 2mm, i.e. every full rotation results in movement of 2mm, then you divide

2mm/2π=0.31831mm

Divide that again by 10 to convert it into cm and you have your virtual pulley radius.

@Simon-4 To permanently set spreadcycle, change the M569 command for that motor to include the D parameter, set to 2. eg:

M569 P0.4 S1 D2

spreadCycle is actually the default, so probably you have D3 with a V parameter. If you set the V parameter very high, eg V25000, you can set the changeover to a very low speed. This means that the motor will at least be quiet at standstill. Send M569 P#, where # is the stepper driver number, to see the current setting and the speed the changeover happens, e.g.:

M569 P121.0 S0 D3 V2000 M569 P121.0 Driver 121.0 runs in reverse, active low enable, mode stealthChop, ccr 0x00053, toff 3, tblank 0, tpwmthrs 2000 (0.9 mm/sec), pwmScaleSum 16, pwmScaleAuto 0, pwmOfsAuto 36, pwmGradAuto 14, pos 8 M569 P121.0 V25000 M569 P121.0 Driver 121.0 runs in reverse, active low enable, mode stealthChop, ccr 0x00053, toff 3, tblank 0, tpwmthrs 25000 (0.1 mm/sec), pwmScaleSum 16, pwmScaleAuto 0, pwmOfsAuto 36, pwmGradAuto 14, pos 8 M569 P121.0 D2 M569 P121.0 Driver 121.0 runs in reverse, active low enable, mode spreadCycle, ccr 0x00053, toff 3, tblank 0, hstart/hend/hdec 5/0/0, pos 8

See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m569-set-motor-driver-direction-enable-polarity-mode-and-step-pulse-timing

Ian

@Drizz1le the TMC2209 drivers on the Duet 3 Mini need to be in stealthChop mode for stall detection to work, but you have them set to spreadCycle mode in your M569 command. Also your homing speed (1200mm/min) may be too slow for stall detection to work reliably. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection#limitations-of-stall-detection and the following sections for more details.

Bear in mind that stall detection is not an accurate method of homing, so if you need precision then I recommend that you use endstop switches.

@gloomyandy

Wow, it's certainly very interesting and I think it might be just what I needed. I will study it well and give an answer.

Thank you very much

@Anawandur From the wiki page on the IR probe, it may not work well with a PEI plate: https://docs.duet3d.com/Duet3D_hardware/Accessories/IR_Probe#bed-surface

This is highly transparent to IR. Paint the underside matt black (see below) before using adhesive sheet to attach it to the bed plate. Changes to the surface finish affect the trigger height slightly. We have a report that as an alternative to painting the underside black you can sand the top surface with very fine grit sandpaper until it has a dull matt appearance, but we have not confirmed this.

Clearly it's not working great with FR4 either. I don't think we have ever tested it with the IR probe, but it sounds like FR4 is invisible to IR too. Painting the back matt black and/or sanding the top may help. But it sounds like you're happy with a BLTouch now.

Ian

thanks I entered the commands in stop.g now I'll check if at the end of the print they both turn off

@resh for setting the probe offsets, see https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_testing#calibrate-the-z-probe-trigger-height

Ian

@gloomyandy it's so weird jerk was not on the list, only spam sites

@Ralms said in Using G30 S0 inside homez.g fails:

The issue I'm raising now, is that G30 will execute from the console, even if deployprobe.g fails, it just ignores it and that should never happen.

G30 works from the console or from within a macro, whether the Z axis is homed or not. The X and Y axes must be homed. When G30 is called, it will run deployprobe.g if the probe type requires it. When and why might deployprobe.g fail, and how would it know if deployprobe.g has failed? If running G30 from the console, it could possibly be too low to fully deploy, eg BLTouch, or off the bed, but I'd say this was operator error rather than the firmware's fault. You could have a check in deployprobe.g for current Z height, if it is below say 2mm, or if the axis is unhomed, move up 5mm. The stock homez.g from the configuration tool moves the Z axis up 5mm before homing to avoid this.

Ian

@dc42 great news!
The modulation parameter goes from -27 to 39.

maxMod.PNG minMod.PNG

@jay_s_uk said in Prevent docking and undocking of probe during multiple G30 Pn:

@Ralms call M401 to undock the probe and then do all your probing routines. That should prevent it docking it between.
Then M402 at the end

That did the trick.
Thank you!

Need to look into submitting some documentation improvements after finishing coding the printer lol

@jay_s_uk Seems to have fixed it. Through my input shaping graph looks very strange, no big peaks

After finding and adressing several issues I belive it is working fine now.

I have:
Lowered the jerk value for Z to 15
Let the bed soak properly before do bed mesh (temp 80 )
Replaced lost screw, one of three holding the hotend to the heatsink. This was hidden by the silicon sock on my Phaetus Rapido hotend.

I think the jerk value was the thing but the other two brought a fair amount of inconcistency too.

So i will end this thread/question here. Thank you for all the help and a little extra to Phaedrux.