thread milling?

Here's the place for discussion related to CAM/CNC and the development of the Path module.
mlampert
Posts: 1633
Joined: Fri Sep 16, 2016 9:28 pm

Re: thread milling?

Post by mlampert »

chrisb wrote: Sun Feb 07, 2021 7:12 am
mlampert wrote: Sun Feb 07, 2021 2:53 am 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
Posts: 37799
Joined: Tue Mar 17, 2015 9:14 am

Re: thread milling?

Post by chrisb »

Got it!
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
GeneFC
Posts: 2834
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: thread milling?

Post by GeneFC »

mlampert wrote: Sun Feb 07, 2021 7:56 am 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
Posts: 37799
Joined: Tue Mar 17, 2015 9:14 am

Re: thread milling?

Post by chrisb »

I don't have a strong opinion and would safely let sliptonic and mlampert decide.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
freman
Posts: 1594
Joined: Tue Nov 27, 2018 10:30 pm

Re: thread milling?

Post by freman »

mlampert wrote: Sun Feb 07, 2021 1:06 am 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.
User avatar
sliptonic
Posts: 2447
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: thread milling?

Post by sliptonic »

GeneFC wrote: Sun Feb 07, 2021 12:26 am
chrisb wrote: Sat Feb 06, 2021 4:44 pm You have to enable Path experimental to get it in the regular menu.
That hurdle has probably outlived its usefulness. :roll:

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.
User avatar
freman
Posts: 1594
Joined: Tue Nov 27, 2018 10:30 pm

Re: thread milling?

Post by 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
Posts: 96
Joined: Sat Nov 14, 2020 9:16 pm
Location: Bargara, Queensland, Australia UTC+10

Re: thread milling?

Post by 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'
Attachments
ThreadPathMacro.py
(22.16 KiB) Downloaded 13 times
ThreadMacroPath.FCStd
(44.13 KiB) Downloaded 32 times
Last edited by bmsaus4ax on Sun Sep 19, 2021 10:12 am, edited 2 times in total.
User avatar
freman
Posts: 1594
Joined: Tue Nov 27, 2018 10:30 pm

Re: thread milling?

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

Re: thread milling?

Post by sliptonic »

bmsaus4ax wrote: Sat Jul 10, 2021 11:30 am 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.
Post Reply