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!
User avatar
sliptonic
Veteran
Posts: 3453
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

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.
Attachments
TestPathKeyholeGenerator.py
(3.95 KiB) Downloaded 27 times
User avatar
WayofWood
Posts: 62
Joined: Mon Nov 26, 2018 4:59 pm

Re: Adding scripts to a job?

Post by WayofWood »

sliptonic wrote: Tue Jan 18, 2022 8:36 pm Start with step one. I'll help as needed.
Thanks a lot for the explanation. Let me dig into this over the weekend!
chrisb
Veteran
Posts: 53785
Joined: Tue Mar 17, 2015 9:14 am

Re: Adding scripts to a job?

Post by chrisb »

sliptonic wrote: Wed Jan 19, 2022 5:22 pm In the real world, programmers do 'pair programming' where one person writes the unit test and someone else writes the code.
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.
User avatar
onekk
Veteran
Posts: 6094
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Adding scripts to a job?

Post by onekk »

sliptonic wrote: Wed Jan 19, 2022 5:07 pm ...
Take a look at the drill_generator (already merged) or the helix_generator (pr pending)

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/
User avatar
WayofWood
Posts: 62
Joined: Mon Nov 26, 2018 4:59 pm

Re: Adding scripts to a job?

Post by WayofWood »

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?
Attachments
TestPathKeyHoleGenerator.py
(4.14 KiB) Downloaded 22 times
keyhole_generator.py
(3.24 KiB) Downloaded 19 times
tslot.FCStd
(13.34 KiB) Downloaded 19 times
User avatar
sliptonic
Veteran
Posts: 3453
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

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
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?

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.
PS: Is it intended that the toolbitfiles have a lowercase file extension and are this way not visible in the file open dialogue?
I'm not sure why they ended up with a lowercase extension. I would prefer they be FreeCAD standard.
Your toolbit model looks good. Only change I suggest is moving the tslot diameter and height attributes into the shape group.
2022-01-20_08-27.png
2022-01-20_08-27.png (49.37 KiB) Viewed 1784 times
User avatar
sliptonic
Veteran
Posts: 3453
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

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.
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 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?
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.
User avatar
sliptonic
Veteran
Posts: 3453
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

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.
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:
  • 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
As a result, the operations are almost entirely untested and untestable and as soon as we want to add new features, we have a mess. The ops need to be refactored to separate these things into functional blocks that can be tested and reused. Generators are the first step in that direction. They abstract out the low-level path generation.

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.
User avatar
sliptonic
Veteran
Posts: 3453
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Adding scripts to a job?

Post by sliptonic »

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?
Post Reply