Posts made by Hernicz

@Chriss Scripting is not a solution for this problem.

The only solution would be if unload.g would run when I click on a filament from the dropdown menu and not when I click on change filament.

I don't know where you run your script from, but if you don't use your filament folder and macros, then the script is irrelevant.

I use filament configs, I also have filament specific temperatures configured there as well, so basically I can set the temp to 0 in my slicer and print the same GCode using different materials. Pressure Advance and XY Compensation is also set up on the filament level. I call it Filament Independent Slicing.

@gloomyandy Because as soon the empty unload.g runs there will be no filament assigned to the tool.

If I cancel filament selection after that I'm left with no filament.

How would I unload the filament if I can't use its unload.g?
Would filament specific configurations of the previous filament still be applied when unloaded?

Also I use unload.g for ERCF and there it works well.

This issue only applies to DWC

Imagine if you would want to eat something you would need to unload the entire fridge before you can chose anything, you cannot just open the door and see what you have or just close the fridge and don't take out anything at all if you change your mind. You need to unload it all if you interact with it and only then you can make decision about the next step.

@droftarts Not really.

My issue is that the unload.g macro runs instantly when I press "Change Filament". There's no way to cancel and I have to wait until unload.g finishes before I'm able to select another filament. I'm also unable to put any script into unload.g, because as soon as unload.g finishes running I have no filament assigned.

The correct sequence would be:

1. I click "Change Filament"
2. Popup appears
3. I click on a filament / ability to cancel
4. (Here can be a checkpoint if I try to load the filament already loaded, but also take into accoult that there might be duplicates in the Multi-Material unit for runuot purposes, so there's a scenario when I want to do that)
5. unload.g runs (current/old filament)
6. load.g runs (next filament)
7. config.g (next filament)

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.