I've been having some issues setting up Renishaw NC tool measurement software on a 0MC control. The problem I was seeing was a 115 P/S alarm, indicating one of the macros was attempting to use an undefined variable. A little bit of further investigation and single blocking the macro along with tons of inserted EOBs to help take look-ahead out of the equation led me to something I didn't expect. The macro was blowing up because it was enumerating an expression that the logic should have skipped?
In a nutshell, it goes something like this:
blah, blah, blah (#21 is empty)
GOTO11
30 or so lines of more blah, blah, blah
WHILE[ABS[#[5040+#21]-#[3+#21]]GT#145]DO1
END1
WHILE[ABS[#[5040+#122]-#[3+#122]]GT#145]DO1
END1
WHILE[ABS[[#[5040+#123]-#116]-#[3+#123]]GT#145]DO1
END1
N11
M99
The code execution path hits the GOTO11, but on its way to N11, it apparently scans and fully enumerates the first WHILE statement and since part of that line ends up evaluating as #[5040+0], it kicks the P/S alarm because #5040 is not valid, even though its a section of code that it does not actually execute and is supposed to skip as the logic is jumping to the N11. I can confirm this is the line that is blowing up by making a modification to the macro that populates #21 and the macro completes without issue at that point. I can also confirm that it is following the GOTO11, as I padded out 5 EOBs and an M0 right after the GOTO and it skipped right over it. Ass soon as single block executed the GOTO line, if #21 is empty, you get 115 P/S.
Is this normal MACRO B behavior on the 0MC? I've used the NC tool setting software on 16i and 21i before and didn't run into this specific issue. I know plenty of folks dislike the Renishaw macros, and I'd rather not get into that debate here. I'm more interested in the way the control is processing the macro, as it'll be something I need to be wary of when writing my own macros on this machine as well.