CNC Lathe and 4th-axis milling...

[Russ4262]

I don't know if it needs to be a separate operation. Maybe. But I'm o.k. with removing it from active use at this time. Awallin stated somewhere that the waterline algo in OCL needs serious work so I don't think we can make it useful from our side.

Sounds good, Sir. Either way. I suppose the waterline option is in no way interfering or taking up extra screen real estate. Keeping it available, but manually accessible as before, seems logical since it is not reliably usable in current form.

On a similar note, I am thinking I can use our 3D Surface Op scan data at high resolution and run an algorithm in python to extract the waterline data since it is limited to a dropdown cutter anyhow.

Have a great day.
Russ

... and yes, I second your thought, "This is looking cool!"

[mlampert]

I don't know if it needs to be a separate operation. Maybe. But I'm o.k. with removing it from active use at this time. Awallin stated somewhere that the waterline algo in OCL needs serious work so I don't think we can make it useful from our side.

If you want to stick with a separate op for now you can stick it into the "experimental features". If you check InitGui.py you'll see what to do.

[JoshM]

Due to my lack of knowledge and expertise in this area of CNC milling and lathe processes, I am reaching out to you. I noticed that the existing FC tool controller[TC] has some fields for some tools that are extraneous to the tool, as I understand the tools. I

Hi Russ,
I'm no expert, but I also noticed that the current Tool definition parameters do not work for all cases. This is more or less true, depending on the level of "completeness" implemented in 3d milling.

For example if one were to implement this to the degree that software not only determined cut paths based on tool tip/shape, but also included the available length of the tool from the Collet to Tip--then we would need to know that length. Since we're not there yet...

Currently, I suspect that most PathWB users use the Tool Diameter indiscriminately for all tools. As is, it is not possible to completely describe all tool types, and there is some overlap in some cases where multiple fields could describe the same information...

I had looked at this a while ago and had made a macro to generate 3d tool shapes from the tool definition to verify that the definition made sense.
I found that the combination of the existing fields for Flat Radius, Corner Radius, Point/Tip Angle, Cutting-Edge Height, and Shank-Diameter allow definition of most common tool types. Currently, Tool material is allowed in the tool definition and that is useless to the program, but good to have for specifying the job.

When I researched this, I looked at several common vendors to see what information is typically provided to the machinist when they purchase and how it is described. Most tools specify Tool Diameter, but that's more of a "catch all" there too. I would recommend the following to support most common tool types in FreeCAD PathWB and came up with the following:

• EndMill (Flat Radius = 1/2 Tool Diameter, CornerRadius => 0, Cutting-Edge Height).
  
  Ballnose (FlatRadius = 0, CornerRadius = BallRadius, Cutting-Edge Height).
  
  CornerRound (Flat Radius = ToolDiameter - CornerRadius, CornerRadius is specified for tool, Cutting-Edge Height)
  
  Tapered Endmill (Flat Radius, Point/Tip Angle, Shank-Diameter, Cutting-Edge Height)
  
  Drill/Mill (Shank-Diameter, Point/Tip Angle, Cutting-Edge Height)
  
  Chamfer (Shank-Diameter, Point/Tip Angle, Cutting-Edge Height)
  
  Reamer--essentially same as TaperedEndMill

A couple of notes as well.

• Only square-EndMills appear to provide Taper. I never found cases where a Ballnose or Chamfer tool had taper.
  
  Endmills would benefit from a field for a Boolean to flag if Center-Cutting is allowed. Operations using non-CenterCutting endmills should always have a RampEntry dressup, or the SanityCheck could at least flag inappropriate use.
  
  In the ToolLibrary Manager, the graphic in the Endmill shows a Shank field, but it's grayed out. The graphic suggests a tool shape you essentially never see (in a Square EndMill), where the shank diameter is smaller than the tip diameter.
  
  Drills and CenterDrills are provided for, but it's not clear the difference, and I suspect the Point/Angle is used differently.

Supporting all tools equally doesn't make a lot of sense to me. A chamfer tool is a specialty operation tool--you don't do Facing Ops with it, and so only want it in limited circumstances. Same for Corner-Rounding, Convex-Radius, and Concave-Radius tools. I'd go further and say that Flycutters are not intended for general use, though they can Face. Slot cutters again are specialty, and require care so they are not raised--for example, with a Rapid Vertical rise at the end of the slot. Throw in Dovetail tools in with SlotCutters.

Best,
Josh

[sliptonic]

Tool attributes need to be extended to store flute count and chipload as well. I've started that process here:
https://github.com/sliptonic/FreeCAD/tr ... /feedspeed

[Russ4262]

Afternoon fellow FC users and forum readers.
I have been working on the tool controller/manager interactions with current OCL tool shapes. I have made some progress. I am attaching my latest version of the 3D Surface Op script to this message. Thank you, Josh

ping

for the great post, providing me with better insight into the various tool terms and how they are

In this script I have a function, setOclCutter(), dedicated to converting stored FC tool properties into OCL compatible function calls for use in OCL operations. Currently, I have conversions for these FreeCAD tools: end mill, ball end mill, bull nose mill, engraver, and chamfer mill. I do need to verify that the FC tool property, "Length Offset," is interpreted as the distance down the shank from collet to beginning of the cutting portion of the tool piece (basically, the smooth part of the shank exposed below the collet??). I am asking for verification because I used this definition in the conversion calculations. It is easily removed if I have the wrong working definition, or it changes based on tool choice.

With regard to contacting AWallin for related input on how he defined his variables and function parameters, I have not reached out to him yet. I will raise that on my priority list related to our progress in this area.

As for the attached 3D Surface Op script, I have made more progress. I have done the following:

• Improved the property inputs from the user to better reflect function within the operation
• Replaced Sliptonic's original waterline function, and replaced it with a set of functions to produce a usable waterline operation
• Improved the line-following algorithm to remove some unwanted breaks and other artifacts
• Incorporated step down (multi-pass or layering) support to the new waterline operation
• Cleaned up the code a little to help Sliptonic separate the script file into multiple operations in the PathWB

ping

I would like to ask the you and others to run some tests and provide feedback for improvements and corrections. I provided my platform specs below. I am aware of a couple of bugs while using the script. So far, I think they pertain to the Qt - python interface. For example, if I change from OCL Dropcutter to OCL Waterline in the properties window, my FC might crash, but if I open the operations settings window, use the menu option to make the same change, then click Okay, my chances of a crash are far less. So, I be advised fellow FC users. Please help me identify the bugs so we can reach a stable version.

UPDATE: 2019-04-29
I have removed the previously-attached script, mentioned above. Instead, the latest script version is found in a later post in this topic. It is available there.

Thanks,
Russ

OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16079 (Git)
Build type: Release
Branch: master
Hash: 6363c90a20b296ab69d7b52230009928199d90df
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: English/UnitedStates (en_US)

[Russ4262]

Sliptonic,
I was thinking about your statement:

I played with your a bit this morning and can't get stepover to behave the way I want. I would expect that if stepover is 100%, the parallel tool path lines on a given stepdown level would be 1 tool diameter apart. Maybe I'm running into what you described above.

With my current implementation the flow for a mult-pass rotational operation is as follows:

• Determine the actual radius of the stock required based on x/y - min/max values
• Calculate the circumference of the rotation at the stock radius
• Calculate the number of indexes(angle scans) necessary at step over value on the circumference
• Make a linear scan of the model at each index
• Obtain the layers with depth_params()
• Loop through the depth_params while doing these at each layer:
• • set index
  • cut to layer depth
  • rotate to next index
  • ...repeat through all indexes

So, with the current implementation, the step over at each step down (layer) diminishes due to the shortened arc length associated with a shorter radius. This is because I only do one OCL Dropcutter scan and then limit each cut per the layers in depth_params(). With current implementation, the step over is only true at the outer most layer(fist step), then diminishes with each subsequent step down.

I understand your statement. If we would like the user-defined step over to be fixed at each layer, then the model will have to be scanned completely at each layer. While this is doable, the increase in computational time might make it impractical. However, I think the implementation would not be to difficult to code. If I get some free time and this "fixed" step over implementation is preferred to the current "diminishing" step over, we can code it and test it. Thoughts?

Russ

[JoshM]

The primary reasons for specifying step-over are to:

-Ensure that the tool is not subject to excess torque.
-Ensure that the model is cut with adequate resolution.

Since the step-over is "true" at the surface of the model, you are meeting the needs of the 2nd reason. Since you know the arc length, is it not true that you can calculate the step-over as it grows with increased radius? If that's the case, you might be able to specify a maximum step-over and then increase the surface passes as needed to ensure the outer maximum is not violated.

With regard to 4th axis milling, I wanted to run something by you, Russ. In Harvey Tools "In the Loupe" they mentioned that the ideal interface angle for a ballnose endmill is at 18-degrees. This is because for a ball mill, there is increasingly little cutting as you approach the tip center. For 3-axis milling, there's not much you can do about this. For 4th-axis milling, there are some cases where you can take advantage of this, and for 5th+ axis milling, even more cases... But, I don't think that the OCL algo accounts for this. Any thoughts?

[sliptonic]

In this script I have a function, setOclCutter(), dedicated to converting stored FC tool properties into OCL compatible function calls for use in OCL operations. Currently, I have conversions for these FreeCAD tools: end mill, ball end mill, bull nose mill, engraver, and chamfer mill. I do need to verify that the FC tool property, "Length Offset," is interpreted as the distance down the shank from collet to beginning of the cutting portion of the tool piece (basically, the smooth part of the shank exposed below the collet??). I am asking for verification because I used this definition in the conversion calculations. It is easily removed if I have the wrong working definition, or it changes based on tool choice.

I haven't had a chance to dig into this so I cant comment on the property implementation. However, I think a helper function like this should either be implemented in a helper module like PathUtils or directly in the ToolController rather than in a specific operation. If a new operation that uses OCL is written, the same kind of cutter manipulation will be needed.

As for the attached 3D Surface Op script, I have made more progress. I have done the following:

• Improved the property inputs from the user to better reflect function within the operation
• Replaced Sliptonic's original waterline function, and replaced it with a set of functions to produce a usable waterline operation
• Improved the line-following algorithm to remove some unwanted breaks and other artifacts
• Incorporated step down (multi-pass or layering) support to the new waterline operation
• Cleaned up the code a little to help Sliptonic separate the script file into multiple operations in the PathWB

Does the OCL waterline operation get us anything that we can't get with other operations? I haven't played with it enough to know.

I would like to ask the you and others to run some tests and provide feedback for improvements and corrections. I provided my platform specs below. I am aware of a couple of bugs while using the script. So far, I think they pertain to the Qt - python interface. For example, if I change from OCL Dropcutter to OCL Waterline in the properties window, my FC might crash, but if I open the operations settings window, use the menu option to make the same change, then click Okay, my chances of a crash are far less. So, I be advised fellow FC users. Please help me identify the bugs so we can reach a stable version.

Ok. I'll take a look. The crash on changing the property value in a task panel sounds familiar. We used to see a lot more of that. mlampert's cleanup of the UI code cleaned most of that up last year but I don't think PathSurface got the same treatment. It was/is still experimental.

[sliptonic]

So, with the current implementation, the step over at each step down (layer) diminishes due to the shortened arc length associated with a shorter radius. This is because I only do one OCL Dropcutter scan and then limit each cut per the layers in depth_params(). With current implementation, the step over is only true at the outer most layer(fist step), then diminishes with each subsequent step down.

I understand your statement. If we would like the user-defined step over to be fixed at each layer, then the model will have to be scanned completely at each layer. While this is doable, the increase in computational time might make it impractical. However, I think the implementation would not be to difficult to code. If I get some free time and this "fixed" step over implementation is preferred to the current "diminishing" step over, we can code it and test it. Thoughts?

Russ

There's a trade-off of efficiency. To scan the model completely for each step-down level is going to take more time but should result in a shorter overall path. With your implementation, The bottom step-down (closest to the model) will have the same number of step-overs (rotational angles) as the top level. That's real machine time that isn't necessary. Also, since the real step-over is diminishing, you're reducing the chipload on the tool. That can cause a problem since the insufficient stepover can cause chip thinning, tool rub, and unwanted heat. I think if the user sets 50% step over, he should get 50% stepover as much as we can possibly manage.

So I strongly vote for scanning at each level, even if it takes longer.

[herbk]

So, with the current implementation, the step over at each step down (layer) diminishes due to the shortened arc length associated with a shorter radius. This is because I only do one OCL Dropcutter scan and then limit each cut per the layers in depth_params(). With current implementation, the step over is only true at the outer most layer(fist step), then diminishes with each subsequent step down.

I understand your statement. If we would like the user-defined step over to be fixed at each layer, then the model will have to be scanned completely at each layer. While this is doable, the increase in computational time might make it impractical. However, I think the implementation would not be to difficult to code. If I get some free time and this "fixed" step over implementation is preferred to the current "diminishing" step over, we can code it and test it. Thoughts?

Russ

There's a trade-off of efficiency. To scan the model completely for each step-down level is going to take more time but should result in a shorter overall path. With your implementation, The bottom step-down (closest to the model) will have the same number of step-overs (rotational angles) as the top level. That's real machine time that isn't necessary. Also, since the real step-over is diminishing, you're reducing the chipload on the tool. That can cause a problem since the insufficient stepover can cause chip thinning, tool rub, and unwanted heat. I think if the user sets 50% step over, he should get 50% stepover as much as we can possibly manage.

So I strongly vote for scanning at each level, even if it takes longer.

+2 , because machining time is much more important.