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