Machine Group Name

[nickbe10]

Mornin' All,

Trying to get the Machine Group Name into my header. I have tried 3 different parameter numbers I found in the NCI & Parameters reference (19247, 19248 and 19970), but with no luck.

Have done it with Tool Group Name using Parameter 20018, but no luck with exactly the same procedure on the Machine Group Name

Do I need to use the NCI gcode 1051 and a buffer? Or am I missing something else....?

[Colin Gilchrist]

There is a "helper" variable, 'rd_mch_ent_no$' that tells MP, "which variables" do I grab?

Parameters are "automatically" read at the start of each Operation, based partly on "the value of 'read machine entity number' helper variable".

If you look in the 'psynclath$' Post Block (check the spelling, I may have a typo in there!), you will see the following line of code:

rd_mch_ent_no$ = syncaxis$

This basically tells MP to "only read the Machine Definition Parameters" for the "Current Axis Combination".

The trick is to change this to:

'rd_mch_ent_no$ = -1'.

Setting 'rd_mch_ent_no$' to "-1", tells MP to "Grab all the Machine Parameters"...

[Colin Gilchrist]

Hey, we should build some of your Lathe Posts this coming weekend!!!

[nickbe10]

30 minutes ago, Colin Gilchrist said:

If you look in the 'psynclath$' Post Block

Hey Colin,

This is for my Mill posts. Just playing with my Header a bit.

I want to output the Machine Group Name (which always contains the p/n and rev) and the Toolpath Group Name (on which I normally have the operation description) on 2 adjacent lines, so output would look like this:

(PROGRAM  - 526W2514-16_REV_)
(OPERATION  - HEX AND WIRELOCK HOLES)

I have everything except the p/n and rev outputting correctly........can I use the "rd_mch_ent_no$=-1" and then use the parameter 19970? I take it that having extracted it here I don't need to extract it in the pparameter post block? Just declare the string.....?

 

[Zaffin_D]

47 minutes ago, nickbe10 said:

Hey Colin,

This is for my Mill posts. Just playing with my Header a bit.

I want to output the Machine Group Name (which always contains the p/n and rev) and the Toolpath Group Name (on which I normally have the operation description) on 2 adjacent lines, so output would look like this:

(PROGRAM  - 526W2514-16_REV_)
(OPERATION  - HEX AND WIRELOCK HOLES)

I have everything except the p/n and rev outputting correctly........can I use the "rd_mch_ent_no$=-1" and then use the parameter 19970? I take it that having extracted it here I don't need to extract it in the pparameter post block? Just declare the string.....?

 

If you are in MasterCAM2017+, you should be able to use the groupinfo function.

      sMachineGroupName = groupinfo(19248)
      sMachineGroupName, e$

 

[nickbe10]

54 minutes ago, jeff.D said:

If you are in MasterCAM2017+,

I am afraid I am an X9 laggard......looks like one more good reason to jump to 2018 which I have loaded but not even started to configure yet......

Thanks for the info tho'

[Colin Gilchrist]

I talked with Nick about this, and he agreed that it would be help others if I just responded in this thread.

The answer to your question will follow, but first, a little background.

Reading Parameters: how MPMaster is setup by DEFAULT

• MPMaster is a 4X Mill Post, that is based off the Generic Fanuc 4X Mill Post from CNC Software.
• This post contains "build-in" logic to read -Operation Parameters, -Control Definition Parameters, - Toolpath Group Parameters, and -Machine Definition Parameters.
• The "default" logic is setup to detect if the MD has a "Rotary about X or Y" of the WCS, or "Rotary about Z".
• Based on the configuration of the Rotary Component Properties, MPMaster will set a variable switch called 'vmc'. If "vmc = 1", we are using a Vertical Machine, and if "vmc = 0", we have a Horizontal Machine.

So, how does all this "Parameter Processing" logic work?

• There is a predefined Post Block named 'psynclath$', that has a somewhat misleading name. It is not a "Lathe" Post Block. The 'psynclath$' Post Block is the Entry Post Block for the NCI Gcode 950 Line. This is the "Axis Combination" Line. This NCI 950 is positioned before every "actual tool change" event. This would be NCI Gcodes 1001 and 1002. (psof$ and ptlchg$). Again, this Post Block already exists inside MPMaster...
• So, the purpose of 'psynclath$' is to do two things: 1. We call 'pset_mach', where all the "magic" happens. Based on the results of 'pset_mach', we then set the value of 'rotaxtyp$'. This is done at "every Tool Change event" automatically, because of the existing logic inside 'psynclath$'.

Ok, so what happens inside 'pset_mach'???

• This is where all of the 'Control Definition', 'Toolpath Group Parameters', and 'Machine Definition Parameters' get captured!
• How does this happen???
• MP has special "Command Variables" that trigger a "routine" to be called.
• This is partially explained in the "comments" inside the Post Block 'pmachineinfo$'...
• When each of these "Command Variables" is encountered on a Post Line, by itself, it triggers the mechanism in MP to "dump" the parameters". This means that MP will repeatedly call the same Post Block (pmachineinfo$), over, and over, and over again. Each time, it reads the logic inside the body of 'pmachineinfo$' to determine "do I do anything with the particular Parameter number, that I'm processing at the moment?"... Well, the answer to that questions is; "We only capture what you want to capture, based on your "prmcode$" logic...

It is important to understand that 'pparameter$' is only used for processing "Operation Parameters". 'pparameter$' is called automatically before the start of each Tool Change Event. But, it can only capture the Parameters in the Operation Parameter Range. That is Parameters 10,000 - 16,999. So any numbers "greater than 17,000", cannot be captured inside 'pparameter$'.

To capture MD, CD, and tlpathgrp Parameters, you need to understand the following:

• The command variable 'rd_md$' calls > 'pmmachineinfo$' for Parameters Codes 17,000 - 17,999 (Reads MD Parameters)
• The command variable 'rd_cd$' calls > 'pmachineinfo$' for Parameter Codes 18,000 -18,999 (Reads CD Parameters)
• The command variable 'rd_tlpathgrp$' calls > 'pmachineinfo$' for Parameter Codes 19,000 - 19,999 (Toolpath Group Parameters)

When you look inside the 'pset_mach' Post Block, low and behold, we have those Command Variables being "called", which process the MD, and CD variables. I only mention MD and CD variables, because there is no "default logic" that is enabled by default, to read the tlpathgrp parameters. (There is a skeleton of logic in place for creating a "lookup table", but it is "commented out".)

There is actually a "script processing order" that we call events inside 'pset_mach', just based on the default behavior of MP.

• At the start of 'pset_mach', we set our "error tracking" variables to "0", for our Rotary Count, Rotary Error, and "Rotate on X". ('rot_on_x' is a generic "flag" variable, which MPMaster uses to track "do we have a Rotary Axis Component" attached to our Axis Combination (yes or no)?
• We set these variables to "zero" at the start, and the logic will then "populate" these variables, based on the logic inside 'pmachineinfo$'.
• The first major "event" inside 'pset_mach' after setting these variables, is 'rd_cd$'.
• When 'rd_cd$' is read on that line inside 'pset_mach', we then "dump and process" all the Control Definition Parameters (18,000 - 18,999).
• When we "process parameters", we literally read each and every "numeric parameter" that isn't a "null value", in numeric order. (start at the top, and read down to the bottom.)

Now, if that doesn't make it confusing enough, there are "different methods" we can use to "read parameters".

• For each "Parameter" we process, a series of events takes place

1. MP puts the Parameter Number (as a whole number value), into 'prmcode$'.
2. It also puts the "Parameter Value as a STRING", into the predefined variable 'sparameter$'
3. Then, it calls 'pmachineinfo$', and looks for processing logic, that uses the current value of 'prmcode$', OR the logic can check the value of 'sparameter$' directly (for example, parse with 'strstr' function).

So, we are going to "loop through" all of the CD Parameter Numbers, starting at 18,000 and counting up to 18,999. We do this when the 'rd_cd$' command variable is read on the 4th line of 'pset_mach'.

Which numbers get captured? That all depends on the logic that is implemented inside 'pmachineinfo$'!!!

Ok, we talked about "2 different methods" of writing the 'parameter code' logic.

1. Inside 'pmachineinfo$', you can add as many Post Lines as you like, that query the value of the variable: prmcode$. This form of logic uses an "if" statement, sometimes in conjunction with an "And" statement, to determine if the value of 'prmcode$' matches an integer value (5 digit) that you compare the variable to. (if prmcode$ = 15240, xxxxxx). Often, we'll use this type of logic (if prmcode$ = xxxxx), in conjunction with "user defined Post Blocks" (a set of square brackets []), to allow "multiple actions" to occur, or to add additional "test" logic to take place.
2. In addition to writing your own 'prmcode$' Post Lines, there are "Parameter Tables" that were created for different purposes. A "Parameter Table" is a data structure in the MP Language that is used to "tie" a numeric or string variable to a "parameter code" value. These tables were created with the purpose of being able to easily "add" additional parameters to the table. If you look inside 'pmachineinfo$' there are already "calls" to run the code in the Parameter Tables, and load data into the variables in the table. The line of code: 'if prmcode$ >= 17000 & prmcode$ < 18000, result = fprm(1)'   <<<< What that does is says "if the value is between 18,000-18,999, then "check 'fprmtbl #1' for the current value of 'prmcode$'. If there is an "entry" in the data table, that matches the "current value" of the 'prmcode$' variable, then take the "value" of the 'sparameter$' string, and load that value into the 'parameter table entry' that matches 'prmcode$'.

 

 

 

[Colin Gilchrist]

Alright, I figured I should break this up into an additional response, before I lost the page.

Ok, so we've just currently discussed what happens when we get to "rd_cd$", and load the Parameter Table for CD.

Actually, scratch the code I copied above:

if prmcode$ >= 18000 & prmcode$ < 19000, result = fprm(2) #Run the parameter table for Control Definition Parameters

Ok, so that loads "parameter table #2" with data from the Control Definition. What happens next inside 'pset_mach'?

----------------------------------------------------

      if sof = 1,
        [
        maxfeedpm = 999999       #Uncomment these variables to force use of machine def values as initial lowest max feedrate value 
        maxfeedpm_m = 9999999    #Otherwise the default (post) initialization setting is used as initial value
        #minfeedpm = 999999
        #minfeedpm_m = 999999
        !maxfeedpm, !maxfeedpm_m  #, !minfeedpm, !minfeedpm_m
        rd_mch_ent_no$ = 0
        rd_md$       #Read machine definition parameters - calls pmachineinfo$
        ]

      rd_mch_ent_no$ = syncaxis$  #Retrieve machine parameters based on current axis combination - read from .nci G950 line
      rd_md$       #Read machine definition parameters - calls pmachineinfo$
      rd_tlpathgrp$  # Read toolpath group parameters - calls pmachineinfo$

      rd_prm_op_no$ = op_id$
      rd_params$       #Read operaitons parameters

---------------------------------------------------

That is the next section of the 'pset_mach' Post Block.

1. There is a "if" statement, to check and see if we are "inside the Start of File Tool Change Event". That is what the 'sof' switch being set to '1' indicates.
2. If we "are" processing 'start of file', then we set "min/max" feed values (inch and metric) to "high values", and "update" the variables. This causes '999999' to get loaded into the "current and previous" variable values. This means when we "read" the min/max feed values, the 'prv_' values will always be "something different", so a "zero" value is still valid, and modality will work to force the output (since the 'prv_' values are different!)
3. Notice what happens next!!! <<<<<<<<<<<<<<< We next set 'rd_mch_ent_no$' to '0'. We do this so we can "get all the machine parameters". Well, most of them anyway... (more on that later).
4. Then, we call 'rd_md$'. <<<<<<<<<<<< This "dumps" all the Machine Definition Parameters, and processes them in 'pmachineinfo$'. We "fill in the parameter table" of 17,000-17,999 values. (if you look at "parameter table #1", you can see if you look at the Parameter Tables themselves, exactly which values get captured. I'll paste in the logic below.
5. Next, we call 'rd_tlpathgrp$'. <<<<<<<<<<<<< This "dumps" all the Toolpath Group Parameters. Note: There is a "Parameter Table" that can be setup to "capture" Toolpath Group Parameters, by "un-commenting" (removing the Pound Signs). Or, alternatively, we can just add an "if prmcode$ = xxxxx" line to 'pmachineinfo$'.

Ok, so at this point, it is important to point something out. We ran the code inside "if sof = 1", on the "first tool change" event. We set the "Helper Variable" 'rd_mch_ent_no$' to "zero", so that we can get all of the "MD" parameters. This "helper variable" is important. You'll notice that in 'psynclath$', we set 'rd_mch_ent_no$' to be "equal to the value of 'syncaxis$'". This variable holds the "component ID" of the current Axis Combination. Internally (done by MP "auto-magically"), setting the rd_mch_ent_no$ this way "limits" the Parameter Values that are processed. This "filtering" helps reduce the Processing Time of the MP Posting Process. That is why this "mechanism" is built into the Post.

----------------------

So one really important thing to understand is this: in order to be able to access all the Parameter Numbers, in the MD, CD, tl_path_grp,  you need to set 'rd_mch_ent_no$' to MINUS ONE!!! (rd_mch_ent_no$ = -1).

rd_mch_ent_no$ = -1

You do this, to tell MP: "Get all the Parameters!!!".

In fact, you want to do this "at the start of your Program", so you can fill in the Header info, but you don't necessarily need this info "in the middle, or near the end".

So, I recommend changing this:

      if sof = 1,
        [
        maxfeedpm = 999999       #Uncomment these variables to force use of machine def values as initial lowest max feedrate value 
        maxfeedpm_m = 9999999    #Otherwise the default (post) initialization setting is used as initial value
        #minfeedpm = 999999
        #minfeedpm_m = 999999
        !maxfeedpm, !maxfeedpm_m  #, !minfeedpm, !minfeedpm_m
        rd_mch_ent_no$ = 0
        rd_md$       #Read machine definition parameters - calls pmachineinfo$
        ]

To this:

      if sof = 1,
        [
        maxfeedpm = 999999       #Uncomment these variables to force use of machine def values as initial lowest max feedrate value 
        maxfeedpm_m = 9999999    #Otherwise the default (post) initialization setting is used as initial value
        #minfeedpm = 999999
        #minfeedpm_m = 999999
        !maxfeedpm, !maxfeedpm_m  #, !minfeedpm, !minfeedpm_m
        rd_mch_ent_no$ = -1
        rd_md$       #Read machine definition parameters - calls pmachineinfo$
        ]

 

Next, enable the "Toolpath Group Parameters Table", by removing the pound sign, and setting your variables.

You can see my "changes" in the "Table #3" near the bottom. Notice that I added "three String Variable Initializations" prior to the Table itself. You must modify the "number of table entries". In my case, I added 3 variables.

 

# --------------------------------------------------------------------------
# Parameter lookup tables - You must adjust the size value if you add any parameters to these tables!
# --------------------------------------------------------------------------
# Machine Definition Parameters 
fprmtbl 1   42   #Table Number, Size
#     Param   Variable to load value into 
      17008   spostname    #Post Processor Filename
      17060   minfrdeg_old #this parameter no longer functions  MU00008b
      17054   minfeedpm    #Limit for feed in inch/min
      17055   maxfeedpm    #Limit for feed in inch/min
      17058   maxfrinv     #Maximum feedrate - inverse time - inch - Minimum value from MD as this is inverse time
      17059   minfrinv     #Minimum feedrate - inverse time - inch - Minimum value from MD as this is inverse time
      17922   maxfrdeg     #Maximum feedrate deg/min
      17062   minfeedpm_m  #Limit for feed in mm/min
      17063   maxfeedpm_m  #Limit for feed in mm/min
      17066   maxfrinv_m   #Maximum feedrate - inverse time - metric - Minimum value from MD as this is inverse time
      17067   minfrinv_m   #Minimum feedrate - inverse time - metric - Minimum value from MD as this is inverse time
      17080   scool50      #Coolant 1 On
      17090   scool51      #Coolant 1 Off
      17081   scool52      #Coolant 2 On
      17091   scool53      #Coolant 2 Off
      17082   scool54      #Coolant 3 On
      17092   scool55      #Coolant 3 Off
      17083   scool56      #Coolant 4 On
      17093   scool57      #Coolant 4 Off
      17084   scool58      #Coolant 5 On
      17094   scool59      #Coolant 5 Off
      17085   scool60      #Coolant 6 On
      17095   scool61      #Coolant 6 Off
      17086   scool62      #Coolant 7 On
      17096   scool63      #Coolant 7 Off
      17087   scool64      #Coolant 8 On
      17097   scool65      #Coolant 8 Off
      17088   scool66      #Coolant 9 On
      17098   scool67      #Coolant 9 Off
      17089   scool68      #Coolant 10 On
      17099   scool69      #Coolant 10 Off
      17101   all_cool_off #First coolant off command shuts off ALL coolant options
      17102   v9_coolant   #Use V9 coolant option
      17406   lim_lo       #Lower rotary axis limit
      17407   lim_hi       #Upper rotary axis limit
      17391   axis_label   #Axis label - 1=X,2=Y,3=Z
      17397   srot_label   #Rotary Axis label (Generally A, B or C) - Not yet available.
      17401   rot_zero     #Rotary zero degree position                            
      17402   rot_dir      #Rotary direction
      17408   rot_index    #Index or continuous
      17409   rot_angle    #Index step
      17410   rot_type     #Rotary type

# Control Definition Parameters 
fprmtbl 2   1    #Table Number, Size
#     Param   Variable to load value into 
      18705   arccomp


str_tgp_1 : ""
str_tgp_2 : ""
str_tgp_3 : ""
# Toolpath Group Parameters 
fprmtbl 3   3    #Table Number, Size
#     Param   Variable to load value into 
      19247    str_tgp_1
      19248    str_tgp_2
      19970    str_tgp_3

Finally, I must "un-comment" this line in "pmachineinfo$":

      #Read parameter lookup tables - 
      if prmcode$ >= 17000 & prmcode$ < 18000, result = fprm(1) #Run the parameter table for Machine Definition Parameters
      #Leave lines below commented until you enter values in related lookup tables
      if prmcode$ >= 18000 & prmcode$ < 19000, result = fprm(2) #Run the parameter table for Control Definition Parameters
      #I uncommented the line below:
      if prmcode$ >= 19000 & prmcode$ < 19900, result = fprm(3) #Run the parameter table for Toolpath Group Parameters

 

 

 

[So not a Guru]

Thanks Colin! I save these explanatory pages offline, in the folder with my MP documentation, because I find them so incredibly valuable in understanding how to work with the posts.

We, on this forum, are blessed to have your expertise and your willingness to take so much of your time to share and teach us all!

[nickbe10]

Nice one Colin. I will play with this later today, the "children" are needy this morning......Will report back with results.

Thanks again Bro'.....talk later in the week!

1 hour ago, So not a Guru said:

We, on this forum, are blessed to have your expertise and your willingness to take so much of your time to share and teach us all!

Couldn't have put it better myself SNG!

[nickbe10]

17 hours ago, Colin Gilchrist said:

Finally, I must "un-comment" this line in "pmachineinfo$":

 

11 hours ago, So not a Guru said:

Thanks Colin!

So needless to say it worked, but where is the emogi for the heavens opening with sun beams shining through and the chorus of angels....?

OK or how about.

So I have heard you talk about the Gentleman at Postability doing "special" things with the MD. Is it this on steroids, certainly opens up some possibilities....

Thanks again C

[Colin Gilchrist]

Hi Nick,

Yes, Dave has been using this "Parameter Reading" capability for years now. He "hooks up" his Post to read the settings in the MD for the Rotary. So if you want to make a change to the Post output, all you do is make an adjustment in the MD, and "presto", the output from your Post is altered correctly, without having to mess with a single variable. All the logic he uses to do the "reading" is encrypted of course, so we don't really know what he is doing "under the hood", I'm just making some educated guesses about what he is doing...