584,814 active members*
5,148 visitors online*
Register for free
Login
IndustryArena Forum > CAM Software > BobCad-Cam > Rapid Feed Rates ?
Page 1 of 2 12
Results 1 to 20 of 21
  1. #1
    Join Date
    Apr 2014
    Posts
    108

    Rapid Feed Rates ?

    well, I'm new to Bobcad,, actually Bobcam for Solidworks V4 and I actually love it, not quite as good as HSMworks but HSM is just too much money and Bobcam is a excellent deal.

    Only problem I have with it is the lck of documentation , tech support does reply very quickly but their answers are vague

    So, my question is. How do I preserve my rapid feed rates? I know they are controlled in Mach3 but, it must be Bobcam's post processor that overrides these rapid rates. Considering I've used HSMworks, Fusion 360, Surfcam and Mastercam and never had this problem the only one factor that has changed is that I'm using Bobcam now

    Thanks in advance
    Kyle

  2. #2
    Join Date
    Feb 2011
    Posts
    212

    Re: Rapid Feed Rates ?

    I know when I program things at work If the feed rate is the same or higher than the rapid it will all become rapids .

  3. #3
    Join Date
    Apr 2014
    Posts
    108

    Re: Rapid Feed Rates ?

    Quote Originally Posted by LEARN View Post
    I know when I program things at work If the feed rate is the same or higher than the rapid it will all become rapids .
    mine is taking on the cutting and plunge feed rates, which are about 15-30 in/min compared to the 100in rapids I used to have. I had a copy guys at work look at the posts and they said the post looks correct, but it certainly isn't . Kind of confusing why it's happening, could be something in Mach3 but it was fine with all the other softwares and I'm using the post from Bobcad that is written for Mach3, which they are partners with so I would like to think that it would be correct...

    If I go and manually delete all the feed rates out of the g-code, then I get my z rapids back but my linear rapids are still stuck at the cutting feed rates

  4. #4
    Join Date
    Feb 2011
    Posts
    212

    Re: Rapid Feed Rates ?

    Ok gotcha .

  5. #5
    Join Date
    Apr 2008
    Posts
    1577

    Re: Rapid Feed Rates ?

    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.

  6. #6
    Join Date
    Apr 2014
    Posts
    108

    Re: Rapid Feed Rates ?

    Quote Originally Posted by SBC Cycle View Post
    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.

  7. #7
    Join Date
    Sep 2012
    Posts
    1195

    Re: Rapid Feed Rates ?

    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.

  8. #8
    Join Date
    Apr 2009
    Posts
    3376

    Re: Rapid Feed Rates ?

    As Burr has said "Careful what you wish for"

    I can think of reasons that feature request is not that important too!!!

    Adds more money to cost of software
    Adds another level of complexity to learn the software
    Adds a little more "clunkyness" to the software

    Will it add value to the masses?????

    Not disagreeing totally with you,,,but I seen the software evolve for enough years,these above points come to mind.
    I've heard,I don't actually know,,,that the biggest problem with Mastercam is that it can do anything,but figuring and learning how is hard because of so much it can do.Also costs a fortune.

  9. #9
    Join Date
    Apr 2014
    Posts
    108

    Re: Rapid Feed Rates ?

    problem solved

    downloaded all the mach3 posts and tired mach3-mill-noatc_rev2 post and all is good now

    Thank you all for your help

  10. #10
    Join Date
    Sep 2012
    Posts
    1195

    Re: Rapid Feed Rates ?

    Quote Originally Posted by jrmach View Post
    As Burr has said "Careful what you wish for"

    I can think of reasons that feature request is not that important too!!!

    Adds more money to cost of software
    Adds another level of complexity to learn the software
    Adds a little more "clunkyness" to the software

    Will it add value to the masses?????

    Not disagreeing totally with you,,,but I seen the software evolve for enough years,these above points come to mind.
    I've heard,I don't actually know,,,that the biggest problem with Mastercam is that it can do anything,but figuring and learning how is hard because of so much it can do.Also costs a fortune.
    They have always exceeded my hopes for change since V24, and I never cease to be amazed by what they manage to fit into their development path. One of my biggest wishes was for the dynamic mouse zoom, and I remember Burr suggesting that they would/could never afford to spend the development time on something trivial like that when it could be spent developing toolpath strategies. Yet, look at what they did in V27! They added the dynamic zoom while also adding significant improvements to parallel finishing, equidistant offset (have you tried the new "spiral" method?), and many of the other features while also introducing new ways to work on the CAD side. My opinion is that Bobcad's development team has some serious kung fu and I'm starting to think you can ask for the moon with them and they'd try to deliver.

    Even as much as Bobcad has grown, I paid more for V21 (which could only do parallel and Z level 3d toolpaths) than I did for V26 Mill Pro. I have faith that they will continue to offer an excellent product for an equally excellent value. Since this improvement is addressed specifically at Mill Pro, those who stick with Mill Standard wouldn't even know it changed and it would not affect the complexity for those who only use the basic functions. For those who know the system well, it wouldn't be any more or less trouble to use, and I'm positive that it would drastically reduce cycle times for one-way adaptive toolpaths. Sounds like it got forwarded to the development team.

  11. #11
    Join Date
    Apr 2009
    Posts
    3376

    Re: Rapid Feed Rates ?

    Well,I WISH
    that the Multi-Level tool paths were included in Mill Pro.I think you should not have to buy 4th axis to obtain those paths.
    that's it !!!! that's all !!!

  12. #12
    Join Date
    Sep 2012
    Posts
    1195

    Re: Rapid Feed Rates ?

    Quote Originally Posted by jrmach View Post
    Well,I WISH
    that the Multi-Level tool paths were included in Mill Pro.I think you should not have to buy 4th axis to obtain those paths.
    that's it !!!! that's all !!!
    Are you wanting the morphing toolpaths? V27 has taken steps that are much closer with the new parameters in Equidistant Offset, but it would be nice to have those multiaxis strategies for a little less than the 4 axis Mill Pro runs, with the idea that they somehow lock the strategies to 3 axis only. I'm getting to know the limits of Equidistant Offset though, and you can get pretty close on most parts. There are some aspects of the multiaxis strategies that are sometimes in the way of getting what you need, while Equidistant Offset often doesn't have problems with the same part. If you were worried about complicated toolpath options, multiaxis is where you really get into some difficult stuff to understand!

  13. #13
    Join Date
    Apr 2008
    Posts
    1577

    Re: Rapid Feed Rates ?

    Quote Originally Posted by cadguy247 View Post
    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!

  14. #14
    Join Date
    Apr 2008
    Posts
    1577

    Re: Rapid Feed Rates ?

    Quote Originally Posted by mmoe View Post
    "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.

  15. #15
    Join Date
    Sep 2012
    Posts
    1195

    Re: Rapid Feed Rates ?

    Quote Originally Posted by SBC Cycle View Post
    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!

  16. #16
    Join Date
    Apr 2009
    Posts
    3376

    Re: Rapid Feed Rates ?

    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.

    Holy Crud !!!!!
    Can you share such a file and see if the rest of us get that same result ?

  17. #17
    Join Date
    Sep 2012
    Posts
    1195

    Re: Rapid Feed Rates ?

    Quote Originally Posted by jrmach View Post
    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.

    Holy Crud !!!!!
    Can you share such a file and see if the rest of us get that same result ?
    In more playing around, I'm thinking that the tolerance setting is where my problems are coming from. I've gone to a tighter tolerance setting over the last few months, more and more. Even though the toolpaths aren't that substantial, I think the simulation must run calculations in a similar manner to when the toolpath is calculated. As the tolerance gets tighter, those calculations get more complex. I don't really need the tolerances as high as I've set them, but I've found that the precision that Equidistant Offset will follow the edge of a part goes up considerably when the tolerance are tighter. After offseting the toolpath 100 times, the quality of the shape of the toolpath is better with tighter tolerances, which is just as important to me as how far apart the steps are. I'll see if I can post a comparison as to why I set the tolerances higher, but it's generally so that the toolpath runs along the surface paths better resulting in fewer areas where the toolpath needs to raise and rapid to a new position. In other words, it stays on the surface better and links better when the tolerances are higher. The main area I find this helps is when running the tool around the edges of a 3d/shapely part to create a 3d roundover.

  18. #18
    Join Date
    Apr 2008
    Posts
    1577

    Re: Rapid Feed Rates ?

    Quote Originally Posted by mmoe View Post
    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.

  19. #19
    Join Date
    Apr 2008
    Posts
    1577

    Re: Rapid Feed Rates ?

    Quote Originally Posted by mmoe View Post
    ... 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.

  20. #20
    Join Date
    Apr 2008
    Posts
    1577

    Re: Rapid Feed Rates ?

    I still can't get rid of redundant feed rates, hope that won't be a problem for you.

    The "lift" speed and the "High Speed" feed are set in Program Block 55. I didn't get fancy with it, just set it at 5000 for the lift and 15000 for the HS (choose what is comfortable for you). It won't adjust automatically between IPM and mm/min. We could do that but it's not necessary unless this becomes useful (and works). We could also adjust the Lift and HS move with an Advanced Posting page in the feature but let's just see if it works first!

    Ramp down is always done at "normal" feed rate for safety.

    Thanks for testing.
    Attached Files Attached Files

Page 1 of 2 12

Similar Threads

  1. HAAS Interpolated Rapid Moves and Feed Rates
    By aspurge in forum Haas Mills
    Replies: 0
    Last Post: 07-31-2014, 12:42 PM
  2. cutter leaving feed lines at high feed rates-walter prototyp end mill
    By shimmwagen in forum DNC Problems and Solutions
    Replies: 9
    Last Post: 02-07-2014, 11:44 PM
  3. Replies: 0
    Last Post: 01-23-2014, 08:54 PM
  4. Rapid Feed Rates
    By creativecad in forum Mastercam
    Replies: 3
    Last Post: 08-18-2009, 01:13 AM
  5. BRIDGEPORT RAPID/FEED RATES OVERIDE
    By 99bluemoon in forum Bridgeport / Hardinge Mills
    Replies: 0
    Last Post: 02-07-2008, 06:18 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •