Tool Check With G91 Moves <resolved>

[mrichards]

Hi,
I have had an issue where the TOOL CHECK button does not behave as expected. I realized that it was only when running intercon generated files.
Examining the G-code, it appears that intercon's rectangular pocket function generates G91 incremental moves.
It appears that hitting CYCLE START just re-starts from the previous line, but the control "forgets" where it was in Z and just carries on generating incremental moves from the tool check position, so I end up cutting air.

Coming from Mach 3/4, I vaguely remember that on a "run from here" resume, Mach would parse the G-code from the start to deal with this situation, but I could be wrong as I very rarely use G91 moves.

Am I mis-understanding how to use the resume function? What's the best way to deal with this (other than avoiding incremental moves) ?

G-code attached.

Thanks.

[Sword]

Hmm, this may be related to something that happened to me today. I did a tool check mainly to raise up from a cut and then upon cycle start to resume, I cycle canceled before it had a chance to come back down, because I decided to check the file for something that thought I forgot to do. Upon restarting the file after checking, it plunged way past the original Z zero. I stopped it and re-zeroed the Z axis and started over again and it was fine. Noted that I needed to check/test the situation, but didn't take the time to today.

[Dan M]

Hmm, this may be related to something that happened to me today. I did a tool check mainly to raise up from a cut and then upon cycle start to resume, I cycle canceled before it had a chance to come back down, because I decided to check the file for something that thought I forgot to do. Upon restarting the file after checking, it plunged way past the original Z zero. I stopped it and re-zeroed the Z axis and started over again and it was fine. Noted that I needed to check/test the situation, but didn't take the time to today.

I've had the same thing happen before using the tool check. It seems like it lost the z0 location happened twice and I just figured I did something wrong with resuming the job. Now I'm scared to use the tool check. I would also like to know how I should do it if I ever need to "pause" a program and restart it. I haven't tried doing it again since it buried the spindle in my work piece. I almost wondered if it had something to do with the m6 macro, but I have no idea since I never tried stopping and resuming in the middle of a program before. I honestly haven't tried to reproduce what happened since I don't want to mess up anything. When it happened I didn't catch it right away because of the dust shoe and didn't notice until it started smoking.

Dan

[cncsnw]

By design, both Run->Resume and Run->Search are supposed to process all preceding lines in the program, so that the control knows where the axes should be and what modals are in effect.

The question it is asking / answering is, "if we start the job now, from the beginning, from here, where will we be and what will we be doing when we get to line NNN?"

As such, G91 incremental moves should not be a problem, so long as they are preceded, somewhere earlier in the program, by absolute moves.

If a program uses exclusively incremental moves on one or more axes, then the Resume or Search results (like the results of running it normally from the beginning) will vary depending on where the axes are when you start.

Assuming your programs do use G90 absolute moves on all axes prior to the incremental section (as the posted example does, and as Intercon program nearly always do), then there should be no problem using Resume or Search to begin in the middle of a Pocket or Frame cycle with incremental moves.

If your results are otherwise, then this is a recently-hatched bug which needs to be fixed.

[cncsnw]

For what it's worth, if you have a custom tool-change macro that incorporates a touch-off procedure, then that could throw a wrench into the works, by modifying the Z axis part zero or tool length offset based on current Z position, without actually touching off.

If you have such a macro, you need to ensure (by testing system variables #4201 and #4202) that any code which modifies the part zero location or tool offsets is skipped over when processing in a Search mode, and also when viewing the graphic preview.

[mrichards]

I have attached the current report and the intercon file.
I'm running the latest mfunc6FixedToolTouchOff.mac file from the forum. I made the following changes to the macro:
-Modified toolchange positions from G28 to G30P3
-Changed #106 to 3 sec.

[mrichards]

I may have found the issue:
Intercon created the following line in the G-code:
G43 D99

G43 is tool length comp, but the argument is D99, which is the tool diameter, (in my case 1.5").
Shouldn't that be H99 (in my case that's 0.0)?

That would put me 1.5" over the work surface.

[cncsnw]

The H99 code is a couple lines down, so that it takes effect with the first Z axis move.

There is nothing wrong with that part of the G codes, even if it does seem strange at first to see the D value on the same line as G43.

I don't immediately see anything in your M6 macro that should cause problems with Run -> Resume, but I suggest temporarily removing the custom M6 (delete or rename the mfunc6.mac file), then seeing if you still have problems searching or resuming within the rectangular pocket cycle.

[mrichards]

Did some more testing today, and re-run the file, I can't reproduce the problem, I don't think there ever was one.
I believe that I did a tool check right at the beginning of one of the long cuts. Upon resume the cutter runs the length of this cut in the air before reversing and ramping back into the work. I had the FRO down around 60%, so that move in the air takes 30 sec. or so. I think I mistook that setup move for a cut move. Had I been patient, it would have been fine.
I still don't understand the G43 D99 line in the code, but it does not appear to be a problem, at least in my situation where not using fixed length tooling.
Sorry for the false alarm.