View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002786 | Path | Bug | public | 2016-11-19 19:33 | 2018-01-12 22:53 |
Reporter | sliptonic | Assigned To | yorik | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | won't fix | ||
Platform | all | OS | all | OS Version | all |
Product Version | 0.17 | ||||
Target Version | 0.17 | ||||
Summary | 0002786: Path.fromShape() doesn't produce correct path | ||||
Description | Path.fromShape() takes a wire and should produce a path directly from the edges. However the resulting path does not meet expectations. | ||||
Steps To Reproduce | test macro:
| ||||
Additional Information | The edges in the wires unsorted are in a reasonable order but are not correctly oriented start to finish. Given the unsorted output below, here's the expected output (with explanation) and the actual output. EXPECTED unsorted edges (0.0, 100.0, ':', 0.0, 0.0) (100.0, 100.0, ':', 0.0, 100.0) (100.0, 100.0, ':', 100.0, 0.0) (100.0, 0.0, ':', 0.0, 0.0) G0 X0 Y0 Z10 (Rapid move to first position) G1 Z10 (feed move to first depth) G1 X0 Y100 Z10 (feed move along first edge) G1 X100 Y100 Z10 G1 X100 Y0 Z10 G1 X0 Y0 Z10 (feed move along last edge) G0 Z10 (rapid back to original depth) ACTUAL unsorted edges (0.0, 100.0, ':', 0.0, 0.0) (100.0, 100.0, ':', 0.0, 100.0) (100.0, 100.0, ':', 100.0, 0.0) (100.0, 0.0, ':', 0.0, 0.0) G0 X0 Y100 Z10 G1 Z10 G1 Y100 Z10 G1 X100 Z10 G1 Z10 | ||||
Tags | No tags attached. | ||||
FreeCAD Information | |||||
|
|
|
I played around with this a bit and I think there are 2 problems here. 1) As you discovered (and the commented out code indicates), Path.fromShape() does not modify the given Wire/Edges in any form. It takes each Edge as it is and translates that to a Command. In order to make a valid Path, or something you expected, the given Edges would need to be sorted /and/ re-oriented. which brings us to the harder problem here 2) If Path.fromShape starts re-ordering and re-orienting Edges, then the given example above has 8 valid resulting Paths it could generate. It has 4 possible entry points and it could process the loop CW or CCW. Obviously it gets more interesting with more complex wires. I've attached the resulting Path of a Contour of a cylinder, 5 circles and 8 lines. 2 loose ends either one can be used as a starting point ..... if I'm not mistaken there are 20 valid Paths possible .... What I'm getting at is that for any decently shaped wire the result is not predictable (and therefore of little value) iff we let Path.fromShape() modify the input wire. It's probably OK to re-orient an Edge (except for the first one) but everything else should be processed as is. The onus of placing the entry point as Vertex[0] of the first Edge in the wire and sorting the rest of the edges properly should be on the caller. There is still the question of which way to traverse a full circle though. |
|
@realthunder do you mind weighing in? |
|
My contribution is in Path.fromShapes(). For the code in Additional Information, to get the path you want
The 'start' parameter specifies the starting position. If not set, defaults to (0,0,0), which will cause the algorithm to use (xMax,yMax,zMax) of the bounding box of the shape as the start position. The GCode produced,
Because of the complex nature of CAM, Path.fromShapes has quite a few parameters for you to play with. It can handle very complex raw wires (such as PCB milling path) and can sort the wires to minimize travel. You can use PathShapeFeature to explore the parameters using Gui. Simply select the shape and click 'Create path from selected shape' in Path workbench. Hover the mouse in each parameter for explanation. |
|
Path.fromShape is a python implementation. It's very old and was meant to be a reference implementation to build more complex things from. I think it should be deprecated and removed. Path.fromShapes is realthunder's implementation of a similar general tool and much more powerful. The only issue I see with it is that the user can't get it into a Job so it can be postprocessed. It's a c++ implementation so I've got no clue. If someone can weigh in on how we modify fromShapes, I think this ticket can be closed pretty quick. |
|
@wmayer do you mind weighing in? |
|
@mlampert what say you in regards to 0002786:0009689 ? |
|
Is the result of fromShapes a valid Path object? If yes, then I suppose the problem lies within the job object itself? |
|
@sliptonic can you explain how path are added to jobs? Couldn't find that in the code... |
|
this is @mlampert's code so he knows it better than I. I believe it's done in the base class PathOp. in _setBaseAndStock() All the operations retain a reference to their job. @mlampert, can you clarify how the Job tree gets built on the GUI side? |
|
Job uses a Path::FeatureCompoundPython as the Operations property, and whatever gets added to that is part of the job. I've never looked at the internals of Path::Compound that code predates my involvement. |
|
Okay, Part.fromShapes() seems to do the job much better than the old fromShape, which could be deprecated. Indeed I see now that it is easy to add the generated object to the Group property of the Operations subobject. So I guess @sliptonic's question is solved too. I suggest then to simply change the docstring of Part.fromShape to indicate that it is deprecated? |
|
https://github.com/FreeCAD/FreeCAD/commit/fb8875df08146c520d8ce8cd351da624360ba5d5 |
|
https://github.com/FreeCAD/FreeCAD/commit/fb8875df08146c520d8ce8cd351da624360ba5d5 |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-11-19 19:33 | sliptonic | New Issue | |
2016-11-19 19:33 | sliptonic | Status | new => assigned |
2016-11-19 19:33 | sliptonic | Assigned To | => yorik |
2016-11-23 07:22 | mlampert | File Added: cylinder.png | |
2016-11-23 07:43 | mlampert | Note Added: 0007485 | |
2017-05-11 03:20 | Kunda1 | Steps to Reproduce Updated | |
2017-05-13 12:55 | Kunda1 | Note Added: 0008992 | |
2017-05-13 16:58 | realthunder | Note Added: 0008993 | |
2017-05-13 17:00 | realthunder | Note Edited: 0008993 | |
2017-07-08 16:57 | sliptonic | Note Added: 0009689 | |
2017-07-08 17:13 | Kunda1 | Note Edited: 0009689 | |
2017-09-25 13:11 | Kunda1 | Note Added: 0010190 | |
2017-11-06 13:03 | Kunda1 | Note Added: 0010387 | |
2017-11-28 03:48 | mlampert | Relationship added | related to 0003276 |
2018-01-11 16:11 | yorik | Note Added: 0010739 | |
2018-01-12 17:32 | yorik | Note Added: 0010746 | |
2018-01-12 18:18 | sliptonic | Note Added: 0010747 | |
2018-01-12 18:42 | mlampert | Note Added: 0010748 | |
2018-01-12 19:05 | yorik | Note Added: 0010749 | |
2018-01-12 19:07 | yorik | Note Added: 0010750 | |
2018-01-12 22:53 | wmayer | Status | assigned => closed |
2018-01-12 22:53 | wmayer | Resolution | open => won't fix |
2018-01-12 22:53 | wmayer | Note Added: 0010751 |