Can We Talk CAM Programs?

[CFLBob]

So now we can see there is no problem with the actual program being used but just the chosen path what can Bob try.

...

Well, not exactly. The program I'm using isn't capable of doing what you did; either the "adaptive tool path for roughing" or the contour cut. When you did the things I did, you got the results I got. Lumpy, with the big visible steps. Since I can't do what you did in DeskProto, to me, that's the software. It tells me I need to use software that can do those things.

If I'm reading this incorrectly, please let me know!

I saw the 5000 RPM and 20 IPM rate in the video and reached the same conclusion about going to 10 IPM - but I didn't know about the three flute cutter. My square-end cutter is two-fluted, and didn't further reduce that, but I reduced the step over between tool paths to 0.0038 (D/65) and step size along the paths to nearly twice that, 0.0076" (D/33). The simulator in Mach3 tells me the time to run that file will be 2-3/4 hours at 10 IPM. It was very close to predicting the actual time on the previous file, so I assume it will be here. That's nearly 5 times the number of tool paths (.0174/.0038 is 4.6) with each step along the path 1/3 the distance. It takes virtually twice as long to run.

 

[Jasonb]

Did you not read this bit?

"Looking at that list of options in your last image the bottom one "contour only" looks like it will be the same as the contour I used so after roughing set that to the full depth of the part and a lit more say 0.45-" total and cut around the outer profile of the part. "

 

[CFLBob]

I did. These are the options I get:

I'm trying to find out if the fact that there are no "detail settings" means it's not enabled in the program or just what is going on. I had always thought of that option as just one waterline pass at the bottom of the part, but I don't really know what it means. If I check the square in that right pane, the settings button turns on and I get a group of choices that say something like:

The choices run from 1 (no refinement) to 9 (gridsize 0.0004, calculation time x64).

If you can explain that, please do. Some work around the house has kept me from digging into the Help file.

 

[kf2qd]

That is part of the reason that I use some macros that I wrote in VBA in AutoCAD. I draw my toolpath and select my macro and out comes G-Code. And I have control over my code. I use this for work at home on my hobby machine and at work with the occasional production job that does not fit well into a conversational programming environment.
To me, that back and forth profile that that program produces is horrible. Profiling the contour would be cleaner and I would think much faster.

 

[Jasonb]

" I had always thought of that option as just one waterline pass at the bottom of the part "

A contour cut is just a pass at full depth* which will clean up whatever you left in the roughing stage and as it is full depth you won't get any steps where tool goes round at different heights. With no sideways stock left the cutter will run along the outside edge of th epart removing metal over the full height back to finished contours.

F360 does have more option such as more than one pass be that a roughing or a spring pass at the final setting. *You can also set multi depths if it's a tall part

This is the tool path of the contour, you can see it is two on mine as I described above but provided you have not left too much material to clean up from the roughing stage a single pass will be OK if you don't have the option. But it can be got round by doing two contours one telling the machine the tool dia is say 5thou larger than it is and a second on actual tool dia so you get a final pass taking 0.0025" off.

Also the code for a single contour pass for you to compare with what you write and what that contour on your program gives

 

[CFLBob]

Can't thank you enough, Jason.

I had experimented with the function last night after my last post/comment. There's a big difference between the F360 and the DeskProto codes. For comparison, I want to post the code for one pass around the part that DP created. I tried to leave a .004 margin around the part. Yours is 44 lines long. Mine is 152. The difference is obvious.

1. G17 G20 G40 G49 G64 G90 G94
2. G0 X0.152 Y0.946 Z0.054
3. G1 Y0.946 Z-0.220 F2.0 S2000
4. G1 X0.167 Y0.892 F6.0
5. G1 X0.181 Y0.853
6. G1 X0.196 Y0.824
7. G1 X0.210 Y0.800
8. G1 X0.225 Y0.780
9. G1 X0.240 Y0.765
10. G1 X0.254 Y0.751
11. G1 X0.269 Y0.736
12. G1 X0.283 Y0.722
13. G1 X0.308 Y0.707
14. G1 X0.332 Y0.692
15. G1 X0.361 Y0.678
16. G1 X0.400 Y0.663
17. G1 X0.420 Y0.658
18. G1 X0.454 Y0.653
19. G1 X0.488 Y0.649
20. G1 X0.512
21. G1 X0.546 Y0.653
22. G1 X0.580 Y0.658
23. G1 X0.629 Y0.673
24. G1 X0.658 Y0.688
25. G1 X0.687 Y0.702
26. G1 X0.707 Y0.717
27. G1 X0.726 Y0.731
28. G1 X0.765 Y0.736
29. G1 X0.838 Y0.731
30. G1 X0.916 Y0.726
31. G1 X0.989 Y0.722
32. G1 X1.062 Y0.717
33. G1 X1.140 Y0.712
34. G1 X1.213 Y0.707
35. G1 X1.286 Y0.702
36. G1 X1.364 Y0.697
37. G1 X1.437 Y0.692
38. G1 X1.510 Y0.688
39. G1 X1.588 Y0.683
40. G1 X1.661 Y0.678
41. G1 X1.734 Y0.673
42. G1 X1.807 Y0.668
43. G1 X1.885 Y0.663
44. G1 X1.958 Y0.658
45. G1 X2.031 Y0.653
46. G1 X2.109 Y0.649
47. G1 X2.182 Y0.644
48. G1 X2.255 Y0.639
49. G1 X2.328 Y0.634
50. G1 X2.406 Y0.629
51. G1 X2.479 Y0.624
52. G1 X2.532 Y0.619
53. G1 X2.567 Y0.605
54. G1 X2.581 Y0.585
55. G1 X2.586 Y0.571
56. G1 X2.591 Y0.434
57. G1 X2.605 Y0.395
58. G1 X2.620 Y0.376
59. G1 X2.635 Y0.361
60. G1 X2.659 Y0.347
61. G1 X2.703 Y0.332
62. G1 X3.224
63. G1 X3.267 Y0.347
64. G1 X3.292 Y0.361
65. G1 X3.306 Y0.376
66. G1 X3.321 Y0.395
67. G1 X3.336 Y0.434
68. G1 X3.341 Y0.542
69. G1 X3.355 Y0.571
70. G1 X3.375 Y0.585
71. G1 X3.389 Y0.590
72. G1 X3.448 Y0.595
73. G1 X3.487 Y0.610
74. G1 X3.506 Y0.624
75. G1 X3.521 Y0.639
76. G1 X3.535 Y0.663
77. G1 X3.547 Y0.707
78. G1 Y1.296
79. G1 X3.535 Y1.340
80. G1 X3.521 Y1.364
81. G1 X3.506 Y1.379
82. G1 X3.487 Y1.393
83. G1 X3.448 Y1.408
84. G1 X3.379 Y1.413
85. G1 X3.355 Y1.427
86. G1 X3.341 Y1.457
87. G1 X3.336 Y1.569
88. G1 X3.321 Y1.608
89. G1 X3.306 Y1.627
90. G1 X3.292 Y1.642
91. G1 X3.267 Y1.656
92. G1 X3.224 Y1.666
93. G1 X2.907 Y1.666
94. G1 X2.688 Y1.661
95. G1 X2.649 Y1.647
96. G1 X2.630 Y1.632
97. G1 X2.615 Y1.617
98. G1 X2.601 Y1.593
99. G1 X2.591 Y1.564
100. G1 X2.586 Y1.427
101. G1 X2.571 Y1.398
102. G1 X2.552 Y1.384
103. G1 X2.542 Y1.379
104. G1 X2.498 Y1.374
105. G1 X2.420 Y1.369
106. G1 X2.347 Y1.364
107. G1 X2.274 Y1.359
108. G1 X2.201 Y1.354
109. G1 X2.124 Y1.350
110. G1 X2.051 Y1.345
111. G1 X1.977 Y1.340
112. G1 X1.904 Y1.335
113. G1 X1.827 Y1.330
114. G1 X1.754 Y1.325
115. G1 X1.681 Y1.320
116. G1 X1.608 Y1.316
117. G1 X1.530 Y1.311
118. G1 X1.457 Y1.306
119. G1 X1.384 Y1.301
120. G1 X1.306 Y1.296
121. G1 X1.233 Y1.291
122. G1 X1.160 Y1.286
123. G1 X1.082 Y1.281
124. G1 X1.009 Y1.277
125. G1 X0.931 Y1.272
126. G1 X0.858 Y1.267
127. G1 X0.785 Y1.262
128. G1 X0.736
129. G1 X0.717 Y1.277
130. G1 X0.697 Y1.291
131. G1 X0.673 Y1.306
132. G1 X0.644 Y1.320
133. G1 X0.600 Y1.335
134. G1 X0.537 Y1.350
135. G1 X0.464
136. G1 X0.400 Y1.335
137. G1 X0.356 Y1.320
138. G1 X0.327 Y1.306
139. G1 X0.303 Y1.291
140. G1 X0.283 Y1.277
141. G1 X0.264 Y1.262
142. G1 X0.249 Y1.247
143. G1 X0.235 Y1.233
144. G1 X0.220 Y1.213
145. G1 X0.206 Y1.194
146. G1 X0.191 Y1.169
147. G1 X0.176 Y1.135
148. G1 X0.162 Y1.092
149. G1 X0.152 Y1.053
150. G1 Y0.946
151. G0 Y0.946 Z0.054
152. M30

The difference is DP only steps in short G1 steps, while the F360 code does the G2, G3, I was saying I wanted it to do plus codes I've never heard of (G17, 18, 43, 54). If I was trying to write this code by hand, my knowledge isn't up to the task.

Still, these G1 steps might leave the part looking smoother because they step in both X and Y, which will invoke Mach3's Interpreter and those lines are going to be smoother than the ones where it suddenly stepped 0.0147 in Y. GWizard Editor shows it as smoother in the circles, too, but that won't affect the boss on the big end but I bet the F360 curves are smoother because of the G2 or G3 versus G1 steps.

I should try this.

 

[Jasonb]

That does look a bit limiting in what it can do, might be interesting to see if teh steps decrease if you alter that settings option though still not going to be ideal.

Probably time to start looking elsewhere for your CAM such as F360. I'd suggest watching Lars Christianson's videos on CAM for Beginners, it's what I started with.

https://www.youtube.com/playlist?list=PL40d7srwyc_OmRH4UQ_E-6UB-GbhPdjc8

 

[CFLBob]

Look at post #42 here: Conrod for an example

I meant to reply to this yesterday, Greg. I read that thread when it was posted and totally forgot. Thanks for the reminder.

 

[ddmckee54]

CFLBob:

Not being familiar with DeskProto at all, I'm wondering what its' configuration is like. You've said that you are using Mach3 as the controller to run your CNC. Mach3 can handle the G2&G3 curve commands. But your G-code contains no curve commands, G2 or G3, just straight line commands, the G1 command.

I believe that once upon a time GRBL could only handle straight line comands. Is it possible that DeskProto is configured to output code for a GRBL controller instead of a Mach3 controller? (Maybe it doesn't have that option? Just one for more reason to find a different CAM software.)

You should still be able to get a single pass contour cut. In the present configuration it won't have any curves, just LOTS of straight lines - like you already found out. You can still do amazing things with a software that has limitations, it just means more work on your part to find ways to push the edges of the limitations envelope.

Don

 

[CFLBob]

DeskProto says it's configured for Mach 3 but I haven't tried to see if I get G2 or G3 by trying another processor. Haven't opened that can of worms.

 

[CFLBob]

This has turned into a valuable learning experience, for which I thank you all.

I ran a contour pass with the margin set to .004" but with the step size along the path still set to .0147" That made a noticeable improvement but there were still marks where the steps had been. Unfortunately, I forgot to take a picture. The final pass was set to zero margin and I decreased the path step to .004".

There's still taper around the two circular bosses and while the small one looks like a cylinder the second one has too many obvious facets. The facet in the middle of that "not exactly a circle" really is a facet because that's where the slitting saw cuts away the bottom of the rod. Since this con rod got barfed by the glitch that made the too-deep trench along the edge close to the camera all of those operations can't be done.

The original goal of this experiment was to emulate the approach I saw @Mayhugh1 use to make his tiny, two-sided parts in his Ford 300 build and fill this side with epoxy, but that might be impossible now with the cutter margins taking up more of the "extra" material than I figured. I'm not sure if I should toss this at this stage or try to figure out a way to still pour the epoxy. I have a second blank that matches this one in size. Maybe I should make a bigger one.

 

[nealeb]

I' ve had a quick look back and can't find the file format used to transfer from the CAD programme to Deskproto for CAM. I saw a passing reference to STL but wasn't quite sure what that referred to. If the model is transferred via STL, though, then this explains the generation of G1 straight-line moves rather than G2/G3 arcs - the model doesn't actually have any curves in it. STL models consist of a large number of (usually) triangular facets and will always end up with straight lines in the gcode. Jason's model in F360 will have curves and generate correct arcs automatically.

These days I'm using Solid Edge for CAD and transferring the 3D model to F360 for CAM, but using .stp format which does maintain the correct geometry.

I may well be wrong about the use of STL, but would like the question cleared up to avoid any confusion!

 

[CFLBob]

Fascinating. Thanks!

A quick check in both my version 5 and 7 programs shows DeskProto will work on .STL, DXF or VRML files. DXF for 2D machining. The conn rod is almost 2D: not really but maybe close enough to be useful for some things. (in software I used to work with there's a concept called 2.5D - it's like that) I've been using STL so long that I never thought of looking at other formats.

I saved the file as VRML and apparently there's a "feature" that changes the dimensions to millimeters but DP thinks they're in inches. My conn rod is 123.5146 inches long. I tried opening the conn rod in Rhino as a metric import, and saved it again, this time it's over 3000 inches long.

Rhino, DP, or VRML file bug? I'd bet on Rhino, but that's a WAG.

The problem is that I don't have a way to see if DP would make better tool paths.

 

[nealeb]

As far as I know, VRML also treats the model as a series of flat planes, much like STL, so not really helping much.

The millimetres/inches ambiguity isn't that unusual - I have been given DXF files to work with that were created in inches but which my CAD software treated as mm because DXF does not always define the units used. However, I have always been able to use a scaling factor in my CAD software to multiply or divide by 25.4 to convert before starting work.

Any chance of saving your STL file with a finer granularity? Mach3 will tend to round off corners if they are close enough, and as long as you are using CV (constant velocity) mode. If you turn off CV mode, the machine tries to start and stop at every "corner" which makes things very slow and will definitely show the faceting effect more clearly, as well as shaking the machine around!

Just had a quick look at the Deskproto 7 features, and it looks as if the best way to get 3D files into it is via DXF 3D. The other formats involve faceting where DXF should handle vectors properly (although I have no experience of this - I use STP which DP does not support). However, I'm not sure what you can get out of your CAD software.

 

[willray]

As far as I know, VRML also treats the model as a series of flat planes, much like STL, so not really helping much.

VRML does have primitives other than planes, but as a format that's been effectively dead for nigh on 20 years, I don't think anyone bothers to even attempt to support the solid geometric primitives anymore. They were never entirely consistent even when VRML was ruled by SGI and Cosmo.

VRML's enduring grace, as it were, is that like STL, its surface representation is so primitive that it only uses triangles.

The irony is that if VRML had survived longer for its intended (3D web browsing) purpose, it probably would have evolved to support more sophisticated surface definitions, and would have thereby lost utility as a format for defining manufacturing geometry.

3D file formats that are more modern pretty much all let you specify surface facets that have more than 3 sides, and as a result remain syntactically valid even if the points defining a facet aren't co-planar.

If the corners of your facet aren't all in one plane, the actual location of the surface isn't defined - which is fine if you're Disney putting eyelashes on a princess, but it plays hell with defining objects for manufacturing.

So, there's your too-much-useless-information about antique file formats for Friday public service bulletin

 

[mu38&Bg#]

Way back in my early CNC days ~2003 I started with Meshcam. It was incapable of fitting arcs to use G2/G3 in the Gcode output. Quickly I realized it was unsuitable for machine components. I found there were many "art" type CAM. I ended up buying VisualMill. If you can't work with an iges file for translation you're giving up a lot in terms of accuracy. No point in tool radius comp if the geometry is a raster and CAM is just guessing. Faster computing today mean finer stl settings will be more accurate and output smaller segments, but then you get huge files and the machine is slow. I have not looked at hobby CAM in years so maybe there are more options, the most common recently was Fusion360.

If you don't want it to cut to full depth using parameters you've set for a certain area, limit the depth for that operation and make another operation for the rest. All CAM have quirks. You need to try different things to see how they work and if you can manipulate them to do what you want.

If the machine is rounding corners, check path blending settings (no idea if Mach has such a setting like G64 in Linuxcnc), or consider reducing acceleration values. Realistically this should only happen at substantial feedrates.

 

[CFLBob]

So, there's your too-much-useless-information about antique file formats for Friday public service bulletin

Since I also have a 3D printer and two different slicer programs for it - the printer version of a CAM program - I wondered if it could import the VRML file (.wrl format). One in particular is very good at looking at the numbers and asking you if the file is really in inches. I figured when it saw the 123.5146 value for X it would ask me and convert it to inches.

The gotcha was that it doesn't know that dead format.

Never mind that 3D printers are additive machining, so it makes the part from the bottom up, not cutting away from the top down. And the Z-axis steps would be around .1mm.

 

[willray]

Since I also have a 3D printer and two different slicer programs for it - the printer version of a CAM program - I wondered if it could import the VRML file (.wrl format).

A particularly useful piece of free software (if you can get past its interface quirks) for fiddling with 3D files, is a program called MeshLab: www.meshlab.net

MeshLab has a wide variety of useful tools for modifying 3D (almost exclusively mesh-defined) files, from utilitarian things like file format conversions, to geometric transformations (like scaling), to mesh repairs, to being able to apply interesting programmatic/conditional math to the surface.

For example, it's reasonably easy to use MeshLab to take a mundane "solid" (watertight STL) model, convert it into a shell, and then blast holes in the shell so that you're left with the shape of the original, but represented as a hollowed-out structure with the surface a random tracery of "web like" structures.

Perhaps more generally useful, it's also fairly easy to take a manifold STL file and thicken thin bits so that they're less likely to fail when printing.

MeshLab's most annoying quirk is that it has no "Undo" function, so save early and save often! If you can get past that, it's a really useful tool if you have a 3D printer. (Yes, it can also read at least a subset of VRML and write STL)

 

[CFLBob]

Thought I'd update everyone on what I've been up to. Over the last few days, I did my epoxy pour and worked on the tool paths to do the second side. I thought of ways I'd like to improve the first side machining, and here's what I came up with.

I thought the first thing I'd do is a contour instead of the waterline cut, except I wanted the thinner layer cuts that waterline gave me. So what I did was create the file for doing one cut the full 0.220 deep and then edited the text file, turning one tool path in to seven layers, each removing .031" It's just block copy and paste in an ASCII text editor. The tool paths came out looking like this.

Then I took the waterline approach and figured out how to keep it from cutting everything I just cut, restricting it to just reducing the middle part of the part (and only to .040 below the top, leaving the last 0.22 for the final rough cut. That one looked like this.

I didn't read the file closely enough; those big, dense, circles within circles on both ends were cutting in the air above the part. A real waste of time. A lot of time, like 20 minutes out of a 35 minute file.

The cuts threw a curve at me because there seemed to be some sort of resonance that started and vibration was high. I didn't want to stop it and try different settings in case I couldn't resume. The part looks like this now.

I think the next step is to recreate this file with no margin so that the top .062 or so is the right shape and the run the contour pass I ran on the first side.

 

[Eccentric]

Coming along Bob, I see you have smooth sides on the conrod now. I have a couple of suggestings. It looks like you are doing a slot cut, this is fine and when starting a machining operation and it can't be avoided, but be aware this is OK for a roughing pass only. As the tool is cutting the slot it is making a conventional cut on one side of the slot and a climb mill on the other. The tool will be pulled to the side of the slot that the flute is advancing into (conventional milling) and pushed away from the other side (climb milling). The tool will have a tendency to bounce back and forth, the amount depending upon your system's rigidity. Use this to make a roughing pass to clear the slot leaving .010" to .020" (again depending upon your machine's rigidity), then take a cleanup pass brining the part to dimension using climb milling. You can also take a second "spring" pass.

Secondly, I have found it best to avoid plunging the cutter into the part. You are only stepping down .031" I think you said, so this would not be an issue. but you do have the opportunity to enter the cut from either the right or the left.

It is good to edit your own Gcode as you become familiar with the post processor and the codes used, but doesn't your CAD program allow you to create a profile, or contour operation where you specify the stepdown and it generates the whole toolpath without the need for copy and paste Gcode? When ever you have to get in there and hand edit a tool path there is an opportunity to make mistakes.

Your comment about attempting to use a 3D printer slicer to generate your tool paths leads me to beleive you are not satisfied with your CAD program. I think you should look around and find a CAD program that you can bend to your will.

Just some thoughts, you are making good progress.