[SBC Cycle]

What toolpath are you using? There are some 3D toolpaths that will only put out feed moves unless you command it to use rapids.

We don't have enough information here to help. We could guess which of the (11) Mach posts you are using for V4 or what toolpath you are using but it's anyone's guess at this point.

BobCAD can't override your rapid rates, it can only tell the machine to move in rapid mode (G00) or interpolated mode (G01). The rapid rate is controlled by your machine's control.

[cadguy247]

What toolpath are you using? There are some 3D toolpaths that will only put out feed moves unless you command it to use rapids.

We don't have enough information here to help. We could guess which of the (11) Mach posts you are using for V4 or what toolpath you are using but it's anyone's guess at this point.

BobCAD can't override your rapid rates, it can only tell the machine to move in rapid mode (G00) or interpolated mode (G01). The rapid rate is controlled by your machine's control.

I'm using 3D advanced roughing and the Mach3-NoATC_mill post as that was the only one that was loaded in with the installation. now I see that there are others to be downloaded which I will try, Do you know of one that works better than the others?

Also, Bobcad tech support edited a post for me that would override the rapids to whatever I put in, so i'll give that one a try over the weekend

So far I love the software, seems it has come quite a ways since a few years ago. I remember people bad mouthing it all the time years ago. Showed it to a few guys at work and they're ready to dump Mastercam for it.

[mmoe]

Rapids are shown in Bobcad as dashed lines, vs. solid lines, so you can see where they will occur when looking at the toolpath (I'm assuming the same is true in Bobcam for Solidworks). Are you using the adaptive mode of Advanced Roughing with it set to "one way" or "zig" (can't remember which they call it as I've seen it both ways)? If so, the only rapids are going to be between groups and large gaps, and only if you check those options. Otherwise, the move to the top of the feed plane and the retract at the end of the job will be the only rapids. They really need to change this so that when using link clearance in the "one way" adaptive, the link move should have the option of being a rapid. It's not cutting anything and it's above the part by the link clearance, so leaving it set to the feed rate is silly in my opinion. I much prefer to cut in one direction only, but the lack of rapids between these cuts forces me to do it with the zig zag setting in order to at least get something from the time it spends going back the other way. For aluminum in particular, I'd much rather cut in the climb direction exclusively, but really don't like the time being wasted. Even for material like wood or plastic where Zig Zag is OK, I feel the smoothness of the machine operating is better in one way or zig only since it doesn't turn around so hard. I've just submitted a feature request as this has been on my annoyance list for a while. Here's what I've requested:

"Feature request for future versions. I'd like to see a feedrate option for the link clearance move in the adaptive toolpath strategies when set to "one way" or "Zig". The issue is that currently the code produces a move in the air that runs at the feedrate for material removal, but there is no need to run at the same speed when cutting air. Toolpath cut times could likely be reduced by 25% or more if the option to increase feedrate for the "link clearance" move were available. It would be ideal if once you manually check the link clearance checkbox (indicating the users is aware of the settings) there was also a subcategory checkbox to activate a feedrate override for the link clearance move that has a data entry box for the desired feedrate, with a further checkbox to set it to "rapid" instead. The rapid option would just output G0/G1 instead of having to output a F value each time a link clearance move is made."

If you are using any of the other options for Advanced rough, there are just limited times that a rapid movement could be made, so it should be no surprise it doesn't rapid much. Again, you can set it to rapid between groups by using the "retract" setting, etc., but that should only affect the toolpath strategy by a few seconds on the typical job, or not enough that you'll see much real world benefit. My guess is that you are probably using the one way adaptive if you're noticing it should go faster, and I totally agree there.

I have Fusion 360 and while it makes a pretty looking toolpath, I'm not sure it's really a better toolpath. I'll be comparing how they look on actual parts, but my guess is that the practical difference in finish quality will be insignificant. Bobcad is definitely easier to generate and define boundaries off of existing 3d geometry with, and just feels like it has a bit more control over the way the strategies and the model interact. There are a few things in Fusion/HSM works that I'd like to see brought into Bobcad eventually, but there is surprisingly little to tell between them in favor of Fusion. Bobcad has quite a bit that Fusion doesn't have though. I've used many other CAM systems as well, and I still prefer Bobcad for well over 95% of what I do. For the other couple % that are extremely specialized, I have applications with specific traits that do those "one things" really well, and it makes sense to have the right tool for the job in those cases. Bobcad Mill Pro with Bobnest, Bobart, etc. is about the most comprehensive CAM application I've come across, and is still what I recommend to most who need a single CAM application. It's amazing that one application can go from V-Carving to serious 3d mold machining to nesting sheet goods parts, and do so for less than most applications can don only a fraction of that. I'd readily admit that my list of things I want to see added or improved is getting to feel pretty picky.

[SBC Cycle]

"Feature request for future versions. I'd like to see a feedrate option for the link clearance move in the adaptive toolpath strategies when set to "one way" or "Zig". The issue is that currently the code produces a move in the air that runs at the feedrate for material removal, but there is no need to run at the same speed when cutting air. Toolpath cut times could likely be reduced by 25% or more if the option to increase feedrate for the "link clearance" move were available. It would be ideal if once you manually check the link clearance checkbox (indicating the users is aware of the settings) there was also a subcategory checkbox to activate a feedrate override for the link clearance move that has a data entry box for the desired feedrate, with a further checkbox to set it to "rapid" instead. The rapid option would just output G0/G1 instead of having to output a F value each time a link clearance move is made."

Are you interested in trying a post processor script that will do just that? I have ran it successfully on a dozen jobs but I can't use it "everyday" in the production environment. I can only promise it has never crashed my Haas and it does reduce cycle time by 25% or more. If you send me your post processor I will modify it for you if you would report back your results.

It doesn't turn the link clearance to a rapid because I really only thought about increasing the feed inside a pocket where I'm only lifting 0.015" or so. I really can't rapid inside the part because the machine simulation doesn't move the same way my machine does but if yours rapids in a straight line it would really reduce cycle times. Either way, I never thought about going ahead and lifting out of the part and using a rapid. That's an interesting idea that might be faster than a "high feed" link move.

BTW, I agree with your post 100%. I can use much higher feed rates when I'm moving in one direction only and it's better for my tooling and machine. The link is the only thing that slows it down and it drives me a bit bonkers sometimes.

[mmoe]

Are you interested in trying a post processor script that will do just that? I have ran it successfully on a dozen jobs but I can't use it "everyday" in the production environment. I can only promise it has never crashed my Haas and it does reduce cycle time by 25% or more. If you send me your post processor I will modify it for you if you would report back your results.

It doesn't turn the link clearance to a rapid because I really only thought about increasing the feed inside a pocket where I'm only lifting 0.015" or so. I really can't rapid inside the part because the machine simulation doesn't move the same way my machine does but if yours rapids in a straight line it would really reduce cycle times. Either way, I never thought about going ahead and lifting out of the part and using a rapid. That's an interesting idea that might be faster than a "high feed" link move.

BTW, I agree with your post 100%. I can use much higher feed rates when I'm moving in one direction only and it's better for my tooling and machine. The link is the only thing that slows it down and it drives me a bit bonkers sometimes.

Heck yah I'd try that out! Does your machine do those dog leg rapids? I figured there are a lot of those out there, which is why I submitted the feature request with both feedrate override for those link motions and the option to jut go to rapid. Mine just goes from point A to point B in straght lines, no matter what those points are (they could be a 3 axis simultaneous move). Here's the machine simulation files as well as the post processor. My post is pretty simple, but I'll explain a couple things that may have you scratching your head otherwise. First, each head has a work coordinate system since they aren't in the same location. In order to spur Bobcad into generating work coordinates that match up with tool numbers, I used line 240 like this: "240. Amount to add to t to obtain t1?53". This takes the tool number I choose, which I consider the same as the spindle number (spindle 1 is tool 1, spindle 2 is tool 2), and it adds 53 to it to produce G54 for spindle 1 and G55 for spindle 2. If I choose tool 3, this generates G56, which I use to set up both heads operating simultaneously. I also use line 241 like this: "241. Amount to add to t to obtain t2?30". The M code to lower spindle 1 is M31, while spindle 2 is M32 and both heads simultanesous is M33. Between these two lines, I get M31 and G54, M32 and G55, or M33 and G56 to control which heads are used while keeping them linked to their appropriate work coordinates.

When simulating a part, you have to set the work offsets in the machine setup to match the simulator. My machine homes to the top of the Z axis and slightly outside of the work area in X and Y. Since I modeled it to be as close to the real thing as possible, those traits exist in the simulation as well. I typically set the X offset to "15mm", Y offset to "45mm", though any value greater than that will place the stock in the working area of the table if you have the origin set to the lower left. If you have the origin at the middle of the part, it's anyone's guess what those values should be. CNC routers typically home to the corner, not the middle of the work area. For the Z axis work offset, you subtract the stock thickness from 200mm, then make that value negative. So if I have a 50mm thick stock, I subtract that from 200mm to get 150mm, then make it "-150" when I enter it into the offset. This will place the bottom of the stock exactly on the surface of the table. On the real machine, the table varies in position because I plane the sacrificial surface down every week or two to get a fresh table, so in the real world that Z offset varies a bit, but it's usually pretty close to the value in the simulator.

There is also a tool holder that I have not included in the files, but I just don't know how to export it yet and haven't taken time to look into that. The simulation still works fine without.

I'll be very interested to see how the post macro you created works. Sounds like you have a ramp up to your fastest feedrate and then back down to the set feedrate? That would work fine for me as well. My machine doesn't really know the difference between rapid and it's maximum feedrate. It will run 15000mm/min maximum feed and the same for rapids, so either solution is fine at my end. I think my machine definition has the rapids set down to 5000mm/min, but that was to counteract the way it calculates the machine times in the simulator, where it's always way too optimistic. Not sure if that will affect your macro or not, but if it does you can set it back up to 15000mm/min.

I've also found that my simulation is a little slower to get started since the second V26 update (and still in V27). They added some components to the simulation that I have tried messing with, and had some success making it better, but it's still a bit of a mystery what the optimum settings are going to be. Let me know if anything strikes you that could be adjusted to speed things up. I'm pretty sure it's a setting or something in my post (which has not been updated in a while) that may be causing the system to have to think longer about the simulation before it gets going. There are times when a relatively simple Equidistant Offset takes 15 minutes before the simulator is ready to go, where it used to take 15 seconds. Once it's ready to go, it runs about the same as it used to. Just not sure why it's taking so long to get ready to simulate.

Thanks SBC!

[SBC Cycle]

Heck yah I'd try that out! Does your machine do those dog leg rapids? I figured there are a lot of those out there, which is why I submitted the feature request with both feedrate override for those link motions and the option to jut go to rapid. Mine just goes from point A to point B in straght lines, no matter what those points are (they could be a 3 axis simultaneous move). Here's the machine simulation files as well as the post processor. My post is pretty simple, but I'll explain a couple things that may have you scratching your head otherwise. First, each head has a work coordinate system since they aren't in the same location. In order to spur Bobcad into generating work coordinates that match up with tool numbers, I used line 240 like this: "240. Amount to add to t to obtain t1?53". This takes the tool number I choose, which I consider the same as the spindle number (spindle 1 is tool 1, spindle 2 is tool 2), and it adds 53 to it to produce G54 for spindle 1 and G55 for spindle 2. If I choose tool 3, this generates G56, which I use to set up both heads operating simultaneously. I also use line 241 like this: "241. Amount to add to t to obtain t2?30". The M code to lower spindle 1 is M31, while spindle 2 is M32 and both heads simultanesous is M33. Between these two lines, I get M31 and G54, M32 and G55, or M33 and G56 to control which heads are used while keeping them linked to their appropriate work coordinates.

When simulating a part, you have to set the work offsets in the machine setup to match the simulator. My machine homes to the top of the Z axis and slightly outside of the work area in X and Y. Since I modeled it to be as close to the real thing as possible, those traits exist in the simulation as well. I typically set the X offset to "15mm", Y offset to "45mm", though any value greater than that will place the stock in the working area of the table if you have the origin set to the lower left. If you have the origin at the middle of the part, it's anyone's guess what those values should be. CNC routers typically home to the corner, not the middle of the work area. For the Z axis work offset, you subtract the stock thickness from 200mm, then make that value negative. So if I have a 50mm thick stock, I subtract that from 200mm to get 150mm, then make it "-150" when I enter it into the offset. This will place the bottom of the stock exactly on the surface of the table. On the real machine, the table varies in position because I plane the sacrificial surface down every week or two to get a fresh table, so in the real world that Z offset varies a bit, but it's usually pretty close to the value in the simulator.

There is also a tool holder that I have not included in the files, but I just don't know how to export it yet and haven't taken time to look into that. The simulation still works fine without.

I'll be very interested to see how the post macro you created works. Sounds like you have a ramp up to your fastest feedrate and then back down to the set feedrate? That would work fine for me as well. My machine doesn't really know the difference between rapid and it's maximum feedrate. It will run 15000mm/min maximum feed and the same for rapids, so either solution is fine at my end. I think my machine definition has the rapids set down to 5000mm/min, but that was to counteract the way it calculates the machine times in the simulator, where it's always way too optimistic. Not sure if that will affect your macro or not, but if it does you can set it back up to 15000mm/min.

I've also found that my simulation is a little slower to get started since the second V26 update (and still in V27). They added some components to the simulation that I have tried messing with, and had some success making it better, but it's still a bit of a mystery what the optimum settings are going to be. Let me know if anything strikes you that could be adjusted to speed things up. I'm pretty sure it's a setting or something in my post (which has not been updated in a while) that may be causing the system to have to think longer about the simulation before it gets going. There are times when a relatively simple Equidistant Offset takes 15 minutes before the simulator is ready to go, where it used to take 15 seconds. Once it's ready to go, it runs about the same as it used to. Just not sure why it's taking so long to get ready to simulate.

Thanks SBC!

That all makes sense, I recall a lot of what you are describing from your simulation thread. I also have the rapids limited in my simulation to get a little more realistic cycle time, it shouldn't affect anything.

As far as the simulation being slower, it has seemed to be that way for me also but I had wondered if it was my graphics card. The replacement laptop I got from Dell when mine crapped about a year ago came with "Switchable Graphics". When I load Solidworks I know it has switched over to the discrete graphics, you can just tell. I configured the AMD Catalyst software to use the graphics card when BobCAD V26 fires up but it just doesn't seem to run as smooth as I remember - it acts clunky like it would if it was using the Intel HD graphics. I really can't say for sure. Just last night I dug into the BIOS and turned off the Switchable graphics so I KNOW it's running all the time. We'll see if that makes a difference.

[SBC Cycle]

... Sounds like you have a ramp up to your fastest feedrate and then back down to the set feedrate? That would work fine for me as well. My machine doesn't really know the difference between rapid and it's maximum feedrate. It will run 15000mm/min maximum feed and the same for rapids, so either solution is fine at my end....

What it does is run a check at every operation to look for an Advanced Rough/Adaptive Rough feature. Once an Adaptive feature is detected, the script searches for changes in Z height (but only for feed moves). If Z is feeding "up", I assume it is cutting air and I override the feed (it could be maxed out, double, or you can type one in). The moment the Z starts making a downward feed move, I revert the feed back to what it was originally.

It increases the post time a bit but not nearly as long as sitting there watching the machine cut air at a slow feed rate.

[SBC Cycle]

I'm using 3D advanced roughing and the Mach3-NoATC_mill post as that was the only one that was loaded in with the installation. now I see that there are others to be downloaded which I will try, Do you know of one that works better than the others?

Also, Bobcad tech support edited a post for me that would override the rapids to whatever I put in, so i'll give that one a try over the weekend

So far I love the software, seems it has come quite a ways since a few years ago. I remember people bad mouthing it all the time years ago. Showed it to a few guys at work and they're ready to dump Mastercam for it.

It sounds like you have your problem solved (I wouldn't have thought it was a post issue so kudos to you for being on the right path) but I wanted to make sure that if you were using the 3D Advanced Rough that you knew about the "Rapid Retract for Large Gap" option in the Links tab of the wizard. Without it checked, just about everything happens at cutting feed rate.

Glad you're having a good experience with it so far and you are at the right place for help!