Hi again and thanks for all the feedback and many useful suggestions!
@RedBarn Research; Yes, sounds non-intuitive but definitely promising! I'll play around with that, thanks so much for the tip. I'm not totally sure if subprogram is the way to go for me tho in a cpu intensive task because there's a bit of a delay in loading the subprogram on my Fanuc 21i but maybe you have good results with that version?
@Vancbiker: Yes, I remember there was such a code, thank you for pointing it out, that may too be useful.
@dandrummerman21: Thanks a bunch for testing out the macro on your machine! Your observations echo mine, except for the G4 stuff.
I'm sorry the macro is so messy. It's old and has been lying around for a while but wanted to take a stab at perfecting it.
So, update:
I tested the macro in MDI today again at work with g05.1Q1 and... uh, it worked. No Z issue. Had no idea why (but your comments have given me hints.) Maybe some slight code changes that I haven't documented. However, like you noted, Dan, it pauses after each half circle.
I couldn't find the exact "original" G101 macro that had no issues (because I'm messy) but: Ripping out #1 and #3 (skew and convexity) variables and calculations made it run smoothly. Meaning I now had a macro that could at least do stable 3-axis travel.
Then at the end of the day after I signed out I tried to make a short program out of it and I got "over tolerance of radius", lol. Before it even made the first move. Then I tried the exact code that'd worked in MDI. Over tolerance of radius. Yeah, it's flaky. Have to check some system variables when I have time. Maybe it's because I didn't give any coordinates after G54 before I started the macro.
I always activate G05.1 like so:
G49
G05.1Q1
G54 ... (rest)
This time the program was just:
G49
G05.1Q1
G54S3000M3F3000
G101 ********
(Tried with both the #1-#3 macro and the simplified.)
I'll try to tinker with it some more tomorrow if I have time, will post updates if I manage any worthwhile results.
Addendum:
Perhaps the control just isn't up to it.
I wrote a macro a number of years ago to engrave serial numbers, date, and time. It would scale, write at a specified angle, or on a specified arc, and optionally project onto a cylinder. It worked, but on many controls was painfully slow.
Not sure if it helps or if it's still of any interest but I had the same exact problem with an engraving macro of mine (is there any macro coder who hasn't done one) and I solved it for my control by splitting it into smaller subprograms. (Quite simple macro tho, only engraving straight lines.) GOTO was the villain. GOTO only searches forward and the code was too long. So I made a master program that passed the character codes to subprograms like:
Code:
%
:0020(FIL=M-GRAVGRAB)
(PRODUCTION LINE ENGRAVING SYSTEM)
G9(EXACT STOP)
#121=#5001(START X)
#122=#5002(START Y)
#123=#5003(START Z)
#131=#121(CURRENT X)
#132=#122(CURRENT Y)
(GRAB Y COORDINATES)
#110=0
WHILE[#110NE7]DO1
#[140+#110]=[#132-[#110*#1/6]]
#110=#110+1
END1
#111=4
#129=#1+#2
N900
WHILE[#[#111]NE#0]DO1
(GRAB X COORDINATES)
#110=0
WHILE[#110NE7]DO2
#[100+#110]=[[#110*#1/6]+#131]
#110=#110+1
END2
G65P[8050+[FIX[#[#111]/10]]]I[#[#111]]C#3
(CALLS 8050, 8051, 8052, ETC DEPENDING ON CHAR CODE)
#111=#111+3
IF[#111EQ34]THEN#111=#0(LOOP KILLER)
N902
G0Z#123
#131=#131+#1+#2
X#131Y#132
END1
M99
%
