What's new
What's new

#3000 macro problem

This just occurred to me and I will test on Monday. Since the alarm logic part of program works perfectly on it's own, I will make the alarm logic portion of the probing program, it's own subprogram. As I typed this I realized that is exactly how renishaw does it in there inspection + macros. I can't wait to try it. I'll let y'all know how it goes.
If there is some machine movement, followed by macro statements, then it is quite likely that the macro statements would be executed before the physical machine movement completes.
In such cases, inserting G31 without arguments, before the macro statements, solves this problem.
As previously suggested, I did try G31 before each line of the alarm logic portion of the program and still had the same problem. I'm excited to see if moving that portion of the program into a separate subprogram works. I might go in tomorrow to test instead of Monday.
After passing each portion of the calculations at N107 would it just not continue to the error code? Shouldn't there be a GOTO107 right after the code for N106...before the #3000 error codes?
I solved it. Moving the alarm code below to its own sub-program solved it. Now it works great.
IF[#601EQ0]GOTO105(SKIP IF 0)
IF[#601LT-.05]GOTO101(#601 OUT OF RANGE)
IF[#601GT.05]GOTO101(#601 OUT OF RANGE)

IF[#602EQ0]GOTO106(SKIP IF 0)
IF[#602LT-.05]GOTO102(#602 OUT OF RANGE)
IF[#602GT.05]GOTO102(#602 OUT OF RANGE)

IF[#603EQ0]GOTO107(SKIP IF 0)
IF[#603LT-.05]GOTO103(#603 OUT OF RANGE)
IF[#603GT.05]GOTO103(#603 OUT OF RANGE)

N101 #3000=1 ( #601 OUT OF RANGE)
N102 #3000=2 ( #602 OUT OF RANGE)
N103 #3000=3 ( #603 OUT OF RANGE)


G49 G53
G5.1 Q0
G91 G28 Z0.0 M5
G28 X0.0 Y0.0