I tested the thing and have one conclusion when using a ballnose endmill in opti-rough: Use it with deep cuts and shallow stepovers - you should be safe - at leas from what I've tested a few times. If you try to use it with shallow DOC and big stepovers, you might get trouble with it colliding. Maybe not always - but be ready for it What I tried to do before was using opti-rough with a ballnose with shallow DOC and big sidestep (I had a 25mm ballnose insert cutter - not solid endmill) - similar to a "constant-z" like approach but with opti's great stock awareness and the possibility to add additional stepovers if needed to take out excessive "lands" of material. I considered that it shouldn't be a problem, but it seems I was wrong. This approach works out great though with bullnose endmills and what's more important - with insert cutters whose nature of milling is shallow DOC and big stepover. I use opti very often to take out material with insert cutters/high feed cutters etc. The approach is to go down in Z by the "millimeter" (+-) and take huge, but consistent sidesteps. No up-step usage because DOC is small. But with solid tools the thing is opposite - big DOC and small sidestep + upsteps - to fine rough out of the angles on surfaces. Anyway - beware with ballnose with this approach. I hope this helps. Take care and all the best! -Maciek.

Crazy^Millman, Colin - big thanks for all your suggestions. Sorry for the long time with the response - I was stuck in urgent and precise prototyping work last week... Since nowadays I'm the only programmer/technology guy in my shop - I was busted 100% I did try what You told me and unfortunately it did not bring any effect I turned off "minimize trimming, then "Fit Transitions" and then both of them - nothing changed. I also played with the length/arc radiuses etc. in the leads with no success. I had to give up because the workload is unforgiving.. I will send it to my reseller and let Them deal with it. But first I have to prep the file since the original is under NDA... I hope the fake one will be curtious enough to reproduce the bug if I get feedback I'll post an update. Take care! -Maciek.

Hi All! Does anyone have this issue in equal scallop that it sometimes and randomly misses lead in and/or lead out passes? To be more specific - not the whole leads, but just portions of it, ex. primary lead or secondary lead... I attach pictures to explain what I mean. Maybe it's me doing something wrong - I don't know... Anyway - this is annoying, because it doesnt feel you have full control over the thing... If anyone has a clue what's wrong - I'll be grateful. I can't attach the MCAM file because of NDA... I tried to explain it on pics only... Sorry and thanks!

Tried to make a dummy flowline to see what your having. I noticed that if I toggle, let's say the "Cut direction" button, after 3-4 toggles all the plots dissapear, even the cut direction arrows, which in your case stays on the screen. If I then rotate the graphics view or just "touch it" with the middle mouse button, the plots and arrows appear again. Maybe this will help you... Anyway it's just a workaround, but it may let you at least proceed forward.. There is also the "Plot edges button" but it seems do do nothing... Another thing - remember to click the button with the flow picture (on the bottom of the window in the "Flowline" section) in the "Toolpath/surface selection window, taht appear just after you select your surfaces. Good luck!

You have to have projection set to 3D instead of 2D on the Cut parameters page. Then You can use tool contact point with the curves (dont confuse it with the boundry). I dont know why this is so, but that's the way it works. I struggled with it for a while also... But You propably know this by now - I'm a year late sorry

Both Vc and SFM are a measure of linear peripheral speed of a tool in reference to the material it cuts. Both are proportional to the RPM which is the angular speed. So RPM causes Vc (and SFM) and the latter is the speed at which the tool cuts (rips off) a layer of material. This cut layer has a mean thikness equal to the mean thickness of the chip (hm) and depends on fz - feed per tooth. Vc is in metric units while SFM is in Imperial units. Vc is the cutting speed in meters/min, SFM is the cutting speed in feet/min. Common formulas in a nutshell: Vc = Dc * PI * RPM / 1000 where Vc is in [meters/min] ; Dc is in [mm] ; RPM is in [1/min] ; Dc is the cutter diameter SFM = Dc * PI * RPM / 12 where SFM is in [feet/min] ; Dc is in [inches] ; RPM is in [1/min] ; Dc is the cutter diameter To switch between them use these formulas : { Vc = 0,305 * SFM } or { SFM = 3,28 * Vc } Hope this helps. Take care!

I went with 45% sideways because of a small stepdown. Did not want to waste that much time. A ball can handle 45% sideways while 6% deep in aluminium no problem. I would also need to trim the path with some "dummy" stockmodel to make it stay off the sphere that was previously roughed with the big tool, but that's a different thing. I know you didn't mean ill will. Me neither. I try to focus on the problem and then tackle it. I rely on Mastercam everyday, even though I do not consider myself a power user. But if something goes wrong, I do worry and - if time provides - try to dig upon the subject more deeply to solve it and explain what was the issue. Since time is my enemy - a lot of times I just go around the problem and at the end of the day come out the same door only from a different corridor... And that I love in MC because it gives you the freedom to do so. I will try to test this "ballnose opti thing" deeper and will let you know what my conclusions are if they will be worth it. Hopefully, in the meantime will also read what others say. Thanks and take care!!

Crazy^millman, wow! Thanks for your help and good advice but unfortunately it did not go in the right isle... I think you misunderstood my question and my problem. That's propably my fault - English is not my native language But to be honest - I don't really understand why you are talking about metetrs of flat areas milled with a ballnose leaving cusps etc. Have You seen the part I attached? If not, be informed that the part is a sphere with 4 vertical technological bosses attached to it which are filleted to the sphere with R10 mm (394 thou radius). From my 15+ year experience, a ball cutter was the first choice to clean up the fillet radii from material left by the 25mm bullnose that I roughed the thing out with... "Beat me up Scotty" - but unfortunately that was my first choice! Sorry it wasn't the face mill nor the flat or bullnose... I admit - the microlift was my overlook which gcode fixed quickly - thanks again gcode Remember when I said "...if You play around with the step-over/step-down/step-up in the file in the toolpath that uses the ball - you could get even worse collision scenarios..."? Well here is one : The same toolpath that gcode fixed - the change is stepover to 45% (3.6mm), stepdown to 6% (0.48mm), step-up not used, because stepdown is small enough (I wanted to use a constant-z like approach with additional side steps if needed). And guess what - you get collisions! This time the microlift is 1mm and the maximum cusp height that is derived from the stepover is: c = R - sqrt[ R^2 - (s^2 / 4) ] = 0,428mm (the microlift in the path = 1.0mm - so it should be safe) where: c = max cusp height (provided you mill off a layer >= the cusp height) R = radius of ballmill (4 mm - it's a 8mm ball) s = stepover (3.6mm) So why are there collisions? Can you explain? Bad craftsmanship? Bad program to do the job? Bad toolpath/tool usage? Bad day? Bad week? Bad what? Well - I don't know the answer - that's why I asked people that are smarter than me - maybe they will come up with something, maybe they had issues like that in the past... I think that this question is also adequate to people who created the software - they know best their intension with this toolpath. If they say - try avoiding or take special care to this opti toolpath with ball endmills - that's fair enough - that's some info at least. But in the end - I think this should be fixed - it might be in 2025, 2028 whatever, but something is said about it and some secrets revealed and some foundation built for the future of this magnificent - after all - software! Step by step - that's how it looks in my world... I attached a file - it's operation no. 5 that generates these collisions. Operation #6 is for comparison, that a bullnose does not have these problems. It has the exact same parameters - only the tool is changed. Crazy^millman I really respect all your knowledge, experience and professional expertise - really. You rule on this forum! But I don't like misunderstandings, hence all the above. Also don't worry about me getting "all butt hurt" - I don't have time for such soap opera BS - I'm here to get rid of a problem - pure and simple. Anyway, my last thought is that this problem DOES need answers and a remedy. All the best to You all! OPTI WITH BALLNOSE.mcam

Thanks gcode. Tried it and it doesn't collide. You could say case closed, but... Anyway - from my perspective - that's a workaround. From my point of view - the toolpath shouldn't do that. Opti is a very powerful and almost automatic roughing startegy in conjuction with stock model. But the most important thing for a programmer is it's reliability. You must be able to trust it! I know, I know - you should always verify and simulate it, but if you get a problem - it could take you more to make it work than sometimes roughing the part "manually" using other paths. So my theory is to rather use bull-nose due to the flat portion that it has - it doesn't generate scallop. Seems opti isn't so comfortable with this scallop generated by a ballnose and may collide. I did this in aluminium - that is a very forgiving material. If you were to mill an exotic... - it definetely would be a problem. I also have a question to the Developers of MC : Is Opti-rough more dedicated to bullnose than ballnose? Does the above "theory" make sense. If yes - than I will do that - will avoid ballnose and the case is closed for now - hopefully it will be more bug-free in the future. What do You think? Besides if You play around with the step-over/step-down/step-up in the file in the toolpath that uses the ball - you could get even worse collision scenarios. Can the Developers make their opinion on that - that would be very useful and life-saving info for all of us. Thanks very much and looking forward to your opinions.

Hi All, Has anyone encounter problems with ballnose endmills in optirough (rest) toolpaths. What I've recently noticed is that this toolpath, when used with a ballnose endmill, may occasionally cause collisions with in-progress stock. This can be seen in verify - red color or in the report tab. The collisions regard the flute (cutting) portion of the tool. I attach an MC file with a dummy project to look at this. The EXACT same toolpath (copied) is used with a bullnose and the collisions disappear. If anyone has any thoughts about this - please let me know. The file is metric. Thanks in advance! Maclaw. OPTI WITH BALLNOSE.mcam

Just made the Benchmark 3.0 test on 2021 (fresh open of file with 2021, clear log, regen all ops in the tree, no edits, no save, nothing) : i7-3930K @ 3,2GHz, 32 GB DDR3 RAM, NVidia GeForce GTX 1660 PLUS, 480GB SSD, Win 10 Pro x64 - all self-built in 2013 - only added the bigger SSD and new GPU - today 1) No of threads = 4 ; priority = NORMAL -> 5:46 [min:sec] 2) No of threads = 8 ; priority = NORMAL -> 5:26 3) No of threads = 16 ; priority = HIGH -> 5:19 4) No of threads = 6 ; priority = NORMAL -> 5:25 No big differences when messing with the thread # and priority. The result didn't knock me off the chair, unfortunately Well maybe it's time to look for a new machine... I still wonder wether the GeForce GPU is a good choice and does it have anything to do with the toolpath calculations? Anyone have a clue? I'm asking because the Quadro prices are at least twice as those of GeForce. And last (but definetely not least) - Quadro's parameters are usually worse than those of GeForce (amount of memory, amount of CUDA cores, memory bus width, memory clock rate, etc. - my logic tells me that these are after all very important parameters)...

Thanks Crazy^Millman I'll give it a shot Does anyone know of a benchmark regarding graphics for 2021 or other versions? How to test your system as it goes for the GPU to know you are good (or not)?

Where can I get the file - I would like to test it... Thanks in advance

Thanks Mr. M, But unfortunately when I use scheduled progs the machine doesnt display the program flow... And this is an issue in my company. It's against our internal safety procedures - how can an operator run a program "in blind"??? This is some kind of absurd....!! Anyway - thanks very much for your interest in this subject Mr. M. I guess for now I will go with the ".ssb" method from the root of MD1, as Brad described above - already backed up all files from that directory in case I or someone else deletes anything important from there. Thanks again Brad for your post. It's amazing how this machine is "safe". You cant even use an edgefinder at 400 RPM with the doors open (max RPM=50).... But when you run a scheduled prog it wants you to do it "blind" - aint that clever Folks? BRAVO!!! :-) The Guy who came up with this clever idea should go to Swedem for a Noble "anti-common sense" prize! I mean - dont these darn MTBs listen to the machinists anymore these days??? Why?. Good thing I also have HAAS machines which are made for machinists and can be operated in a normal manner still maintaining RESONABLE safety issues. They say Haas this, Haas that, but.... oohh man... to move axes (while spindle is stopped) in this Okuma, it would be good to have 4 hands and a checklist procedure like airline pilots - so many buttons and key switches you must press to achieve this. Going this way, in a few years you wont be able to touch this machine while working on it... This is crazy!!! It's so darn sad they screwed these "little" things up so much - in - at the end of the day - a resonably fast and rigid machine which must say the okuma is. It's just sad. But when working on a daily basis these "little" things just make you go mad.... aaahhhhh!!! Anyway - sorry for the sorrow words but I just had to say it However I will still try the ".sub" method in free time (if it's possible at all). Anyway when I come up with something will let you all know. Take care Folks :-)

Hi Brad, I want to use the ".sub" method. Why cant I select MULTIPLE (not just one) subprogram file? Do You know a way of achieving this??? Because what's the use of having a main .min program calling just one subprogram .sub file? I prefer using the .sub method because I dont want to trash my root MD1 directory. I want to use my machine to do 4 pallets of different parts in one run. I will post out 4 part programs and want to have a 4 line main .min prog to control which subs to execute. I dont want to do megabytes of copy paste stuff to put it in one file because it's annoying, a lot of work and may also be dangerous if you leave something out.... Beside - this week I will do 4 parts at a time on 4 fixtures/pallets, next week I will do another (different) 4 parts. All I would need to do is post out the 4 progs for the new parts into subs and do minor (or none) editing to my main prog and fire of the production with no windows copy/paste BS and merging large files into one and all that headache.... Thanks in advace for your help.