Adding scripts to a job?

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
zohozer
Posts: 119
Joined: Mon Jul 28, 2014 8:35 pm

Re: Adding scripts to a job?

Post by zohozer »

Hi WayofWood. I am also working in the wood/furniture industry and to my current job I do have a combination of SolidWorks with Alphacam. A nice feature of Alphacam is the fact that can import an entire SolidWorks assembly, break down and sort the pieces by thickness, nest them automatically into sheets, recognizes and extracts all the features for mechanisation, applies the apropiate machining styles and generate the gcode for our CNC machine, all of this very quickly. I think such a solution we need to aim for to FreeCAD.

Would be great if Path workbench would be able to recognize all the features that needs to be mechanized and apply the apropiate mechanisation/drilling startegies.

For thinkering this old video can present some ideeas on how they are doing this process: Alphacam 2014 R2 - Feature Extraction
User avatar
WayofWood
Posts: 62
Joined: Mon Nov 26, 2018 4:59 pm

Re: Adding scripts to a job?

Post by WayofWood »

sliptonic wrote: Thu Jan 20, 2022 7:20 pm All my comments are predicated on the idea that a keyhole is a super simple cut as described. I could be convinced that the input geometry should be a wire and the logic is to follow the wire from start to end and then reverse it with rapid moves to exit. That would work as well and would let you do all kinds of crazy keyhole cuts. Does that have value?
Thanks a lot for the explanation.

If I understand you right the generator should have the simple motion with an ideal set of information so that in the key hole example the start point and the the end point are know. The GUI would then implement a method that would help to select the start and the end point (e.g. by selecting the center of the circle or by selecting the starting point).

Would it maybe even make sense to separate the logic in three steps?

The three stages could then be something like
  • GUI select points
  • Information converter (backend stage 1) - convert bad into usable information
  • Generator (backend stage 2) - create G-code from perfect information
I think that this could have a few advantages:

The code for the information conversion becomes scriptable: Imagine we would iterate the code a bit more (and some one more talented in coding python than me would contribute ;)) and we would find a method to identify a keyhole and its direction by selecting an arbitrary part of the keyhole. I think it would be nifty if this piece of code could be called from outside the GUI. This way one could test if a certain element is part of a keyhole.

The "information converters" become reusable: At the moment pocket and adaptive behave differently when selecting an open notch (see image below). While adaptive is cleaning the area if one selects three wires from the bottom pocket requires a face to operate.
Bildschirmfoto vom 2022-01-22 20-37-23.png
Bildschirmfoto vom 2022-01-22 20-37-23.png (27.8 KiB) Viewed 2044 times
In the three step architecture above adaptive and pocket could both use the same converter to create a face from an open wire and then create different G-code.

Operations could use different "information converters" without the code becoming a mess: For the keyhole operation (I don't want to beat this example to death and I am aware that other operators would benefit more) there might be a case where you select a circle and provide a direction and one where you select the start and the end point. For the pocket operation one could provide a face or an open wire, etc. Depending on the provided information and/or user input the operation could call a different information converter.

What do you think?

PS: Sorry for being slow in responding. We have cut down three large trees in our garden and my wife has only limited understanding for me sitting at the desk while she is chopping firewood. :)
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

WayofWood wrote: Sat Jan 22, 2022 7:50 pm
If I understand you right the generator should have the simple motion with an ideal set of information so that in the key hole example the start point and the the end point are know. The GUI would then implement a method that would help to select the start and the end point (e.g. by selecting the center of the circle or by selecting the starting point).
The GUI is going to interact with the user for getting selection, updating controls etc. That's just the visual stuff. The heavy lifting is done by the operation.
Would it maybe even make sense to separate the logic in three steps?
  • GUI select points
  • Information converter (backend stage 1) - convert bad into usable information
  • Generator (backend stage 2) - create G-code from perfect information
What you're thinking of as the backend stage 2 is the operation. It isn't really 'bad' information. It's just raw. There are only so many thing that the user can select and something has to convert that selection into usable geometry that reflects the user's intent.
The code for the information conversion becomes scriptable:
Scriptability is absolutely the goal. We want as much of Path to reusable to macros and also external scripts as possible. But we're working in 'baby steps'. Reusing complex logic is really tough if the functions aren't thoroughly tested to validate all the assumptions. So the first step is the generators.
Keyhole isn't a great candidate for reuse, but think of something like helix: Now that the helix generator is done and tested, a helix toolpath can be generated by the helix operation for clearing circular holes. BUT it can ALSO be used for creating a helical entry path into a pocket which is a feature we don't have now. And it could replace the helical entry into an adaptive pocket which is duplicate code.
The "information converters" become reusable: At the moment pocket and adaptive behave differently when selecting an open notch (see image below). While adaptive is cleaning the area if one selects three wires from the bottom pocket requires a face to operate.
Maybe. You're starting to touch on something that I think about differently. Probably too much to go into here. It's a conversation Russ and I have had at length related to 'Target Shapes'

My plan is to get all of the abstract Path generation stuff abstracted out to generators. That should simplify some of the operations to a trivial point. Others still have a lot of complexity. The next step will be to take some of the complexity out to make reusable components that take a users's selection and calculate target shape that feed into an operation.

To return to the keyhole generator, I have a question:

Do the keyhole cutters have a cutting edge on the top of the wide part? What I mean is that they can cut on the plunge and they can cut laterally. Can they also cut while being raised? Or does the cutter assume it's being retracted out of an existing hole? Are all cutters the same or do they vary in this regard?
User avatar
WayofWood
Posts: 62
Joined: Mon Nov 26, 2018 4:59 pm

Re: Adding scripts to a job?

Post by WayofWood »

sliptonic wrote: Sat Jan 22, 2022 9:13 pmDo the keyhole cutters have a cutting edge on the top of the wide part?
No. Only on the bottom; so they can't cut themself free.
sliptonic wrote: Sat Jan 22, 2022 9:13 pmScriptability is absolutely the goal. We want as much of Path to reusable to macros and also external scripts as possible. But we're working in 'baby steps'. Reusing complex logic is really tough if the functions aren't thoroughly tested to validate all the assumptions. So the first step is the generators.
Keyhole isn't a great candidate for reuse, but think of something like helix: Now that the helix generator is done and tested, a helix toolpath can be generated by the helix operation for clearing circular holes. BUT it can ALSO be used for creating a helical entry path into a pocket which is a feature we don't have now. And it could replace the helical entry into an adaptive pocket which is duplicate code.
But this is also a good example on the vale the additional step would provide: The helix generator would create a helix-shaped path at a certain location for a hole or a certain diameter.

However before the generator is able to run this task the GUI is performing certain actions: If a face that contains holes is selected, the user most likely want the holes and not the face to be cut. If an edge is selected that is the wire of the face of the bottom of a hole this could be use as well as the respective face.

Even with the generator this piece of code would be fully redundant between the drilling and the helix operation.

Personally I do think that there is potential for reusable improvements in the selection step and if there is anyhow a refactoring of the operations planned, an additional step would create more flexibility going forward.
Maybe. You're starting to touch on something that I think about differently. Probably too much to go into here. It's a conversation Russ and I have had at length related to 'Target Shapes'
Could you link to a thread with that discussion?
My plan is to get all of the abstract Path generation stuff abstracted out to generators. That should simplify some of the operations to a trivial point. Others still have a lot of complexity. The next step will be to take some of the complexity out to make reusable components that take a users's selection and calculate target shape that feed into an operation.
And I fully agree with you. I would only take it one step further and separate logic and gui from what you currently would have in the GUI part.
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

WayofWood wrote: Sat Jan 22, 2022 9:55 pm
sliptonic wrote: Sat Jan 22, 2022 9:13 pmDo the keyhole cutters have a cutting edge on the top of the wide part?
No. Only on the bottom; so they can't cut themself free.
Ok. This is a good test. The keyhole generator should check if any part of it's cutting direction is +z if so, it should raise an exception. The test suite should test this specifically Especially if you want to feed the generator a wire instead of start and end points.
But this is also a good example on the vale the additional step would provide: The helix generator would create a helix-shaped path at a certain location for a hole or a certain diameter.

However before the generator is able to run this task the GUI is performing certain actions: If a face that contains holes is selected, the user most likely want the holes and not the face to be cut. If an edge is selected that is the wire of the face of the bottom of a hole this could be use as well as the respective face.
Yes. All of this is upstream from the generators. Some of it belongs in the gui, most in the operations.
Maybe. You're starting to touch on something that I think about differently. Probably too much to go into here. It's a conversation Russ and I have had at length related to 'Target Shapes'
Could you link to a thread with that discussion?
Not really. Multiple conversations over Zoom and in the gitter chat room. If you want to dig in deeper, catch me on gitter or we can set up a time to talk and save our typing fingers for the code.
My plan is to get all of the abstract Path generation stuff abstracted out to generators. That should simplify some of the operations to a trivial point. Others still have a lot of complexity. The next step will be to take some of the complexity out to make reusable components that take a users's selection and calculate target shape that feed into an operation.
And I fully agree with you. I would only take it one step further and separate logic and gui from what you currently would have in the GUI part.
We've done pretty good at separating the GUI and operation logic. Mlampert did a good job of refactoring us that way a while back.
Take a look at PathHelix.py and PathHelixGui.py for an example. The GUI is really doing nothing more than registering the command and taking care of the form controls.
User avatar
onekk
Veteran
Posts: 6146
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Adding scripts to a job?

Post by onekk »

OT or to be more clear "general discussion".

Final goal would be scriptability.

So in future we should have a Pocket operations, with an external generator, so maybe one could some some different strategies like spiral pocketing and so on, and the Gui part is simply calling an appropriate generator to obtain "Path informations" i.e. "final gcode to put in the operation, like in the generators under "Generators" directory?

Same things could be done as example for an operation like "Tab or Tags" or "Dogbone", as a feature of "Profile" generator?

Regards

Carlo D..
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
WayofWood
Posts: 62
Joined: Mon Nov 26, 2018 4:59 pm

Re: Adding scripts to a job?

Post by WayofWood »

Identifying the start and the end point is surprisingly simple by selecting the arc at the bottom of a properly modeled keyhole:

Code: Select all

import FreeCAD
from PathScripts.PathUtils import loopdetect

doc = FreeCAD.ActiveDocument
obj = doc.getObject("Pocket001")
elt = doc.getObject("Pocket001").Shape.Edge13

startPoint = elt.Curve.Center
endPoint = FreeCAD.Base.Vector(startPoint.x, startPoint.y, startPoint.z)
for wire in obj.Shape.Wires:
	for e in wire.Edges:
		if (e.Curve.TypeId == 'Part::GeomCircle' and loopdetect(obj, elt, e) and e.Curve.Center.z == elt.Curve.Center.z):
			endPoint = e.Curve.Center
			
print (startPoint)
print (endPoint)
I will now try to somehow stitch an operator and a generic keyhole generator together.
Attachments
test-keyhole.FCStd
(41.42 KiB) Downloaded 21 times
User avatar
WayofWood
Posts: 62
Joined: Mon Nov 26, 2018 4:59 pm

Re: Adding scripts to a job?

Post by WayofWood »

I have to admit that I don't yet fully understand the structure of the code.

Path[Operation]Gui - Pretty clear to load the Gui panel and manage the Gui. If we follow the simple logic in the last post the user only has to select the arcs, select the toolbit and the coolant.

The call of the Generator should be based on the Path[Operation].py file. All the examples that I found are either quite complex like drilling as they use the code to identify the circular holes or they do not use a generator.

If I take drilling as an example there is an ObjectDrilling class defined that is then called from the Creation function.

Would I need to create a "PathKeyholeBase" class to identify the features or could I integrate this directly into the Operation?
Attachments
TestPathKeyHoleGenerator.py
(4.09 KiB) Downloaded 23 times
keyhole_generator.py
(2.57 KiB) Downloaded 22 times
tslot.FCStd
(13.55 KiB) Downloaded 15 times
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

WayofWood wrote: Mon Jan 24, 2022 9:03 am I will now try to somehow stitch an operator and a generic keyhole generator together.
I've becoming a major believer in test-driven development (TDD). Write the tests first. See it fail. Then write the code to pass the tests. If you don't work this way, then the tests are an afterthought. They never get completed. The real problem, however, is that the only validation of your logic is your own implementation and that is biased.

With TDD, you have two perspectives on the code. The test and the implementation. And the tests are useful for detecting regression bugs.

I'm serious when I say you can go faster if you work this way. Write JUST the generator and the tests for the generator. Make a PR for that. Let us ask questions and challenge your assumptions. Only when the generator is merged, turn your attention to the operation that uses it.
onekk wrote: Sun Jan 23, 2022 11:55 am Final goal would be scriptability.
No. Scriptability is not THE goal. It is a goal. So is maintainable code, speed, test coverage, documentation, translatability, and probably some more that I haven't thought of.
So in future we should have a Pocket operations, with an external generator, so maybe one could some some different strategies like spiral pocketing and so on, and the Gui part is simply calling an appropriate generator to obtain "Path informations" i.e. "final gcode to put in the operation, like in the generators under "Generators" directory?
The GUI should never call the generator. It should have no knowledge that generators exist. That is coupling at a level we do not want. The implementation of generator logic should be done at the operation level.

Likewise the GUI should never handle Path commands/Gcode. The GUI handles user interaction. Controls, clicks, drags, etc.
User avatar
onekk
Veteran
Posts: 6146
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Adding scripts to a job?

Post by onekk »

sliptonic wrote: Mon Jan 24, 2022 5:05 pm
No. Scriptability is not THE goal. It is a goal. So is maintainable code, speed, test coverage, documentation, translatability, and probably some more that I haven't thought of.
Yes sorry, I'm biased on scriptabilty, but at the very end an automated test is a script.

sliptonic wrote: Mon Jan 24, 2022 5:05 pm
So in future we should have a Pocket operations, ...
The GUI should never call the generator. It should have no knowledge that generators exist. That is coupling at a level we do not want. The implementation of generator logic should be done at the operation level.

Likewise the GUI should never handle Path commands/Gcode. The GUI handles user interaction. Controls, clicks, drags, etc.
OK, better explanation:

The GUI will never generate directly GCode commands, it will simply pass the generator some data and pass to the Operation the GCode.

Some place for GCode generation will be left, but I could think of a pocket on which you could choose different strategies, like "spiral pocket", "plain pocket" "helical pockets" and so on and the GUI will call the appropriate generator and retrieve the Gcode to be put on Operation.

Or I'm missing something?

I've not studied in deep the new operation I have downloaded:

Code: Select all

__title__ = "Helix Path Generator"
To study it but I have only gave a quick read at the code on it.

Thanks and Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
Post Reply