Hi, I think there's a small bug in the drilling function of Fusion360 CAM. The toolpath that is displayed and simulated is different from what is written to the G-code. Have a look at the images please. The bug can be corrected by setting the "Top height" to "Stock Top". Then, the simulated path and the real path seem to be the same.
remaining images...:
It is really easy to forget to change the "Top Height" to "Stock Top", and then, after 1 hour of machining, the part is ruined with the last move of the machine... X-)
Can you share a link to the file and what post are you using.
Mark
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Sure,
here's a minimal example:
I was using wincnc.cps. But I don't think that this is relevant because the g-code output is correct. Only the simulation and the displayed toolpaths in Fusion360 are incorrect.
On my machine the code does run and look the same as the simulation. Here's my code.
There is a rapid to Z5 then the drill cycle moves down 45mm then returns back up to Z+5 and moves to the next hole. The drill cycle is not really correct though as the P01 -45 is a move to the top of the hole and the depth is zero, but that is just because you haven't set the planes correctly. Is the code in your screen shot good or bad? It could be your post or machine doesn't like the -45mm move.
Mark
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
If you look at the last image Willa1980 attached you can see a slot across the job where the cutter hasn't returned to the clearance level. Either his control or post is not doing what's shown in the simulation. Still all down to not setting up the op correctly though.
Mark.
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
If you look at his drill cycle there's a Z-28.3 then R-23.3 i think that might be the problem. If changing the R-23.3 to R5 works it's probably something in the post.
Mark
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Hi,
yes the problem is the "Z-28.3" and then the "R-23.3": The origin is on top of my box and I want to drill 28.3mm into it. The post uses the G81 command, to move the drill towards z=-28.3mm. The retract height is set to 5mm above this height (=-23.3mm) in Fusion360. So the g-code is correct (although not usable, because it destroys the part). But the problem is that this part destruction is not shown in Fusion. Fusion shows that the drill would retract to 5mm above the stock (=+5mm) both in the simulation and also in the toolpath. This is (in my opinion) not how it should be.
Thanks,
William
Willa1980-
This is probably not related at all, but I'll mention it anyway. I recently had a problem with drilling operations on my machine also. In my case, the tool was moving directly to the bottom of a drill hole (taking a sideways diagonal downward path) and then lifting up and performing the drill operation as it should. To fix it I had to activate a drill cycle patch in the interface software for my machine. (I think it is a fix for a firmware bug in the controller). I had know idea it was there till the mfg told me. I'm running a techno LC4896
The problem is in the post processor, it is not dealing with the way you have the drill cycle set up. You could modify the post to allow for the way you are trying to use the drill cycle but that might cause other problems. At the moment you have the total depth set to the point selected and the top of the hole at the same height and the post is not dealing with that. If you set the Hole top to 23.3 (The depth of the hole you want to drill) it will work. The examples in the help file have the point at the top of the part and you enter the depth of the hole by the way.
Mark.
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
@Willa1980 wrote:remaining images...:
It is really easy to forget to change the "Top Height" to "Stock Top", and then, after 1 hour of machining, the part is ruined with the last move of the machine... X-)
One tip, once you have "Drilling" setup how you like you can us Make Default so Top of stock is the default setting.
Mark.
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
If I read everything correctly, the 'bug' doesn't appear to be in the drill cycle, post or machine, but in the simulation engine. With a retract height set at -23.5, the R value should also be -23.5; hence, the machine did exactly as it was instructed. If the retract height had been set to +5.0mm, presumably all would have been fine.
What does appear to be happening is that the simulation engine is using the 'clearance height' when showing moves between features. William, if you changed your retract height to 5.0mm does the simulation look the same?
The other possibility is this has something to do with G98 vs.G99 and how the simulation engine is treating the drill cycle. Don't know what controller is involved here, but on our machines with G98 in force the drill would have cleared the part; G99 would have resulted in the same gouge.
Fred
I think the post is wrong and only moving the drill up 5mm from the total depth, the post for my machine works correctly (it matches the simulation). Because the point selected is at the bottom of the part and the hole depth is also the bottom of the part so in effect zero depth the post is getting it wrong. I think whoever wrote the post didn't anticipate someone setting up the drill cycle this way.
Mark.
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
@Willa1980 wrote:Sure,
here's a minimal example:
I was using wincnc.cps. But I don't think that this is relevant because the g-code output is correct. Only the simulation and the displayed toolpaths in Fusion360 are incorrect.
Sorry I was being a bit slow understanding what you were saying about the g code being correct. The confusion here is the simulation is assuming the drill is returned to the retract height after each hole and the person writing the post needs to make sure it is. If you use dump.cps you get the raw data for the cycle like this.
My control always returns to the retract height so there's no problem but as your control doesn't the post should use cycle.clearance instead of cycle.retract then it will look like the simulation.
Mark.
Mark Hughes
Owner, Hughes Tooling
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Mark,
Point taken...I should have expreimented further. None of my posts will allow a negative number for the R value regardless of where I set the Retract Plane. Thanks.
Fred
Can't find what you're looking for? Ask the community or share your knowledge.