Bizarre Generated Code from Millface Operation?

[falviani]

FreeCad:
OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20477 (Git)
Build type: Release
Branch: master
Hash: 7d8ab175a68e476427e6e337fe3099b52da49dc8
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

1) Reload file and recompute.
2) Use --no-show-editor
3) Export to gcode.
4) Step down is still 0.5mm
No change - output file is still 1053K,

I also tried doing a separate file, using a path pocket operation with almost identical parameters (1mm stepdown rather than 0.5 mm). Also produced 1053K File. Attached. A first guess is that they're both using the same algorithm, but I have no evidence for that.

[chrisb]

1) Reload file and recompute.
2) Use --no-show-editor

You either did something different from your description or you didn't upload the right file. --no-show-editor is not set.

I have the same situation as before:
- Loading your file and directly exporting GCode takes 10 minutes to show in the editor and creates a 28000 lines file.
- doing a full recompute before doing the rest in the same ways results in a file of 200 lines without noticeable time lag.

OS: macOS High Sierra (10.13)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20406 (Git)
Build type: Release
Branch: master
Hash: bb45a2b01f9aafeae00cdf60c87b43fc36ad28ad
Python version: 3.8.2
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: C/Default (C)

[chrisb]

What happens if you inspect the GCode? If you mark the lines you should see the coloured mill paths.

[falviani]

I double checked twice and the --no-show-editor argument is definitely set. The file is attached. Also, I had started running the simulator - and it had repeated the paths more than twice - when my wife called for dinner. When I came back roughly 35 minutes later the simulator was still running. The saved file from this with the correct time stamp was still 1053 KB. I can't think of anything else.

[Russ4262]

I can reproduce the results with MillFace. I have not tested the other PathAreaOp-based operations. Yes, @FAlviani, MillFace and PocketShape use the same algorithm, Path.Area().

I did notice that changing the OffsetPattern to Line, Spiral, or Triangle removes the repetitive gcode issue. This suggests the problem is in Path.Area(). Further testing confirms problem is post-20276 nightly. Suggests recent Path.Area() commit on 5 April might be the issue. Running personal test file on 20276 yields correct g-code for inspection. 20477 produces erroneous g-code.

Russ

[m0n5t3r]

Sorry, I got thrown off by the initial post saying it's 1050 MB (not kB) and didn't look closer

The issue seems to be with whatever is generating the zigzag:

• zigzag goes back and forth forever (edit: like it's missing a stop condition or something; I thought maybe it was a rounding error on finish depth, but if you set finish depth to non-zero it does the same)
• offset does a single pass; if you also make it keep the tool down, it's pretty efficient
• zigzagoffset does the perimeter, then zigzag printer goes brrr (same as zigzag on its own)
• spiral is as broken as ever
• line works, does a single pass; with keep tool down it's almost like zigzag, but with a 3d printer-ish way of sorting paths
• the weirdo options (grid and triangle) also work correctly (I assume the results are pretty if you surface something shiny)

[dubstar-04]

[*] the weirdo options (grid and triangle) also work correctly (I assume the results are pretty if you surface something shiny)

The weirdo options! Ha ha, that has made my day.

We should vote on removing them from the options.

Thanks,

Dan

[chrisb]

I double checked twice and the --no-show-editor argument is definitely set.

Yes, here it is. And as to be expected after Russ' post, it still behaves the same. If you urgently need some GCodes - e.g. because if you cannot get to your mill you go on the nerves of your wife - you may upload the final file, and someone here will recompute it.

[Russ4262]

Paging Dr. RealThunder

ping

I think the recent change to Path.Area() might be the culprit for the issue experienced here. When you have time, will you please check. I went back to 20276 release last night and the issue does not occur. I'm using 20477 and I have the issue experienced here, like @falviani and @m0n5t3r.

Thank you, Sir.
Russ

[falviani]

It's not urgent - I have my wasteboard surfaced adequately. But I wanted to point out a problem. Now that others have reproduced it, I'm confident it will be tracked down and squashed quickly.