Fusion Manufacture
Talk shop with the Fusion (formerly Fusion 360) Manufacture Community. Share tool strategies, tips, get advice and solve problems together with the best minds in the industry.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Post processor: Understanding subprogram & pattern implementations

Message 1 of 10
966 Views, 9 Replies

Post processor: Understanding subprogram & pattern implementations

Hi there,


I'm trying to modify my Mazak post processor to output operations as local subprograms and to share subprograms for patterned sections. I've been using both the Fanuc and Haas NGC post as references but am having a hard time understanding these implementations and the edge cases they're covering. Could someone familiar with these implementations share a bit more about them?


The subprogram implementations seem to consist of:


// Called on every onSection
function subprogramDefine(_initialPosition, _abc, _retracted, _zIsOutput) {}

// Sets up redirection buffer
function subprogramStart(_initialPosition, _abc, _incremental) {}

// Empties redirection buffer and saves the subprogram to be output in onClose
function subprogramEnd() {}

// Very confused by this function. It seems to both determine whether the
// current operation is "valid" as a subprogram, but it also seems to be
// actually writing rotations/translations and defining the work plane for
// the section?
function subprogramIsValid(_section, _patternId, _patternType) {}

// Also confused by these -- what determines whether the pattern
// needs to be output as absolute or incremental?
function setAxisMode(_format, _output, _prefix, _value, _incr) {}
function setIncrementalMode(xyz, abc) {}
function setAbsoluteMode(xyz, abc) {}

// Utilities used by subprogramIsValid -- don't fully understand them
function areSpacialBoxesSame(_box1, _box2) {}
function areSpacialBoxesTranslated(_box1, _box2) {}
function areSpacialVectorsDifferent(_vector1, _vector2) {}


My big open questions -- What makes a subprogram "valid"? What are the supported pattern types? How does the implementation know whether a subprogram needs to be output in absolute or incremental mode?


Also, my actual use-case for this is in using multiple WCS, which is output as a pattern by specifying multiple WCS in the Setup as opposed to creating an actual pattern folder. For these, the code is identical except that the WCS changes. Is it sufficient to check the initial and final position of sections with the same pattern ID to identify this kind of pattern?


Thanks for any and all help in understanding this.


Best regards,


Labels (2)
Message 2 of 10
in reply to: zach.allaun

Hello Zach,


I can shed some light on subprogram support in a post.  Copying this logic to another post can be quite involved, since there are areas outside of the subprogramXXX functions that need to be modified.  Were you successful in adding the basic subprogram support to your post?  If not, then sometimes it is easier to take a similar post with subprogram support already supported and modify it with your output requirements, for example the Mazak VC500 post could be used as a seed post.


Now on to your questions.


My big open questions -- What makes a subprogram "valid"? What are the supported pattern types? How does the implementation know whether a subprogram needs to be output in absolute or incremental mode?


What makes a subprogram valid?

There are 3 different types of subprograms; operation, patterned, and cycles.  Operation subprograms are always valid, the post simply outputs each operation as a separate program.  Patterned operations can be valid if they have the same size bounding box and the first and last tool position in the patterned operations are translated by the same distance.  Cycle subprograms are valid when there are multiple cycle operations on the same group of holes and there are at least minimumCyclePoints in each operation.


What are the supported pattern types?

Linear patterns are supported.  Circular patterns are only supported when the pattern is revolved around the axis of a rotary table.


How does the implementation know whether a subprogram needs to be output in absolute or incremental mode?

Translated linear patterns will always output the subprograms in incremental mode.  Circular patterns can be absolute if the rotation causes each pattern instance to be in the same location.


Are patterns output using the Multiple WCS Offsets supported?

Patterns generated from using the Multiple WCS Offsets feature in the setup are patterned, will be output as subprograms, and will be in absolute mode since the bounding box and position for each operation are the same.


I hope this clarifies your questions.  You really don't need to know how each of the subprogram functions work, you just need to make the proper changes in your post and it should work like magic.  Let me know if you need assistance implementing the code.

Bob Schultz
Sr. Post Processor Developer

Message 3 of 10
in reply to: bob.schultz

Thanks so much for taking the time for such a thorough response. I'll dig
into this a bit later and follow up here.
Message 4 of 10
in reply to: bob.schultz

@bob.schultz  Thanks again for the response. You shed a lot of light on the situation.


I'd like to get your opinion on what I'm trying to accomplish, because it sounds like I may be able to get away with a simpler implementation than the default that supports operations/patterns/cycles.


I would like my post to:

  1. Output each operation as a subprogram, and
  2. Share subprograms for patterned operations created using Multiple WCS Offsets

If I'm understanding the current code correctly, this should be fairly simple to implement. Non-patterned sections (those sections that do not have a patternId) are output as a subprogram using the existing allOperations logic. When I first encounter a patterned section, I can check that it is a part of a Multiple WCS Offsets pattern by confirming that all initial position/final position/bounding box is the same for each instance of the pattern. If they are different, then I output a new subprogram for that section. If they are all the same, then I associate that pattern's ID with that subprogram and use it for subsequent instances of the same pattern.


If that strategy passes the gut check for you, I'll give it a go and post a link to a commit for the implementation both to get a second set of eyes on it and as a future template in case others ever want to do the same. (My Mazak post is available at and I'm working on open-sourcing my Brother Speedio post.)

Message 5 of 10
in reply to: zach.allaun

Also, while I have you "on the line"... Is this safe to use?


I mean "safe" as in not likely to disappear on me one month. 😅 I sort of guess at it after seeing a 2018 talk that George Roberts gave and remembering a forum post I read about the scope property...

Message 6 of 10
in reply to: zach.allaun

@zach.allaun any post that you download and save to your Cloud Assets or local storage will not disappear at any point. However, when using posts of unknown origin, there is risk involved, so tread carefully

Seth Madore
Customer Advocacy Manager - Manufacturing
Message 7 of 10
in reply to: zach.allaun

@seth.madore  Sorry, I meant the feature I linked to specifically: operation properties. 

Message 8 of 10
in reply to: zach.allaun

Hello Zach,


I would suggest against trying to optimize/shorten the subprogram main functions, you may be opening a can of worms.  The simplest thing is to include the subprogram functions and make the other required modifications to the post.  You can of course leave out any references to cycleProgramIsActive and don't have this option available in the property to exclude cycle subprograms.


To omit incremental subprograms (shifted patterns) you can check to see if incrementalSubprogram is set to true after the test in subProgramIsValid and then set validSubprogram to false if so.


You will also need to add a Both option to the useSubroutines property so that both patterned and operation subprograms can be output in the same program.  Currently they are mutually exclusive.


You can use operation properties if you like, just be aware that if you make a property both a Post and Operation property, then the property displayed in the post dialog will be ignored, as the operation properties will override the post property and must be changed in each operation, changing the post property will not override the operation properties.  You can also use a Manual NC command to override the Post property if you desire.

Bob Schultz
Sr. Post Processor Developer

Message 9 of 10
in reply to: zach.allaun

hello bob
your entry is a few years ago but I'll try anyway!

How far have you come with the implementation?

I have to try this for the Heidenhain and need help for it?
Can I see your results?

kind regards?
Message 10 of 10
in reply to: R_Weiss79

Hello Ron,


The Heidenhain post already supports subprograms, which can be enabled using the following property.




If you need to enable both All Operations and Patterns at the same time, then I can walk you through the changes.


Bob Schultz
Sr. Post Processor Developer

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report