In 1847 and beyond we can use a "Referenced Generic Motion". As part of Siemens "Agile" manufacturing we are supposed to discuss the new software.
My thoughts. I saw the demo Siemens put up in the forum, but it is not enough information to figure out how to define one from scratch. After a few hours or reading many many document links, watching the video over and over I finally figured out define and use a referenced Generic Motion or Probe operation. I made a few of my own.
This has great potential when finished.
What do you think about the following? Some have been submitted for ER, enhancement request, but not all. ERs are still part of the process, put yours in also. Volume of users wanting an ER still counts.
#1 Have a complete 10-15 minute video turtorial on how to create a Referenced Generic Motion cycle. This could increase the number using it significantly.
#2 Be able to use the Variables from the UI to drive more than motion. They need to be able to be Passed to UDE definitions within a machine control. This is supposed to support all the probing and special cycles/machine macros we have correct? The postprocessor only sees the variables when processing the Reference Sup Op parent start from what I see in the data dump from Postbuilder. We need to be able to reference the variables anywhere within the sub-ops or use them as entry to the UDE inputs. If it could pass the variables to the INSERT UDE, we wouldn't need postprocessor experts to make the output work.
#3 Some macros need helical arcs, Is there a way to have helical arc moves in Generic motion?
#4 I can simulate the cycle, show it on the screen and verify it, but many routines will call a cycle/macro for the machine motion. I only want to postprocess part of the moves. I can build a Dontcut UDE to stop/start postprocessor output by putting unwanted output to a dump file. Do we all need to be post experts? Could there be a Stop/Start output command at the input level?
#5 This works with points and CSYS for location. What about holes, cylinders? as an input. I want to be "model centric" for data input, not typing centric.
#6 What about multiple locations or holes handled by one operation? Could that be done?
Thanks for your comments!
With respect to comments #3 to #6, it looks like you would like to use the Feature Based GMC (See What's New in NX 1847 -> Manufacturing (CAM) -> Feature-based Machining ->Generic motion operations for features).
This Feature Based GMC enables:
• Model (feature) centric definition. Only program your cut pattern in the context of a single feature, with use of all feature parameters (next to tool parameters and user parameters) and -if needed- additional user specific parameters.
• Single definition, applied on multiple locations/orientations with common NCM. Your single feature specific cut pattern is applied to all features within your feature group, where the traverse in between is generate based on common ncm settings (like lowest safe z, clearance box et cetera).
• Additional move types. This operation type comes with a few new move types like spiral, conical and helical move types.
• Cycle emulation. NXCAM will not switch between canned/emulated cycle output but it will provide all data to the postprocessor to facilitate easy switching. On output the manual cut pattern will start with a MOM_expand_on event providing the cycle control point (MOM_feature_origin) and all feature attributes (mom_ftr_xxx), user attributes (mom_usr_xxx) and others (see your Post Review Tool ). At the end of the output follows a MOM_expand_off to mark the end of the manual cut pattern.
With this the prostprocessor should have suffcient data to decide whether to activate a specific subprogram (if available for the specific configuration) or output the complete path (in case no specific canned cycle or subprogram is available for the selected configuration).
I will attach a part file with a few simple examples, one (THRILLER_LINEAR) containing a simple manual cut pattern that includes a helical move. The examples shows application for two holes only, to extend the number of holes do include more within your feature group ....
This will not replace a tutorial but would at least be a starting point to explore the power of this new operation type.
(It is also available within the hole making template, toggle on the Template Setting and select it to have it copied into your own part file)
Suggestions, remarks are welcome, thanks,
Don't know but it might be easier to make this Feature based GMC a fit for your use cases.
I don't know the relevant use cases in your area, this Feature based GMC operation type seems like a perfect fit to program any specific cut drill/mill pattern for any geometry that can be defined parametrically. As it also supports Mill User Form tools it will enable programming for quite some use cases that we currently don't support by our path processors.
I can image usage for:
No need to take care for manual definition of traversal motions, just focus on programming your own cut pattern for a single (customer specific) feature in the context a specific tool. Select a serie of similar shapes with different orientation and varying dimensions (just combine them in the feature group object) and insert a feature based GMC operation below to have the previously defined cut pattern applied on all.
Sure there is enough opportunity for improvements, tutorials, ootb samples, additional subops, alternative ways to group your feature set et cetera. Give it a try (e.g. start with the samples that have been provided on an earlier reply) and let us know your findings.