UG NX2 POSTBUILDER :: SYNON? 2

[hattrick]

I'm a little stumped on what would seem to be a fairly straight forward fix. I have a brand new 4-Axis POST, pulled from POSTBUILDER's Library and very lightlty massaged to achieve a few "home-grown" issues. What I'm having trouble doing is defining normal APT "power-word" usage.

For instance in UG I'd like to be able and just call RD,RETRCT and have the UG POST result in G0 G91 G28 Z0.0, allowing me to cleanly pull away from a part in pure tool axis without regards to a clearance plane value etc.

But I cannot seem to define a "SYNON table" that would recognize RAPID RETRCT as an Input Command.

Any ideas on how to easily place the common APT SYNON table into the UG POSTBUILDER logic library?

 

[jelmerra]

Postbuilder is directly communicating with nx. There is no intermediate cls conversion involved. The postprocessing event calls standard MOM events which will render output if it is supposed to do so and if defined at all.

You could place these go home moves in an end of path event.

Jelmerra

 

[hattrick]

Just be sure I'm understanding this correctly; since UG is managing the POST internally, with no external CLSF, it does not have the ability to "compile" or "filter" any command that is not defined in a MOM value?

I assume to make this work I'd have to have a MOM definition for every "APT power-word" I'd like to use? RD,RETCRT would have to have something like a MOM_rd_retrct. Then that MOM would have to map the String Call and desired output when the command was initiated from within an actual Toolpath. From what you're saying I assume with no MOM value out there, beyond the standard UG Library, POSTBUILDER will simply not act upon any commands since it does not know what to do with them.

I agree installing the command statement into Start-Up or End-of-Path Commands within the Machine button of a normal UG Toolpath would be the place for them to reside.

 

[jelmerra]

Yes you are relying upon nx to recognise/calling each individual event. If it has not been designed in you will need to define your own. If you put the debugger on in postbuilder you will see how nx handles the events and what variables are used.

For instance mom_motion_type will tell you if it is rapid, engage, retract, approach and a couple of other states. It depends a bit on cam programming style how useful the variables are. For instance if you put some of the safety distances to zero they will be gone at the time of postprocessing. Note that variables use lower case mom and events (procedures) use upper case MOM as a prefix.