M05 at specific tool changes

[Luke.Hicks430]

My Lathe manager doesn't like having an M05 at the end of every tool block because this is unnecessary wear on the spindle/brakes. So I manually edit them out at every tool change. 

I am currently working on our postprocessor to have it post out all the consistent manual changes I make. I have considered taking the M05 out of the line in the PP so that it will go away, but I have one problem with that: When our lathe is going from a turning tool to a milling tool I want that M05 to be there.

 

Is there a variable or some line of code that I can use in an "if" statement that will only put the m05 in there is the next tool is a milling tool?

 

For example:

 

If (next tool is mill tool),

     [

     pbld, n$, "M05", e$

     ]

 

Thank you for your help!

[Colin Gilchrist]

Which post are you starting with? That will make all the difference in how you should go about accomplishing this.

 

The variable 'posttype$' determines if you are in Lathe mode (posttype$ = 2), or not (posttype$ = 1 (mill), or 0 (undefined))

 

But...

 

That variable only shows what the "current" operation value is. To get the "next" operation posttype$ value, you need to use a buffer. The 'Generic Fanuc 4X MT_Lathe' post has a buffer built into it, that tracks "previous", "current", and "next" values for operations. It actually stores and tracks something like 31 different variables related to the tool, turret, spindle, chuck, operation, tool change, cut type, spindle direction, operation id, and so on.

 

The post block 'preadcur_nxt' is used to read the "current" and "next" values from buffer 1. This allows you to check in 'ptoolend$' for what is coming at the "next" operation.

 

The code you'd need to add is pretty straightforward:

if n1_posttype <> posttype$ & n1_posttype = two, pnullstop

The 'pnullstop' will set the spindle direction 'selector' variable to output spindle off, then output the string select for the spindle, based on the current setting for 'posttype$'. So if you are in "Lathe" mode, it will output the Lathe Spindle Off code. If you are in Milling mode, it will shut off the Mill Spindle.

[Luke.Hicks430]

Colin,

 

does that catch if the next operation is a c-axis operation as well?

 

It seems to not be working for me.

 

I am using the 'Generic Fanuc 4X MT_Lathe'.

 

I'm editing this all in the pl_retract post block.

 

Here's where I'm currently at:

pl_retract      #Retract tool based on next tool gcode, lathe (see ptoolend)
      cc_pos$ = zero
      if home_type = one,
        [
        pmap_home   #Get home position, xabs
        ps_inc_calc #Set inc.
        pbld, n$, psccomp, e$
        pcan1, pbld, n$, *sgcode, pfxout, pfyout, pfzout, *toolno, e$
        pbld, n$, strcantext, e$
        if n1_posttype <> posttype$ & n1_posttype = two, 
	     [
	     pbld, n$, pnullstop
	     if spindle_no = 1,
      	  	   [
      	  	   string11, e$
      	  	   ]
      	     else,
      	 	   [
      	 	   string13, e$
      	  	   ]
	     ]
        ]
      else,
        [
        #Retract to reference return
        pbld, n$, `sgcode, psccomp, e$
        if home_type = m_one, pbld, n$, *toolno, e$
        pcan1, pbld, n$, *sg28ref, "U0.", [if y_axis_mch, "V0."], "W0.", strcantext, e$
        if n1_posttype <> posttype$ & n1_posttype = two, 
	     [
	     pbld, n$, pnullstop
	     if spindle_no = 1,
      	  	   [
      	  	   string11, e$
      	  	   ]
      	     else,
      	 	   [
      	 	   string13, e$
      	  	   ]
	     ]
        cutoff_proc = zero  #Reset flag if we are retracted
        if home_type > m_one, pbld, n$, e$
        ]

String 11 is to select which spindle to stop, string 11 = P11

[Luke.Hicks430]

I noticed that my 'preadcur_nxt' block does not contain the variable "n1_posttype"

 

Here's my preadcur_nxt block:

preadcur_nxt    #Read current and next tool record
      c1_gcode = rbuf (one, rc1)     #Current tool record
      #Place buffered variables in post global variables
      cuttype = c1_cuttype
      lathtype = c1_lathtype
      lathecc = c1_lathecc
      gcodecc = c1_gcodecc
      y_axis = c1_y_axis
      millcc = c1_millcc
      n1_gcode = rbuf (one, nc1)     #Next tool record
      if cuttype = one, cc_1013$ = one
      else, cc_1013$ = zero
      if lathecc = zero, compok = one
      else, compok = zero

[Luke.Hicks430]

I figured it out,

 

The line you gave me should have been:

if n1_posttype <> posttype$ & n1_posttype <> two, pnullstop

Thank you for your help!

[Colin Gilchrist]

Glad you got it figured out Luke!

 

The reason you don't see that variable being set is because of the way that Buffer Files work.

 

Inside the "Pre-Read" section of the post, this is where we fill in the values to the buffer file, using the 'wbuf' command. The thing about the MP Language is this: you can only pass a single parameter to a function. So when you write to a buffer, and read from a buffer, you are telling MP what the starting index variable name is to a ordered list of variables. This gives the affect of passing a single dimension array to the function.

 

In the case of Buffer #1 for the 'Gen Fan 4X MT_Lathe' post, that buffer is defined as holding 31 separate numeric variables. So each call to 'wbuf' or 'rbuf' reads or writes all 31 variables at once.

 

Look at the 'preadcur_nxt' post block. There are two separate 'rbuf' calls:

	  c1_gcode = rbuf (one, rc1)     #Current tool record
	  #
	  # Lines in-between buffer read functions removed for clarity
          #
          n1_gcode = rbuf (one, nc1)     #Next tool record

In both cases, the 'rbuf' function is setting the values of 31 different variables, with a single call, from the exact same buffer number. There are exactly two differences in each buffer read function:

1. The Index variable, which tells MP what variable is the first variable in the ordered list is different. The first 'rbuf' function call starts with 'c1_gcode'. So that is where the first piece of data gets written, and the next 30 variables get written, in order, into the next 30 variables that follow. The same is true for the call that starts with 'n1_gcode'; it is writing to a list of 31 variables that starts with 'n1_gcode'.
2. The only other difference between the calls is the record index variable. This is the 2nd argument in the function. For the first call, the variable is 'rc1'. The second call uses 'nc1'. The only difference between the value of the two variables is that the value of 'nc1' is offset by '1'. So basically, the 'rc1' variable number would match the value of the tool change being processed, and the 'nc1' variable would be offset by "1" tool change, so you are getting the "next" row from the buffer.

When the function call "n1_gcode = rbuf (one, nc1)" is made, that is where the 'n1_posttype' variable is being set. That variable (n1_posttype) is the 19th variable in the ordered list. Once the single 'rbuf' call is made, it makes all 31 variable values available, with only one function call.

 

The same thing is true for writing to a buffer, but in that case, you must set all the values of the ordered list, prior to calling 'wbuf'. If you look in 'pcur_recd', all 31 variable values are set prior to the 'wbuf' call. There are actually only 24 variables set "directly" in that post block, but there are three post block calls which set the remaining variables:

 

pmatrix_su

pset_turret

pmap_home

 

All three of those post block calls will end up setting the remaining 7 variables in the ordered list. So all 31 variables get set, and then there is a call made to "write" the variable values: c1_gcode = wbuf (one, wc1).

 

The only other thing about buffers that can be a little confusing is the way that the record index variables work. Every time a read/write call is made to the buffer file, the record index variable is automagically incremented by '1'. So the next time the post block is called, the variable is already increment by '1' from the last time it was called. That way MP can "keep track" of which record to read from, or write to, the buffer file. The only time this "auto-increment" function is not true is if you set the Command Variable buf_no_index$ to '1'. That prevents the record index variable from being automatically incremented, which then requires that the post writer keep track of the value and set it prior to making the read or write call.