Null tool sequence numbering

[So not a Guru]

I'm working with the Generic Haas 3X post.

I want to out put sequence numbers matched to the Mastercam operation number on null toolchanges. But I only want the numbering to output at the beginning of the operation, instead of at every retract.

I use this at my actual toolchanges:

      if omitseq$ = 1 & tseqno > 0,
          [
          if tseqno = 2, n$ = t$
      if tseqno = 3, n$ = opmgr_opno
          pbld, *n$, comment$, e$
          ]

I'm thinking I should be able to add some AND logic to the 1st line that would limit the output, but I can't figure out how.

[So not a Guru]

After looking thru the variable choices, I thought cutpos2$ would work here

      if omitseq$ = 1 & tseqno > 0 &cutpos2$ = 0,

But, I get no sequence number output at null change at all that way. Am I misunderstanding how the cutpos2$ variable should work?

[So not a Guru]

I see, I missed that 0 resets at null tool changes. Back to the drawing board

[Guest]

You need to set a condition check....

=Since you're using the Op number

You 'll want to set a if opnumber is not equal to prv_opnumber, to output the new n otherwise pass on through 

[Colin Gilchrist]

Operation Number is not available as a pre-defined variable, but is available as Parameter 15240. There is an 'internal' operation flag variable that will hold the "reference ID" of the Operation. This is what most post developers use to check and see if they are processing a "new" operation, but that won't give you what you want, which is a Sequence Number that matches the Mastercam Operation Number.

Do a search on the forum for 'op_num', or '15240'. You should get some hits explaining how to capture the parameter value in a user defined variable.

You need to be sure you update (!) the variable at the end of 'ptlchg$' and 'ptlchg0$', so that MP will track the previous value.

The logic would be something like this:

If op_num <> prv_op_num & omitseq$ = 1 & tseqno > 0, pdosomething.

[crazy^millman]

What if you wanted the N block number to be in the tool list and at each tool call? Will you need a buffer? I did a simple process, but if the tool gets used more than once the process is broken and it doesn't match. I am thinking the dreaded buffers will be needed since buffers are used for making the tool list. How do you make the tool list use a number and then have the program use it for a tool even if the tool is used more than once in the program? Any way without buffers?

[So not a Guru]

10 hours ago, Colin Gilchrist said:

Operation Number is not available as a pre-defined variable, but is available as Parameter 15240. There is an 'internal' operation flag variable that will hold the "reference ID" of the Operation. This is what most post developers use to check and see if they are processing a "new" operation, but that won't give you what you want, which is a Sequence Number that matches the Mastercam Operation Number.

I got that bit, my opmgr_opno variable is = to the 15240 in my pparameter postblock

if prmcode$ = 15240, opmgr_opno = rpar(sparameter$,1)      #Operation number

I have the Mastercam operation numbers outputting fine if the operation is at an actual toolchange, or "Force tool change" box is checked. It's only in my ptlchg0$ postblock that I'm struggling.

I can get the Mastercam op numbers to post, but it causes the number to repeat at every retract move, in all ops.

10 hours ago, Colin Gilchrist said:

If op_num <> prv_op_num & omitseq$ = 1 & tseqno > 0, pdosomething.

I'm gonna play with this & see if I can get something like it to work.

Thanks Colin

[Zoober]

11 hours ago, C^Millman said:

What if you wanted the N block number to be in the tool list and at each tool call? Will you need a buffer? I did a simple process, but if the tool gets used more than once the process is broken and it doesn't match. I am thinking the dreaded buffers will be needed since buffers are used for making the tool list. How do you make the tool list use a number and then have the program use it for a tool even if the tool is used more than once in the program? Any way without buffers?

Couldn't you use the normal lookup table method used for N$ increments inside the buffer and ptlchg to keep track?

Of course you would prolly want to use different  variables  (say tused and btused ) inside the buffer and in ptlchg postblock

I think they would maintain the same increments whether pre-processed (buffer) or processed.

      tused = flook(3,t$)
      #"This tool has been used ", *tused, "times", e$  ### Debug for counting number of tool changes for N numbers. 0 is first time run.
      result = finc(3,t$)

Just thinking out loud...

[Colin Gilchrist]

11 hours ago, C^Millman said:

What if you wanted the N block number to be in the tool list and at each tool call? Will you need a buffer? I did a simple process, but if the tool gets used more than once the process is broken and it doesn't match. I am thinking the dreaded buffers will be needed since buffers are used for making the tool list. How do you make the tool list use a number and then have the program use it for a tool even if the tool is used more than once in the program? Any way without buffers?

If you wanted to tie the N Block value to the Tool Number, and also indicate "which" use that N Block is (example: N0010001 "T1" use "0001", N0010021 "T1" use "0021"), then yes, you'd need a buffer.

But I think Zeke is asking for a Block Number that matches the Operation Number in Mastercam. That would be doable during Tool List generation, and also during NC Code output, without needing a buffer file.

 

[crazy^millman]

10 hours ago, Zoober said:

Couldn't you use the normal lookup table method used for N$ increments inside the buffer and ptlchg to keep track?

Of course you would prolly want to use different  variables  (say tused and btused ) inside the buffer and in ptlchg postblock

I think they would maintain the same increments whether pre-processed (buffer) or processed.

      tused = flook(3,t$)
      #"This tool has been used ", *tused, "times", e$  ### Debug for counting number of tool changes for N numbers. 0 is first time run.
      result = finc(3,t$)

Just thinking out loud...

Right there you just lost me. I have never been able to wrap my brain around buffers. I thought I had some time ago, but every time I kept getting bad results. We need to make this happen for a customer so I will reach out and see whom can help us get this done. Thanks for the suggestion I really appreciate it. Here was how I did my poor mans process.

 

fmt  "N" 4  nstore        #Sequence Number Store

ptooltable      #Tooltable output
      sopen_prn, no_spc$, *n$, *t$, sdelimiter, pstrtool, sdelimiter, *tlngno$, no_spc$, sclose_prn, e$


psof$            #Start of file for non-zero tool number
      if output_graph, pgraphics #Output Okuma Graphics Code, see pgraphics
      pcuttype
      probe_head$
      nstore = one
      toolchng = one
      if ntools$ = one,
        [
        #skip single tool outputs, stagetool must be on
        stagetool = m_one
        !next_tool$
        ]
      pbld, n$, *sgabsinc, sg80, "G40", *sgcode, e$
      inhibit_probe$
      sav_absinc = absinc$
      ptoolcomment, e$
      pbld, *nstore, "G30 P1", e$ 


ptlchg$          #Tool change
      pcuttype
      toolchng = one
      nstore = nstore + 1
      if mi1$ = one, #Work coordinate system
        [
        pfbld, n$, *sg28ref, "X0.", "Y0.", e$
        pfbld, n$, "G92", *xh$, *yh$, *zh$, e$
        ]
      inhibit_probe$
      if prog_stop = one, pbld, n$, *sm01, e$
      if prog_stop = two, pbld, n$, *sm00, e$
      ptoolcomment, e$
      pbld, *nstore, "G30 P1", e$ 

The above works great if you use the tools and don't reuse them again in the program, but if you need to use them again then the above is no good. The tool numbers are not the important part of the equation it is when it is called in the tool list the N number matches the N number in the program where the tool is called. Can't use mid auto restart on the machine because they don't want to use block numbers, but on Okuma's I don't know of another way to mid auto restart in the middle of an operation without block numbers. They consider just having the N number at the Tool Change good enough for restart purposes, but again posted out of Mastercam like I have it will only work if the tool is not used more than once in the complete program and everything follows a perfect order.

[Zoober]

In our toolchange block, we use a lookup table and increment it each time the tool is used.

Here is a part of the lookup table:

# --------------------------------------------------------------------------
# Define Tool Number Usage
flktbl  3       64      #Lookup table definition - table no. - no. entries
    0   1
    0   2
    0   3
    0   4
    0   5
    0   6
    0   7
    0   8
    0   9
    0   10
    0   11
    0   12
    0   13
    0   14

.................................

And here is how we increment it in our ptlchg_com postblock:

tused       : 0     #Nth time a tool is used - for N9 numbering


ptlchg_com      #Tool change common blocks
     .........	
	code and stuff here
........

      tused = flook(3,t$)
      #"This tool has been used ", *tused, "times", e$  ### Debug for counting number of tool changes for N9 numbers. 0 is first time run.
      result = finc(3,t$)
      if tused = 0, n$ = (t$*10)+ tused
      if tused > 0, n$ = (t$*100)+ tused
      if plane$ < 0, plane$ = 0
      if sof & scomm_sav <> snull,
        [
        spaces$ = 0
       *n$, pspc, scomm_str, *scomm_sav, scomm_end, e$
        spaces$ = sav_spc
        ]
....... more code and stuf here
.......

We use the tused variable to store the tool number and number of times used.

The finc(3,t$) line increments the lookup table value of times used by one.

For T1, it outputs N10 the first time used, then it outputs N101 second, N102 third, N103 fourth, etc....

For T2, it outputs N20 the first time used, then it outputs N201 second, N202 third, N203 fourth, etc....

[crazy^millman]

1 hour ago, Zoober said:

In our toolchange block, we use a lookup table and increment it each time the tool is used.

Here is a part of the lookup table:

# --------------------------------------------------------------------------
# Define Tool Number Usage
flktbl  3       64      #Lookup table definition - table no. - no. entries
    0   1
    0   2
    0   3
    0   4
    0   5
    0   6
    0   7
    0   8
    0   9
    0   10
    0   11
    0   12
    0   13
    0   14

.................................

And here is how we increment it in our ptlchg_com postblock:

tused       : 0     #Nth time a tool is used - for N9 numbering


ptlchg_com      #Tool change common blocks
     .........	
	code and stuff here
........

      tused = flook(3,t$)
      #"This tool has been used ", *tused, "times", e$  ### Debug for counting number of tool changes for N9 numbers. 0 is first time run.
      result = finc(3,t$)
      if tused = 0, n$ = (t$*10)+ tused
      if tused > 0, n$ = (t$*100)+ tused
      if plane$ < 0, plane$ = 0
      if sof & scomm_sav <> snull,
        [
        spaces$ = 0
       *n$, pspc, scomm_str, *scomm_sav, scomm_end, e$
        spaces$ = sav_spc
        ]
....... more code and stuf here
.......

We use the tused variable to store the tool number and number of times used.

The finc(3,t$) line increments the lookup table value of times used by one.

For T1, it outputs N10 the first time used, then it outputs N101 second, N102 third, N103 fourth, etc....

For T2, it outputs N20 the first time used, then it outputs N201 second, N202 third, N203 fourth, etc....

Look great, but how do you tie that to a the tool list like this? You see the tool numbers don't follow any traditional tool number so the tool numbers cannot be used to track the process they are being used, but since they can be any random tool number they must be accounted for, however the numbers cannot be relied on to query as part of the process. Where I just cannot see how to make buffers do what needs to be done here since they use traditional process to store and query stored data, not random in nature data like we are dealing with here on this project.

(N1 T27011202 - 28.57 SPOT FACE MILL - H27011202)
(N2 T15400000 - 102 MM FACE MILL - H15400000)
(N3 T15999930 - 10.00" FACE MILL - H15999930)
(N4 T15600030 - 155 MM FACE MILL - H15600030)
(N5 T35100050 - 1.00 SPOT DRILL 135D - H35100050)
(N6 T30031251 - 8 MM DRILL - H30031251)
(N7 T30053150 - 17/13 DRILL - H30053150)
(N8 T30031252 - 5/16 EXL DRILL - H30031252)
(N9 T74035650 - DS-1150 PORT TOOL - H74035650)
(N10 T68039350 - M10X1 RIGHT-HANDED TAP - 10 - H68039350)
(N11 T23019750 - 5MM FLAT ENDMILL - H23019750)
(N12 T35037550 - 3/8 SPOT DRILL 90D - H35037550)
(N13 T30075050 - 3/4 DRILL - H30075050)
(N14 T59106051 - P-HOLE PORT TOOL - H59106051)
(N15 T33078750 - 20 MM DRILL - H33078750)
(N16 T74081250 - DS-1156 PORT TOOL - H74081250)
(N17 T68086650 - M22X1.5 RIGHT-HANDED TAP - 22 - H68086650)
(N18 T43224450 - 56.26 FINE BORING TOOL - H43224450)
(N19 T33029950 - 7.5 MM DRILL - H33029950)
(N20 T45224950 - 57.125 FINE BORING TOOL - H45224950)
(N21 T30040651 - 13/32 DRILL - H30040651)
(N22 T30034450 - 11/32 DRILL - H30034450)
(N23 T33026851 - 6.8 MM DRILL - H33026851)
(N24 T35075050 - 3/4 SPOT DRILL 90D - H35075050)
(N25 T50031851 - .320 REAMER - H50031851)
(N26 T50003101 - 7.96 REAMER - H50003101)
(N27 T86125050 - 1 1/4 CHAMFER MILL - H86125050)
(N28 T68047252 - M12X1.75 RIGHT-HANDED TAP - 12 - H68047252)
(N29 T68031550 - M8X1.25 RIGHT-HANDED TAP - 8 - H68031550)
(N30 T45200050 - 50.8 FINE BORING TOOL - H45200050)
(N31 T29025050 - 6 MM ENGRAVER 60D - H29025050)

(T30040651 - 13/32 DRILL - TOOL DIA. - 10.319)
N21 G30 P1
T30040651 M6
N21 M403 TLFON
G15 H25
(***TAP DRILL DS-1323 LOCS. *** B180 H-25***)
G0 G90 G15 H25 X-29.36 Y47.09 B180. T30034450

Here even through we are 1255 lines into the program the N21 matches the N21 in the Tool list. I need a bullet proof process that I know without a shadow of a doubt will match the N number in the Tool list to the N Number in the program. Like I have it works, but again use that tool more than once you break the connection and it is not bullet proof. What you have tracks the tools and updates them begin used through the program, but I see not correlation between the tool list to make sure they match. OP_ID$ will not work or OP_Number will not work since again the tool numbers are random in nature and no way to track tool number 15 to make sure N15 is being used since it may be T98467350. Hopefully I am making sense and not over thinking this.

Zeke sorry for the highjack.

[Zoober]

I would have to see how the tool list is being created. Normally, it is with buffers.

[Zoober]

Just a heads up....

When creating a buffer for 8 digits tool numbers, be sure not to index on the tool. Use a different value, even if it is a dummy.

Otherwise, your buffer might end up with 86,125,050 or so records.

[So not a Guru]

On 5/10/2017 at 1:23 PM, C^Millman said:

Zeke sorry for the highjack

It happens, no worries.

[KORLOY]

Hi guys and "So not a Guru"!

I have absolutely same problem -  I can't solve my op_num output on every retract. So how you solve the problem? I played with 

If op_num <> prv_op_num & omitseq$ = 1 & tseqno > 0, pdosomething.

 like Colin said, but didn't worked for me.

So,

n$=op_num
pbld, n$*, e$

added in the ptlchg0$ postblock is causing op_num output on every retract, what logic I need to add in this postblock to get correct op_num output)??

Thanks for the answers! 

[jlw™]

I do this in practically every post I do.  I also want a block number on my null tool changes.  I also want that block number to be the Mastercam op manager op number so I can find it easily if I need to tweak something.  So, here's the short of what I do.

First, setup a variable to store your op number:

fmt "N" 4 blockno

then setup the postblock:

pfn #output block numbers = mcam op number

        blockno = opinfo(15240,0)

        *blockno

Now we call it in the post by placing the "pfn" any where we want the block number.  I like it right before my comment in ptlchg$ and ptlchg0$.  This will give you block numbers at safe start points as well as every op change from mastercam.  It makes using X+ setup sheets even nicer because the N# in the program matches the sheet and your guys can check them off as they go down the sheet.

I personally prefer a blank line between ops to so I often add *e$ in my pfn block.  It makes scrolling through the code on a control panel a little cleaner to see the breaks.

Hope that helps and if you don't like the op manager number you can setup logic to count up however you like.

It's quick and easy and give you what you want.

[KORLOY]

I tried your method "JLW" but it didnt worked, it's still posting N on EVERY RETRACT

Program looks like this :

 

As you can see I manage to get correct N on the Start at the program and at ptlchg$  (#Tool change), but at ptlchg0$  (tool number repeats)  It's not working like I prefer. 

Here is a post segment:

 

 

By the way, why pspindchng is working great? It changes only ONE time with retract to second block.

I'm so close to get result that I want , than my N will perfectly match X+ setup sheet!

Thank you!

 

[Zaffin_D]

Check the current op_id$ to the previous op_id$.

if op_id$ <> prv_op_id$,

  [

  #Write opnum only if we are at a new    op

  ]

[Colin Gilchrist]

7 minutes ago, jeff.D said:

Check the current op_id$ to the previous op_id$.

if op_id$ <> prv_op_id$,

  [

  #Write opnum only if we are at a new    op

  ]

But for this to work, it also depends on where in the Post the 'op_id$' variable is updated. Some Posts have '!op_id$' at the end of 'ptlchg_1002'. So what I do is comment out, or remove that code, and add '!op_id$' to the end of 'psof$', 'ptlchg$', and 'ptlchg0$', so the 'op_id$ <> prv_op_id$' check will always work...

 Note: ignore the single quote marks when using the variables...

[jlw™]

Be sure to uncheck "output sequence numbers" in the control def:

[KORLOY]

22 hours ago, Colin Gilchrist said:

But for this to work, it also depends on where in the Post the 'op_id$' variable is updated. Some Posts have '!op_id$' at the end of 'ptlchg_1002'. So what I do is comment out, or remove that code, and add '!op_id$' to the end of 'psof$', 'ptlchg$', and 'ptlchg0$', so the 'op_id$ <> prv_op_id$' check will always work...

 Note: ignore the single quote marks when using the variables...

Thank you Jeff, Colin and jlw™ . I made everything like you guys said (made a check - if op_id$ <> prv_op_id$, and updated "!op_id$")

 

but it causing an error

Where the problem is?

[Colin Gilchrist]

All logic inside a Post Block nush must be indented by spaces. MP is a column dependent language. Any statement that begins in the 1st column is always a "definition of something".

Standard indenting in MP uses 6 space  characters before the line of code starts, and every subsequent indent is 2 spaces.

The problem is you didn't put spaces in front of the if statement. So MP thinks you are trying to define a Post Block of some kind. 

[Colin Gilchrist]

I highly recommend you stop using whatever editor that is, and use Mastercam Code Expert to edit Posts.

[KORLOY]

Thank you  a lot!!!! worked!!!

By the way I commented---> #!op_id$  before this check, you can see it in the photo I attached if someone will need this in the future