Posts made by Hernicz

I'm using ERCF Filament Changer and configured it to utilize filament change macros instead of tool changing. Most of the stuff is handled by the RRF (I try to give control to the Duet rather than the Slicer)

My problem is that when I manually load another filament using DWC, I have to wait for the unload.g to run first before I can select another filament.

I would like this to be changed, so when I manually change filament the popup window appears first, then I select the filament.

Then it checks if I want to load the same filament. Keep in mind there is a possibility of having the same filament in multiple slots in the ERCF in case of runout, so if it just gives a "Filament already loaded" message runout switching might fail.

Just after selecting filament the unload.g macro would run.

This also might need the previous filament stored somewhere so the correct unload.g is used (not the one the next filament has)

To be honest it would be nice to have a graphical interface for multi-material units, where filaments can be assigned to specific slots and their usage could be monitored and saved in a file.

@dc42 I tested Secondary Dive Height as well and it's wonderful, but it disables Secondary Dive Speed.

@Herve_Smith Maybe setting K to K0:0 would solve your issue. It's fan compensation.

You can test it first (before changing K) by heating up to target temp and then turn on the fan to 100%
If your temp starts to climb while M307 K is non-zero then thats your issue.

I already have this working. It saves babystep value on pause, cancel, print end and loads it at print start.

G32 and G29 resets it to 0.

It's also possible to continously monitor it with daemon.g in case of event of power loss.

@dc42 I've made some tests according to what @sinned6915 said and I have to say he's saying something. There's a minimum movement distance to actually get the commanded distance.

I've attached a dial indicator to measure Z axis movement then moved the Z axis up-down-up-down.

If I move the Z:

• 0.01 : I get no movement
• 0.02 : dial moves less than 0.01 both directions
  But here comes the interesting part, if I move Z:
• 0.05 : I get 0.03, like 0.2 is deducted from it.
• 0.07 : I get 0.05
• 0.09 : I get 0.08 only 0.1 gets deducted

And it seems that from 0.125 I actually get the right movement distance that had been commanded.

Considering this there are two options

• I probe with 0.05 dive height hoping that the backlash is equal among all the probing moves (I assume it is because I don't se issues on my prints with 0.05 Z-Hop, but testing it now with 0.15) or
• I set the dive height to 0.125-0.15 which is still pretty low and gives true movement distance.

I would chose the latter.

@sinned6915 This is why I requested this feature so the first dive height is high enough that the probe doesn't touch the bed in X-Y movements, but after the first probing move it dives from lower height thus speeding up the sequence.

Whithout this feature the only option to speed probing is to slide the pin of the probe on the heatbed. It works, but definitely not a solution in the long run.

Low dive height fast probing @ 1mm/s, sliding the pin

Also as @dc42 said, if the Z axis doesn't move due to backlash the probe the sequence will throw a "Probe triggered before probing move" error.

@sinned6915

1. I'll do some tests.

2. 2 mm is far more than 1 full step. Also full step depends on motor angle as well. (1 full step with a T8 is 0.04 mm with a 1.8° Stepper, half of that with a 0.9°, a full rotation of the shaft is 8mm travel, so 2mm is 50 or 100 full steps depending on motor angle) We need to keep in mind that the probe trigger point will be most likely in a microstep, so in my opinion full step probing isn't necessary as we dont even know if the motor is in a full step or not if microstepping is enabled we can only pass full steps but we dont know if we actually stopped at one.
   Microstepping is pretty good on trinamic steppers so I dont really see the point.

3. Euclid is cool, but we use different probes and different machines. This feature is for touch probes.

@dc42 Thank you very much. I'll do some repeatability and other tests.

@sinned6915 The BL-Touch has more than 1mm unnecessary travel, many of us has anti backlash nuts.

I have a Retraction Z Hop of 0.05 mm without problems. I should see artifacts if I would have backlash, so I assume a 0.2-0.3 mm secondary dive height shouldn't cause any problems.

Also I can test it with a variable height probe repeatability test script.

I still think we would definitely benefit from this feature.

@sinned6915 I do G32 with 0.001 precision with really good repeatability. Probe also set up to 0.001.

Of course if you probe with different speed or dive height the measurement will be off, but RepRap only renders the probing successful if you have the same values on two consecutive probing moves.

The purpose of this request is to lower the dive height on secondary/finishing probing moves thus speeding up the process.

@dc42 Yes. Like we have M558 ... F1200:120 we could have M558 ... F1200:120 H1.5:0.3

Thank you.

@Phaedrux It would be a just a couple of numbers, wouldn't make it reach the line limit.

M558 ... H1.5
vs
M558 ... H1.5:0.3

It wouldn't only help with G32, but with G29 as well.
See, if the bed isn't flat you need bigger dive height, but after an initial probing move that height will just waste time, especially if there are multiple probing moves at the same spot and the tolerance is low.

If we look at it this way: Why the secondary probing speed? I mean we can change probe parameters mid sequence. I do it for a long time, modularised probe configurations for high speed initial homing, 7.5 mm high dive initial probing in bed.g and then a general config with the same parameters for finalizing touches.

The only thing cannot be done is modifying probe parameters mid-probe-move.

Secondary dive height is more useful than secondary probing speed IMO, also no more "Probe triggered before probing move" because you dont need to set the dive height so low that the BLTouch pin literally slides on the heatbed. With a fast high dive initial probing then a slow low dive probing meshes can be made much faster even on an uneven bed with high precision.

It would definitely make probing better.

Low dive height fast probing @ 1mm/s, sliding the pin

This is an old video, but if I remember right for this sequence I used modular motor configs as well, increased jerk, max speed and acceleration for G29 (they can be set higher for shorter moves without stalling), thats why the knocking sound when the motor stops after a move.

@jay_s_uk I do that as well, but I would like to change it in a single probing move.

Dive from 1.50 mm first then do 0.3 dives.

It would be nice if we would have a secondary dive height for M558 (like the Fnnn:nnn for probing speed)

@dc42 That's good to hear

I don't know what the future might bring, but I'm certain we will not need more than 10000 probe points for a while.

Also 10K is nice round number

@o_lampe Can the planner run on the SBC?

@jens55 This is RRF, but I modified the source code and compiled a firmware .bin file.

I think preparations has to be made for faster probing methods.
BEACON - 2000mm/s bed probing

I modified the firmware, just about to do a test print to check if I actually able to print anything with a mesh like this.

Took 1 hour 10 min at low (0.01 mm) precision with a BLTouch in fast mode. Fast BLTouch Probing

I would like the bed mesh size to be increased to 100 x 100 (10K points) for SBC users.

As far as I know we are limited to 441 points because of the memory limitations of the MCU.

You can write a code in daemon.g that would clear the global variable for you if your axes aren't homed (which would happen in you disable motors or idle hold anyway)

The only thing is that you might need to put the code in a while loop in daemon.g so the variable get cleared faster (daemon.g has some delay, that you can lower with a while loop)

Be aware, when you home an axis it gets "un"homed during a homing sequence, therefore you need to set up additional variables to prevent your G32 global variable get cleared when you home an axis that was already homed.