WOOOO HOOOOO !!!! That did the trick. Back to perfect code once more. Thanks again Frederick, you keep pulling my toes outta the fire. Jon
----- Original Message ----- From: "Lauzus, Frederick" <[EMAIL PROTECTED]> To: "Jon Baker" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 08, 2000 9:01 AM Subject: RE: [mfg-smartcam] No G80 Been there, done that. Long explanation, quick fix. --== THE EXPLANATION ==-- The problem is that you are using two different variables, #FXD and #CYCLE, to output your canned cycle commands. The template variable #FXD is used to output the cancel canned cycle command (G80) but does not output the call canned cycle commands (i.e. G82). The call canned cycle commands are being output by the variable #CYCLE instead. There is no interconnection between the variables so in a sense, the left hand doesn't know what the right hand is doing. Where the problem lies is that #FXD is originally set to output G80 and never has the opportunity to output the G82. Since G80 was the last value #FXD output, and < #FXD> is modal, SmartCAM does not consider it a changed value and does not output it again. --== THE FIX ==-- An easy way to address this is by using an #UPDATE() command. You can think of #UPDATE() as the opposite of #RESET(). It will tell SmartCAM that the value of a variable has been output even if it hasn't. Add an #UPDATE(#FXD) to any template sections that output codes using #CYCLE. @OP_SPFACE #IF(#U1=1)<#RESET(#CYCLE,#XPOS,#YPOS)#EVAL(#U1=0)> < #ABSI>< #CYCLE>< #RTNLVL>< X#XPOS>< Y#YPOS>#EXLN < Z#ZDPTH R#ZCHK>< P#DWELL>< F#FEED> #UPDATE(#FXD) In this case the #UPDATE(#FXD) tells SmartCAM the #FXD has output the code for the canned cycle call. When #FXD reverts back to G80 SmartCAM considers that a change in state and will output it. ============================================= Fred Lauzus, CAM Programming Coordinator High Steel Structures, Incorporated mailto:[EMAIL PROTECTED] http://www.highsteel.com ============================================= -----Original Message----- From: Jon Baker [mailto:[EMAIL PROTECTED]] Sent: Friday, December 08, 2000 11:28 AM To: Lauzus, Frederick; [EMAIL PROTECTED] Subject: Re: [mfg-smartcam] No G80 Shoot, I will post the whole enchilada if you want to look at it. Thanks ----- Original Message ----- From: "Lauzus, Frederick" <[EMAIL PROTECTED]> To: "Jon Baker" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 08, 2000 8:18 AM Subject: RE: [mfg-smartcam] No G80 > Jon, > > would you post the @OP_BORE section (or whatever section your using to bore) > of your template file? > ============================================= > Fred Lauzus, CAM Programming Coordinator > High Steel Structures, Incorporated > mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > http://www.highsteel.com <http://www.highsteel.com/> > ============================================= > > > -----Original Message----- > From: Jon Baker [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 07, 2000 6:45 PM > To: [EMAIL PROTECTED] > Subject: [mfg-smartcam] No G80 > > > Hey, who added this twist to me. > I am programming away, and need to add a point after a bore so the tool > will move out of the way before tool changing. So I process out my code, > and it does the bore, then DOESN'T call a G80 up before calling out the > point location. This will cause my machine to bore again at the new > location. Strangely, this is the first time I have run into this, as > generaly after using a hole cycle, you cancel out and change tools > immediately. > Any suggestions as to where in my tmp file I need to do something? > Thanks in advance > Jon > > > ====================================================================== To find out more about this mailing list including how to unsubscribe, send the message "info mfg-smartcam" to [EMAIL PROTECTED] ======================================================================
