• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login
  1. Home
  2. Hernicz
  • Profile
  • Following 0
  • Followers 0
  • Topics 7
  • Posts 60
  • Best 8
  • Controversial 0
  • Groups 0

Hernicz

@Hernicz

11
Reputation
15
Profile views
60
Posts
0
Followers
0
Following
Joined 23 Feb 2020, 04:16 Last Online 1 Dec 2024, 09:47
Location United Kingdom

Hernicz Unfollow Follow

Best posts made by Hernicz

  • Guide to Marlin's Fast BLTouch Probing feature on Duet

    If you're tired of the clicking noise of the probe this guide is written for you

    Link to video

    First let's declare that I'm not responsible if you break your probe or ram your nozzle into the heatbed. I tried to write an universal guide with safety in mind but we all know s&@t happens sometimes. That's why I ask you to double check yourself if you want this feature. No typos.

    It's pretty unsafe to move around with a deployed probe, or probe the heatbed with a probe not deployed.

    READ THIS GUIDE CAREFULLY FIRST AND IF UNSURE DON'T DO IT!

    This guide suggests that you have the following properly configured:

    • BLTouch (works as it should without issues)
    • Probe offset (obviously)
    • Printer boundaries/Axis limits are set correctly (G1 X0 Y0 F3000 moves your nozzle over the corner of your heatbed, or that is your axis minima)
    • Mesh grid (the probe only probes printable area, no obstruction between probe points)

    If any of the above is untrue please fix before you go on with this guide.

    The base of this feature lies on modular config.g. This means that some parts of the configuration are in separate files called by M98 in config.g (and anywhere else). In this way it's possible to store the probe settings in one place and reset to these settings with M98 after any modification.

    In these separate files we can change the probe type from P9 to P5 and deploy the probe manually just before probing then retract and change it back afterwards.

    First of all a config subfolder needed to be created in the System folder (sys) and a probe folder inside the config folder.
    (You can name it anything, but you have to modify the code below accordingly.)

    alt text

    alt text

    In /config/probe/ you have to create 4 files:
    probe_config.g
    probe_config_fast.g
    probe_offset.g
    mesh_grid.g

    alt text

    Now you have to copy your probe configuration from your config.g into these files as below:

    ============================================================

    • probe_offset.g : Here goes your probe offset G31 from your config.g so you have to copy that single line here. Later on if you need to modify offsets you have to do it in this file.

      Copy your own offset, don't copy mine.

    Grab a piece of paper/notepad and write/type down your X and Y offsets. You will need it later.
    For example in my case:
    G31 P1000 X68.9 Y -1.5 Z3.24

    Probe_Offset_X= 68.9
    Probe_Offset_Y= -1.5

    alt text

    ============================================================

    • mesh_grid.g : Copy your M557 line here. Same as above, if you ever need to modify your default mesh grid you have to do it in this file.

      Write down your grid's X and Y minimums on the paper/notepad.
      For example:
      M557 X22:198 Y30:190 P21:21
      In this case:
      Mesh_First_X= 22
      Mesh_First_Y= 30

    Use your own coordinates, don't copy this.

    alt text

    ============================================================

    • probe_config.g : Copy your M558 line here and make two new lines:
      M98 P"config/probe/probe_offset.g
      M98 P"config/probe/mesh_grid.g

    This way probe_offset.g and mesh_grid.g will be called when you call probe_config.g. (Needed because probe type change zeroes probe offset.)

    alt text

    ============================================================

    • probe_config_fast.g : Repeat what you did in probe_config.g but change the probe type from P9 to P5.

       You might need to add 0.1 sec settle time (R0.1) if you have issues
      

    alt text

    ============================================================

    Now you have your default probe config (probe_config.g), which is a type 9 and your fast probe config (probe_config_fast.g) type 5.

    Lets head to config.g and add your default probe config by adding the following line to your probe section:
    M98 P"config/probe/probe_config.g"

    The 3 lines of the old probe configuration have to be commented out(it can be deleted later if you got used to modular config).
    I advise to put at least five " ; " just to make it visible because from now on if you want to modify your probe config you have to do it in the 4 files you created earlier.

    Keep the line which defines your BLTouch Pin Servo!

    alt text

    Grab your paper and do a simple math with your probe offset and mesh grid minimas (this will help you to move your probe ower the first point before the probe pin gets deployed):

    First_Point_X = Mesh_First_X - (Probe_Offset_X)
    In my case:
    First_Point_X = 22 - (68.9) = -46.9

    First_Point_Y = Mesh_First_Y - (Probe_Offset_Y)
    In my case:
    First_Point_Y = 30 - (-1.5) = 31.5

    You will need the values in the upcoming macro in a way like this:

    G1 X-46.9 Y31.5 F9000

    Again, don't use my values, calculate your own.

    ============================================================

    Now head to your macro folder and create a file called Fast BLtouch Mesh.g (or whatever) and copy the following:
    (don't forget to edit line 4 with your calculated positions, and check that "Raise and Return Z" commands suits your machine.)

    G91 ;Relative positioning
    G1 Z5 F1500 ;Raise Z 5mm
    G90 ;Absolute positioning
    G1 X-46.9 Y31.5 F9000 ;Here goes First_Point_X and First_Point_Y positions you calculated above
    G91 ;Relative positioning
    G1 Z-5 F1500 ;Return Z 5mm
    G90 ;Absolute positioning
    M98 P"config/probe/probe_config_fast.g" ;Call probe_config_fast.g module (Switch to Fast Probe Mode)
    M98 P"deployprobe.g" ;Deploy the probe
    G29 ;Probe the heatbed and generate heightmap
    M98 P"retractprobe.g" ;Retract the probe
    M98 P"config/probe/probe_config.g" ;Call probe_config_fast.g module (Switch to Default Probe Mode)
    G91 ;Relative positioning
    G1 Z5 F1500 ;Raise Z 5mm
    G90 ;Absolute positioning
    G1 X-9999 Y-9999 F9000 ;Go to Parking Position
    G91 ;Relative positioning
    G1 Z-5 F1500 ;Return Z 5mm
    G90 ;Absolute positioning

    alt text

    You're ready to go. Do some tests with the mouse pointer over the Emergency Stop button just to be safe.

    Also make sure the pin of the probe doesn't touch the heatbed while moving.

    ============================================================

    ============================================================

    GCode References:
    G31: Set or Report Current Probe status
    M557: Set Z probe point or define probing grid
    M558: Set Z probe type
    M98: Call Macro/Subprogram

    ============================================================

    ============================================================

    Even tough we can have Marlin's Fast BLTouch Probing feature on the Duet/RRF like this, it would be nice to have a new parameter for G29 and G30 that only retracts the probe after a probing sequence/move.

    ============================================================

    ============================================================

    posted in General Discussion bltouch fast marlin probe feature rrf
    undefined
    Hernicz
    23 Feb 2020, 09:45
  • RE: BL-touch randomly deploys

    @zynch BLTouch wire too close to exruder stepper wire.

    posted in General Discussion
    undefined
    Hernicz
    9 Mar 2022, 10:15
  • Increase Bed Mesh Size for SBC users

    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.

    posted in Firmware wishlist
    undefined
    Hernicz
    17 Jun 2023, 15:21
  • Issues with PID Tuning (RRF 3.4.0-b7)

    I just changed my aluminium heatblock to a copper one and my 40W heater to a 50W one and now it's impossible to correctly PID tune it. I'm using RRF 3.4.0-b7

    After PID tuning my heater I have the simptoms below:

    • Temp overshot, more than 10C which triggers a heater fault
    • Worse temp holding than with aluminium heatblock and 40W heater
    • Temperature slowly climbs up to trigger a heater fault during printing. This one is possibly caused by the fan even tough the fan barely cools the heatblock. It's like the fact that the heatblock is way over target temp is disregarded to compensate a fan which doesn't really cool the heatblock.

    Yes, I can delete the secound K and lower S but I swapped the heatblock and heater hoping it would be better. I sort of suspect E as well. I doubt 1.35 would be right for all the heatblock variations.

    Something is wrong with PID tuning which makes it unable to tune a different heatblock and stronger heater.

    posted in Beta Firmware
    undefined
    Hernicz
    14 Jan 2022, 23:52
  • RE: Guide to Marlin's Fast BLTouch Probing feature on Duet

    @oliof Yes it has the ability (it had it back then as well), but if the firmware doesn't keep it deployed it will get retracted (at least after every probe point). On my Duet3 6HC it retracts even as a P5 I need servo commands to keep it deployed.

    By the way I experimented with using short dive height, sliding the pin on the heatbed with very good results. Unfortunately sliding the pin on the heatbed will eventually wear it off (how fast depends on surface), so this method is definitely not advised if you want accuracy in the long run (and don'twant to change the pin).

    The biggest problem with BLTouch that the pin has an unnecessary >1mm travel until it gets triggered, so @ 1mm probing speed thats 1 sec / touch. It would be nice if we would have a probe with adjustable pin deployment so we could deploy just under the trigger point of the probe and set dive height a bit more than the highest point of the heatbed (compared to Z0)

    In this video the probing speed is 1mm/s, but because the dive height is so short it is really rapid.

    https://youtu.be/Vq_Jz201ndw

    posted in General Discussion
    undefined
    Hernicz
    16 Jan 2022, 02:32
  • RE: Secondary Dive height for probing

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

    posted in Firmware wishlist
    undefined
    Hernicz
    29 Jun 2023, 11:04
  • RE: Secondary Dive height for probing

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

    posted in Firmware wishlist
    undefined
    Hernicz
    29 Jun 2023, 22:13
  • Secondary Dive height for probing

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

    posted in Firmware wishlist
    undefined
    Hernicz
    29 Jun 2023, 10:44

Latest posts made by Hernicz

  • RE: Better filament Load and Unload handling

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

    posted in Duet Web Control wishlist
    undefined
    Hernicz
    30 Nov 2024, 10:20
  • RE: Better filament Load and Unload handling

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

    posted in Duet Web Control wishlist
    undefined
    Hernicz
    22 Nov 2024, 20:13
  • RE: Better filament Load and Unload handling

    @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)
    posted in Duet Web Control wishlist
    undefined
    Hernicz
    22 Nov 2024, 19:05
  • Better filament Load and Unload handling

    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.

    posted in Duet Web Control wishlist
    undefined
    Hernicz
    17 Nov 2024, 11:17
  • RE: Secondary Dive height for probing

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

    posted in Firmware wishlist
    undefined
    Hernicz
    11 Nov 2023, 09:09
  • RE: Why ?

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

    posted in Firmware wishlist
    undefined
    Hernicz
    7 Aug 2023, 11:36
  • RE: Script to make babysteps permanent

    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.

    posted in Firmware wishlist
    undefined
    Hernicz
    1 Aug 2023, 12:02
  • RE: Secondary Dive height for probing

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

    posted in Firmware wishlist
    undefined
    Hernicz
    9 Jul 2023, 12:54
  • RE: Secondary Dive height for probing

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

    posted in Firmware wishlist
    undefined
    Hernicz
    9 Jul 2023, 12:01
  • RE: Secondary Dive height for probing

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

    posted in Firmware wishlist
    undefined
    Hernicz
    8 Jul 2023, 13:08
Unless otherwise noted, all forum content is licensed under CC-BY-SA