Fusion360 postprocessor for linuxcnc lathe with tailstock axis in Z Direction

More
02 Feb 2025 09:31 #320398 by Tim_cnc
Good morning everyone,

I've ran into some problems generating gcode for my linuxcnc lathe.

The lathe has following geometry:
XZ-lathe with turn-tooling on a revolver on the XZ-stack (Spindle rotates around Z)
Tailstock with drill-tooling on a revolver on a axis parallel to Z but named Y so i can use G33.1

This setup works perfectly fine for me if programmed by hand. My only problem is the CAM-programming with Fusion360. Everything works fine besides the drilling operations. The Fusion post spits out the Toolpath with the letter Z instead of the needed Y for drilling-cycles. I was unable to change this behaviour in the linuxcncturn-post.
Does anyone know a workflow or a fix to this problem? After a lot of research surprisingly few people even have a tailstock axis on their cnc lathe?

Thanks for your suggestions
Tim
Attachments:

Please Log in or Create an account to join the conversation.

More
09 Feb 2025 18:02 #321077 by andypugh
I don't think that I have ever seen a motorised tailstock for drilling. Every example that I have seen used toolpost-mounted drills for feed-per-rev drilling.

Fusion probably can't be persuaded to use Y as it won't believe that Y can be parallel to Z. You _might_ have more luck with the tailstock axis as W (supplementary axis parallel to Z)

That said, the postprocessor is just Java, I would have thought that it was possible to make anything happen in there for specific G-codes.

Please Log in or Create an account to join the conversation.

More
16 Feb 2025 20:53 #321767 by Tim_cnc
Thanks a lot for your answer. Sorry for replying so late.
I really find it quite remarkable that noone tries to drill with a tailstock axis!

I ran into the problem, that the used functions in the linuxcnc-turn post aren't well documented at all and at the same time use quite old standarts. I didn't found a way to change the axis-letter for G0 commands. I could change the axis-letter of the drilling-cycle itself but then still have to approch-move and rapids on the wrong axis-letter. Because the rapids are all handeled the same way, it would affect all gcode-moves if the letter is changed. Also this post doesn't support custom geometry.
I also did not find a way to make it work with W. Also i use rigid-tapping on this axis and thus cannot usw the axis as W(W doesn't support spindle-synchronous-moves).
In a nutshell I just need the information parsed to the post from the cam to include the right axis in the first place. But I am also open to any other ideas!

Best regards Tim

Please Log in or Create an account to join the conversation.

Time to create page: 0.085 seconds
Powered by Kunena Forum