G112 Fanuc

0 views
Skip to first unread message

Kathy Douds

unread,
Aug 4, 2024, 8:33:23 PM8/4/24
to gensdogmonsle
Ive been working on creating custom post processors for lathes in our shop. I have started with the a PUMA 240 with fanuc control on it. So far I have been very surprised at how methodical the existing posts have been layed out and the number of functions availible.

I am however getting a bit overwhelmed with the XC milling. I seem to be able to get it to post using X diameter and a C angle ( polar cordinates) but I would really much prefer the use the G112 X C polar interpilation using cartesian cordinates. This style would be much prefered as it would alow the use of the G41 radius wear compesation which is used quite extensivly throughout the day as the machines heat up and tolerances drift. As well it allows the controller the interpolate the code so we dont need massive blocks of linear movements in the code.


As well I have attached my work in progress post. It is built off of a the HAAS XZC post. I have been using the ACTION XC-AXIS ENABLE custom parameter for forcing the change of the var useXZCMode and var usePolarMode.


I see what you mean about the R value. As it appears that I am already sitting at retract plane when it is called. If you find what you did before and can let me know that would be great! Im a bit confused oh how you would tackle that having the extra feed plane involved.


Actually the code you used is correct. For some reason I had the idea we used cycle.stock. But the R-value on this machine isn't the retract plane so to speak. The "retractplane" has gone lost. What happens now is that it goes to the cycle clearance. From there it goes to the incremental R-plane which is the feed plane you set on the CAM Side.


Now this could be my own fault, and if so I can start a new thread on it. I did have to remove the G53 moves, replace with G28U/W moves, and insert an M28 (C-axis) and G28 H0. but I can't imagine those actually screwed it up.


Fortunately unfortunately there are certain things I haven't been able to test on the post as the machine has been very busy with a couple tight lead time jobs this past week so I'm glad someone else is able to help test this. I did some quick air cutting on the machine last week and came up with a few problems with the post in regards to live tooling, cross drilling and cross tapping. When it was milling a contour in the air it all looked fine, however perhaps that's not the case.


Dealing with all the drilling cycle syntax seems all very trivial now that I see the post cant mill a hex. I hope to be able to run a test cut on our machine in the next couple of days between setups to confirm I would have the same result.


When the Y that is generated for the original Haas post is changed to C it needs to be cut in half (changed to radius). Unfortunately its not as easy as just formatting it with scale0.5 because then the radius doesn't line up correctly. However if all the new C values and all the R values are cut in half it seems to make a good toolpath.


If someone with more understanding of the way the path section of the post processor is generated would have time to amend these changes to my Puma June 6 post that would be a huge help. Otherwise I will have to take a stab at this tomorrows.


So I modified the setPolarMode function to apply these changes and the toolpath now looks correct in the Cimco backplot. I haven't tested on machine. If someone has time to try it that would be great otherwise It may be a little while before our machine is free.


In theory I dont belive the large negative X numbers shoulding make difference because your machine will do all the milling on the top side and be interpolating those values. I was able to reproduce your issue and then fix it with changing the scale factors. I then did a couple more parts and they seemed on size (in simulation).

3a8082e126
Reply all
Reply to author
Forward
0 new messages