How can I find out if X and Y coordinates were not output due to modality ?

[pullo]

Right  now I'm using a line : if (prv_x$ = x$ & prv_y$ = y$ ) , "M113"   to add the M113 to the end of the line , but it's adding in many more M113 's  than is necessary .

It should only add an M113 if the line reads :

4444 L Zxx.xxx  M113 i.e. only  the Z  coordinate creates a movement.

 

I know this might sound cryptic, but I'll explain more  if the need arises.

Gracjan

[Zaffin_D]

Have you tried adding the format round function?

if ((prv_x$ = fmtrnd(x$)) & (prv_y$ = fmtrnd(y$))), "M113"

 

[pullo]

What the   if (prv_x$ = x$ & prv_y$ = y$ ) , "M113" is doing is  legitimate , it's just that it's covering  more cases that I need ...

I just need the cases where there is just a L Zxxx.xxx  move .....

Gracjan

[crazy^millman]

don't you need to make it a variable and track that variable? By using the process you are using your forcing output and not as needed. By using a variable in MP you have more control of it coming out when needed and not. Using "Command" then anytime the conditions are true you will get the output. With the variable you might be able to setup a counter or other conditions to decide when you want the desired output. You should be able to do the same thing with what you have done, but using a variable for output seems to always do things differently than just doing the old school force like you have in the example.

[Zaffin_D]

Do you have a pz$ block in your post?

[nickbe10]

Your code is going to output every time X and Y are the same as previous (modal condition), not when there is only Z movement.

I would be very wary about hijacking the modal check system for something other than what it was designed for.

For instance I use it to output H1 D1 offsets for all tools on a machine with tool management, but I haven't changed its function, just the variables I am controlling (as per Ron).

What is it you are trying to do?

[Colin Gilchrist]

Maybe a dumb question, but does your Post actually use 'x$' and 'y$' for output? 

Most modern Posts use 'xabs' and 'yabs' for output.

But regardless, use whatever works.

Ok, first, you need to make sure that you have code to "update" the variables you are checking.

I would add this to the end of 'pnc_output' (may have spelled the name wrong):

       @x$, @y$, @z$ #force format before updating 

      !x$, !y$, !z$ # update variables (set previous to current, no output)

That will ensure that the updating happens after each line of NC movement is output.

Second, if you only want output with "z only", shouldn't you be checking Z?

     @x$, @y$, @z$

   if prv_x$ = x$ & prv_y$ = y$ & prv_z$ <> z$, "M113"

 

Notice that I added the "forced formatting" (@) commands just before the line that compares current and previous values. 

[pullo]

I would have thought that the addition of prv_z$ <> z$ would have curbed the unnecessary outputs , but so far it has not . Than You guys for showing me some new directions I can go .  The code works so far so I can machine , but I'll try to implement the other stuff whenever I develop some free time.

Gracjan

[Colin Gilchrist]

Most modern Posts also maintain "2 sets" of variables: "xabs, yabs, zabs", and "xinc, yinc, zinc".

So, technically, as long as you test "after the incremental variables have been calculated", you should be able to do the following:

if zinc & not(xinc) & not(yinc), "do something".

[jlw™]

And I learn something again that actually has application for me right now.

Colin, you are the best.

[pullo]

This is a post I have been nurturing  since  1992 .  It's for Heidenhain  415.  For this control to move smoothly ,  I need to introduce M112  Txx.01 where T is the loosened tolerance of the toolpath and M113  turns it off. This was taken out of action in the next Heidenhain control , the 425  and replaced by CYCLE DEF 32.0 as it is difficult to work with...

The thing is that M112 actually introduces a "fillet" at the control level. And as you know you cannot fillet a fillet, so one has to turn this off before an arc movement as it will be most probably tangent to the previous element ( line) .  But it's not that easy ,  I found out that you have to turn  it  off one linear movement before an arc is output. 

Now the only case when my movement stops is when I have a line: 

(In Heidehain L  is a linear line or G01  and  C is circle )

L  Zxxx.xxx  . It has to be L Zxxx.xxx M113 .    

Hence  my need to find out if X and Y were modally left out . 

There is something tricky working with the  prv_ values when it comes to x , y and z ,  but I 'll  iron it out

Before dynamic came along  I just simply turned off arc interpolation in all 3d  toolpaths, but with dymanic the control starts to starve on the code .... hence my need to reintroduce 

arcs into 3d toolpaths.

Gracjan

[Colin Gilchrist]

If you want to send me a Zip to Go file, I'll take a crack at solving this for you.

Does your Post have the 'get_next' switch enabled? This will set the "next" variables which are calculated by MP.

'next_gcode$' will hold the upcoming NCI gcode value. So you can do something like "if next_gcode$ > 1, "do something"

[Colin Gilchrist]

So, one of the things that I think is important to understand, is this:

When you have a "machine function", like this auto-fillet thing, you need to use Numeric Variables to track the "on/off" state.

Why?

Because Numeric Variables can be used in Boolean statements, where "strings" can not. We can operate mathematically on a numeric variable, and thereby use them to test conditions.

So, the MP language has a special function for doing this: the String Select Table.

I would recommend setting up a SST, in order to use modality to your advantage. 

[pullo]

Colin  , I usually love to figure these things out for myself , but there are many things you mentioned that are intriguing/interesting .  So  I'll give it a few more jabs  and then send it over to You. 

Gracjan

[pullo]

I finally figured it out .  I  did  the comparison of x$ , y$ and z$ with their prv_  values after I  had tried to output them . Therefore the prv_ values were  always identical to what I had output and there was no trigger. Once I picked up the prv_ values upstream  the  code started to work.

Gracjan

[jlw™]

Mind sharing the code for the fix?

[Colin Gilchrist]

Glad you figured it out.

Modality is a blessing, but you've got to be aware of "how and where" variables get changed. MP will automatically copy the "current" value to the "previous" value, when the variable is output to the NC File. The "output" is what causes MP to update the prv_ value of the variable.

[pullo]

The solution was not in the code being this or that.

This expression will find me a line where the X and Y coordinates were left out due to modality :  if (prv_x$ = x$ & prv_y$ = y$ & prv_z$ <>  z$ ), "M113".

But if write the code like this :

pprintM113

                      if (prv_x$ = x$ & prv_y$ = y$ & prv_z$ <>  z$ ), "M113".

 

plin$

                      n$, sgcode, x$,y$,z$,pcc,pfr,pprintm113,e$ 

 

then what happens is that as I output X, Y an Z and THEN COMPARE their previous values to the present ones , I am a bit late here and am in fact comparing identical values as the

prv_ values were updated upon output . 

But if I pick up the values of prv_x$ and prv_y$ and prv_z$ before output I will really get the previous values , not the present ones.

 

 

pprintM113

              if (help_x = x$ & help_y = y$ & help_z <> z$ ) , "M113"

 

plin$

    help_x = prv_x$

     help_y = prv_y$

     help_Z = prv_z$     #  now I am picking up the right previous values as they precede the next line 

 

    n$, sgcode, x$,y$,z$,pcc,pfr,pprintm113,e$ 

 

 

Gracjan

[pullo]

Colin , where is there mention of  get_next$ ?  

Gracjan

[Colin Gilchrist]

I'm not sure there is a specific "chapter" that mentions the "Get Next" routine. I think if you look in Volume 3 (old documentation), under the "G" section of the pre-defined variables, you'll find a description of this Command Variable.

I'll check later on when I get a chance to look at the documentation, to see if I can give you a better explanation.

The specific variable you need to enable is:

getnextop$   :  1

From what I remember, enabling this variable tells MP to create a list of "next variables". I'm not sure if MP needs to run the "pwrtt$" loop for the "get next" functionality to work or not.

The "get next" routine basically maintains a separate set of variables, that give you some limited information about the "next move" in the NCI. The only tricky part, is that you don't get "every single bit of information" about what is coming up. There are a limited amount of "next value" variables, but so far I've been able to get all the info I needed when using these variables.

Here are some important variables that get set when the 'getnextop$' routine is enabled:

Variable Name    Description

nextop$               This variable holds the next "NCI G-code Value" on the upcoming line. (0,1,2,3 = motion | 1000,1001,1002 = toolchange | 1003 = end of file)

nextdc$                This variable holds the value of the "Upcoming Drill Cycle". Typically, this is used at the Tool Change event, to detect what Drill Cycle is being processed "below".

nextxc$                Holds the X position of the Arc Center, if the next move is a G2 or G3 arc.

nextyc$                Holds the Y position of the Arc Center, if the next move is a G2 or G3 arc.

nextzc$                Holds the Z position of the Arc Center, if the next move is a G2 or G3 arc.

nextx$                  Holds the next X position.

nexty$                  Holds the next Y position.

nextz$                  Holds the next Z position.

nextcflg$              Holds the next "Contour Flag" value. This one is important, since the Contour Flags are the only indicators of "where we are at, during a 'cut', while Contouring".

[pullo]

Found it , must have typoed myself out of the answer the first time around....I just invented a new verb here

Gracjan

[Colin Gilchrist]

I might have steered you wrong initially, with 'get_next'. There is no underscore character in the variable name...