[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.