As if you didn't use cut paste to produce your abortion....
Easy enough write by hand, in it's entirety...and the main program would never change again, once written. And all you'd need to supply after that is a set of subprogram for each cutting tool's toolpath.
But you're an idiot and an asshole; and so you'll have to just figure it out on you're own, like I did.
It will loop, just not with the intended effect.
Indeed!
Yeah, I like macro programming. It isn't always the best solution, but you can use it to do some useful stuff.
Looks good to me.
No that's OK, but thanks.
I'm not in the US, so it's unlikely, but I guess anything's possible...
No problem.
Im not going to argue this forever. The parameters of the project was the nc file never gets touched or even seen by the operators. The UG programmers continue with no changes in their programming. It has to be easy to run each time.
Yours did not meet those requirements. Why would you want to post out 8-10 programs per part?
Whatever man.
Tweak your post to turn this
G90G10L20P1X0.Y0.Z0.(G54.1P1)
G54.1P1
G90M06T1 T2 G43H1Z10. .... G28G91Z0.
G90M06T2 T3 G43H1Z10. .... G28G91Z0.
G90M06T3 T1 G43H1Z10. .... G28G91Z0.
M30
into this
G90G10L20P1X0.Y0.Z0.(G54.1P1) G90G10L20P2X0.Y1.Z0.(G54.1P2) G90G10L20P3X0.Y2.Z0.(G54.1P3) G90G10L20P4X0.Y3.Z0.(G54.1P4) G90G10L20P5X0.Y4.Z0.(G54.1P5)
#2=5.2
G90M06T1 T2 G43H1Z10. #1=1 WHILE[#1LE#2]DO1 G54.1P#1 .... #1=#1+1 END1 G28G91Z0.
G90M06T2 T3 G43H1Z10. #1=1 WHILE[#1LE#2]DO1 G54.1P#1 .... #1=#1+1 END1 G28G91Z0.
G90M06T3 T1 G43H1Z10. #1=1 WHILE[#1LE#2]DO1 G54.1P#1 .... #1=#1+1 END1 G28G91Z0.
M30
And if you want to run only one part just make #2=1.5
Some posts would have the starting position for the next tool just at the end of the tool so watch it.
DanP
very nice. This is what i suited it to for our needs, Simply hardcoded into the tool change section of the post. This is by far the simplist way to do this. All that is needed in the main is % O0001 #100 = 10 (Enter program number) #101 = 8 (Enter number of positions) M198P#100 %
% 00010 (posted from ug) T1M6 #105=1 WHILE[#105LE#101]DO1 G54.1P#105 (gcode here) #105=#105+1 END1 G28G91Z0. M30 %Awesome, I passed it on. Thanks. Kickass man!!! Dang, could it get any simpler?
[ snip ]
Just out of curiosity, why the fractional part in the values assigned to #2? I'm guessing it's to allow for floating-point inaccuracy, although I didn't think that was an issue on CNC machines.
Nice bit of code BTW. I never thought of doing it that way.
Unless Im wrong, hes using the .2 to keep the loop going. could of been anything. 5.5. 5.9.
I had a glitch once in a serial number routine I wrote, the control panel got it wrong every 20 numbers, it was a Matsuura. I have fixed it by not using an integer. Other people I have worked with do it as well, I have never asked why.
As a result I am doing it just in case. It freaks me out when things don't go the way they are supposed to.
DanP
Thanks for the tip. I had a hunch it was something learned from bitter experience.
Any chance you have a copy of that macro? I would like to see it, curious to see what the root cause is.
Thanks,
No copy but I can tell you the 500 something variable holding the serial number and being incremented was being split in individual digits with the FIX function and every multiple of 20 was giving the previous number.
So, start with 1 in #500, do the maths with FIX and extract 4 digits into #1, #2, #3 and #4, block skip the engraving sub call and watch the numbers on the screen as you push cycle start.
For 19 in #500 I would get #1=0, #2=0, #3=1, #4=9 and for #500=20 they would stay the same. Carry on to 40 and there is #1=0, #2=0, #3=3, #4=9.
The control was an old Matsuura. I run the macro in Vericut and it was fine.
Start with #500=1.2 and all is fine. I am glad I spotted it on a dry run.
DanP
us to see what the root cause is.
number and being incremented was being split in individual digits with the FIX function and every multiple of 20 was giving the previous number.
#1, #2, #3 and #4, block skip the engraving sub call and watch the numbers on the screen as you push cycle start.
20 they would stay the same. Carry on to 40 and there is #1=0, #2=0, # 3=3, #4=9.I find the issue you describe very interesting because I haven't seen it be fore. Wish you had a copy of the macro to share.
Serial number Macros I wrote in the past were: Year, Month, Day then count starting at 1 for that day. It made traceability extremely easy.
Anyway, I threw a quick and dirty macro together (pasted below) to see if I could recreate your issue. It did not duplicate your issue. I created the S/N counter and method of extracting digits as you described and the macro runs without duplicating the error you described.
I stepped through the program to watch as the variables changed. Then I cre ated a loop, went through a bunch of cycles and still no errors noticed.
I do initialize the 100 series variables I'm using by giving them 0.0 I do this for all macros I create as a safety, because a variable set to null c an sometimes have very bad effects when least desired.
I don't normally use local variables unless I am going to use them in a cus tom G code. So here I used common variables for my calculations and 1 perma nent common variable to store the accumulated Serial Number. I used the var iables numbers in the order I created the macro.
% O1115 (FOUR DIGIT SERIAL NUMBER) (EXTRACTING DIGITS LEFT TO RIGHT)
IF[#500LE0.]THEN#500=1 IF[#500GT9999]#3000=1 (TOO MANY DIGITS)
WHILE[#500LT9999]DO1 (CREATED LOOP TO TEST MACRO) (DELETE OR COMMENT OUT THE LOOP WHEN MACRO IS DONE)
#100=0.0 #101=0.0 #102=0.0 #103=0.0 #104=0.0 #105=0.0
(#100= FIRST DIGIT) (#102= SECOND DIGIT) (#104= THIRD DIGIT) (#105= LAST DIGIT)
#100=FIX[#500/1000] (EXTRACT 1ST DIGIT BY DIVIDING AND ROUND DOWN)
#101=#500-[#100*1000] (REMOVE 1ST DIGIT) #102=FIX[#101/100] (EXTRACT 2ND DIGIT BY DIVIDING AND ROUND DOWN)
#103=#500-[#100*1000]-[#102*100] (REMOVE 1ST AND 2ND DIGITS) #104=FIX[#103/10] (EXTRACT 3RD DIGIT BY DIVIDING AND ROUND DOWN)
#105=#500-[#100*1000]-[#102*100]-[#104*10] (EXTRACT LAST DIGIT BY REMOVIN G ALL OTHERS)
(#501 THRU #505 FOR VIEWING MACRO VALUES ONLY) (EASIER TO COMPARE THEM TO #500 IF ALL ARE TOGETHER) (WHILE TESTING THE MACRO) (COMMENT OUT OR DELETE WHEN MACRO IS COMPLETED)
#502=#100*1000 #503=#102*100 #504=#104*10 #505=#105+0.0 #501=0.0+#502+#503+#504+#505
#500=#500+1 (ADD 1 TO PERMANENT SN COUNTER)
END1
M30 %
Dan,
You were talking about an older controller so I edited the macro (mostly IF/THEN) to run on older or new. I also revised some other things I noticed. Anyway here is the less quick and dirty macro version.
% O1115
(FOUR DIGIT SERIAL NUMBER) (DIGITS LEFT TO RIGHT) (TO BEGIN S/N FROM SCRATCH) (#500 SHOULD BE 0. OR 1.)
IF[#500GT10000.]GOTO1000 IF[#500LE0.]GOTO1002
N1 WHILE[#500LT10000]DO1 (CREATED LOOP TO TEST MACRO)
#100=0.0 #102=0.0 #103=0.0 #104=0.0 #105=0.0
(#100= FIRST DIGIT) (#102= SECOND DIGIT) (#104= THIRD DIGIT) (#105= LAST DIGIT) #100=FIX[#500/1000] #101=#500-[#100*1000] #102=FIX[#101/100] #103=#500-[#100*1000]-[#102*100] #104=FIX[#103/10] #105=#500-[#100*1000]-[#102*100]-[#104*10]
#502=#100*1000 G04X.5 #503=#102*100 G04X.5 #504=#104*10 G04X.5 #505=#105+0.0 G04X.5 #501=0.0+#502+#503+#504+#505
#500=#500+1
END1
IF[#500GT9999]GOTO1001
M30
N1000 #3000=101 (#500 VALUE TOO LARGE) N1001 #3000=102 (MACRO HAS OUTLIVED USEFULLNESS) N1002 #500=1 GOTO1
%(#501 THRU #505 FOR VIEWING MACRO VALUES ONLY) (EASIER TO COMPARE THEM TO #500 IF ALL ARE TOGETHER) (WHILE TESTING THE MACRO)
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.