Path.Area: Welcome, to the new era!

Here's the place for discussion related to CAM/CNC and the development of the Path module.
sliptonic
Posts: 621
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcom, to the new era!

Postby sliptonic » Tue Jan 31, 2017 7:36 pm

realthunder wrote:
sliptonic wrote:Yes and no. The Path commands can handle additional axis of movement but the viewprovider ignores everything except XYZ.

hmm... I have zero experience with any machine beyond XYZ. So, how does it work? ABC is supposed to be the surface normal, right? So if any ABC move is executed, is the following XYZ in the rotated space or not. How does Path handle this? And also, if the user machine has less axis, say only has A, is there any way to convert Gcode file containing ABC move? I think this is in the Path postprocess territory. I haven't looked at that yet.


No, Gcode is pretty primitive and simple. Each move/axis is independent. The moves don't translate or rotate the part, they translate/rotate the cutting point relative to the current part coordinate system. So an 'A' move effectively rotates the cutting tool around the X axis. In practice, of course, it might be rotating the part in a rotary device or a trunion table or some other device but the part's coordinate system hasn't changed.

The only qualification to this is how arc moves are handled. A gcode (G17/G18/G19) determines the plane and then any arc moves (G2/G3) that follow are calculated in that plane. G17 is the default so arcs are calculated in the XY plane. The other selection planes are almost never used these days but I mention it now since it does affect how gcode is processed.
sliptonic
Posts: 621
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcom, to the new era!

Postby sliptonic » Tue Jan 31, 2017 7:44 pm

mlampert wrote:
realthunder wrote:... How does Path handle this? And also, if the user machine has less axis, say only has A, is there any way to convert Gcode file containing ABC move? I think this is in the Path postprocess territory. I haven't looked at that yet.

Currently none of the ops generate A,B or C moves. If the machine doesn't have all the axis then you can't generate g-code that would utilize any of those axis. It is definitely not something the postprocessor could do, the post processor is just the translation between abstract path command to physical command.


This is mostly true but there is a special case:. A 4th axis postprocessor could re-map an axis, say the Y axis, to A and have a property for the radius of the part. Then a 2D cut could be applied to a cylindrical object. Check out the lithophanes on Scorch's blog for an example. This is exactly the technique he uses. I think we could knock out a postprocessor in a weekend if anyone wants to play. :) Then again, this might be better as a dressup.
realthunder
Posts: 151
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcom, to the new era!

Postby realthunder » Wed Feb 01, 2017 9:40 am

sliptonic wrote:No, Gcode is pretty primitive and simple. Each move/axis is independent. The moves don't translate or rotate the part, they translate/rotate the cutting point relative to the current part coordinate system.

All this talk about coordinates is head spinning. See, when we think in terms of the ViewProvider, if the path contains ABC move, how should it display the toolpath? Moving toolhead doesn't really make any sense here (although, It'll be really nice to show the toolhead, and possibly animate it). The ViewProvider has to transform the XYZ coordinate with the current ABC to correctly show the toolpath, right?

My Path.Area is practically done. I am waiting for the cloud build results. Next, I am thinking of making some improvement on the Path ViewProvider. But this will be delayed, since I am caught up with something else. Before I get my hands dirty, I'd like to hear from you guys first. My thought of improvements are
  • Add support of ABC
  • When showing 'Nodes', use arrow instead of cross to visualize direction of the move
  • Add toolhead animation, with a play button to show continuous movement, single step button to step through the process, and a progress bar to jump back and forth.
herbk
Posts: 354
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Path.Area: Welcome, to the new era!

Postby herbk » Wed Feb 01, 2017 1:37 pm

Hi realthunder,
Before I get my hands dirty, I'd like to hear from you guys first. My thought of improvements are
Add support of ABC
....
your Path.area isn't merged to master jet, so i'm not able to say anything about it...

But, before thinking about new big steps to the feature, the things we have should be running well first... Especially for me: I don't need the workpath shown on the screen with each detail, i need the part comes out of the machine like expected.... ;) ;)
With "running well" i mean: the produced gcode is without foults and runs on each machine effectiv.
But "running effectiv" on the machine depends on the machine. Now we have only xyl axis, but quite for that are two different types of machines common, for which different workflows are necessary: "Mills" (like sliptonic on use) and "routers" (where i usualy work with). Both machines need (to work effectiv) differnt workflows, if you ad axis ABC, there are a lot machine configurations more possible, and for that also a lot more possibilities to make the gcode cumbersome or effectiv for a machine...

For that reason we are back to the theme "whats the first thing in a "path workflow".
I'm still in mind, there is only one "logical" way:
If i want to produce a gcode for a specified machine (and that is true if i make a path with toolcompensation), then i have to setup the machine first and the tooltable is part of the machine.

I wold like it mostly, if i can preset different machines, each with it's own tooltable. After creating a new job i would like tho select the machine i want to use for it. And on each path i want to be able to select the tool i want to use from the machines tooltable.
Especially on routers it must be possible to select the pathes in order to the tool it should be done with. On bigger routers (the bigest i can use has a tablesize 3500x2200mm) you make allways a lot of peaces at once and the order of the pathes (on the machine) has to be sorted by the tool.
Gruß Herbert
sliptonic
Posts: 621
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcom, to the new era!

Postby sliptonic » Wed Feb 01, 2017 2:49 pm

realthunder wrote:
My Path.Area is practically done. I am waiting for the cloud build results. Next, I am thinking of making some improvement on the Path ViewProvider. But this will be delayed, since I am caught up with something else. Before I get my hands dirty, I'd like to hear from you guys first. My thought of improvements are
  • Add support of ABC


Supporting ABC is, in my opinion a lower priority. Some code you could study for visualization is in Gcoderipper. The viewplane (ISO1/ISO2/ISO3) is what controls it. See: http://scorchworks.com/Gcoderipper/g_co ... .html#wrap
relevant mantis ticket: https://www.freecadweb.org/tracker/view.php?id=2553

  • When showing 'Nodes', use arrow instead of cross to visualize direction of the move

  • This one would be helpful. They should be quite small/subtle
    relevant mantis ticket: https://www.freecadweb.org/tracker/view.php?id=2428

  • Add toolhead animation, with a play button to show continuous movement, single step button to step through the process, and a progress bar to jump back and forth.

  • I would really like to see simulation at some point but not done this way. I'd rather see material removal simulation. So start with a stock shape and then remove material by sweeping a tool through it so the resulting object can be compared to the desired object. I don't think this is computationally feasible using booleans, especially for really large paths. I've seen some discussion about a voxel workbench and that is interesting to me in this area.

    Path has intentionally been kept very lean so it can handle large paths. I think that this continues to be a high priority. We should be able to display a Path with a million commands and not slow down the GUI. Whatever you decide to work on next, please keep speed as a high priority.

    All these are really good projects but there are others that might make even more use of your skills. Here's my small list of big dreams that take a much stronger programmer than I am.
    • A method of doing 'rest' milling. The basic idea is this: Detect area to be milled using a tool. Generate path. Calculate which parts of the area aren't reached by the tool. Use those areas as the input for another operation with a different tool. A blog post I did about this years ago.
    • How about doing for libactp what you did for libarea? Libactp itself can't be distributed directly with FreeCAD because of license but still might be immensely useful to Path users. I, for one, would LOVE to see some kind of adaptive roughing in Path.
      more info
    • Similarly, Opencamlib and openvoronoi need to be integrated into FreeCAD. License issues exist here too, of course. OpenCamLib for 3D surfacing and openvoronoi adds the possibility of center-line engraving. There are other solutions for center-line engraving that might work better for us. They need investigating.
    • If you want to stay within FreeCAD, I think there's some cool things that could be done between Path and the Robot workbench. This also fits in with the visualization angle.
    realthunder
    Posts: 151
    Joined: Tue Jan 03, 2017 10:55 am

    Re: Path.Area: Welcom, to the new era!

    Postby realthunder » Wed Feb 01, 2017 3:22 pm

    sliptonic wrote:All these are really good projects but there are others that might make even more use of your skills. Here's my small list of big dreams that take a much stronger programmer than I am.

    Wow, these are some advanced stuff. It'll take me some time to digest. And I am just planning on my first real CNC job besides those PCB milling I've done in the past, and that's what got me started with FC Path in the first place. I already have a toolchain to do PCB, and when searching for a CAM to do a little heatsink, I thought why not give FC Path a try, maybe try it with PCB first just to get familiar. And, the rest is history.
    sliptonic
    Posts: 621
    Joined: Tue Oct 25, 2011 10:46 pm

    Re: Path.Area: Welcome, to the new era!

    Postby sliptonic » Tue Feb 14, 2017 10:12 pm

    I've been playing with Path.Area when I'm still only having only limited success. I'm sure this is because I don't understand it yet and because I'm mostly trying to do things that I can't do other ways in Path now.

    For example, I started thinking about what a lathe turning operation would look like. I modeled a chess pawn and it's positioned as it would be in a lathe (ie sitting on the XY plane at 0,0)

    Then I positioned a cube like this:
    pp4-2.png
    pp4-2.png (82.45 KiB) Viewed 348 times


    I managed to get the FeatureArea generating pocket wires and I think I got the workplane correctly assigned so it seems to be working on the cube object. My thought was that taking a difference between the cube and the pawn would give me a shape that could be pocketed in a zigzag with the movements parallel to the Z axis (zig angle = 0). If the wires could be correctly ordered, this should give me roughly the path to clear to turn the pawn from a cylindrical stock.

    So far I haven't gotten the boolean part working, not to mention the wire ordering. I'm posting my file here to see if anyone can do better. :)
    Attachments
    lathepart1.fcstd
    (17.96 KiB) Downloaded 7 times
    herbk
    Posts: 354
    Joined: Mon Nov 03, 2014 3:45 pm
    Location: Windsbach, Bavarya (Germany)

    Re: Path.Area: Welcome, to the new era!

    Postby herbk » Wed Feb 15, 2017 7:33 am

    Good morning sliptonic,
    my (first) suggestion to generate a gcode for a lathe would be like that:
    cess2.png
    cess2.png (34.85 KiB) Viewed 332 times

    Picture is only simple, but i think you understand what i'm in mind... :)

    1. take the part in slices (the red lines). Each slice gives the coordinate for the x axis. The distance of the slices makes the quality of the surface
    2. take on each slice the radius, it gives the y coordinate.

    Then we need two different steps of a procedure, one for rawing and one for the surface

    For rawing the tool hase to run along the x axis for fast removing material. For rawing it could be possible to use only each 10 xy coordinate, - e.g.
    For finising the tool follows the xy coordinates from each slice.

    Edit: maybe its possible to use cura (or an other 3D printing slicer) to generate the slices...

    Edit Edit: to generate the xy coordinates only by slices will not result in a smoth surface... for rawing it may work...
    For the surface the gcode genarator hase to be more smart, has to note where is to cut a radius or where to move a longer (more theen slice dstance) distance in one direction...
    Gruß Herbert
    chrisb
    Posts: 1869
    Joined: Tue Mar 17, 2015 9:14 am

    Re: Path.Area: Welcome, to the new era!

    Postby chrisb » Wed Feb 15, 2017 8:57 am

    herbk wrote:1. take the part in slices (the red lines). Each slice gives the coordinate for the x axis. The distance of the slices makes the quality of the surface
    I don't think that path should do any slicing. If we mill a radius we don't tesselate the curve either. The path should be a circle (for the head of the chess pawn) and the quality is controlled by feed and speed.
    sliptonic
    Posts: 621
    Joined: Tue Oct 25, 2011 10:46 pm

    Re: Path.Area: Welcome, to the new era!

    Postby sliptonic » Wed Feb 15, 2017 4:51 pm

    A little closer working manually I get this from a boolean cut:
    snapshot-1.png
    snapshot-1.png (6.68 KiB) Viewed 291 times


    And this looks promising with the Feature area zigzag pocket...
    snapshot-2.png
    snapshot-2.png (11.32 KiB) Viewed 291 times


    And then apply the PathArea.....Nope.

    snapshot-3.png
    snapshot-3.png (22.38 KiB) Viewed 291 times