hexagon logo

clearplane height inconsistencies when calling external subroutines

Dear CMM gurus!

I wrote a bunch of generic subroutines which will be called by a number of different programs. While these programs will consistently be using a single stylus throughout their runtime, the styli do vary from program to program. Because of this the subroutines don't contain any LOADPROBE statements of themselves and according to my tests they seem to be working just fine when called from main programs using different stylus lengths. However, I recently ran into a nasty problem with clearplane moves initiated from such a main program right before calling one of my external subroutines. As you're probably aware of, PC-DMIS forces me to make a LOADPROBE statement outside of the subroutine definitions within the external program file containing the subroutines even though the probe specified in it will not always be the one that will be used when calling the subroutines. Unfortunately, I suspect this to be the cause for my problem. It seems that whenever I do a MOVE/CLEARPLANE right before calling a subroutine from a main program using a stylus length different from the one specified in the external program file, the clearplane move ends up on the wrong height----as if the probe specified in the external file was loaded instead of the one specified in the main program. On the other hand, if I place an operator comment between the MOVE/CLEARPLANE and the subroutine call, the height of the move is correct.

Can you confirm this behavior? Is there an easy (preferably foolproof) way around this problem? Can you think of any other potential pitfalls arsing from the fact that I'm calling an external subroutine contained in a file which has a different LOADPROBE statement at its beginning? And is there by any change a command similar to PROBEDATA() which returns the currently loaded probe?

Thank you very much and cheers,

Daniel
Parents
  • Your MOVE/INCREMENT, <0,0,0> solution worked great in most of the problematic cases, but I ran into another problem: Apparently, clearplane moves are being ignored if the subroutine that gets called after them (or rather after the MOVE/INCREMENT, <0,0,0>Wink is starting with a dedicated movepoint of its own, which is weird. Do you, by any chance, also know a convenient way around this problem?
  • A TIP/ command will also activate the MOVE/CLEARPLANE
    You can store your tip angle in a variable so you never actually experience any tip rotations. Just load the tip command below the clearplane command.
Reply Children
No Data