[earlywood]

I'm trying to cut a bunch of identical copies of a 3D part out of one big block of wood. I can fit 15 of the 3D parts in a 12" X 48" X 2" piece of wood.

The problem:
It takes about 10-15K lines of code to cut out one of the parts so times that by 15 and you're up in the 200,000 lines of code range. Also, the part has about 500 faces on it because it is a cad representation of a laser scan of the actual part. It's hard to go from laser scan data to solid parts without ending up with a bunch of faces. Therefore, with 15 parts, we're dealing with 7500 faces. If I try to create a cut path for all 15 at once, I run out of memory on my computer during the number crunching.

Question:
Is there a way to reuse the same block of 15K lines of code over and over again (like make that block of code a "feature") or something like that? Then hopefully, I could have the 15K lines for the part and then just a few more lines that would specify where the local MCS for each part would be.

I would imagine that NX would have some built in functionality for this... but I can't seem to locate it.

Thanks in advance!

Brad

[br1]

Use your long program as the sub program followed with a m99. Write another (Main) program with locations to run the sub program. Have both in same location (either machine memory or pc folder) run the Main Program, its done all the time. You do not need the M98 P499 as I have in the example.

[earlywood]

br1,

So you're telling me that I need to write the main program myself and paste the sub program (the 15000 line one) where necessary. Totally doable. For the record, is this something that NX will do or at this point, is writing the code myself the only way to get it done.

[br1]

Yes, write it yourself

G90 G92 X125.72 Y60.25
G00 X2.1 Y55.695 (this line places the sub where ever you need it)
M98 PXXXX (this line calls the sub program up, the M98 as well as the "P" are needed, if your program is O1234 then this line would be P1234)
G00 X23.25 Y0.0000 (this would be the distance moved from your zero point)
G90 G92 X0.0000 Y0.0000 (this resets the zero origin of your part)
G00 X2.1 Y55.695
M98 PXXXX

This method is an example only, I am sure are other ways of doing it.

[earlywood]

Thanks br1.

Now, what if I want to rotate every other instance of the part 180 degrees to nest the parts in there a lot tighter and maximize my material usage? I suppose I could generate another block of code that was for the flipped part, and call out that block in certain spots, while also calling out the original sub-program as well.

That's what I'll try unless there is a way to simply "flip" the sub-program 180 degrees that would be easier.

[br1]

look here, CNC Mach3 G-Codes

[1 Infinite Loop]

Making your own programs via subs and work locations can work just fine. However, if you have to mirror subs or use coordinate rotation you might want to consider doing it inside NX. Back in the day I used to do most of my programming free hand and it wasn't uncommon to program subs two or three deep. I haven't done that for quite some time and I program every aspect of the nc file inside NX. Ultimately NX has more power than the machine control, changes can be easily made and tool paths can stay associated with your model. You have a LOT of programming power with NX.

Back to your issue...
It sounds like you should try to instance or copy operations. It works quite nicely and barely taxes your cpu. For my work I use instance almost exclusively because all the operations are linked to each other; if the stepover is changed in one then all the instances get updated automatically. Copies are just that, copies. They do not update when one is changed.

To access it you right click an operation, then object-transform. In the transformation dialog at the top you can choose the type you want. In the middle of the dialog don't forget to set the result to move, copy or instance.

By the way I am using nx7.5. I took a quick look in nx8 and the dialog appears to be the same.

[br1]

Yes I would agree with 1 Infinite Loop, "I was just thinking back in the day." I think having the software do it would be more what you want, less stress, and easier to see if you have made a mistake. Good luck.

[1 Infinite Loop]

@BR1
I think your right on about operators knowing these things. Even though we program everything inside NX it's still good to know G coding. IMO operators should be aware of the options of their machines, as well as G codes, and how it all works.

You never know when an old nc file has to be run and there is no part file for it nor a programmer to sift through the file. When it happens and it's good to be prepared.

[earlywood]

Absolutely wonderful. That's just what I was looking for. I will give it a shot today.

My G-Code skills and knowledge are admittedly weak. I have heard "you've got to know G-Code" from skilled programmers more times than I can count.

I use the CAD side of NX all day every day, so I have been hoping to roll right over to the CAM side without getting too serious about the code, but I'm starting to see that I'll be putting myself at a pretty good disadvantage and leaving the door open to make some big mistakes that could end up damaging my machine.

I appreciate all of your help!

[1 Infinite Loop]

I hope I didn't lead you wrong...I feel it's important to know how the machines works but I would still use the power of NX to do the programming.
: )

[earlywood]

Not at all. The way I look at it is that NX has been employing intelligent and experienced programmers for years trying to make all the magic work within NX. Might as well take full advantage of what they have come up with.

[earlywood]

For the record: I have been using "instance" since I got this advice and it's been working great. Thanks for your help.

[camster]

Be carefull if you Mirror your tool paths in NX. The cut direction changes from climb mill to conventional. If your cutting wood this may not be a problem but if you plan on using cutter compensation you will get undesired results on the mirrored paths.

I will mirror the path as a copy instead of an instance then I can "lie" to the system and change the cut direction from climb mill to conventional and the mirroring will reverse the direction. Still something thay need to fix IMHO.

[earlywood]

It sounds like you should try to instance or copy operations. It works quite nicely and barely taxes your cpu. For my work I use instance almost exclusively because all the operations are linked to each other; if the stepover is changed in one then all the instances get updated automatically.

1-I-L,

I've been using instance now with great success. Never underestimate the depth of the right-click menus within NX!

I mentioned above that I can fit 15 parts into one block of wood. That's a 3x5 layout. I also would like the ability to run 1x1, 3x1, 3x3, 2x1, 2x2 etc layouts. Following the suggestion in NX Help, I have created assemblies (3X1 for example) and then I add 3 copies of the same component and orient them to minimize material usage. I then create the tool paths for one of the components and instance it to the other two. This works fine in all of the ways that instance works, but if I move on to a different layout (3x2 say), then I have to again create the tool paths for one of the components and instance it to the other 5. So... if I decide that I want to change the tool paths for each part (say add an operation), I need to go into every layout and add that manually, then re-instance all of them. This becomes a rather large pain in the ass. So, my question is:

Is there a way to essentially link toolpaths of children components to their parents? You can link geometry from children to parents easily, but it doesn't seem to be an option for tool paths. This would be so great for me as I could go change the tool path for that one component and it would update itself in all assemblies that it is used in.

Make sense? See how much sweeter that would be than having the base cut paths defined in each assembly? Any ideas?

Thanks.

[1 Infinite Loop]

1-I-L,
Is there a way to essentially link toolpaths of children components to their parents? You can link geometry from children to parents easily, but it doesn't seem to be an option for tool paths. This would be so great for me as I could go change the tool path for that one component and it would update itself in all assemblies that it is used in.

Make sense? See how much sweeter that would be than having the base cut paths defined in each assembly? Any ideas?

Thanks.

Not that I'm aware of but perhaps John can chime in on that. Essentially you'd probably have just as much work to link components to paths as you would selecting geometry. If you have to move geometry around once in a while you might consider selecting component geometry; that way when you reposition your components, all you have to do is regenerate the operations but not have to worry about re-selecting geometry. Especially given we have multi-core computers and NX can crunch multiple operations at the same time.

If you are swapping out components with different components you may have to select some new geometry if you are doing anything other than cutting parts automatically from top to bottom such as using cut area on certain faces or using boundaries.

[earlywood]

I have been bringing in components, linking the appropriate geometry, then selecting faces on the linked body. When I then move the components around, the instanced paths don't move with them, so I need to re-instance.

Are you saying that I can skip the linked body and simply select faces on the component itself and then the instances will move when the components move? That would make things better.

[1 Infinite Loop]

Sorry if I was not clear enough... Yes, you can select components for part/cut area/boundaries/blank geometry but, no, the instances will not move with the components. Keep in mind instances are from your original operation and the part geometry from that operation.

Like I said, you can create operations using components; I do it almost all the time. You won't be able link instances to it but the flip side is new operations will be associative to the components so if you move them around then you can easily regenerate your operations. Another benefit to machining components is the file is small rather than having a huge part exist right from the get go. There are some parts I machine that are 100-200MB but when I bring them in as a component my file is only about 130k to start out which is nice, especially when our network traffic is busy and saves can take longer than usual.