Creating Lasercutting Paths

Here's the place for discussion related to CAM/CNC and the development of the Path module.
leonardshelby
Posts: 48
Joined: Sat Feb 24, 2018 6:09 pm

Creating Lasercutting Paths

Postby leonardshelby » Wed Dec 05, 2018 8:08 pm

I am trying to create paths for a K40 lasercutter. K40 whipserer is a nice open source tool that allows these cheap machines to run from gcode.

I am running into a few issues though.. maybe someone here can help?

My parts have 'folding lines' and cutlines and I can't find a way to get them cut in a single line yet.

I am creating them as the 0,2mm thin slots in the shape, so that path will recognize them. In the tool settings I am using a mill with 0,2mm diameter (the beam diameter of this CO2 laser in focus). Now I was hoping that "use compensation" in the Tool Controller would do the trick, but it will just dismiss the slots. So far it only runs 'around' the inner lines when unchecked as in the attached screenshot.

Edit: I just found the engraving option where I can select single edges for engraving/cutting.. that could to the trick :)

Here's my info:

OS: macOS 10.14
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15305 (Git)
Build type: Release
Branch: master
Hash: 4d4f0162776b80f9740ef129536d8ba85ea72f73
Python version: 3.6.7
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)
Attachments
Screenshot 2018-12-05 at 20.48.12.png
Screenshot 2018-12-05 at 20.48.12.png (67.73 KiB) Viewed 701 times
herbk
Posts: 1428
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Creating Lasercutting Paths

Postby herbk » Wed Dec 05, 2018 8:36 pm

Hi,
Path unfortunaly makes only "looped" pathes, with one exception... May be that could help:
https://forum.freecadweb.org/viewtopic.php?f=15&t=31921
Gruß Herbert
leonardshelby
Posts: 48
Joined: Sat Feb 24, 2018 6:09 pm

Re: Creating Lasercutting Paths

Postby leonardshelby » Wed Dec 05, 2018 9:11 pm

Yes, that example also uses engrave. Just with a seperate sketch for the lines. In my case it is probably easier to create slots/holes in the part with the edge I want to cut in mind. I'll have to get comfortable with the path module and see. Thanks for the link!
JulianTodd
Posts: 51
Joined: Tue Oct 23, 2018 3:35 pm

Re: Creating Lasercutting Paths

Postby JulianTodd » Fri Dec 07, 2018 6:10 pm

I wonder if laser Laser cutting should be its own workbench. Now I have thought about it, there is not as much an overlap of features with "normal" CNC milling as it looked.
User avatar
sliptonic
Posts: 1557
Joined: Tue Oct 25, 2011 10:46 pm

Re: Creating Lasercutting Paths

Postby sliptonic » Fri Dec 07, 2018 6:32 pm

We're going to run into a similar issue when we start building operations for lathe, 4th axis milling, etc. I wouldn't be in favor of entirely new workbench for each of these flavors. Rather, I'd like to see the concept of 'job types' added.

A job type would roughly correspond to a machine type and control the kinds of operations that are permitted and could reduce visual noise in the GUI from tools that don't really apply.
leonardshelby
Posts: 48
Joined: Sat Feb 24, 2018 6:09 pm

Re: Creating Lasercutting Paths

Postby leonardshelby » Fri Dec 07, 2018 11:00 pm

It works pretty straight forward already using engrave and a few workarounds.

A "laser/plasma" option in the tool type dropdown with other options (xy movements only, optional z axis for focal length/rotary axis) could make sense.

That said, those Z movements and some other gcode are ignored by K40whisperer and I can lasercut parts already from FreeCAD's generated gcode.
JulianTodd
Posts: 51
Joined: Tue Oct 23, 2018 3:35 pm

Re: Creating Lasercutting Paths

Postby JulianTodd » Mon Dec 10, 2018 12:44 pm

Maybe you're right, keeping it all in the same work-bench. It's all CAM paths doing XYZ motions at particular speeds.

But I guess we'd need a generalization of the idea of a milling bit, to include things like "jet of water" and "beam of light" as well as "spinning cylinder of metal with blades". All of these feel similar when cutting, but you get big differences with (a) leading in-out from the cut pass (because the water jet has to turn on and off in the waste metal away from the job as it's a bit scrappy), and (b) linking (because lasers can turn on and off instantly).

I've always favoured putting leads, links and ordering in a totally separate block component (like those "dressup" stages), rather than rolled in to the main toolpath algorithm. That's how I structured it in the UI of the first CAM system I worked on back in 1994 called "Machining Strategist/DepoCAM", but it didn't catch on with the rest of the world. It does isolate the software components much better, and makes them easier to reuse across the different strategies.
leonardshelby
Posts: 48
Joined: Sat Feb 24, 2018 6:09 pm

Re: Creating Lasercutting Paths

Postby leonardshelby » Mon Dec 10, 2018 3:07 pm

After the first few days working with paths, I am running into the same issue as I do with part design: the name of the edges that I select for engraving change, even when I am not deleting the 'source'-lines when working in sketcher. So it breaks the paths, just like references to ext. geometry in part design tend to break.

I can fix it by deleting and redoing the edges or faces in the path tools as my models are simple. But I guess this can be frustrating for users that do prototyping for more advanced parts.
User avatar
sliptonic
Posts: 1557
Joined: Tue Oct 25, 2011 10:46 pm

Re: Creating Lasercutting Paths

Postby sliptonic » Mon Dec 10, 2018 4:01 pm

JulianTodd wrote:
Mon Dec 10, 2018 12:44 pm
But I guess we'd need a generalization of the idea of a milling bit, to include things like "jet of water" and "beam of light" as well as "spinning cylinder of metal with blades".
I believe improving the tool definition is the most pressing thing on our plate right now. The tool and tooltable classes are in C++ but very simple. They're basically just bags of properties. All the behavior of a tool is done in python, specifically in the tool controller.

We already have the idea of a tool type which drives which properties are to be populated. We could add an additional type for 'waterjet/plasma/laser'. The type would only have a diameter.

The tool controller in python, on the other hand needs more work. Specifically, it should make a shape object available based on the configured properties. A laser/waterjet would just return a cylinder but a more complex tool might return a more complex shape. Such a shape could be either rendered on the screen for visual confirmation or converted to a mesh for collision detection.
I've always favoured putting leads, links and ordering in a totally separate block component (like those "dressup" stages), rather than rolled in to the main toolpath algorithm. That's how I structured it in the UI of the first CAM system I worked on back in 1994 called "Machining Strategist/DepoCAM", but it didn't catch on with the rest of the world. It does isolate the software components much better, and makes them easier to reuse across the different strategies.
I like this approach too though I think our UI could be better. mlampert had some interesting ideas about 'super operations' which would be user-configured regular operations with pre-added dressups.