Adding scripts to a job?

[sliptonic]

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?

You're missing something. The GUI will never talk to the generator. It won't import a generator or have any knowledge that such a thing exists. The GUI will primarily interact with the operation class. It can query the operation to get the values for enumerations (comboboxes). It gets current operation property values and sets the UI controls to match. When the UI control contents change, it updates the operation and sets property values. If the operation is long-running like adaptive, it might have a button to tell the operation to terminate current recalculation. That's about it.

Sidebar: The GUI is also involved in configuring the target geometry that the operation will work on. That is a larger topic that I don't want to get into yet. Suffice to say that the GUI's role in that job will be minimal and the work of interpreting the user selection and building intermediate geometry will be handled outside the GUI.

In your example, The Gui would display a combobox with values like 'spiral pocket', 'zigzag' etc. The GUI knows nothing about these, just that they're values to show in a combobox. When the user selects one, the gui tells the operation, that the value of 'pattern' is now 'zigzag'. That's all the guI does.
The operation does the rest.

[onekk]

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.

OK guess the point, or better seen my error:

Sorry for bothering:

"GUI code" will pass data to "Operation code" that choose the strategy and invoke the appropriate "Generator" passing appropriate parameters obtaining in return "Pseudo GCode" to store somewhere in the "document object", at "final Gcode" creation step, "Pseudo Gcode" is translated using the "post processor" to "machine Gcode".

Is this resembling much closely the work done?

Regards

Carlo D.

[sliptonic]

"GUI code" will pass data to "Operation code" that choose the strategy and invoke the appropriate "Generator" passing appropriate parameters obtaining in return "Pseudo GCode" to store somewhere in the "document object", at "final Gcode" creation step, "Pseudo Gcode" is translated using the "post processor" to "machine Gcode".

Is this resembling much closely the work done?

Yes. The operation can call more than one generator, but essentially, that is correct.

[WayofWood]

I found some more time over the weekend to try my hands on the code with limited success and would appreciate help with a few questions. I am really not a developer and therefore might run into issues that sound almost trivial to others.

Development setup

Before jumping into some question about the code: Is there any good documentation about the most efficient setup on how to write some code for FreeCAD? Let me share how I am approaching a few of the practical aspects right now and I hope someone could point me to a better way.

• Testing: In order to get FreeCAD to run the test cases for the generator (see my last post) I have added the test case to the TestPathApp test set and then run

  Code: Select all

  freecad -c -t TestPathApp

  as outlined here. I am sure that there is a more efficient way to run an individual test case
• IDE: I more or less randomly picked Eric. At the moment it's main help is syntax highlighting but I was wondering if there is a better setup that would in particular help with code completion and debugging.
• Debugging / Running code: In order to test some code I run FreeCAD and then use the python console. Most likely there is leaner way ...

Apologies for asking trivial questions - also happy to get a pointer to a place to read more by myself on these topics.

Now a few more questions to the Path Source code and a short update on where I stand right now:

• PathKeyholeGui.py: The GUI part seems very straight forward to me and I basically stripped down the Drilling GUI class and the respective panel. Again I am struggling with an embarrassingly simple problem: How would I call the GUI so that I can see at least some error messages?
• PathKeyhole.py: In the current FreeCAD master the drilling operation does not yet utilize the generator. I looked at the code sliptonics repo and understand how the generator is being called. What confuses me is the use of the use of PathCircularHoleBase - which makes for course sense for drilling but would not be necessary for a keyhole operation. If I just want to call the generator for every Base feature selected: Can I directly build the command in the Create function with the selection being in obj.Base or would it be necessary to create a PathKeyHoleBase class for some reason?

Thanks a lot for you help in advance!

[sliptonic]

I found some more time over the weekend to try my hands on the code with limited success and would appreciate help with a few questions. I am really not a developer and therefore might run into issues that sound almost trivial to others.

Great! Here to help, if I can so don't be afraid to ask.

Development setup

Before jumping into some question about the code: Is there any good documentation about the most efficient setup on how to write some code for FreeCAD?

Not really. There are a few tricks that make things a lot easier though.

1) Switch to the Path workbench. Select an object in the tree, then right-click and 'send to Python console'. This will give you a reference to the object so you can inspect its properties. Same thing if you select in the 3D window but you'll get a reference to the document object (obj), shape (shp), and subelement (elt).

2) If you're doing anything in the python console and importing your own module:

Code: Select all

import mymodule as m
from importlib import reload
reload(m)

This way you can edit your module, reload it, and try again without having to restart FreeCAD.

Let me share how I am approaching a few of the practical aspects right now and I hope someone could point me to a better way.

• Testing: In order to get FreeCAD to run the test cases for the generator (see my last post) I have added the test case to the TestPathApp test set and then run

  Code: Select all

  freecad -c -t TestPathApp

  as outlined here. I am sure that there is a more efficient way to run an individual test case

I made a file next to TestPathApp called TestLittle. It has just the tests I'm interested in. Then

Code: Select all

FreeCADCmd -t TestLittle

[*] IDE: I more or less randomly picked Eric. At the moment it's main help is syntax highlighting but I was wondering if there is a better setup that would in particular help with code completion and debugging.
[*] Debugging / Running code: In order to test some code I run FreeCAD and then use the python console. Most likely there is leaner way ...
[/list]

I use an editor (NeoVim) and make a lot of use of PathLog for debugging. I don't use a regular debugger but would like to find a way to integrate one more easily. I'll often try out new ideas just in FreeCAD macros and figure out how to implement them in the regular logic later.

Now a few more questions to the Path Source code and a short update on where I stand right now:

• PathKeyholeGui.py: The GUI part seems very straight forward to me and I basically stripped down the Drilling GUI class and the respective panel.

Don't go too far with the GUI yet. I want to talk about this before implementation. I have some ideas that might change how you're doing it and I don't want you to waste your time. Also the GUI can be trickier than it seems. There are issues of translation to consider. Selection gates, document observers, etc. The GUI really needs more discussion and collaboration so that thinks are intuitive and seamless. The GUI code is quite complex with a bunch of class inheritance. New contributors often want to focus on the GUI because it's tangible but I'm suggesting you focus on the generator, get a PR going, then talk more.

Again I am struggling with an embarrassingly simple problem: How would I call the GUI so that I can see at least some error messages?

I don't understand where you're at yet. Showing a panel designed in QT designer? Populating the panel? triggering a recompute of the underlying operation? I think it's too early.

[*] PathKeyhole.py: In the current FreeCAD master the drilling operation does not yet utilize the generator.

Actually, it does. Are you sure you're up to date? https://github.com/FreeCAD/FreeCAD/blob ... ng.py#L234

I looked at the code sliptonics repo and understand how the generator is being called. What confuses me is the use of the use of PathCircularHoleBase - which makes for course sense for drilling but would not be necessary for a keyhole operation. If I just want to call the generator for every Base feature selected: Can I directly build the command in the Create function with the selection being in obj.Base or would it be necessary to create a PathKeyHoleBase class for some reason?
[/list]

Drilling is a bit different because both Drilling and Helix inherit from circularholebase. Likewise, pocket, profile, millface all inherit from PathAreaOp.
Keyhole will probably be more like vcarve in structure.

[WayofWood]

Great! Here to help, if I can so don't be afraid to ask.

Thanks a lot for the explanations. This is very helpful. I most likely will need a bit of time to work through the magic world of github and will try to submit a PR.

[WayofWood]

Sorry for the long radio silence; going through a rough time right now and limited time for hobbies.

I tried my best to create a PR with the generator and the test. Feedback welcome (and most likely necessary )!

[Kunda1]

PR issue #6464 needs review