[Moggot]

Alright, so here's something I can't find a straight answer to;

I make a tiny little plastic part that has a 0-80 tapped hole in it. Normally I tap these by hand but now I need to ramp up and make a lot of these parts. About 500 at a time from a 6x12x.25 delrin sheet (did I mention they're tiny?).

I have the auto-reversing tapping head sold by Tormach. I understand how to calculate proper feed rates down, how to double them during retract, etc. It works just fine with hand written code.

My normal work flow is to generate tool paths in HSMexpress, pattern those in HSM to fill the stock, post and off we go. It works great. From time to time I adjust the array to suite variances in stock or what have you, so HSM's ability to crank out code in response to those changes is awesome.

What I am faced with now is how do I come up with code to tap 500+ holes in one program. In theory I could spend a week copy/pasting code and inserting the hole coordinates off a table. But that sucks because it'll take me forever and I'd have to redo it if the array spacing/size ever changes. 'Hand coding' is really not an option here. What I'd like to do is find a way to generate the tapping code in HSM, and then array that just like any other op.

In perusing the 'manual' that came with the head, it mentions you can run it using G85, a canned boreing cycle. HSM will happily spit out a G85 cycle, but my understanding of G85 is that it will feed down at a specified rate and then retract at the exact same rate.

The documentation that comes with the tapping head states that the head will compensate for the 2x speed difference when using G85. I don't really understand what they mean, and it doesn't elaborate on the subject. Could the tapping head somehow 'slip' to allow for the slower retract speed? It seems unlikely, particularly as this is a 0-80 tap in plastic; even if the clutch can slip surely it won't do so with threads as weak as this. There's surprisingly little information about G85 out there, and seemingly nothing about using the tapping head with anything but hand written code for a handful of holes per program.

There doesn't seem to be a canned cycle that will do what the procunier needs; retract at 200% feed. So it seems my options are essentially to either hand code 500+ tapping cycles (oh hell no), learn the arcane methods of calling subroutines (maybe?), or futz with pathpilot to reduce the Z axis rapid speed to something that is twice whatever I want to feed the tap at, and then use a normal drill cycle (seems skeevy even to me).

Anyone got any good ideas?

[SCzEngrgGroup]

My modifying the HSMXpress POST, you can ANY cycle do whatever you want it to...

Regards,
Ray L.

[popspipes]

Sprutcam has a transform function that would do this, I set up the first part, set the ops wanted and go to the transform function, enter the number of pieces and the cordinates and go.

Maybe HSM would have something similar??

[Hirudin]

Are the holes in a grid? If so, you could try out my array macro. I posted it in a recent thread: http://www.cnczone.com/forums/tormac...etter-way.html . I won't post it again here as I get the impression that nobody tried it or maybe they know a better way (perhaps the macro is needlessly complicated, but it will work with any code, which is nice). I just tried HSMWorks' "Make Pattern" function. That will kinda do the same thing, but only with code it generates. It also just re-wrote ALL the code, which is exceptionally inefficient. My macro can be edited, with confidence, at the machine by simply changing a few variables.

Editing the HSMXpress post is another option. Find the part of the post that generates code when that partucular boring cycle is used and see if you can make heads or tails of how it works.

(later...)
I just opened up my own post to see if I could figure out how to make it retract at double the feed-rate, but nothing there made sense to me. SCzEngrgGroup, would be kind enough to elaborate on how it's done?

Personally, I'd try editing the "stop boring" cycle, as that's something that's not likely to be used on a Tormach. Here's the section of my own post that I would guess would need to be edited...

    case "stop-boring":

      if (P > 0) {

        expandCyclePoint(x, y, z);

      } else {

        writeBlock(

          gCycleModal.format(86),

          getCommonCycle(x, y, cycle.bottom, cycle.retract),

          cyclefeedOutput.format(F)

        );

      }

Actually, as long as code is being edited, might as well take over the "case "tapping":" section.

    case "tapping":

      if (!F) {

        F = (1/tool.getThreadPitch());

      }

    

      writeBlock(

        gCycleModal.format(84),

        getCommonCycle(x, y, cycle.bottom, cycle.retract),

        "P" + milliFormat.format(P),

        "F" + tool.getTappingFeedrate(F),

        "S" + tool.spindleRPM

      );

[SCzEngrgGroup]

To support a tapping head with 2:1 reverse, make the following changes to the POST:

In the OnCyclePoint method, replace the "tapping" case with this:

case "tapping":
if (tool.type === TOOL_TAP_RIGHT_HAND) {
F = cycle.feedrate;
writeln(" (Tap: " + formatComment(tool.description) + ")");
writeBlock(gMotionModal.format(0), zOutput.format(cycle.retract));
writeBlock(gMotionModal.format(1), zOutput.format(z), setFeedrate(F, "onCyclePoint"));
writeBlock(gMotionModal.format(1), zOutput.format(cycle.retract + 0.75), setFeedrate(F * 2, "onCyclePoint"));
//onDwell(1.0);
writeln("");
}
break;


At the very end of the method, replace the "else" with this:

} else {
if (cycleExpanded) {
expandCyclePoint(x, y, z);
} else if (cycleType.match("tapping")) {
if (tool.type === TOOL_TAP_RIGHT_HAND) {
var F = cycle.feedrate;
writeln(" (Tap: " + formatComment(tool.description) + ")");
writeBlock(gMotionModal.format(0), xOutput.format(x), yOutput.format(y));
writeBlock(gMotionModal.format(0), zOutput.format(cycle.retract));
writeBlock(gMotionModal.format(1), zOutput.format(z), setFeedrate(F, "onCyclePoint"));
writeBlock(gMotionModal.format(1), zOutput.format(cycle.retract + 0.75), setFeedrate(F * 2, "onCyclePoint"));
writeln("");
writeln("");
}
} else {
writeBlock(xOutput.format(x), yOutput.format(y));
}
}

Regards,
Ray L.

[Hirudin]

Very nice, thanks!

[Moggot]

To support a tapping head with 2:1 reverse, make the following changes to the POST:

In the OnCyclePoint method, replace the "tapping" case with this:

case "tapping":
if (tool.type === TOOL_TAP_RIGHT_HAND) {
F = cycle.feedrate;
writeln(" (Tap: " + formatComment(tool.description) + ")");
writeBlock(gMotionModal.format(0), zOutput.format(cycle.retract));
writeBlock(gMotionModal.format(1), zOutput.format(z), setFeedrate(F, "onCyclePoint"));
writeBlock(gMotionModal.format(1), zOutput.format(cycle.retract + 0.75), setFeedrate(F * 2, "onCyclePoint"));
//onDwell(1.0);
writeln("");
}
break;


At the very end of the method, replace the "else" with this:

} else {
if (cycleExpanded) {
expandCyclePoint(x, y, z);
} else if (cycleType.match("tapping")) {
if (tool.type === TOOL_TAP_RIGHT_HAND) {
var F = cycle.feedrate;
writeln(" (Tap: " + formatComment(tool.description) + ")");
writeBlock(gMotionModal.format(0), xOutput.format(x), yOutput.format(y));
writeBlock(gMotionModal.format(0), zOutput.format(cycle.retract));
writeBlock(gMotionModal.format(1), zOutput.format(z), setFeedrate(F, "onCyclePoint"));
writeBlock(gMotionModal.format(1), zOutput.format(cycle.retract + 0.75), setFeedrate(F * 2, "onCyclePoint"));
writeln("");
writeln("");
}
} else {
writeBlock(xOutput.format(x), yOutput.format(y));
}
}

Regards,
Ray L.

Now we're getting somewhere- thanks for posting this!

Unfortunately I can't get it to work as is and my understanding of javascript is pretty limited. I've made some edits that seem to make things work, but I may be missing something catastrophic.

First problem I run into is an error;

ReferenceError: formatComment is not defined

I think I understand what's going on in the lines containing the formatcomment that seems to be causing this, and that it's not critical. This line just inserts a comment in the g-code describing the tool, correct? I can certainly live without that.

So, I comment that line out and try again, where I get another error;

ReferenceError: setFeedrate is not defined

This one I'm having a harder time understanding. Elsewhere in this method the term feedOutput.format(F) seems to be used to insert the F term. By changing the 'offending lines from

                    writeBlock(gMotionModal.format(1), zOutput.format(z), setFeedrate(F, "onCyclePoint"));
                    writeBlock(gMotionModal.format(1), zOutput.format(cycle.retract + 0.75), setFeedrate(F * 2, "onCyclePoint"));

to

                    writeBlock(gMotionModal.format(1), zOutput.format(z), feedOutput.format(F));
                    writeBlock(gMotionModal.format(1), zOutput.format(cycle.retract + 0.75), feedOutput.format(F*2));

The post runs and I get reasonable values; 12.5 down and 25 up at 1000RPMs for a 0-80 tap. Most importantly, I can array the operation in HSM like any other toolpath and it spits out what appears to be safe code. Unless you see something boneheaded on my part, it looks like I've got a working solution.

Thanks again for the help!

[SCzEngrgGroup]

These should be the missing pieces:

var feedFormat = createFormat({decimals: (unit == MM ? 1 : 2), forceDecimal: true, trim: false});


/************************************************** ****************************
* format Comment - Format a G-code Comment
************************************************** ***************************/
function formatComment(text) {
var s = String(text);
s = s.replace(new RegExp("[\(\)]", 'g'), "");
return s;
}


You should be able to replace setFeedrate() with feedFormat.output()

Regards,
Ray L.

[Moggot]

Just an update- I haven't included the changes for the comment or original feed format, but did get a chance to test out the code generated by the modified tapping operation arrayed using HSM's pattern function. It worked perfectly, and didn't require a stich of hand coding.

Hooray!

Thanks a bunch Ray, this'll save me a whole lot of headache.