FORCING XY OUTPUT AFTER INDEXING

[ADV_Cole97]

Alright y'all, here's what I got. I have a UMC 750 post that I updated to have a safe position return during indexing. The problem now is that if the x or y starting location of the next operation happens to be at the same location the previous operation ended, the post doesn't output a new XY location, so now the machine is drilling a hole over in left field or cutting a contour in the air. I have tried to add an *Xout, *Yout. but that seems to be calling the starting point from the previous operation. I am now using *xr$, *yr$ and that worked for a few tests, but now on my last part, it gave me the correct numbers, but the wrong sign (+ /-).   Attached is the rotary position section, and the reinitialize XY section that I wrote. What am I doing wrong here?  

[Guest]

18 hours ago, ADV_Cole97 said:

What am I doing wrong here?  

Have you tried the debugger? This should tell you pretty quickly where the problem is.

[ADV_Cole97]

2 hours ago, nickbe10 said:

Have you tried the debugger? This should tell you pretty quickly where the problem is.

I'm not quite sure how to interpret the NCI part of the debugger. Using it to find the line in the post that generated the code isn't helping because it is pointing to exactly where I expected. Here are a couple snips from the debugger  

[Guest]

1 hour ago, ADV_Cole97 said:

I'm not quite sure how to interpret the NCI part of the debugger.

I am not as familiar with the 5  axis post(s) as I am with Mpmaster, however I notice you are in ptlghg0 when you are having the problem. Is it always occurring only at null tool change events? I would look for differences between ptlchg and ptlchg0, like forced or updated variable output.

Also run the debugger in trace mode to get more info on the post blocks involved with any one output statement. 

Problems often occur when you are trying to work "across" operations as the post may have read the next NCI line before you think it has (or it hasn't read it when you think it has), so you might need to save a variable or maybe use a flag to control across the transition from one NCI pair to the next. Notice how your output is from the previous op, it is "old" data.

You can "watch" variables (in conjunction with break points) to see how their values  change through the posting process to see when they are updated.

[Alex Dales]

you can try using the force() command to force the X and Y to recall, even if they would have been the same value.

In our posts, the output variables we call for x and y are called xabs and yabs, so the command to force out the next x and y call (even if the values haven't changed) is

	result = force(xabs, yabs)

this basically mean the next time the post reads xabs, yabs, zabs, it will treat it as thought it was programmed as *xabs, *yabs, zabs

One thing to watch out for with the force command, is that it defines the first and last variable being forced, so if you have you IJK arc center points all defined in a row, and your G18 arc want II and K the J would also be forced if you program force(I, K). So it often best to use multiple force commands then to try and use one and accidently force something you didn't want.

[ADV_Cole97]

Solution:

While using trace, I think I nailed down where the variables were getting changed, but the code in that section of this post was a little beyond my knowledge, so instead of trying to figure that code out and make what I had work, I took a bit of a different route, I knew that when "pradipout" is commanded, the variables are set to the correct value, so I wrote some logic inside that block to force the output if mi1$ =0.  Inside the rotary positioning block, it sets re_init_xy to one. Inside the prapidout block, if re_init_xy equals one, and mi1$ equals 0, then it will force output xy, if not, it runs the standard prapidout block

[Colin Gilchrist]

The big issue with the 5-Axis Post, is the use of Global Formulas for output. To add a wrinkle to the issue, the way Mastercam formats the NCI Data means that Null Tool Change can occur between Operations, but also between Multi-passes and Depth Cuts.

I think you will want to manipulate the "previous" values. 

Either:

     prv_xa = 9999
     prv_ya = 9999
     prv_za = 9999

Or by manipulating the previous value of xabs, yabs, and zabs

     prv_xabs = 9999
     prv_yabs = 9999
     prv_zabs = 9999

Try adding either set of code to "ptlchg0$".

[MIL-TFP-41]

have you tried moving the *xout, *yout before the " !p_abs, !s_abs " line?

I do something similar in my our posts & it works out great.

	ppos_cax_lin    #Position the rotary axis before move - rapid
      if p_inc | s_inc,
        [
        sav_gcode = gcode$
        gcode$ = zero
        punclamp
        pbld, n$, sgcode, *p_out, *s_out, e$
	pbld, n$, *xout, *yout, e$
	pclamp
        !p_abs, !s_abs
        ps_cinc_calc
        gcode$ = sav_gcode
        ]