Improvements to Tool Handling (and other fixes) #628

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!
Linden
Posts: 109
Joined: Wed Aug 19, 2015 10:35 pm
Location: Canada/Philippines

Re: Improvements to Tool Handling (and other fixes) #628

Post by Linden »

sliptonic wrote: I've definitely been thinking about this and looking at svgnest. It's MIT license so compatible with FreeCAD but I was unaware of the python port. Thanks for that.
I m glad i have been a little use its always good when we dont have to re invent the hole wheel.
I had a look at TSP equations there are lots out there and lots to read. I think the nesting solution would be easer to implement as we have something to work from. The math in both these areas gets over my head pretty quickly. Hopefully I will find some time to bash around with python a little and see if i can get any where. I would be happy if i could get a blank selection box to open inside free cad at this stage. lol

Keep up the good work and I will keep trying to brake things and let you know what i find.

linden
Linden
dlhenke
Posts: 35
Joined: Fri Mar 24, 2017 1:47 pm

Re: Improvements to Tool Handling (and other fixes) #628

Post by dlhenke »

I have the same issue on OS X Sierra and Elementary linux 64bits..
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Improvements to Tool Handling (and other fixes) #628

Post by sliptonic »

I suggest you start a new thread for experiments with shape nesting. That way you can document what you find and others can jump in and help too. It'll get lost in this thread, I'm afraid.
dlhenke
Posts: 35
Joined: Fri Mar 24, 2017 1:47 pm

Re: Improvements to Tool Handling (and other fixes) #628

Post by dlhenke »

I solved in my source..

in Freecad Dir /src/Mod/Path/PathScripts/linuxcnc_post.py
go to line 137
and add this

if pathobj.MachineUnits == "Metric":
UNITS = "G21"
UNIT_FORMAT = 'mm/s'
else:
UNITS = "G20"
UNIT_FORMAT = 'in/min'

thats it..
working now.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Improvements to Tool Handling (and other fixes) #628

Post by GeneFC »

I have been testing the improvements, and they appear to work correctly. They definitely clean up a couple of quirks in the tool handling.

I have discovered one "improvement" that creates a bit of difficulty for me. In particular, the post processor operation appears to always process the entire job with all of its path operations instead of processing only the selected path operation(s). Is this intentional?

I usually have a number of different operations in a single job, including profiles, pockets, and drilling. I do not have an automatic tool changer, so I always create separate g-code files for each operation. It appears this is no longer supported.

Included in the updated PathPost.py are the comments

# Attempt to figure out what the user wants to post-process
# If a job is selected, post that.
# If there's only one job in a document, post it.
# If a user has selected a subobject of a job, post the job.
# If multiple jobs and can't guess, ask them.

I would like to select only the subobject, not the entire job.

I can do it my way by several means, of course, but it would be nice if the selection of operations to be post-processed could be specified as it has been in the past.

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10634 (Git)
Build type: Release
Branch: master
Hash: abe15bbd83671b24f9fadc7a064d8baf5aa52ff3
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0


Gene
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Improvements to Tool Handling (and other fixes) #628

Post by sliptonic »

GeneFC wrote:I have been testing the improvements, and they appear to work correctly. They definitely clean up a couple of quirks in the tool handling.

I have discovered one "improvement" that creates a bit of difficulty for me. In particular, the post processor operation appears to always process the entire job with all of its path operations instead of processing only the selected path operation(s). Is this intentional?
It is intentional, but that doesn't mean it's right :-)

The job has become more complex and contains a lot of the context that operations are executing with. When you post-process a single operation, you probably don't really want to post the operation in isolation. It's more like you want to post process the job as though it only contained the one operation, and the proper tool. You still want the output to be aware of the type of machine selected, the tool controller settings, etc. but you don't want the other operation paths.

I can see two ways to do this.

1) Allow user to select a sub-object. If a subobject is selected, we post-process the job but exclude all the children except the selected one.

2) Always post-process the job like now and expect the user to dis-able any operations not desired. This would be more intuitive if spacebar toggling both hid the operation and toggled the active status.

How should I handle the condition where the user has Ctrl+selected multiple children? Do I need to be aware of the order in which multiple children were selected?

This is a good workflow issue and a good solution will make the system more intuitive and flexible. Feedback wanted but please try to think about the things other users, including newbies, might try and the kinds of mistakes that might be made.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Improvements to Tool Handling (and other fixes) #628

Post by GeneFC »

Sliptonic,

Thanks for the detailed reply.

Yes, I certainly want the overall process to be universal for all (or at least most) users.

As I noted, I do not have any problem creating what I need. I often add supplemental structures or delete design features as needed to assist the path generation process. I simply make the changes, output the g-code, *don't* save the file, close, reopen, make more changes, output more g-code, etc. I can do the same for path selection.

I wanted to make sure I was seeing the new functionality correctly and that I was not overlooking some new feature that included an option for selecting the paths to be exported.

By far the most important items to me are overall capability and accuracy of the generated g-code. The ability to select specific paths for export would be useful, but by no means critical.

Gene
chrisb
Veteran
Posts: 53941
Joined: Tue Mar 17, 2015 9:14 am

Re: Improvements to Tool Handling (and other fixes) #628

Post by chrisb »

I haven't had time to test the new version yet, but from the description the GCode generation does now exactly what I always expected it to do. And I missed it in the past. For me that's what a job is all about: creation of a single GCode session. As the job is created first it is not naturally selected at the time of GCode creation while one of the sub-paths usually is. I frequently change properties of a path or a tool controller like changing a tool and then I had to select the job, create GCode, reselect the element from before. If I do it in this way it is a little bit annoying, if I forgot to select the job it annoys a bit more.

@GeneFC: From a systematic view I would recommend to create multiple jobs, but from a usibility view I can understand quite well, that you don't want to create as many jobs as you have tool changes.

What can we do about it?
  • As it is quite common, that a mill doesn't have a tool changer (I don't have one either) I am quite sure that your machine supports a manual tool change. That's what you should check first. Do you use linux_cnc? Anybody here who knows more about the tool change there?
  • We could have an additional function doing the desired creation of parts of a job. You could simply configure it to be in the menu or to be omitted. No configuration of different behaviour for the main create GCode button needed.
  • We could have a generic GCode element - which I would like to have anyway. I think we used to have it but with increased maturity of Path Workbench it seems to got lost because it wasn't needed anymore.
    Such an element would offer the user a possibility to enter arbitrary GCode either directly (making the job machine dependent) or symbolic (leaving it to the post_processor to handle it). With such an element you could move the mill to a save position and stop the machine for a tool change.

    Such an element could be of use here but in other places too, whenever the user needs something too special to justify a dedicated implementation in the workbench.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Improvements to Tool Handling (and other fixes) #628

Post by sliptonic »

chrisb wrote: We could have a generic GCode element - which I would like to have anyway. I think we used to have it but with increased maturity of Path Workbench it seems to got lost because it wasn't needed anymore.
Such an element would offer the user a possibility to enter arbitrary GCode either directly (making the job machine dependent) or symbolic (leaving it to the post_processor to handle it). With such an element you could move the mill to a save position and stop the machine for a tool change.

Such an element could be of use here but in other places too, whenever the user needs something too special to justify a dedicated implementation in the workbench.
It's still there. It's called a 'custom' and it's under the Path->Partial Commands menu. FWIW, I think that menu needs to be renamed.

This would also be a good case to customize your tool change. Right around line 88 in linuxcnc_post.py is a TOOL_CHANGE = '''''' Just insert custom gcode to be executed on tool change into that quote string.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Improvements to Tool Handling (and other fixes) #628

Post by GeneFC »

chrisb wrote: @GeneFC: From a systematic view I would recommend to create multiple jobs, but from a usibility view I can understand quite well, that you don't want to create as many jobs as you have tool changes.
As I noted above, there are numerous ways to deal with this subject. So it is not really a big deal for me. I have even tweaked some of the python code to get what I needed. (I started programming in 1965, but I am not at all proficient in python or C++.)

As a further note, sometimes it makes sense to do all the operations on a workpiece sequentially, and sometimes it does not, especially with manual tool changing. As an example of the latter, it may be more time efficient and less error prone to use the same tool and same operation on multiple pieces before changing and rezeroing a manual tool to continue work on the original workpiece. Depends on whether the tool setup or the workpiece replacement is faster. The preference for combined or separated g-code files would depend on the machining strategy.

Flexibility in path creation would be useful, but it is not really essential.

Gene
Last edited by GeneFC on Mon Mar 27, 2017 2:16 am, edited 1 time in total.
Post Reply