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 245 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 4 times

Regards,
CVH