We are currently using Heidenhein 530 controls. One of the common cycles which we use is a "bore milling" cycle ("CYCLE DEF 208" in conversational or "G208" in ISO).
We have configured our post processor to output the code by using the "chip break" cycle under drilling, and changing the "Step Values" in the cycle parameters. Though this method gives us the opportunity to output the correct code, it is a lousy shortcut.
The flaws I am trying to overcome includ:
1. NX percieves the cycle as a drill cycle, which means the simulation in "Verify Tool Path" doesn't display the actual tool path I am posting out.
2. The IPW generated by the simulation is incorrect (only the size of my tool and not the size of the hole my cycle is generating)
3. Time / operations are wrong
4. The interface... I'd like to output the canned cycle from an operation which actually displays a GUI which includes the paraemters of that cycle, i.e. "depth, clearance, feed/revolve, rough diam, finish diam.
Any help would be greatly appreciated.
You can create an UDE with the parameters and display a separate tab that shows the UDE in the operation dialog.
See customizing an operation dialog in the NX CAM documentation.
Production: NX10.0.3, VERICUT 8.1, 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 Preparing: NX12.0
Employees of the customers, together we are strong
How to Get the Most from Your Signature in the Community
What version of NX?
Note NX10.0.x (combined with Postbuilder 10.0.x) allows creating of custom cycles.
But in both the custom UDE and custom cycle cases, behavior will still be the same in *simulation* - you would (at most) just see the tool plunge down & back up - as the simulation engine (CSE or VNC) doesn't know how to handle the G208 call. You would have to edit CSE (I am assuming this can be done somehow - I know vrtually nothing about CSE) so it emulates what happens on the control.
I don't know if verify, or the internal IPW, can be modified to behave correctly by using the above approach.
A completely different appoach may be to use the hole milling operation type in NX, and alter the post to not output all the G0/1/2/3 motion blocks, but instead output the appropriate G208 call (I *think* you can do this, but the logic & coding may not be all that easy). My basic approach would be to check the operation type, and when you get to the appropriate point, use "MOM_disable_address" to turn off all (or almost all) word output. Then when done, re-enable the same words, output the G208 block, and finish up.
You might need(or want) a UDE to set parameters for the call, if you can't extract from NX. Note the UDE(s) could also be used as the trigger to disable & re-enable all the word output. So by positioning the UDE event (using the *_Marker "UDE"s) you could control exactly where the G208 is output.
The best way would be if Siemens would add the "motion output type" option to ths operation type to output as a "Machine cycle" - so NX & the IPW is correct, and you don't have to do a lot of BS in the post. (CSE would still need work to interpret the G208)
Production: NX10.0.3.5 MP16/TC11.2
I'd rather be e-steamed than e-diseaseled