Hole position post
Well the order of the holes is still the same but indeed it will go too far up and down again if it calls the cycle again for each hole. Is it possible you share your part and post processor with us?
Laurens Wijnschenk
3DTechDraw
AutoDesk CAM user & Post editor.
Found out the hard way is the best way to win.
In that post, for some reason the cycle is forced for tapping.
@AchimN can you explain this?
Laurens Wijnschenk
3DTechDraw
AutoDesk CAM user & Post editor.
Found out the hard way is the best way to win.
What you see with the tapping now is something specific for the Haas post.
You would see different code with the fanuc post.
Laurens Wijnschenk
3DTechDraw
AutoDesk CAM user & Post editor.
Found out the hard way is the best way to win.
Laurens Wijnschenk
3DTechDraw
AutoDesk CAM user & Post editor.
Found out the hard way is the best way to win.
Well those shouldn't matter if you ask me.
It's a fault in the post because it repositions to the cycle's first X and Y. So the cycle comes correctly to the post but the post messes up badly.
Laurens Wijnschenk
3DTechDraw
AutoDesk CAM user & Post editor.
Found out the hard way is the best way to win.
@Rob_Lockwood wrote:
Inconsistent bottom depths would be a good way to force the output of an individual canned cycle.. It's even entirely possible it would look stupid in the final result, if the variance was less than the format allowed for digits.. returning to the first hole is indeed weird, though.
True,
But the return of the first hole indeed suggests a different problem.
But this is in the latest Haas post:
switch (cycleType) {
case "tapping-with-chip-breaking":
case "left-tapping-with-chip-breaking":
case "right-tapping-with-chip-breaking":
forceCycle = true;
if (!isFirstCyclePoint()) {
writeBlock(gCycleModal.format(80));
gMotionModal.reset();
}
}
That code forces the whole cycle to be output for every hole.
So there shouldn't be a way around, no matter how you program yoru tapping cycle.
Laurens Wijnschenk
3DTechDraw
AutoDesk CAM user & Post editor.
Found out the hard way is the best way to win.
The only reason for repeating cycles is a different hole depth (even if not visible into the cycle itself because of formatting the Z-values).
So even for very small differences in hole depth the software will force the post to output a single cycle for each hole.
The reason for forcing the "tap with chip breaking" cycle into the haas post is that haas does not have a G84 with chip breaking, so we are outputting a cycle for each stepdown to be able to have chip breaking tapping.
KerimY
Software Engineer
@KerimY wrote:
The only reason for repeating cycles is a different hole depth (even if not visible into the cycle itself because of formatting the Z-values).
So even for very small differences in hole depth the software will force the post to output a single cycle for each hole.
Yes we understand that part. But as @Lonnie.Cady says why does it reposition to the first hole location?
@KerimY wrote:
The reason for forcing the "tap with chip breaking" cycle into the haas post is that haas does not have a G84 with chip breaking, so we are outputting a cycle for each stepdown to be able to have chip breaking tapping.
If the re-calling of the cycle is for that maybe we should make a post property for that so that people who don't have the parameter set correctly can still safely use the post.(You can't just assume it is set correctly)
Apart form that I just heard you are part of Autodesk so I recommend you get your profile representing that since now nobody knows who you are and what you do.
Laurens Wijnschenk
3DTechDraw
AutoDesk CAM user & Post editor.
Found out the hard way is the best way to win.
