@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

@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.

@dc42 I think I am just over thinking this, if I use G1 R2 I can zip back to the print position rapidly with only minor retraction.

prime.g

G91 ; relative pos G1 Z3 F1000 ; raise Z G90 ; back to absolute pos M106 S0 ; fan off M109 ; wait for temp M42 P0 S1 ; turn servo on M280 P0 S100 ; servo home 100 degrees G4 P100 ; wait 1 second ; move near pebble wiper, two movements to come in from ; the right edge so any tail hangs over the far edge. G0 X-35 Y160 F30000 G0 X-42 Y161 F24000 G0 X-39 Y153 F24000 ; move to pebble wiper purge spot ; make a pebble G1 E1.5 F200 ; purge reduce from 5 to 3 G4 P200 ; wait 200ms G1 E5 F300 G4 P200 ; wait 400ms; G1 E10 F500 ; purge G1 E5 F360 ; Pebble Purge M106 S1 ; fan 100%, cool and harden the pebble G1 E1 F240 ; Final Slow Pebble Purge G4 P14000 ; Dwell for 12s, a bit long, need to tune down this. ; do a minor retraction G92 E0 ; reset extrusion G1 E-0.4 F1500 ; Retract a bit ; servo wack the pebble away M280 P0 S0 ; whack! G4 P250 ; Dwell for milliseconds ; zip over the brush G0 X-35 Y123 F24000 ; move across brush G0 X-39 Y200 F24000 ; back over the brush G0 X-35 Y123 F24000 ; move across brush G0 X-39 Y200 F24000 ; back over the brush G0 X-35 Y200 F24000 ; back over the brush G0 X-25 Y131 F24000 ; back over the brush G0 X-40 Y131 F24000 ; back over the brush G0 X-25 Y131 F24000 ; back over the brush M106 R2 ; Cooling Fan Off M280 P0 S100 ; servo home M42 P0 S0 ; servo off ; restore Z before moving tool back G91 ; relative pos G1 Z-3 F1000 ; lower nozzle G90 ; back to absolute pos G29 S1 ; mesh levelling on ; return to position where toolchange was initiated from G1 R2 X0 Y0 Z2 F50000 ; Move to saved position at lightning speed G1 E0.4 F1500 ; Unretract G92 E0 ; reset extrusion

@jay_s_uk Thank you very much, this works very well.

@dc42 Thanks for reply. Ok ill give up on the Titans then, I am thinking of moving my original Hemeras to be Bowden extruders, as they are too heavy for moving at reasonable speeds. I guess I have my answer then. TItans out, Rotos or something light for direct.

@gloomyandy said in Trying to fix my dual markforged (HAQ-XY) kinematics:

at it is probably not a good thing

Ill redesign the belt tensioning mechanism and the belt mounting, when measuring it indeed looks to be too loose
WIll see what this does

@adhanabal why didn't it complete the tuning? Did it produce an error, and if so what was the message?

This may get you started. Temporarily configure the heater port as a GpOut port in M950 instead of a heater. Turn the heater on at full power and record the temperature at regular intervals, perhaps every 10 seconds, until a typical desired chamber temperature is reached. Then turn the heater off. Continue taking temperature readings until the temperature has dropped by 10C or mkre from its peak. Plot the temperature in a spreadsheet.

Look for the fastest rate of rise of temperature in the plot, which will be when the temperature is only a little above ambient. Use that value in degC/second as the R parameter in the M307 command. For the D parameter, use the time in seconds before that rate of temperature rise was achieved or nearly achieved.

@Phaedrux

I don't think they have. Honestly, I had been printing with this printer for years with the same modifications. I moved twice and now have space to set them back up. It was about a year that my printer was offline and now bringing it back online, I've run into a few issues here and there. But maybe? I've cleaned and lubed up all the moving parts on the Z axis at this point. I do have some new lead screws, brass lead screw nuts, and stepper motor to lead screw couplers on order.

Here's my axis config from the current config.g.

; Axes
M584 X0 Y1 Z2:4 ; set axis mapping
M671 X-20:320 Y0:0 S0.5 ; position of leadscrew/bed pivot point at left and right of X axis
M208 X0:305 Y0:300 ; X carriage moves from -5 to 205, Y bed goes from 0 to 200
M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation
M906 X800 Y800 Z1200 ; set motor driver currents
M92 X80 Y80 Z409 ; configure steps per mm
M208 X0:300 Y0:300 Z0:400 ; set minimum and maximum axis limits
M566 X900 Y900 Z12 ; set maximum instantaneous speed changes (mm/min)
M203 X6000 Y6000 Z180 ; set maximum speeds (mm/min)

M201 X500 Y500 Z20 ; set accelerations (mm/s^2)

@abraxas in assisted open loop mode the motor is commanded to move and the encoder is used to monitor the movement. As the error between commanded motion and measured motion increases, the firmware will increase current up to the maximum configured in order to increase torque. It also uses the acceleration and velocity feedforward terms to increase motor current in anticipation of needing more when accelerating or moving at high speeds. If steps are lost (which will always be a multiple of 4 full steps) the firmware will not try to recover them. So you should always set the error threshold to less than 4 full steps.

In closed loop mode the firmware will keep on trying to achieve the current requested position. So lost steps will only persist for as long as the motor cannot provide sufficient torque to overcome an obstruction, or while is it being commanded to move or accelerate faster than is possible.

I hope this clarifies the behaviour for you.

@Bsisson this is more a slicer question than a firmware setting. The firmware allows the slicer ot inject changes i acceleration into the generated gcode file. The various settings are fairly well labelled as far as i can see.

In the end, i ended up at PA of 0.12

@cosmowave I don't see why the mechanism for detecting if a move is a travel move or a printing move in M204 couldn't also be used for applying a different feedrate. Maybe raise it as a feature request on Github?

I see the usefulness of it to, as you say, make gcode material independent. You can do this with the RRF filament profile, but it is generally focussed on temperatures and filament changing. I think that much of the Gcode granularity is probably best left to the slicer, as there are a number of other settings, eg bridging speed and extrusion factors, fan speed etc that are handled by the slicer with more granularity than the firmware or DWC could ever hope to do. It's just to entrenched in the generated Gcode. Which makes it very difficult to make Gcode fully material independent.

Ian

@cosmowave No, Markforged (HAQ-XY) kinematics

@droftarts

I want to give you a feedback: I was wrong! I had to lower the y axis. I adjusted it and now my maximum deviation is about 0.2 mm. I feel good with it!

I printed some califlowers and could fine-tune the Skew with a M556.

I think my machine back in business!

Thx for your help!

Thanks all for questioning my setup! I now managed to get it fixed / changed in the following way:

# define Z probe G31 X0 Y60 Z3.80 P25 # Y was -50 before # bed leveling with left+right lead screws G30 P0 X10 Y130 Z-99999 # Y was 20 G30 P1 X240 Y130 Z-99999 S2 # Y was 20 G28 Z # mesh leveling M557 X20:240 Y55:230 P9:9 # Y was -49:137

So I had to roughly add 3 x probe_offset to most positions compared to my previously (flawed) configs.

Now the visual heightmap in DWC looks reasonable.