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: 594
Joined: Tue Oct 25, 2011 10:46 pm

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

Postby sliptonic » Mon Jan 30, 2017 5:49 pm

realthunder wrote:
chrisb wrote:Impressive.
I currently have two questions:
- Do you plan an integration with the concept of jobs and the tool selection as they exists now?
- In the other post you said, that circles can only be approximated, does this mean that no G2 or G3 commands are created in GCode?


- Yes, of course. Path::FeatureShape is a quick demo of Path.fromShapes script function. I am waiting for the Path developer's response here.
- The path generation uses the same libarea as the existing Path scripts. So, you will get all the G2 and G3 move as usual. What libarea does is to discretize all curves into line segments, do some processing, and fit back with arcs. The fitting of course is not perfect, but you can control the accuracy by tuning various parameters I exposed here.


This is definitely some powerful stuff. I was finally able to get it going and created pockets from shapes that wouldn't be possible otherwise. Very cool.

Since chrisb immediately asked the question about integrating this into the rest of Path, let's talk about that. I'm of two minds about it and not sure about the best way to proceed.

I still feel pretty strongly that this isn't an end-user tool. It's a 'swiss army knife' for making paths but as a general-purpose tool it isn't optimized for any one task. It's absolutely chock-full of options and parameters that aren't self-explanatory or intuitive. (Reorient?, clip-fill? explode? coplanar?, open mode? join type?, thicken? to name just a few). That's not a criticism, it's just an observation. If we put a tool like this in the main workflow, we're going to have a lot of confused casual users showing up in the forum needing help and complaining. When I look at tools like Fusion 360, I see tons of options and settings that are similar to these but they are presented in an integrated and seamless way. The options that are important to pocketing appear in the pocketing context and are not present when the user is profiling.

Up until now, the user-facing functionality in Path has all been done in Python. The basic unit of work is the 'operation' and the context of the operation is the 'job'. Operations generally work on features of a base object (ie Faces, Profiles, holes, etc) I would suggest that what realthunder has built is more fundamental and needs to be integrated into the end user tools. For example, the pocket operation needs to be rebuilt to use the Path.Area strategies. In other words, I think it's a mistake to create a new tool that creates pockets in a different way rather than improve the existing pocket tool. The same thing is true for profiling, etc.

I said I was of two minds. My other thought is that we NEED a swiss army tool in Path. Advanced 'power users' will need to create unusual kinds of paths and having a general purpose tool is great. Even more importantly, the developers working on those end-user tools need something like this to explore the libarea options. So I think FeatureArea/PathShape should be further developed as a general purpose tool but NOT left on the main toolbar. Maybe we should add something like an 'advanced' menu item or an optional toolbar that is disabled by default. Basically hide the super-powerful tools from the novice users.

Another option would be something like a 'wizard' that takes the user through a set of dialogs to configure all the deep magic. I have no idea how such a thing would be built and I'm not really a fan of 'wizards' but some people like them.

Either way, I think we should merge as soon as possible and start figuring out how to make the UI / workflow as intuitive and simple as possible.

Realthunder, please don't 'lone wolf' this development. Path is a team effort and there's people who are good at UI/UX issues that can help.
realthunder
Posts: 104
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Mon Jan 30, 2017 6:30 pm

sliptonic wrote:This is definitely some powerful stuff. I was finally able to get it going and created pockets from shapes that wouldn't be possible otherwise. Very cool.

Since chrisb immediately asked the question about integrating this into the rest of Path, let's talk about that. I'm of two minds about it and not sure about the best way to proceed.


Thanks for this thoughtful response. And I agree hundred percent with you. I designed Path.Area with the intention of being a developer's tool in the very beginning. I spend extra miles to expose as many parameters as possible to make it flexible (also keeping with the spirit of parametric modeling, I guess). The current UI change is just some hack for quick demo. UI design is never my strength, anyway.

I've already fixed the clang build error, but haven't pushed the change yet. Just a few last touch and it is ready to be merged.
mlampert
Posts: 279
Joined: Fri Sep 16, 2016 9:28 pm

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

Postby mlampert » Mon Jan 30, 2017 8:40 pm

yay - best of both worlds!
how about a parameter setting, not exposed in the preferences dialog, to enable/disable?
chrisb
Posts: 1651
Joined: Tue Mar 17, 2015 9:14 am

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

Postby chrisb » Tue Jan 31, 2017 1:50 am

From a user's point of view I want to have it simple. And powerful. And these two tasks to combine is not simple.

I want to have standard applications similar or equal to the existing ones:
First I think we can agree that the concept of Job and Tool Controlles is sufficiently settled (I am not talking about the UI here, that might change).

Next I want these simple things like "Select a face and create a pocket". That's how it always starts and often that's enough.
Sometimes there is more about it and then I want to have the possibility to fine tune the creation of paths to very special needs. So I can imagine a GUI where I have some kind of one or more expert tabs where I can fine tune additional parameters.
I do not really want to have two possibilities to create the same path, although I can live with it. So I would rather not have the tools as they are now plus an additional tool for all the fancy stuff.

I like systems doing exactly what I want (I remember the DWIM function the lisp editor had at university, meaning "Do What I Mean" :D ) but as much as people try there comes a point where I want to do something else so I really want to have a possibility to access all these neat functions - if ever necessary. Well as a last resort for verrryyy special things there is always the possibility for Python macros.

And here we come to the implementation part: I would like to have a uniform interface to the calls of the libarea object, so that I can have a quick glimpse at a python file and understand immediately how to create an appropriate macro for my special needs (here I would have liked to enter an Utopia emoticon).
realthunder
Posts: 104
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Tue Jan 31, 2017 11:13 am

Some new features added.

Segmentation, to break long curve into segments. Immediate use case: PCB milling autolevel.
Screenshot from 2017-01-31 18-29-09.png
Screenshot from 2017-01-31 18-29-09.png (290.41 KiB) Viewed 218 times


3D wire sorting support. Why stop at 2.5D? Highly experimental, though. Path currently ignores A,B,C axis, I think.

Code: Select all

import Part,Path
doc=App.newDocument('test')
sphere=doc.addObject('Part::Feature','sphere')
sphere.Shape = Part.makeSphere(4)
sphere.ViewObject.Transparency = 50
box=doc.addObject('Part::Feature','box')
box.Shape = Part.makeBox(16,16,10,App.Vector(-8,-8,-5))
box.ViewObject.Transparency = 80
pocket = Path.Area(PocketMode=2,ToolRadius=0.5).add(box.Shape).getShape()
Path.show(Path.fromShapes(sphere.Shape.project(pocket.Wires)))
doc.recompute()

Screenshot from 2017-01-31 19-11-59.png
Screenshot from 2017-01-31 19-11-59.png (189.4 KiB) Viewed 218 times
cox
Posts: 912
Joined: Wed Nov 26, 2014 11:37 pm

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

Postby cox » Tue Jan 31, 2017 11:37 am

:o :shock:
Need help? Feel free to ask, but please read the guidelines first
triplus
Posts: 4850
Joined: Mon Dec 12, 2011 4:45 pm

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

Postby triplus » Tue Jan 31, 2017 12:59 pm

Looking good.

P.S. I would vote for the changes to be upstreamed in a way current Path developers and maintainers get to know and understand the code and functionality involved. And for more discussion to evolve around specific parts of it. This way optimal results will likely be achieved on the long run compared to doing it in a hurry and figuring out the details after.
sliptonic
Posts: 594
Joined: Tue Oct 25, 2011 10:46 pm

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

Postby sliptonic » Tue Jan 31, 2017 1:51 pm

realthunder wrote:3D wire sorting support. Why stop at 2.5D? Highly experimental, though. Path currently ignores A,B,C axis, I think.


Yes and no. The Path commands can handle additional axis of movement but the viewprovider ignores everything except XYZ.
realthunder
Posts: 104
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Tue Jan 31, 2017 6:58 pm

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.
mlampert
Posts: 279
Joined: Fri Sep 16, 2016 9:28 pm

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

Postby mlampert » Tue Jan 31, 2017 7:25 pm

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.

As a simple example, let's say you wanted to cut out a disk in the X,Y-plane. Path has 2 ways of doing that (assuming you moved the tool to the radius and depth already):
a) stitching together a circle by G2 or G3 commands, as it is done today by all ops in Path
b) rotate the XY-plane by a G1 command and specify the C value

a) has the advantage to be supported by almost all practical machines today, whereas b) has the advantage to result in a perfect circle (no Pythagoras involved anywhere in the processing).