Problem in autoleveling system

[IanCarr-deAvelon]

Please fill this out:

pcb2gcode version (run pcb2gcode --version to see this):
2.2.0
Git commit: latest
Boost: 106700
Gerbv: 2.7.0
Geos: Not installed

What did you try (include command-line arguments):
pcb2gcode --front pinpad-F_Cu.gbr

What happenned:
The gcode produced probes 70 points; #500 to #569, but then uses eg #578 during milling.
This appears to be because workareaLenX is calculated, but then the offset is added before milling (at least setting offset=0.0 removes the problem)
or

130c130,131
<     workareaLenX = ( workarea.max_corner().x() - workarea.min_corner().x() ) * cfactor + 
---
> //IAN
>     workareaLenX = 1.0 + ( workarea.max_corner().x() - workarea.min_corner().x() ) * cfactor + 
132c133
<     workareaLenY = ( workarea.max_corner().y() - workarea.min_corner().y() ) * cfactor +
---
>     workareaLenY = 1.0 + ( workarea.max_corner().y() - workarea.min_corner().y() ) * cfactor +

What did you expect to happen:
Variables/Registers to be set before use.

Please attach your input files and relevant output files and images. Don't forget to include your millproject file and gerbers!

pinpad-F_Cu.gbr.txt
millproject.txt
output.ngc.txt

[eyal0]

Oh, I thought that this was fixed already in #490

That was a very recent change. Can you tell me when you downloaded your code?

[eyal0]

I'm now seeing the same error as you. I'm working on it.

[eyal0]

Oh damn. The exact floating point problem that was mentioned here is exactly what happened.

[IanCarr-deAvelon]

I've just got up and found I've missed the chance to assure you I tried a new git clone before opening the issue. Thanks for fixing this so fast.
Yours
Ian

[eyal0]

No problem!

Was this actually causing you trouble? As far as I can tell, the unassigned variables would have been multiplied by zero anyway so it shouldn't have had any effect.

If you test the new code and see that it has a problem, re-open this bug and I'll investigate.

[IanCarr-deAvelon]

I don't have a CNC mill, I'm writing PC code to persuade a 3D printer to do it with a Dremel. My problem was that my program crashed with undefined errors. Initially I was using a version of pcb2gcode from a few months ago and there were much stranger things in the gcode. I spent a bit of time searching on line thinking there were standard registers which did things I didn't know about. Once I pulled the latest version it was clear that the remaining problems related to the Z values being calculated as if they were just outside the probed area. Yes, I do see that there is zero weighting on the undefined values in the end.
I'm convinced that the gcode is now correct and I'll get on with finishing my program.
Yours
Ian

[eyal0]

Cool! There is a PR #408 to add a flag to make the output of pcb2gcode compatible with Marlin printers. If you're 3D printer uses Marlin firmware, that might interest you.

I worked on it for a while but never completed it because the person that opened the PR stopped responding, probably already being satisfied with a solution. If you need marlin compatibility and you're will to do some testing of code, I can pick it up again.

I didn't write most of pcb2gcode but I picked up the maintenance of it when it was basically abandoned by previous authors. I continue to maintain it even though I have no access to either CNC or 3D printer. So I'm only able to make changes that don't require me to test them on real hardware.

I'm surprising that you're able to make use of the autolevelling because most 3D printers are on Marlin and I don't think that Marlin supports variables like that.

Anyway, if there's any other support you need, let me know.