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
  • so i can comment on this. this is a bug i have seen with clearplanes and the way i work around it is that everytime i initiate a new clearplane i put a movepoint or a increment point right after. this seems to engage the most recent clearplane. even putting in a simple MOVE/INCREMENT, <0,0,0> will work
Reply
  • so i can comment on this. this is a bug i have seen with clearplanes and the way i work around it is that everytime i initiate a new clearplane i put a movepoint or a increment point right after. this seems to engage the most recent clearplane. even putting in a simple MOVE/INCREMENT, <0,0,0> will work
Children
No Data