Cancel
Showing results for 
Search instead for 
Did you mean: 

Import CLSF with NX Open

Pioneer
Pioneer

Hallo again,

 

as the title indicates, I am looking for a way to import a modified CLS-File using NX Open.

The journal doesn't log anything when the CLFS-Manager is opened.

 

Cheers

10 REPLIES

Re: Import CLSF with NX Open

Esteemed Contributor
Esteemed Contributor

The CLSF manager is very ancient and I really doubt there will be any journaling support added, since CLS files are more or less fading out.

 

There is the legacy API function UF_CLSF_import, so you might succeed using the .NET wrapper function if it exists.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX12.0

How to Get the Most from Your Signature in the Community

Re: Import CLSF with NX Open

Siemens Phenom Siemens Phenom
Siemens Phenom

There is a "wrapped" function in the NXOpen.UF namespace.

 

It's called NXOpen.UF.UFClsf.Import.

 

You pass it the tag of the part file into which you want to import, and the name of the CLSF.

山田
yamada

Re: Import CLSF with NX Open

Pioneer
Pioneer

Thank you very much, I will try that.

 

You wrote that CLS files are fading out, is there are a state of the art way to manipulate a NX- generated toolpath and generate a operation with the edited toolpath?

Re: Import CLSF with NX Open

Esteemed Contributor
Esteemed Contributor

My question is....Why do you need to edit the toolpath?

If we can figure out a way to not have to do that, then the whole issue goes away.

 

Also note you can play rather extensive games with the output using postbuilder.

 

Note there are some (I believe non-associative) edit options in NX.

Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled


Re: Import CLSF with NX Open

Esteemed Contributor
Esteemed Contributor

Ingfu wrote:
You wrote thatCLS files are fading out, is there are a state of the art way to manipulate aNX- generatedtoolpath and generate a operation with the editedtoolpath?

There is the graphical tool path editor to edit a tool path in place, select it via the context menu of the operation using "tool path => edit".

 

Generally as Ken asks, why edit the tool path?

I would change the operation to get the desired tool path, which will be remembered by NX and can be repeated if the geometry changes.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX12.0

How to Get the Most from Your Signature in the Community

Re: Import CLSF with NX Open


Ingfu wrote:

You wrote that CLS files are fading out, is there are a state of the art way to manipulate a NX- generated toolpath and generate a operation with the edited toolpath?


I have the same question as the others - what do you need to edit?


CLS files are not fading out. They are a format for output, just like a G code file. When you export a CLS file (or list), the system converts a subset of the tool path information in to readable text.

 

In NX terminology, you generate an OPERATION, and this writes an internal binary TOOL PATH that is saved in a container with the operation. So regardless of what you do to the tool path, if you generate the operation, the path is replaced.

 

Importing a CLS converts the text file in to the internal format, and puts the paths in the containers with the operations. But these imported paths have far less information than an internal path. 

 

If you really want to edit a path with the API, you can export the CLS, read the text file, and then write a new internal tool path. This what is done, for example, in a user defined operation. 

 

Mark Rief
Retired Siemens

Re: Import CLSF with NX Open

Pioneer
Pioneer

We have a proved tool path that may not be altered, but may be split up following certain rules. Then the machining operations may be spread over several machines. If I used a post processor, I wouldn't be able to post for the different machines afterwards.

Is that a scenario that could be solved effeciently with a User Defined Operation? Every single split up Tool Path slice is supposed to be an operation on its own.

Re: Import CLSF with NX Open

If you want to split the path, have you looked at Tool Path > Divide or Tool Path > Divide by Holder?

Mark Rief
Retired Siemens

Re: Import CLSF with NX Open

Esteemed Contributor
Esteemed Contributor

What it soundle like to me....(speculating here...)

They have a really long program, many operations, one or many tools.

Sometimes the want to run the whole thing on one machine.

Sometimes they want to run some of it on one machine, and some on another machine (e.g. all the roughing on the "older, slower, not so precise" machine, and then finish on the "new/precise but also in high demand" machine.  (or whatever reason they want to split across machines).

 

If you have the CLS, you can edit it to have it all together, or split it into pieces based on operation (or tool change or whatever) boundaries.  If you use GPM or iCAM or other technologies, the CLS remains *exactly* the same, hence remains "proven".

 

If you use UG post (particularly across releases/MRs/MPs), while you can technically do the same thing (based on what operations/groups, and post you select), the likelyhood of output changes approaches 100% if you have surface contouring, or stepovers in planar/cavity mill.  So (while it *MAY* successfully cut the part), you don't 100% KNOW it will successfully cut the part, without actually cutting the part.  (depending on what is important, e.g. surface finish, NX verify/Vericut may not be able to pick up issues).

 

Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled