Dear Jescombe,
this didn't change the situation at all. Nether adaptive with surface not adaptive with edges works. Latter one tells that "edgewalker has no edger to load". Sounds like a bug, since surface is defined by edges as far as I understand.
Best regards,
Timo
Beginner's problems with model change
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Beginner's problems with model change
Dear Jescombe,
this didn't change the situation at all. Nether adaptive with surface not adaptive with edges works. Latter one tells that "edgewalker has no edger to load". Sounds like a bug, since surface is defined by edges as far as I understand.
Best regards,
Timo
this didn't change the situation at all. Nether adaptive with surface not adaptive with edges works. Latter one tells that "edgewalker has no edger to load". Sounds like a bug, since surface is defined by edges as far as I understand.
Best regards,
Timo
Re: Beginner's problems with model change
So the steps I used for testing were;
- Open a copy of your latest file attachment
- Disable the active operations in Job_out
- Open the Part workbench
- Select the original BaseFeature model from Body_out, and Part->Create Copy->Create simple copy
(should create a new BaseFeature002) - Hide Body_out
- Open the Path workbench
- Create a new Path Job, based on BaseFeature002
- Select Face32 (the large flat face) and click on Adaptive
- In the Operation panel, click on Use Outline, and then apply
(should get a path that ignores the holes & pocket, but still remains away from the edges) - In the Extensions panel, click on Enable Extensions, and then select Edge 158 & Edge 162
(should get a path like the screenshot in earlier message, that also clears the open edges at the bottom)
Re: Beginner's problems with model change
Dear Jescombe,
thanks, I will see what I can get done. Redoing all jobs entirely is quite an excercise.
In the attached picture the Step geometry wire loop direction can be seen from the extension attempt. Large surface has a hole into which the edge reinforcement is attached. Since it is a hole, attachment edge should have running direction opposite to large surface outer edge (outside of the picture). This loop gets copied to frame top edge by the individual frame side surfaces, creating automatically same running direction than the original hole had. If the orientation is not checked and reversed, it has incorrect (hole) orientation for the frame top surface outer edge loop. This can be seen from pink extension, it points incorrectly inside. Looks that material direction check is not done for the loop in FC either. Should be, this is common situation in Step files.
Check may be quite complicated in some occasions, like surfaces having long and curvy fingers. I wouldn't hold breeth waiting it to be perfectly solved for some time. Therefore I suggested a loop ignorance/consideration possibility by the user. Then it is enought that loops are identified and user can choose whether they are holes or islands.
In principe this is not a bug, but Step file weakness seen often. Therefore I don't know how I should try to report it in FC community so that someone dealing with the routines could write a solution to it. Can you give a hint?
Best regards,
Timo
thanks, I will see what I can get done. Redoing all jobs entirely is quite an excercise.
In the attached picture the Step geometry wire loop direction can be seen from the extension attempt. Large surface has a hole into which the edge reinforcement is attached. Since it is a hole, attachment edge should have running direction opposite to large surface outer edge (outside of the picture). This loop gets copied to frame top edge by the individual frame side surfaces, creating automatically same running direction than the original hole had. If the orientation is not checked and reversed, it has incorrect (hole) orientation for the frame top surface outer edge loop. This can be seen from pink extension, it points incorrectly inside. Looks that material direction check is not done for the loop in FC either. Should be, this is common situation in Step files.
Check may be quite complicated in some occasions, like surfaces having long and curvy fingers. I wouldn't hold breeth waiting it to be perfectly solved for some time. Therefore I suggested a loop ignorance/consideration possibility by the user. Then it is enought that loops are identified and user can choose whether they are holes or islands.
In principe this is not a bug, but Step file weakness seen often. Therefore I don't know how I should try to report it in FC community so that someone dealing with the routines could write a solution to it. Can you give a hint?
Best regards,
Timo
- Attachments
-
- Extension direction.PNG (179.84 KiB) Viewed 382 times