White paper; "Add Pocket Zig-Zag Toolpath

[HJ Seef]

White paper "Add Pocket Zig-Zag Toolpath".

Originele tekst in het Nederlands, vertaling naar globaal engels.
Original text in Dutch, translation into global English.


Introductie

Mijn eerste CAD-ervaring was met CeadsCad op een HP1000 main frame, en daarna overgestapt naar AutoCAD 2.6. In AutoCad R10 DOS veel AutoLisp-routines ontwikkeld. Daarna jaren geprogrameerd met de relationele datebase Paradox in PAL, en daarnaast een beetje Arduino-C ervaring. Ik gebruik vanaf 2015 QCAD.

Ondanks herhaalde verzoeken in de afgelopen jaren van meerdere gebruikers, laat de introductie van kamerfrezen in QCAD/CAM nu wel heel lang op zich wachten.

OK, QCAD is open source, en er moeten mensen zijn met meer hersens en actuele programmeer-ervaring, dus laat ik een voorzet geven met een inventarisatie, en een basis-ontwerp-werkvolgorde voor een eenvoudige kamerfrees-routine.

My first CAD experience was with CeadsCad on an HP1000 mainframe, after which I switched to AutoCAD 2.6. I developed many AutoLisp routines in AutoCAD R10 DOS. After that, I programmed for years with the Paradox relational database in PAL, and also have some Arduino-C experience. I've been using QCAD since 2015.

Despite repeated requests from several users over the past few years, the introduction of pocket milling in QCAD/CAM is taking a very long time.

OK, QCAD is open source, and there must be people with more brains and up-to-date programming experience, so let me offer an inventory and a basic design workflow for a simple pocket milling routine.

Read more in the attached pdf.....

[CVH]

Onnodig en ook vervelend is dat het DXF- en NC-bestand nu zeer snel veel (te!) groot wordt.

Dat zal altijd het geval zijn voor het NC-bestand.
Uiteindelijk is dat het probleem niet, een paar tot meer dan 120 miljoen lijnen is niet abnormaal in mijn geval.

Bv. 11000 mm² verwijderen (AddPocketZigZagToolpath.DXF) met een tool-diameter van 0,10 mm vereist al gauw twee duizend G-code lijnen.
Dit voorbeeld is te simplistisch, één gebied met één eiland.
Het wordt een pak moeilijker voor de situatie van uw printplaat voorbeeld.

Ondanks herhaalde verzoeken in de afgelopen jaren van meerdere gebruikers, laat de introductie van kamerfrezen in
QCAD/CAM nu wel heel lang op zich wachten.

Tja.

OK, QCAD is open source, en er moeten mensen zijn met meer hersens en actuele programmeer-ervaring.

QCAD CE is het enige deel dat open source is, QCAD PRO of QCAD/CAM zijn dat niet.
Voor de QCAD PRO of QCAD/CAM add-ons is er maar één ontwikkelaar.

Groet,
CVH

[HJ Seef]

=> => "OK, QCAD is open source, and there must be people with more brains and actual programming experience."
=> "QCAD CE is the only part that is open source; QCAD PRO or QCAD/CAM are not. For the QCAD PRO or QCAD/CAM add-ons, there is only one developer."

Yes, and these are the two major problems hanging over QCAD's future like the Sword of Damocles. If the sword falls, the sole developer falls, and so does QCAD. Making all the effort and energy put into it for nothing.

Even a programmer has to raise and feed his children. That's the reason why I've now purchased QCAD for the third time. However ....

I only hope the sole developer has taken the necessary precautions to ensure the source code becomes available after his fall. After all, if that doesn't happen, the autocad highway robbers will win; and they won't have to do anything to get it.

[HJ Seef]

=> "This example is too simplistic, one area with one island. It becomes much more complex for your printed circuit board example. "

OK, challenge accepted. The PCB does indeed contain a complex chamber structure. Yet, it turns out to be quite simple to devise a solution method (algorithm) for it.

To make the solution method suitable for rough milling, or finishing with a plotter or laser cutter, the title of the white paper has been changed to "Draw Pocket Zigzag Path." I think this solution also fits better with QCAD's design philosophy. I did my part and come up with a solution; now it's up to the ECMAscript enthusiasts to develop it.

[CVH]

It wasn't meant as a challenge, but why not take on the challenge!
Naar aanleiding van de herziening van uw White paper heb ik U een privaat bericht gestuurd. zie rechts boven.

Regards,
CVH

[CVH]

All,

Making progress, seems feasible.
But not really in the way the white paper describes it simplistically.
To start, there is no logical sequence in the pattern segments.

For us that is obviously the top-leftmost to the bottom-rightmost as in the white paper.
Just a matter of connecting one ending to the next.

In the attached DXF there are some erratic boundaries a the left.
Created 2 hatches of those using a dedicated pattern:
Top in scale 1 ... step-size 1, the lower in scale 0.1

The tool then creates the paths AGAIG.
- Top: Hatch loops: 3 - Hatch lines 292 - 13 paths - 9358units long in total
- Low: Hatch loops: 3 - Hatch lines 2916 - 26 paths - 90652units long in total

Detail Top scale 1

ZigZagPaths.png (3.37 KiB) Viewed 4844 times

Here horizontal and it works for a Hatch at an angle, although it was only a quick test.

At boundaries it injects a part of the common local boundary.
It must be logic that these are already inward offsets to compensate for the tool radius.
But it avoids to follow the boundary over an extended length with the chance of doing things twice.

Some logical looking connections along the boundaries are not made based on 'Too long'.
The correct logic would be: 'Don't cross another pattern segment' what increases the complexity by at least two.

Especially in the finer grid you may probably spot things that might be merged.
Give it a try but you won't end up with 10 or so paths.

Between endpoints it must traverse, let QCAD/CAM 'Travelling Salesperson Algorithm' handle that.

Looking forward to team up with HJS (user HJ Seef), TBC.

Preliminary_ZigZagPaths.dxf

Development base

(353.48 KiB) Downloaded 114 times

Regards,
CVH

[HJ Seef]

=> "To start, there is no logical sequence in the pattern segments."

Yes there is, but it is not clear to you ... yet.


=> "Looking forward to team up with HJS (user HJ Seef), TBC."
Send you a private message (in dutch).

Checked the attached example. Altered the outer boundary. Mind that all zigzag-paths must start in the same direction. That's important when rough milling a pocket.

[CVH]

Live test of the Add-On tool: DrawZigzagPocketPath

The tool exploits primarily:
- The QCAD hatching engine
- Generating offsets to a Polyline, a set of Polylines (A Pro resource called RPolygonOffset)

In that lies it strength ... But also its weakness in some cases.

From the above design in '250715_Triac_Module_B_Cu_LaserZigZag.dxf' by user HJ Seef I isolated the required contours.
There was still some work to be done to correctly define the 26 perfectly closed Polylines on layer 'B_CU'.
Then I defined a Hatch with the area to process, the copper to be removed on layer '2) ...'
A copy of that Hatch was fed into DrawZigzagPocketPath and the results can be found in the attached file on layer '3) ...'

250715_Triac_Module-ZigZagTest.dxf

(2.96 MiB) Not downloaded yet

250715_Triac_Module-ZigZagTest.png (12.73 KiB) Viewed 270 times

Green: Zig-Zag tool paths, Cyan: Finishing passes, Blue: Original contours.
I must add that the needed parameters are quite harsh, the working Hatch has 11,336 line segments to be merged.
The total length of the trajectories is over 75 meters for a PCB not larger than 78 by 124mm.
Even at FEED 1000mm/min that would take over an hour not accounting declarations at reversals.

What I could have expected for this test:

• Pattern stability should be rigorous by default.
  The Hatching engine may simply time out => Maxed out this preference to 10,000ms, 10s and more is possible.
  New is the complexity threshold in recent releases.
  It is rare, but not unknown, for the hatch engine to fail partially.

• Offsetting any arbitrary set of Polylines is, as is well known, not always guaranteed to be flawless.
  Said to be an issue of small values from small shapes (Arcs), the number system and not complying with fixed internal tolerances.
  The solution is typically found in scaling the source up and scaling the results back down.
  In such a case we must adapt the Add-On tool options accordingly.

Noting the Hatch engine flaws documented for layers 'X) ...' and 'XX) ...' I can conclude that the live test went well.
Well but not error free, the Add-On didn't invent those errors in the export.
These were most probably generated by the Hatching engine.

Offsetting these 25 contours was no problem, on purpose each limited to a single offset to all 25 Polylines at once.

Regards,
CVH

[CVH]

Did the same test but now angled at 22.5 degrees.
12257 Hatch-segments merged to 64 Zig-Zag paths.

More chains but all in all a fraction shorter.
This time it took about 19 minutes to generate the export.

Some time factors are:
- Waiting on the Hatching engine, time-out is maxed out at 10s (Longer is possible).
- Waiting on RPolygonOffset results, about 8-9s per call for the set of 25 Polylines.
- In between rigorous testing, eventually with warnings of the unexpected, not expecting everything to be as expected.
- (Fast) C++ resources that return the unexpected circumvented by JS code.
- With some tweaks it runs on QCAD 3.32.4 just the same as on QCAD 3.26.7 (Scripting is not backwards compatible, nor forward).

The most important note: Error free
And that all in a single click

250715_Triac_Module-ZigZagTest2.dxf

(3.17 MiB) Downloaded 2 times

Regards,
CVH