Post processor: Understanding subprogram & pattern implementations

[zach.allaun]

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,

Zach

[bob.schultz · Accepted solution]

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.

[zach.allaun]

Thanks so much for taking the time for such a thorough response. I'll dig
into this a bit later and follow up here.

[zach.allaun]

@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 https://github.com/keycult/mazak-hcn and I'm working on open-sourcing my Brother Speedio post.)

[zach.allaun]

Also, while I have you "on the line"... Is this safe to use? https://github.com/keycult/mazak-hcn/blob/main/post-processor/mazak.cps#L206

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...

[seth.madore]

@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

[zach.allaun]

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

[bob.schultz]

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.

[R_Weiss79]

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?
Ron

[bob.schultz]

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.