Sub program location start/end file

[PMC Shop]

Fellow programmers;

 

I am trying to configure a post for use at multiple facility sites. I know that the control definition sets up subroutines to post out before or after the main program. Can anyone tell me how to change that setting from inside the pst? Is there a variable, a parameter, or something that I can use to switch back/forth on the fly? I've changed the setting in the control and compared the NCI files, but I cannot see anything that indicates where it happens. Anybody?

 

Any help will be appreciated;

 

-PMC

[Tim Johnson]

That is parameter 18713.

[PMC Shop]

Thank you Tim.

 

Can you possibly tell me what value range this parameter should be when read? My variable always seems to be zero. Maybe, since I have never had to worry about reading/writing parameters, I'm just not doing it right. I'm not getting any errors.

I borrowed some code from mpmaster. I am using rd_cd$ to to store 18713 in a variable in a table. I should mention that I am using Router, not Mill. The original pst what created in Mastercam 8, then v9, then X5 and finally X9. Everything works, and a lot of functionality was added.

 

variable definition:

# --------------------------------------------------------------------------

# General Output Settings

# --------------------------------------------------------------------------

wheresub    : 0      #Read param 18713, sub before/after main program

 

# --------------------------------------------------------------------------

# Parameter read postblocks:

# --------------------------------------------------------------------------

pprep$          #Pre-process postblock - Allows post instructions after the post is parsed but before the NC and NCI file are opened.

      param_read$ = 1      

      rd_mch_ent_no$ = 0  #Read only the machine base parameters (use to collect common parameters from CNC_MACHINE_TYPE)

      #rd_md$       #Read machine definition parameters

# Control Definition Parameters 

fprmtbl 2   1    #Table Number, Size

#     Param   Variable to load value into 

      18713   wheresub

# --------------------------------------------------------------------------

pset_mach

      rd_cd$ 

      rd_tlpathgrp$  # Read toolpath group parameters - calls pmachineinfo$

      rd_prm_op_no$ = op_id$

      rd_params$       #Read operaitons parameters

# --------------------------------------------------------------------------

# Machine definition and control definition parameter capture:

# --------------------------------------------------------------------------

pmachineinfo$   #Machine information parameters postblock

 

      #Read parameter lookup tables - 

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

 

Again, any and all help is greatly appreciated

[Tim Johnson]

Ok, it took a while but I got it.

 

It appears at least on my end and the way I did it, you need to open up the machine definition, open up the machine definition, make your subprogram change, HIT THE GREEN CHECK MARK FIRST and make MC ask you to save it. When I saved first it would save the file but not take effect (X9 bug?) then save the machine definition. If MC doesn't ask you the replace the machine then manually change it yourself. It didn't ask a few times.

 

What I did;

pheader$         #Call before start of file
      rd_cd$ # added                        

pmachineinfo$  # postblock called to retrieve data
           #"prmcode ->", ~prmcode$ "  :  data -> ", sparameter$, e$  # For Debugging
           # Capture the desired parameter
           if prmcode$ = 19248, sgroupname  = sparameter$
           if prmcode$ = 19105, smachinepath  = sparameter$
           if prmcode$ = 18713, wheresub = rpar(sparameter$, 1) #<<<<<<<<<<<<<<<<<<

      "(MACHINE NAME - ", *smachinename, ")", e$
#      "(MACHINE NAME - ", sgroupname, ")", e$ replaced 02-23-2008
      "(DATE: ", *smonth, "-", day$ , "-", year$ , ")", e$
#      "(MASTERCAM POST - ", "ENSHU JE60S)", e$
      #"(PROGRAM NAME - ", sprogname, ")", e
      #"(DATE=DD-MM-YY - ", date, " TIME=HH:MM - ", time, ")", e
#      "(MCX FILE  - ", smcpath$, smcname$, smcext$, ")", e$
      #"(MASTERCAM - V", *vers_no, ")", e
      #"(POST      - ", spostname, ")", e
      stck_matl$ = ucase(stck_matl$)
      #"(MATERIAL  - ", stck_matl, ")", e
      #"(PROGRAM   - ", sprogname, sextnc, ")", e
      #"(TIME      - ", *time, ")", e
      #"(POST DEV  - ", *slicense, ")", e
      "test", *wheresub, e$ # <<<<<<<<<<<<<<< added fot testing
      spaces$=sav_spc
      " ", e$

On after main program;

 

%
O621(JE80S 625-602-063 SHOULD BE 0)
(MACHINE NAME - ENSHU JE80S)
(DATE: APR-21-16)
testwheresub 0.  <<<<<<<<<<<<<<<<<<<<<<<<<<

 

On before main program;

%
O621(JE80S 625-602-063 SHOULD BE 1)
(MACHINE NAME - ENSHU JE80S)
(DATE: APR-21-16)
testwheresub 1.
 

Hope that helps

 

[PMC Shop]

It should. One last thing. Since I now know I was off in the wrong direction, how do I overwrite that parameter and force it to switch between before/after?

[crazy^millman]

It should. One last thing. Since I now know I was off in the wrong direction, how do I overwrite that parameter and force it to switch between before/after?

 

I think you will want to use a switch either a mi or mr switch from an operation.

[PMC Shop]

That's the plan, but writing it back to the parameter seems like it will have to occur in the header before the start of the file. How do I actually write to the parameter?

[crazy^millman]

That's the plan, but writing it back to the parameter seems like it will have to occur in the header before the start of the file. How do I actually write to the parameter?

 

Well guess you really need to define your process. Once you define your process and see what works and what does work on the machine then you can come back with a good method to work out what the post needs to do. Then once you can document that and give a clear direction you want to go in then someone can review it and see what will work and what will help you out. Right now it is just some back and forth on a napkin to see what you might do. I think there is already a lot of what you need existing it is just a matter of making sure someone is on the same page as you. Once that is established then someone should be able to help point you in the right direction. Hopefully that makes sense and helps guide you in the right direction.

[Tim Johnson]

I've not had a need to overwrite control definitions (yet) so I would have to do some playing around but I have my own work to do. I half remember Colin stating that during the posting process the machine def reads the post and then reinitializes the post to conform to the definition. I would think you can re-reinitialize the post after the def has done its carnage but without trying I don't know that.

 

If you have to manually change a parameter (mi$/mr$/cantext$) between posting in order to create a separate style of program wouldn't just changing the machine definition between each posting be about the same amount of labor?

[PMC Shop]

You're right. Creating a different machine def, control, and post would be one heck of alot faster and simpler. I'm attempting to idiot-proof the process long term. We're going to be adding three more facilities in three different states over the next couple of years. We're so busy right now, that we are getting behind. And yes, I have my own workload to do, too. Again, thanks for all of the help.

[Colin Gilchrist]

You should not try and manipulate this through the "post" only. The reason is that the MP.DLL (post engine) does a bunch of the work of "maintaining" the subprogram and main program "streams" for you. You can certainly disregard the switch inside the Control Definition, but if you do this; you are responsible for all file stream manipulation!

 

If you look at the Control Definition, that "before/after" switch is fairly important. When it is set to "Subs Before", the MP.DLL engine auto-magically sets the "Main Program output Stream" to the "EXT" file. It does this so that when you post, the NC file is "blank", the "Sub" file contains your Subprograms, and the "Main" file is written to the "EXT" file. In 'peof$', there is a call made first to "mergesub$", then "clearsub$", and finally, "mergeext$" and "clearext$" are used to merge in the "main" program (after the subs.)

 

When the switch is set to "after" the Main program is written to the main NC file, and the "Subs" are just merged and cleared after the main program is finished outputting inside 'peof$'.

 

The reason I say to do this in the CD, is due to the fact that MP.DLL is controlling the output streams for you, "behind the scenes".

 

Even though you have multiple sites coming online soon, you should still try an maintain a standard like this:

 

1 Machine Definition, 1 Control Definition, and 1 Post, for each machine that is being programmed. Make the Machine and Control Definitions the place were you do the "configuration" of each machine. You should be able to setup all the coolant options, Drill Cycles, and yes, subprogram styles, from within the MD/CD.

 

In fact, depending on your specific situation, there is no reason not to have 1 post for "all 3 axis routers", but have a different MD/CD setup to reference this "universal" post.

 

 

As I mentioned, you can manipulate the Subprogram Streams if you wish, but you lose some of the "auto-magic" that happens in the background when you do this.

 

You'll need to be familiar with the "File Manipulation" functions:

  subout$ = zero #The 'subout$' variable controls the "output stream". There are 4 possible values; 0, 1, 2, or 3

  subprg$ = one
  auxprg$ = one
  extprg$ = one 

  #The sub/aux/ext 'prg$' variables are used to "initialize" the alternate output streams.
  # The streams indicate 3 "alternate" files you can write data to. 'subprg$' is used
  # auto-magically by MP to write the subprogram data stream.

  # These alternate streams (and the variables that control them) can have 3 possible states:
  # 0 = Disable writing to the alternate file stream
  # 1 = If the alternate file already exists, erase the contents and open, or create a new file
  # 2 = If the alternate file already exists, open the file and append data. If no file exists, start a new one

Once you've finished manipulating your alternate files, and have written data to them, you can merge in that alternate data into the current NC File Stream (subout$ = zero).

  mergesub$  #Merges subprogram file stream data
  mergeaux$  #Merges auxiliary file stream data
  mergeext$  #Merges external file stream data




  clearsub$  #clears (erases) subprogram file stream data
  clearaux$  #clears (erases) auxiliary file stream data
  clearext$  #clears (erases) external file stream data

[PMC Shop]

Thank you Colin. That was very informative and I will probably take your advise, but I will play around with it later for curiosity's sake. Between you and Tim I think there is a lot usable info here.

[PMC Shop]

Also, after looking at the subout$ setting, I realized that the output is being forced to zero at the start of the header, to three at the end of the header, and then back to zero at the end of the sub or file.

[Colin Gilchrist]

Yes, a setting of '3' indicates that we've directed NC code output to the "EXT" file.