Tool Length Offset setting for tools exceeding quill travel

[CRM]

I did a Centroid conversion on a Trak DPM bed mill I bought for my home shop. I program on GibbsCAM, and use the same post processor we developed for the Haas VF-3 SSYT at work with no problems.
A couple years ago, my employer purchased a new Clausing knee mill equipped with a Fagor 8055 control. They claimed that they too could sum Z (quill) and W (knee) axes, like the Centroid I was familiar with. This was important to us, since we regularly need to use a variety of tools on jobs that vary in length nearly as much or greater than the available CNC controlled quill travel. Long story short, it didn't perform as advertised and the operator interface was not nearly as user friendly as what I was accustomed to on my Centroid equipped home mill. So, on my suggestion, we had Granite Controls out of South Dakota retrofit a Centroid control in place of the Fagor, reusing the servo amps and drive motors.

Although the post processor for the Haas VF-3 SSYT at my employer works just fine to output code for my Trak DPM bed mill conversion at home; it gives Z axis overtravel alarms near constantly on the knee mill at work running the same Centroid control configured for Z/W axis summing. Always happens at the beginning of a program or during tool changes (manual, no ATC). I was hampered by the fact we don't have a lot of spare time at work to tweak outputted g-code or mess with parameters, then run tests to see if it changes the behavior. Granite Controls hasn't been the most helpful either, so we are left with a machine we all avoid because it takes so long to try to get programs we generate with GibbsCAM to work on it.

Recently, because I am working on installing a rotary axis on my home mill, I stumbled upon Centroid's YouTube channel and video explaining TLO procedures and the use of "Reference Tool", along with CNCSNW's page graphically showing how Centroid calculates TLO along with his writeup of post processor development "rules".
Those post processor "rules" will hopefully help me understand what to tell GibbsCAM what to modify in the post to get code that runs without generating alarms. I'm sure it has to do with how we are setting TLO and the fact that we are limited to such short Z axis CNC control. I thought the axis summing would have handled that issue. Your graphic explanation of TLO and the use of "Reference Tool" along with Centroid's YouTube video on the same are helping me understand how all that is being calculated by the control. BUT, what do you do if the length change from your shortest tool to your longest tool exceeds the quill travel and you MUST reposition the knee during the program?

[cncsnw]

I would have to find a machine equipped in that manner to test with, or set up some type of benchtop simulation, before I could make any conclusions.

It might be as simple as adding a "IF #50001" line to a custom M6 macro, so that CNC12 does not read farther into the CNC job beyond the tool change until after you have cranked the knee up or down. For example, a custom M6 macro (mfunc6.mac) to do a normal manual tool change, without parsing ahead until the tool change is complete, could look like this:

Code: Select all

; M6 - manual tool change
M6         ; do default action
IF #50001  ; wait for execution to reach this point before parsing further

[CRM]

looks like I'll have to find time to learn how to write macros...

[xr4x4ti]

I maybe have a similar issue on my DPM, that once I realized what was happening I worked around it.

Basically, I have the quill and the head summed like you are talking about. If I power up the machine and home it with the quill not at the very top of its travel and then move the quill up and try to run a program, it will say that there is an error and you will exceed the Z travel.

Like I said, I addressed the issue by always making sure the quill is all the up when I home the machine.

Is there a way to fix this in the PLC?

I don't mean to hijack the thread, I think these to issues are related.

[CRM]

I'm sure the issues are similar, and share a root cause. CNCSNW provides a key piece of information regarding the "look-ahead" of the parser. I think the control "sees" the next move after a tool change (but before the operator has a chance to reposition the knee) and throws an overtravel alarm.
I wish Centroid would commit to configuring a mill like this and do some real-world lab testing with tool length variances that exceed quill travel to work the bugs out. Especially since they have videos for the ALLIN1DC specifically mentioning axis summing in a knee mill scenario.

[cncsnw]

Another key point is to make sure you have a negative value for Parameter 75, so that scale summing is only applied in local coordinates.

With a positive value in Parameter 75, moving the knee will invalidate the quill travel limits.