OpenDACT 3.1.1A corrupts the value of "Z-probe height"

[Bougakov]

I used serial port sniffer to locate this issue.

My z-probe is located 12.4mm below the nozzle on a hinge. The value is entered in EEPROM:

EPR:3 808 12.400 Z-probe height [mm]

For some reason OpenDACT corrupts it. When I open the program and use "check current heights", it probes once, then sends this:

M206 T3 P808 X5.280

and, almost immediately, this:

M206 T3 P808 X5.280

In the program the value gets displayed as 5.2799999

Why would it touch this value, it should be treated as a constant?

[coelacant2]

Was just checking through the GCode.cs and found the broken logic. Starts at line 143 and ends at 149. Been a while since I messed with this and see that the main reasoning for modifying the value was to determine the Z-probe height without asking the user (higher precision), assuming that the previous Z Max height was correct for printing.

The only issue here is that the Z-Probe height value is never set based off of what the probe returns.

If you want a temporary workaround, then reduce your max z height by 12.4mm before calibration and after calibration increase it by 12.4mm. Then of course the z probe height will need to be set to 0.

I will work on a fix for this.

[Bougakov]

I will work on a fix for this.

Please consider making the tool more verbose (like writing g-codes it generates, to the log) - it could have made spotting this easier. I used http://www.serial-port-monitor.com/ - but since its freeware version is very limited, it was quite a challenge.

[outlookhazy]

Would this explain why after I got my Z-Probe dialed in and working with G30, running OpenDACT appears to be wiping EEPROM values and crashing into the plate? I haven't had time to clone the code and dig in, but I must be missing something

[outlookhazy]

I couldn't help myself, I'm doing a bunch of rewriting. I'll see what I can track down.

[Bougakov]

@outlookhazy , check that "steps per mm" in OpenDACT matches the actual setting.

[lincolnep]

I have the exact same issue with it changing the z-probe height to -39 in the eeprom then homing after that it just crashes into the bed.

I only spotted this when watching it in advance mode and saw the eeprom Z-Probe height change.

Is they any way to stop it changing the z-probe height as it is correct.

[outlookhazy]

I ended up writing my own version of the program, using a different calibration algorithm

[lincolnep]

Cool would you be willing to share?

As I am not having very much luck with Auto Delta calibrations and Repetier.

I have two different options left to me move to Marlin (that has it own problem to deal with) or manual calibrations and forget about automatic which just sucks.

[Bougakov]

@outlookhazy , please share your work, it will be highly appreciated.

[outlookhazy]

@lincolnep @Bougakov I make no claims that it will work for other people - but if G30 already works for you and your printable radius is set properly - you can give it a shot. Firmware is selectable but I really only support Repetier.

Check my fork, you'll find a v0.1 pre-release

[lincolnep]

@outlookhazy Thanks Outlookhazy I gave your tool a go last night and found a few issues

1. If you have offsets set for your probe then it will get stuck while probing as it try to go out of the printable radius. (to fix this you could put in a setting for probable print radius that could be set manually) --I tested this by removing my probe offsets and it started working.

2. This is not really a problem but I nearly shit myself when the program moved hotend down to the heatbed as it was going so fast. --I assume that I could just change the max freedrate to something lower to fix this as at the moment it is set to 200. But it would be nice to pull the freedrate from the homeing freedrate not just use the max.

3. At the end of a calibration run the program lock up while homing not sure why it was getting a bit late at the time so i didn't do any more testing. --I am on the latest windows 10 at the moment is there a version of .net or vb frameworks that i need?

Thank you for help if you would like me to test anything else I can do it tonight.

[outlookhazy]

@lincolnep for clarity sake, please leave future comments on my fork so as not to clutter up Steven's feed with things not relevant. In reply - yes, I suppose I should have warned about that stuff - I really wrote it for myself and was tuning settings on-the-fly.

1. The offset thing was intentional, i'm actually using something like 80% of the printable radius to generate points (I can't remember off the top of my head and i'm about to head to bed). My probe is almost directly underneath the nozzle so that was fine for my use - you're correct that changing the printable radius temporarily for calibration will be a fine workaround.

2. Haha - yes. I was doing LOTS of iterations, very quickly. 50 point 6 factor 3 probes per point, 20 iterations at a time - once I had things dialed in I was just playing with how fast I could make it go and still get good results. Note: it's also trying to avoid overfitting the solution by applying a random rotational offset to the points each time at each ring (depending on the number of points)

3. Depending what you saw, it may not have been a lockup - I'm moving to a park position at 0,0, ~75%(?) Z height after each iteration - this is to avoid homing twice if/when it loops.

[fougere57]

Hey, hello, i'am new here, I have a same problem that @outlookhazy, my z-probe height to 39 after 1 iteration. Have you resolve your problem, thank you a lot. Sorry for my English, I am a French personne.