Adding scripts to a job?
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Adding scripts to a job?
In the real world, programmers do 'pair programming' where one person writes the unit test and someone else writes the code.
Here's a unit test for keyhole generator.
You should make the generator pass this test.
If you don't know how to set up and run the unit tests, let me know and I'll write a quick summary.
Here's a unit test for keyhole generator.
You should make the generator pass this test.
If you don't know how to set up and run the unit tests, let me know and I'll write a quick summary.
- Attachments
-
- TestPathKeyholeGenerator.py
- (3.95 KiB) Downloaded 27 times
Re: Adding scripts to a job?
I like the notion of "buddy checking" for this .
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Adding scripts to a job?
Thanks for explanation, I hope to be able to look at the code and maybe create something in the week end.
Many 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/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: Adding scripts to a job?
Find attached a first crack at the generator and the respective test file.
I deviated from sliptonic's logic of having a start point and an end point for two reasons:
(1) This would prevent us from defining multiple keyholes in one go. I would find it more convenient to select multiple holes and then give a direction and length rather than create 4 operations for 4 keyholes
(2) Personally I feel that the endpoint of a keyhole slot is a pain in the neck to select
This however also comes with a downside: As the script currently expects the face at the bottom of a hole to be selected and this approach would not work for an actually modeled keyhole where the bottom is a oval shape.
Feedback welcome.
PS: Is it intended that the toolbitfiles have a lowercase file extension and are this way not visible in the file open dialogue?
I deviated from sliptonic's logic of having a start point and an end point for two reasons:
(1) This would prevent us from defining multiple keyholes in one go. I would find it more convenient to select multiple holes and then give a direction and length rather than create 4 operations for 4 keyholes
(2) Personally I feel that the endpoint of a keyhole slot is a pain in the neck to select
This however also comes with a downside: As the script currently expects the face at the bottom of a hole to be selected and this approach would not work for an actually modeled keyhole where the bottom is a oval shape.
Feedback welcome.
PS: Is it intended that the toolbitfiles have a lowercase file extension and are this way not visible in the file open dialogue?
- Attachments
-
- TestPathKeyHoleGenerator.py
- (4.14 KiB) Downloaded 23 times
-
- keyhole_generator.py
- (3.24 KiB) Downloaded 22 times
-
- tslot.FCStd
- (13.34 KiB) Downloaded 19 times
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Adding scripts to a job?
The generator has nothing to do with the user selection. That's all going to be handled in the GUI and operation code.WayofWood wrote: ↑Thu Jan 20, 2022 10:27 am (1) This would prevent us from defining multiple keyholes in one go. I would find it more convenient to select multiple holes and then give a direction and length rather than create 4 operations for 4 keyholes
(2) Personally I feel that the endpoint of a keyhole slot is a pain in the neck to select
Looking at your example, you take the input face and immediately calculate a startPoint from its center of mass. Why not just take the startPoint and let the operation calculate the COM?
Same thing with the endPoint. You calculate it from the startPoint, direction, and length. If you push THAT logic upstream to the operation and just take the endPoint from the operation you gain two things:
First the generator is simpler. Second, the op could allow different ways of selecting, defining a keyhole. Maybe the user wants to fully model the keyhole and select various faces. Maybe we just let the user key in coordinates for SP and EP. Maybe we do ALL those things. Whatever we allow for input in the op, we resolve that to SP and EP to call the generator.
I'm not sure why they ended up with a lowercase extension. I would prefer they be FreeCAD standard.PS: Is it intended that the toolbitfiles have a lowercase file extension and are this way not visible in the file open dialogue?
Your toolbit model looks good. Only change I suggest is moving the tslot diameter and height attributes into the shape group.
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Adding scripts to a job?
There's another thing that I'm not crazy with in your first go:
In the example I sketched out, the implied assumption is that the cutter is AT the starting point before the generator acts. It does it's job but the cutter starts and ends at the same point and then something else can take over. It's first move is TOWARD the bottom of the face - the plunge move.
In your implementation, the assumption about the machine's starting condition is ambiguous and the first move is TO the given startpoint but you don't know if that's straight down, or straight sideways. It's ambiguous. Then the last move returns to the startPoint but doesn't retract out of the hole. That means the operation has to add the retraction move.
In the example I sketched out, the implied assumption is that the cutter is AT the starting point before the generator acts. It does it's job but the cutter starts and ends at the same point and then something else can take over. It's first move is TOWARD the bottom of the face - the plunge move.
In your implementation, the assumption about the machine's starting condition is ambiguous and the first move is TO the given startpoint but you don't know if that's straight down, or straight sideways. It's ambiguous. Then the last move returns to the startPoint but doesn't retract out of the hole. That means the operation has to add the retraction move.
Re: Adding scripts to a job?
Could you explain me the logical split between the operation and the generator? In my mind the split was "front end / back end" and with that logic I would have pushed as much logic into the generator to limit the operation to the selection of the entry points.sliptonic wrote: ↑Thu Jan 20, 2022 2:29 pm The generator has nothing to do with the user selection. That's all going to be handled in the GUI and operation code.
Looking at your example, you take the input face and immediately calculate a startPoint from its center of mass. Why not just take the startPoint and let the operation calculate the COM?
I get your point but don't fully understand the intended purpose of the split. I tried to better understand this from the code but it seems that most operators are not using a generator. Is this in order to reuse the generator outside the GUI in a different context?
On the file extensions: The lower case extensions have the effect (at least on my Linux machine) that they do not show up in the open file dialogue. To encourage users creating their own tools it might be worth to change the spelling to standard going forward.
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Adding scripts to a job?
Most of the operations don't use generators yet. And that's the problem. The current operation logic has poor separation of concerns so the operations end up:WayofWood wrote: ↑Thu Jan 20, 2022 3:39 pm Could you explain me the logical split between the operation and the generator? In my mind the split was "front end / back end" and with that logic I would have pushed as much logic into the generator to limit the operation to the selection of the entry points.
I get your point but don't fully understand the intended purpose of the split. I tried to better understand this from the code but it seems that most operators are not using a generator. Is this in order to reuse the generator outside the GUI in a different context?
On the file extensions: The lower case extensions have the effect (at least on my Linux machine) that they do not show up in the open file dialogue. To encourage users creating their own tools it might be worth to change the spelling to standard going forward.
- controlling user selection and storing it.
- validating selected geometry
- storing user option configuration
- Interpreting user selection to determine intermediate geometry
- Calculating tool paths from intermediate geometry
- Handling moves between targets
Drilling is a good example. Until recently, the drilling was just like the rest. It held a list of 'locations' where a hole should be placed. It also had properties for start and end depth. That meant that ALL holes in the op were drilled from the same start depth to the same end depth. Also, there's an implied assumption that the holes are aligned with the Z axis so drilling on a 5 axis machine doesn't work.
The helix operation is almost exactly the same as drilling. It works on the same kinds of targets, has the same concern with orientation. Has the same problem with depths, etc. The only difference is the kind of gcode that is generated.
Now the drilling logic has been removed to a generator that works on just one hole. It takes simple input geometry and outputs gcode for just that hole. The operation still just stores a list of locations so there's no new functionality yet, but as the operation gets smarter about selection, the generator should stay unchanged. A different generator will handle any moves necessary to rotate a part to the correct orientation for drilling.
Using generators, most of the gui and logic for helix and drilling will be shared and much simpler. The differences will be the real differences. The GUI will just present and validate user input for the various properties. The operation will iterate through the targets and call whatever generators are needed. If a target isn't correctly aligned, it will call a rotation generator to align the target, then calls the proper drilling/helix generator.
The operations get simpler and the pieces get testable. Instead of coding complexity, we build up complexity from simple parts.
At least, that's the idea.
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Adding scripts to a job?
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?