thread milling?

[mlampert]

Today I think that some of those ops are used a lot and we can't move them out of experimental for 0.19, so this might be the lesser of two evils.

Regarding the argument: do you mean can or can't?

I don't think we can, introducing a dependency like OCL this late in the release cycle is a no-go in my book. The most important thing right now is to stabilize and ship 0.19 so it makes the Debian release.

[chrisb]

Got it!

[GeneFC]

I don't think we can, introducing a dependency like OCL this late in the release cycle is a no-go in my book. The most important thing right now is to stabilize and ship 0.19 so it makes the Debian release.

Interesting, I was actually thinking the opposite. Version 0.19 is about to be "cast in stone" for the next year or two. Do we want the "experimental" ops to remain hidden for that release?

Sliptonic has mentioned a number of times that he would like to see more testing of changes and new ops. Keeping some of the cutting edge stuff buried a bit may not help in this quest.

I am not arguing, just observing. Clearly we do not want to bake in a problem with dependencies such as OCL. At the same time we do not want to restrict things that no longer need to be restricted.

What to do????

Gene

[chrisb]

I don't have a strong opinion and would safely let sliptonic and mlampert decide.

[freman]

Most of those have a dependency on OCL which is currently not a requirement for FC. I get your point though, maybe we could add a checkbox with corresponding warning message to the preferences.

At what point does it become a dep of FC? Surely at some point this has to happen, isn't a new major release a good time?

Are there distros for which this is a problem?

Ah. Just about all of them !
https://repology.org/project/opencamlib/versions

Since that master source for OCL does not seem to have moved in a couple of years, isn't the best solution to fork it into FreeCAD and stop worrying about deps ?

It could always be synced up if it changes but it does not look that is going to introduce a lot of maintenance work

https://github.com/aewallin/opencamlib/issues/56

In practice I don't have much time to do maintenance work, and no time to do development work on opencamlib. It would be good if there is a volunteer maintainer who wants to take over.

[sliptonic]

You have to enable Path experimental to get it in the regular menu.

That hurdle has probably outlived its usefulness.

Gene

I don't really like the idea of just making it a preference flag. These aren't advanced features, they're experimental. We don't want users to think that these features will eventually become a real part of Path or that jobs that use them won't break or crash their machine.
If the distinction between experimental and mainline functionality has outlived its usefulness, than let's just put everything up front. The entire point is that it _should_ be difficult to get access to them because we want users taking responsibility for turning them on.

My opinion is put the dangerous stuff on a high shelf. Not everything needs to be easy.

[freman]

My opinion is put the dangerous stuff on a high shelf. Not everything needs to be easy.

Yep, keep the guns and narcotics away from the children ( especially Hunter) !

Oh, best hide the rotation feature too.

[bmsaus4ax]

I have a Macro to generate thread milling paths for Internal and External threads (attachments)
Went my own way with the code as I have used this method before (used to be in the Iscar catalogues/manuals long ago, before they made the online calculator based on their catalogue product numbers)
Could not get my head around the module interactions in the Experimental Feature Code to expand to include external.
My code needs a bit of a tidy up but is still an ongoing project.

My question at the stage is:
Is it possible to interact with the inbuilt ".ui" via a custom ".....Gui.py" file? Can't do local builds yet.
I can create a Task Panel type UI dialog to interact with the macro, but am wondering if more integration can be achieved locally. The Custom OP and the macro work fine but would like to learn more of the integration. Have had a bit of a play with an unpacked AppImage but no joy as yet.

EDITED: ORIGINAL "ThreadPathMacro.py" incorrectly named module i.e., second "ExtRHclimb()" should have been "ExtRHconventional()".
File replaced.
Update Edit: Corrections to X, Y, centre positioning : errors existed when position was not '0, 0'

[freman]

Interesting, I'll try to find time to look at this later.

I would really suggest you get set up for doing a full local build. Getting a clone of the source code tree and building is relatively simple. It just means pulling in the relative devel packages ( header files ) for your platform.

Use qt5 Designer for creating and editing .ui files for manipulating dialogues etc.

What sort of tool is this designed to use?

[sliptonic]

My question at the stage is:
Is it possible to interact with the inbuilt ".ui" via a custom ".....Gui.py" file? Can't do local builds yet.
I can create a Task Panel type UI dialog to interact with the macro, but am wondering if more integration can be achieved locally. The Custom OP and the macro work fine but would like to learn more of the integration. Have had a bit of a play with an unpacked AppImage but no joy as yet.

You want to use the existing threadmill .ui file but with your own macro code?
Yes, it's possible. The .ui file contains no logic of its own so you can just load it and get a reference and then do anything you want with it.

Simple example:

Code: Select all

form = FreeCADGui.PySideUic.loadUi(":/panels/PageOpThreadMillingEdit.ui")
form.show()

Look closer at the PathThreadMillingGui.py file for how the controls are set up and responded to.

That said, I agree with freman. Getting a local build set up isn't too difficult.