OK, so it seems there is some confusion over tool length compensation and tool offset and wear adjustment. I didn't know there was a difference between 'tool length compensation' and 'tool offset'! Anyways, my machine has only a set of 128 offset (labelled 'length' from memory), length wear, diameter and diameter wear settings.
The offset applied by H is the tool length/offset + the length/offset wear. For the purpose of this conversation, I am only talking about tool length offset. I am not talking about any sort of diameter or automatic tool shape compensation or wear correction. Just the tool length offset applied by H.
When I use tool length offset (G43 Zx Hx) it works exactly as expected for everything in XY plane (G17). It also works as expected for the start and end point of an arc in G18, it does not work for the center point of the arc, causing an impossible arc.
I have not spent any more time playing with this on the machine recently as have spent the last while removing a broken tap from one of the spindle drive lug bolts. It was a gift with the machine, M3 tap broken flush that had to be drilled out from below! Got it out last night without even scratching the thread...
Also, I am waiting for the manual before doing much more...
Yep, keen to get that manual. I had another surprise tonight where I found out that a G53 uses tool length offset! All the other manuals I have read say that a G53 will cancel tool length offset. The program I was running has a G53 Z0 after each operation. This causes a Z axis soft limit. I changed them to G49 G53 Z0 and all was good. So, yeah, really want that manual to start understanding this machine better.
double post
Last edited by Superman; 10-17-2020 at 06:31 AM.
I may be in error..
I pictured a G3 being a CCW move putting the centre on z0 plane... your pic shows a CW arc with centre below the start point
Arc sweep direction is when viewed from the plus side of the of the third axis ie... XZ so view from Y+ side.
G53 is to "single shot" use the machine co-ord system. Which cannot be moved. I suppose you could have active compensations show thru on all work co-ord systems.
I am not a machinist or g-code expert, but we have a huge Quickmill that does the same thing when we use the right angle head. We found out the hard way we need to program in a safe move in the different planes because the right angle head offsets are not used until after the first move. Could this be the problem?
So... the manual turned up for my machine. Quite a comprehensive manual about everything except g code programming. A huge section on what all the buttons do and a huge section on macro programming (disabled option on my machine) and about 10 pages on g code. Oh well, it was a gamble I guess. The pages relevant to this discussion are attached. There is no mention of tool offset behavior for arcs or different planes at all. Just that "The program designated ending point of Z axial movement can be shifted through the previously set offset dimension in the positive or negative direction".
The manual did answer some questions like what my mystery buttons do, why a G83 drill cycle was repeated multiple times (K means number of repeats) and confirmed that only a Tx command is required for a tool change (i.e. a tool preselection generated by the post processor would cause a tool change).
So, unless the local Mazak tech can find time to look at it for me, I am out of options. So far the consensus from everyone I have spoken to except this forum is that there is some sort of software bug in this machine.
So far the consensus from everyone I have spoken to except this forum is that there is some sort of software bug in this machine.
It may not be an actual 'bug'. It may simply be a limitation of the hardware controller.
Very old CNCs had these great big PCB boards with hundreds of chips, just to do the most basic control. In effect, although they did not think of it that way back then, they were trying to build a limited-function CPU. Trouble is, some functions were just too complex for the hardware. I seem to recall that on some machines you had to pay extra for an extra PCB to implement the g2/g3 commands.
All this has been rendered obsolete by the use of a PC as the controller. It could be running Mach3, Mach4, UCCNC, LinuxCNC or several other PC-based programs. The huge difference is that with a modern PC, it is no trouble at all to have the SW run 6 axes synchronously. It's just software, running on a 3 GHz processor with 6 GBytes of memory!
We do have a similar problem with some of the external pulse engines from China. They try to emulate an ESS, but they miss out on certain g-code instructions. Probing is a notorious example.
Cheers
Roger
So it is just like any other standard control which I was saying before, what you where trying to do is not standard programing and your control can not do what you wanted to do, there are some ways to do some creative programing to make it follow the path you want, but just for an exercise that is an unpractical move it is not worth the trouble
So for the basic arc you need to use I & J value with no K or you could try the R value if the control supports it
Mactec54
See that is where the disagreement is. Everybody else and all my testing says that any standard controller should be able to perform this operation.
My controller does support R but it does the exact same thing as using I/J and K. The actual problem is that the arc end point is Z compensated for tool length, but the center point is not.
Haha, yeah I have seen one of those old hardware based controllers. This controller is not that bad. It runs on an Intel 486 CPU. It can do some of the more complex operations like helix milling, rigid tapping etc. It can perform arcs in every plane, but just forgets to correct the arc center if tool length offset is used when performing an arc in G18/G19 planes. I also have a mach 3 based router which I have a love/hate relationship with!
Mactec54