What determines post processor block run order?

[deezums]

Hello

I'm trying to modify a post processor, mainly just the order that certain blocks are run at the start of the NCI file. I am trying to post a tool list as well as a manual entry with both comments for setup notes and pallet change/stage codes. Currently my manual entry posts first, then the tool list. I would like this reversed as it makes no sense to have a tool list in the middle of code.

Using the post debugger I can see how the NC file is generated, but I can't determine where or how to move the order of blocks as they run.

Currently my post starts at pheader$ + pset_mach + pparamater$. This grabs the date and mastercam file name. Next, it jumps to pcomment$ + pcomment2 + pspc which I believe is from the manual entry window. After that is done it goes to ptooltable, so this ends up putting the manual entry above the tool list.

I can't find any handoff from pheader to pcomment. I believe all I need to do is change the run order of pcomment and pwrtt, but I can't find where! Here is the block of code, with some commented stuff removed.

pheader$ #Call before start of file
hour = int(time$)
min = int((time$ - hour)* 100)
if hour > 12, hour = hour - 12
if hour = 0, hour = 12
year$ = year$ + 2000

"%", e$
spaces$=0
*progno$, " ", scomm_str, sprogname$, scomm_end, e$
scomm_str, "DATE - ", *smonth, "-", *day$, "-", *year$, scomm_end, e$ # MON-DD-YYYY
spaces$=sav_spc
comment$ # File descriptor
spaces$=0

if seqno$ = 0, omitseq$ = yes$
sav_progno = progno$

if tseqno = 1 & omitseq$ = 1,
[
seqno$ = 1
seqinc$ = 1
n$ = seqno$
]
sav_rot_on_x = 0
header = 0

Help please!

[nickbe10]

57 minutes ago, deezums said:

I am trying to post a tool list as well as a manual entry with both comments for setup notes and pallet change/stage codes.

 

Tool list switch is at the top of the post

# --------------------------------------------------------------------------
# General Output Settings
# --------------------------------------------------------------------------
hel_2100    : no$   #Acramatic 2100 style helical moves, 0=no, 1=yes
force_dpts  : no$   #Force XY output on all drilling lines including cycle call?
haas        : 1     #Haas style peck drill and extended offsets, 0=no, 1=yes
wcstype     : 2     #0 = G92 at start, 1 = G92 at toolchanges, 2 = G54, 3 = Off
force_wcs   : yes$  #Force WCS output at every toolchange?
tool_table  : 1     #Tool table, 0=no, 1=yes, 2=Predator VCNC, 3=MetaCut View

Do a search for Moving Manual Entries using String Buffers by djstedman for a detailed description of how to get your Manual Entries how you want them.

It's more involved than you think......

[Colin Gilchrist]

You can't change the order in which the blocks are called. That is automatically sequenced by MP.DLL.

However, the Comment Processing is handled by the placement of the 'comment$' command variable, and that you certainly can move.

'pwrtt$' is typically the block that generates the Tool List. When the 'tooltable$' variable is active, it is automatically called in-between 'pheader$' and 'psof$'.

Look in your 'pheader$' code. Put a pound sign (#) in front of the line that is 'comment$ #File Descriptor'. That will deactivate it being called "during the header output".

Now, find 'psof$' and at the top of the Post Block, add a "new line". Put in 6 spaces, do not use Tab, and then type 'comment$', without the (') . Just (   comment$  )

Then hit "enter". Do not put 'e$'.

[deezums]

That did the trick Colin, thank you!

Volume 3 of the MP Post Ref guide has a predefined postblocks list on page 2-205, is this the order things are called in, just for my future reference?

[Colin Gilchrist]

Not really.

Calling order is based on the NCI Data.

When your Program is "posted", first, MP.DLL converts the "operations" you have selected (remember, you can "uncheck" individual Ops, so they might not be included "at the time of posting."), into "ASCII NCI Data". This data is "your program", but in a generic "Mastercam" format.

The NCI data is arranged in "2 line sets". The 1st line contains a single integer value. This is the "NCI G-code". Based on the "NCI Gcode Value", MP calls what is termed an "Entry Post Block". There is 1, and only 1, "entry point", for each "NCI Gcode" value.

The "NCI Reference and Parameter Guide" tells you "which Entry Post Block", gets called for each NCI code.

Now, MP.DLL (The actual Post Engine), also has "automatic routines" that are triggered, based on the "configuration data" present in your PST File. The PST file is just "an instruction list". It tells MP how to interpret the NCI data, and transform it into NC Code output. But there is so much more that it "can" do, in the hands of a capable programmer.

1st to be called is 'pheader$', based on the NCI 1050 line. This is the first place that "output" to the NC File occurs. Technically, there are other blocks called prior to this one, but this is where the first output occurs.

If "tootable$" is enabled, next there is an entire "Pre-Read Loop" that executes. MP reads the entire NCI File, but it "skips" the "Motion" (Gcode) output. It only looks at "Tool Change Events", which occur for each New Operation, but also occur at "Depth Cuts, and Multipasses" as well. During the Pre-Read Loop, we build output for the Tool Table. MP Does this by "flagging" each tool number. If a Tool has "not been used yet", then it is "signed positive", which allows entry into "ptooltable". If the Tool has "already been used before", then MP signs the tool "negative", which prevents duplicate entries in the Tool Table. It also exposes a weakness in the "default" Pre-Read architecture, because you can't "sort" the Tool List numerically using this method. If you want a "sorted" list, then it requires adding Buffers to the Post.

After "Pre-Read Loop" has completed, we encounter a bunch of lines in the NCI File that do not call "Entry Blocks". These are the "prepatory NCI Gcode Lines", and their purpose is to "set the values for pre-defined variables, prior to the Tool Change Event. (Examples: 1014, 1016, 20xxx series parameters, ect.)

The next NCI Line to cause "output" to the NC File is NCI 1001 Line. This is the "Start of File" Tool Change.

Based on a "flag" in the PST File, we actually do this weird "I'm going to read 2 lines ahead, then backup to call the 1st Tool Change, thing", but don't concern yourself with that now...

So, NCI 1001, calls 'psof$'. This is the "Start of File", and is the 1st Tool Change Event.

In SOF we typically output "T1 M06", (or a different T#), and then do a "startup line"

G0 G90 G54 X0 Y0 S2000 M03

Followed by a "Tool Length Comp" Line:

G43 H01 Z2.0

And that basically takes care of the 1st Tool Change.

Then, we start processing "motion" code. All of the NCI Gcodes for motion; 0, 1, 2, 3 have common "Entry" Post Blocks. But "modern Posts", all sort these into a "common routine". This helps to make sure we are "processing" each type of motion correctly. For example, Axis Substitution (4X), involves taking a "3X" path, as 3X data in the NCI File, and "Wrapping" it around a Diameter. One of the Linear Axes is replaced with Rotary Motion.

 

 

[deezums]

Thank you for the explanation, I've seen some crazy stuff done with post processors! I had one that would output conversational text files for accurite millpwr at a previous job, that couldn't have been easy!

The pre-read loop, I think I've seen this one. If you step through the debugger just right it seems it's possible to get it stuck in this loop, it never actually posts code.

I also see the 1006 parameter for my comments in the NCI file, I recall seeing this as "before" in the manual entry parameters. I can see now how having the comment# line in the header would post this "before" the next post block which should be the tool data gathering loop!

Comments are buffered in scomm$, line by line? 1006 is posted as code so there are no scomm_str/scomm_end flags. This is the actual bit of code the NCI file will point at for every comment? It formats to uppercase and saves any spaces?

spaces$ = 0
scomm$ = ucase (scomm$)
if sof & gcode$ >= 1051, scomm_str, scomm$, scomm_end, e$
if gcode$ = 1005, n$, pspc, scomm_str, scomm$, scomm_end, e$
if gcode$ = 1006, n$, pspc, scomm$, e$
if gcode$ = 1007, scomm_str, scomm$, scomm_end
if gcode$ = 1026, scomm$
if gcode$ = 1008 & header = zero, n$, pspc, scomm_str, scomm$, scomm_end, e$
if gcode$ = 1008, scomm_sav = ucase(scomm$)
spaces$ = sav_spc

Once again I really appreciate you taking the time to explain this! Knowing where in the post I'm going to jump next is going to be a big help!

[Colin Gilchrist]

I'm happy to help. I'm glad you are following along ok, and searching out info on your own. That's exactly how I started.

Just FYI, I happen to teach online classes in Post Processor Development for Mastercam. If you'd like to get some formal training, I'm the only option besides going to CNC Software directly, and taking their Post Processor classes. (Great training, but $$$)

There is a huge amount of information in the Post Documentation. Do you know which version of the documentation you have? For a long time, there was just "Volume 1, 2, and 3" of the MP Reference Guide. Written for V9, it was "old", and didn't show the "new X style" of Post formatting. You had to use the V9 Ref Guides, in conjunction with the NCI and Parameter Reference PDF, for your specific Mastercam version. So it was difficult to figure out "the big picture" sometimes. For 2017, they rebuilt the documentation, so it is easier to follow, is updated for modern MP formatting, and doesn't have to refer to any of the outdated material.

[Colin Gilchrist]

Ok, Comments are kind of a weird animal inside MP.

All Comment String Variables are written to the NCI File, along with a "NCI Gcode Value". MP stores the Comment Strings, along with their "NCI Gcode value", in a special "internal comment buffer", that is maintained by MP.

Typically, at the "Start of File", there is the "1008" code, which is the "Operation Comment String". This too, gets stored in the Comment Buffer. We might have 1 Comment String, we might have 30 comment strings. The point is that all comment strings are stored in this buffer, in the order in which they were read from the NCI File.

The comments continue to "get stored", until the 'comment$' Command Variable is encountered on a Post Line (by itself). When that happens, all stored comments are processed through 'pcomment$', which in turn, calls 'pcomment2'. It is inside 'pcomment2', where we have different "if statements", that are used to format each "comment type" for output. Typically, this consists of running the "UCASE" function (to convert the comment string to Uppercase), and the line will either "have comment markers", or not. ()

As you correctly deduced, the variable 'scomm$' is continually "overwritten" by MP, while processing each comment from Comment Buffer. Each Comment String Variable is loaded into 'scomm$', and the variable 'gcode$' is set to the 'comment string's gcode value', and then we call 'pcomment$ > pcomment2'.

So, in general, we can move the location of Comment Output around, by simply moving 'comment$'.

In other cases, I have users that want to output "Manual Entry" to the Header, so they can put in "Setup Comments" into the File Header. They actually want this prior to the 'Tool List'. Ok, no big deal. Move 'comment$' to 'pheader$', and we're all set...

Not so fast. When we move 'comment$' to 'pheader$', we have a problem. We end up outputting the 'Operation Comment' (NCI Gcode 1008), "up in pheader", instead of before our 1st Tool Change. Bummer.

The secret is to add some logic. You'll see there is a "if gcode$ = 1008 & header = 0". This is testing to see if we are "still in 'pheader'". So, if we are, we end up "saving" the String variable to a "temporary string variable", and then we add some logic to 'psof$' to "test" and see if this string is "not empty", and if there are characters in the String, we output it. If not, then the logic works to prevent an "empty comment  ()" from being output.

[Mitch The Machinist]

On 2/21/2018 at 9:37 PM, Colin Gilchrist said:

Not so fast. When we move 'comment$' to 'pheader$', we have a problem. We end up outputting the 'Operation Comment' (NCI Gcode 1008), "up in pheader", instead of before our 1st Tool Change. Bummer.

The secret is to add some logic. You'll see there is a "if gcode$ = 1008 & header = 0". This is testing to see if we are "still in 'pheader'". So, if we are, we end up "saving" the String variable to a "temporary string variable", and then we add some logic to 'psof$' to "test" and see if this string is "not empty", and if there are characters in the String, we output it. If not, then the logic works to prevent an "empty comment  ()" from being output.

Currently using MCam21, I've always had this issue with our posts. I'm struggling to get  the "if gcode$ = 1008 & header = 0" line to work correctly ( and the "if gcode$ = 1008, scomm_sav = ucase(scomm$)" line). Also not fulling understanding if I need to add some logic to 'psof$' and not sure what it would be. 

[JParis]

6 minutes ago, Mitch The Machinist said:

Currently using MCam21, I've always had this issue with our posts. I'm struggling to get  the "if gcode$ = 1008 & header = 0" line to work correctly ( and the "if gcode$ = 1008, scomm_sav = ucase(scomm$)" line). Also not fulling understanding if I need to add some logic to 'psof$' and not sure what it would be. 

If I am understanding what you're trying to accomplish, check out this thread, KI believe it covers what you're looking for

 

[nickbe10]

46 minutes ago, Mitch The Machinist said:

Also not fulling understanding if I need to add some logic to 'psof$' and not sure what it would be. 

If you look at psof$ you will notice a control variable (sof), it is initialized as 1 in the misc variables section and at  finish it turns off (sof=0).

So the test is if sof = 1 you are in psof$ which is where you may or may not want to output. If you don't want to output here you need to save the data and output where you want.

I use  two buffers to store origin and general text info. and another to output code for probes etc.

so one stores "as comment" data and one stores "as code" data

Using buffers allows me to exceed the standard character count

 Do a search for Moving Manual Entries using String Buffers by djstedman to see how to set this up

  

[Mitch The Machinist]

I got it figured out now. I didn't have "header_done : 0" or "sop_comm" defined. Once I added those, she looks just like I want!

%
O10246( 812R070 )
( DATE - NOV. 30 2020 )
( TIME - 2:37 PM )
G0 G17 G20 G40 G49 G80 G90
G187 P2 E0.025
 
( NEW AGE PROGRAM )
( )
( CYCLE TIME: )
( OPER. INITIALS: )
( STOCK SIZE: )
( G54 SET PART X Y )
( MAX DOWN IN VISE )
( X0 )
( Y0 )
( Z0 )
( )
 
 
(                  TOOL LIST                  )
(=============================================)
( T1 |  1/2 3FL S-CARB FLAT ENDMILL | DIA. - .5 )
( T2 |  1.25 AXD MITSUBISHI MILL | DIA. - 1.25 )
(=============================================)
 
 
 
( ROUGH OUTSIDE OF PART )
 
T1 M6 ( T1 |  1/2 3FL S-CARB FLAT ENDMILL | DIA. - .5 )

 

Thanks for the help.

 

-Cheers