Couple of potential bugs...

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
JoshM
Posts: 456
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Couple of potential bugs...

Post by JoshM »

I searched and didn't find this complaint from anyone else, so here goes:

When Editing a Path-Drilling-Object to Remove Base-Geometry elements, there doesn't appear to be any trap if I Remove the final item. If I do this, there appears to be no trap, and the list is repopulated with other elements--not the same elements, but my guess is the following elements in whatever list defines the Freecad 3D model... BTW, if I attempt the same on a 3DPocket's Base-Geometry elements, the final removal properly leaves a blank list... Helix operations suffer the same issue as Drill. Reset brings this result immediately...

Is there a reason that Base-Geometry field differs in format in Helix/Drill compared to other operations?

I noticed this because I've realized that in its current form, Freecad/Freecad-Path-WB while largely usable, has a few quirks. One that is particularly challenging is that a FC3D model that with a Path-Job built around it SHOULD theoretically allow modifications to the FC3D model--by definition of the stated functionality that FC aspires to provide. It does, but when new elements are added to the FC3D model, the element indices become corrupted, and thus the Path-Job becomes corrupted. This generates an ERROR flag on the operation, and often, by opening that operation's Base-Geometry and probing, I can figure out which elements are not those I had previously selected, remove them, and add back the proper elements. It appears that certain elements/operations are more susceptible to this--but I don't KNOW this, I've just observed it happen to the same elements a couple of times, where others seem less corruptible. In the example file I am attaching, the Pocket_3D-PourVent
operation, and the Drilling-MountingShoulderScrews operations are particularly susceptible...

On this and last posted versions, I can set the Height fields, but they immediately revert to default values, so at the moment, I have no control over these parameters...

Also, I've noticed that within the Path-Operations, changing values in fields always requires clicking into another field before the APPLY becomes an option to press.

I would note that the Pocket_3D-PourVent operation leaves an undesirable result because it splits the compound 3D cut into separate operations leaving material, where there should be none. Practically speaking, all machines have some backlash, and expecting cuts that do not overlap to remove all material is unrealistic--same reason why I don't Facemill with a 100% step-over, a setting allowed (defaulted to I believe) in FC-Path-WB, but disallowed (limited to 95% I believe) in other CAM packages I've used.

I've followed Brad's advise about configuring jobs for manual tool changes, which I really appreciate from the perspective of organizing the job. Because this is new to me, I'm not sure the typical approach, and I noticed that the FULL-STOP issues an M0 program stop which seems fine, but that I have to insert Custom-GCode to park and Stop the Spindle. I then can change my end-mill, invoke the Auto-Tool-Zero script from my Mach3 controller software, then hit Cycle-Start, and the program picks up flawlessly. From the FC-Path-WB/Job-Definition perspective, is there a better way to achieve this result than my current approach using custom Gcode? It's fine, but clutters my Job-Operations list... Is this a task that is generally implemented in the post-processor?

I also caught Brad's response about turning off operation-paths to inspect--Bravo, that's great! I am curious though if there is an intent to allow operations selection when generating GCode? As stands, selected or not, all operations are included--even if the job is deselected.

Finally, I'd a suggestion: there are cases where I define an operation, and it would benefit from some ability to overcut. If that operation is a Facemill, it's covered as stands. Take for example, the Pocket_3D-PourVent operation. I just need those cuts to extend further where, and if I change the Pass-Extension field to -5mm for example, it would be perfect--except where it cuts into my FC3D model. If, by contrast, that was a "smarter" field that provided those same path extensions, where no conflict would otherwise arise, it would provide significantly improved functionality...


All that said, I am able to use the existing product to make real things, and that's so awesome and rewarding!

Best Regards,
Josh


OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12373 (Git)
Build type: Release
Branch: master
Hash: 494a9a3f3b573edb887a000dbab831a49d7729db
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)
Attachments
FreeCad_Path_Example_Project_000.FCStd
(377.71 KiB) Downloaded 30 times
roivai
Posts: 117
Joined: Thu Feb 02, 2017 5:29 pm
Location: Oulu, Finland

Re: Couple of potential bugs...

Post by roivai »

JoshM wrote: Thu Oct 12, 2017 2:29 pm I searched and didn't find this complaint from anyone else, so here goes:

When Editing a Path-Drilling-Object to Remove Base-Geometry elements, there doesn't appear to be any trap if I Remove the final item. If I do this, there appears to be no trap, and the list is repopulated with other elements--not the same elements, but my guess is the following elements in whatever list defines the Freecad 3D model... BTW, if I attempt the same on a 3DPocket's Base-Geometry elements, the final removal properly leaves a blank list... Helix operations suffer the same issue as Drill.

Is there a reason that Base-Geometry field differs in format in Helix/Drill compared to other operations?
Yea, that is a feature, not a bug. ;) Seriously, this should be thought out better. What makes the Drilling/Helix different from others is that it has that automation to find drillable holes whereas other operations require the user always to select the shapes where the operation is applied. At the moment the circular hole tool (i.e Drilling/Helix) checks if there are anything in the list of holes and if not, it kind of assumes that the operation was just generated and runs the command to find all drillable holes from the base object. A few months ago this made perfect sense as there was no way to add holes manually. I added the methods to add custom features as drilling locations, but didn't notice that one could remove everything manually..

So what I suggest is that the automated search of the holes is removed from the opExecute and moved to a separate function which is then called when the operation is initially generated or the Reset button is pressed. Does that sound reasonable @mlampert, @sliptonic?
User avatar
JoshM
Posts: 456
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Couple of potential bugs...

Post by JoshM »

Thanks Roivai--appreciate the help!

The bug with Heights is KILLING me. Path is insisting on Z-heights, based on who knows what, and I just found out the hard way how poorly it chooses in some cases, and it messed up the cut... Luckily it was Delrin, so no harm other than lost work, but that's an important thing to clear up because it limits the utility of the Path-WB for real work.

In the attached file, the issue occurs on the 2nd drilling operation, performed with a 7/64" square-end mill. Following the tool change to that tool, the rapid travel is at 11mm, and my work is at 12mm, so...

EDIT: I see that if I make my Depths start at 12mm, the Heights moves up to 17mm for rapid travel, but if I begin my cut at 6mm--which is reasonable, given that I've milled a pocket to that depth--the Rapids mess up my work.

Regards,

Josh


OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12373 (Git)
Build type: Release
Branch: master
Hash: 494a9a3f3b573edb887a000dbab831a49d7729db
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)
Attachments
FreeCad_Path_Example_Project_001.FCStd
(383.6 KiB) Downloaded 31 times
mlampert
Veteran
Posts: 1772
Joined: Fri Sep 16, 2016 9:28 pm

Re: Couple of potential bugs...

Post by mlampert »

JoshM wrote: Thu Oct 12, 2017 2:29 pm... It does, but when new elements are added to the FC3D model, the element indices become corrupted, and thus the Path-Job becomes corrupted. This generates an ERROR flag on the operation, and often, by opening that operation's Base-Geometry and probing, I can figure out which elements are not those I had previously selected, remove them, and add back the proper elements. It appears that certain elements/operations are more susceptible to this--but I don't KNOW this, I've just observed it happen to the same elements a couple of times, where others seem less corruptible. In the example file I am attaching, the Pocket_3D-PourVent
operation, and the Drilling-MountingShoulderScrews operations are particularly susceptible...
This is a general FC issue, if you want you can search for "topological naming" and you'll find plenty of comments and discussions. It's not trivial to solve, I think there's work beeing done as we speak but currently it is what it is - unfortunately.
On this and last posted versions, I can set the Height fields, but they immediately revert to default values, so at the moment, I have no control over these parameters...
issue #3210 PR is imminent.
Also, I've noticed that within the Path-Operations, changing values in fields always requires clicking into another field before the APPLY becomes an option to press.
This is how the rest of the FC UI works - we could definitely deviate from that standard but the UX gurus say that's not much appreciated by customers .
I would note that the Pocket_3D-PourVent operation leaves an undesirable result because it splits the compound 3D cut into separate operations leaving material, where there should be none. Practically speaking, all machines have some backlash, and expecting cuts that do not overlap to remove all material is unrealistic--same reason why I don't Facemill with a 100% step-over, a setting allowed (defaulted to I believe) in FC-Path-WB, but disallowed (limited to 95% I believe) in other CAM packages I've used.
Not sure what "PourVent" means but these are some of the reasons we introduced Pocket_Shape.
I've followed Brad's advise about configuring jobs for manual tool changes, which I really appreciate from the perspective of organizing the job. Because this is new to me, I'm not sure the typical approach, and I noticed that the FULL-STOP issues an M0 program stop which seems fine, but that I have to insert Custom-GCode to park and Stop the Spindle. I then can change my end-mill, invoke the Auto-Tool-Zero script from my Mach3 controller software, then hit Cycle-Start, and the program picks up flawlessly. From the FC-Path-WB/Job-Definition perspective, is there a better way to achieve this result than my current approach using custom Gcode? It's fine, but clutters my Job-Operations list... Is this a task that is generally implemented in the post-processor?
yes - look for TOOL_CHANGE in your post processor and add your procedure there
I also caught Brad's response about turning off operation-paths to inspect--Bravo, that's great! I am curious though if there is an intent to allow operations selection when generating GCode? As stands, selected or not, all operations are included--even if the job is deselected.
Each operation has an "Active" flag - which probably does what you want. It's been the topic of discussion before if the functionality should be coupled with Visibility instead.
Finally, I'd a suggestion: there are cases where I define an operation, and it would benefit from some ability to overcut. If that operation is a Facemill, it's covered as stands. Take for example, the Pocket_3D-PourVent operation. I just need those cuts to extend further where, and if I change the Pass-Extension field to -5mm for example, it would be perfect--except where it cuts into my FC3D model. If, by contrast, that was a "smarter" field that provided those same path extensions, where no conflict would otherwise arise, it would provide significantly improved functionality...
If I understand you correctly you don't actually want to build g-code based on your model. What you're asking for is arbitrary modification of the removal shape - that is currently not supported.
mlampert
Veteran
Posts: 1772
Joined: Fri Sep 16, 2016 9:28 pm

Re: Couple of potential bugs...

Post by mlampert »

JoshM wrote: Thu Oct 12, 2017 6:00 pmPath is insisting on Z-heights, based on who knows what

Code: Select all

SafeHeight = StartDepth + 3mm
ClearanceHeight = StartDepth + 5mm
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Couple of potential bugs...

Post by GeneFC »

JoshM wrote: Thu Oct 12, 2017 6:00 pm The bug with Heights is KILLING me. Path is insisting on Z-heights, based on who knows what, and I just found out the hard way how poorly it chooses in some cases, and it messed up the cut... Luckily it was Delrin, so no harm other than lost work, but that's an important thing to clear up because it limits the utility of the Path-WB for real work.
Josh,

I NEVER use a gcode file from FreeCAD without first taking a look in a simulator (Camotics) or at least at the gcode itself. Ideally this should not be necessary, but there are almost daily changes occuring, so the behavior might not be exactly what it was previously.

This situation is not actually bad, since progress in the Path workbench is good. However, it means that the user needs to take extra care to ensure a usable result.

[edit]
One more thing: 3D Pocket has some odd behaviors with regard to depths. You might consider using the Path Pocket operation. It works pretty well except that it does not seem to allow selection of CCW vs CW (climb vs conventional).

Gene
User avatar
JoshM
Posts: 456
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Couple of potential bugs...

Post by JoshM »

Okay--just took another run at this and have some success!

I realized that on the previous pass because of the Helix operation, it dragged a 3/16" bit through my 12mm tall work at 11mm after finishing a Drill operation. Then, the 7/64" drill operation was also at 11mm rapid travel, again running right through the Delrin... I caught the latter issue looking at the it's Drill operation but couldn't figure out the first issue because that operations was correctly specified--so, there is the potential--among other potential issues--to ruin your job either due to the current Operation, or the Subsequent operation...

My work around is to specify my Start of Drilling/Helixing, 6mm above the work, at 12mm, so that it specified 15mm Safe-Height, and 17mm Clearance Height, and my work isn't ruined. It's a relatively small price to pay, and likely is a short term issue, but let's be clear, the existing algorithm causes harm.

Frankly, the specifying Heights per Operation leaves lots of room for trouble, and I don't see much upside. It's a far safer option to specify a Rapid Height for the JOB, given ALL bits will have to clear obstacles... I get that you may gain a bit of efficiency if you are cutting away material, then specifying further clearances based on the machined surface, but it's pretty darn risky....

Gene, thanks, and agreed I have GWizard's simulator, and what I've realized is that the key is to run the simulation, look at the 3D view from the side, a Front or Side view--not Perspective View--and make sure no horizontal RED LINES exist below the Green lines. The vertical red lines showing Drill/Helix returns are the only acceptable red lines below the Green...

@mlampert, thanks on your detailed response! I'm fine with the FC standard of needing to click before Apply--it's an odd choice but it's done, and it's not flukey, so I'm over it...

I get that the element index issue is a larger FC issue. It seems much better than back at v0.12-v0.15 at least. My take away at this point is that FC-Path-WB is usable, with a bit of care, and at least for the moment, the key is having a game plan up front, so that you avoid that issue.

"PourVent" was a name I gave an Operation. I try to use meaningful names to help keep things organized, and I'm working on a mold for pouring a urethane casting using Delrin for the mold. That operation is intended to carve out a 3D pocket to allow me to inject plastic, and to let air out--thus, "Pour Vent"--sorry for the confusion it caused you though :D

Thanks for clarifying that the post-processor is where I need to put that--I'm new to this, and beginning to figure out the larger context...

I think we almost understand each other on what I was driving at when I suggested a "smarter" Pass-Extension... I'm attaching screenshots, showing without Pass Extension and with a -2mm Pass Extension. If the -2mm Pass Extension looks as shown, except where it cuts into the model. I get that you're suggesting that I'm asking for a deviation from the model--but, that's what Pass Extension is--as depicted in a 3rd attachment, for the Facemill operation... My only suggestion is that Pass Extension is a WONDERFUL thing to have, the key to making it really helpful is to change the algorithm such that Pass Extension is allowed except where is would violate the model. It's actually NOT "arbitrary modification of the removal shape" in the sense that what I'm asking for will give me what is asked for in the model, whereas what I get now deviates from the model due to the realities of the world.

Practically speaking, I two pockets specified in FC that touch, will always leave residue because the bit just barely cuts the line where the two pockets are adjacent. As I suggested earlier, this is why you specify a step-over for Facemilling, Pocketing, etc... In this case, I'm looking at how I can guide my machine to provide a clean result, which is after all, the goal, no? Path does have exceptions--Ramps, Dogbone dressup, etc... This falls in the same category to my thinking.

In any case, there's WAY MORE good than bad here, as evidenced by the Results I'm posting! I do apologize if anything I suggest comes across as demanding--that's not my goal. I'm just trying to advocate for the development to allow for a very capable tool-suite. By my estimation, as is, you're somewhere between 90 and 98% there, which is pretty amazing for open source development. Let me be clearer actually: Thanks for the hard work that has gotten things where they are, it's really cool stuff!

Best Regards,
Josh
Attachments
IMG_2849.JPG
IMG_2849.JPG (70.15 KiB) Viewed 1993 times
Pass_Extension.jpg
Pass_Extension.jpg (336.07 KiB) Viewed 1993 times
3DPocket_PassExtension.jpg
3DPocket_PassExtension.jpg (271.83 KiB) Viewed 1993 times
3DPocket.jpg
3DPocket.jpg (264.83 KiB) Viewed 1993 times
GWizardSimulator.jpg
GWizardSimulator.jpg (314.79 KiB) Viewed 1993 times
mlampert
Veteran
Posts: 1772
Joined: Fri Sep 16, 2016 9:28 pm

Re: Couple of potential bugs...

Post by mlampert »

JoshM wrote: Thu Oct 12, 2017 8:37 pm My work around is to specify my Start of Drilling/Helixing, 6mm above the work, at 12mm, so that it specified 15mm Safe-Height, and 17mm Clearance Height, and my work isn't ruined. It's a relatively small price to pay, and likely is a short term issue, but let's be clear, the existing algorithm causes harm.

Frankly, the specifying Heights per Operation leaves lots of room for trouble, and I don't see much upside. It's a far safer option to specify a Rapid Height for the JOB, given ALL bits will have to clear obstacles... I get that you may gain a bit of efficiency if you are cutting away material, then specifying further clearances based on the machined surface, but it's pretty darn risky....
... and yet you set StartDepth to 6mm because that's all it needed ;)

Seriously though - I agree with your point and making Safe/ClearanceHeight a Job global setting is what the change in progress does - you can still overwrite it for each individual op though - no need to panic, we got you covered :mrgreen:
User avatar
JoshM
Posts: 456
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Couple of potential bugs...

Post by JoshM »

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

Re: Couple of potential bugs...

Post by sliptonic »

roivai wrote: Thu Oct 12, 2017 3:22 pm
So what I suggest is that the automated search of the holes is removed from the opExecute and moved to a separate function which is then called when the operation is initially generated or the Reset button is pressed. Does that sound reasonable @mlampert, @sliptonic?
Sounds reasonable to me.
Post Reply