I'm looking for some help with the code formatting for milling with a Right Angle Head, on a Siemens 840D.
I was able to use some of the Tips and Tricks Videos, along with some assistance from Mike Maninno to get the Siemens NX Devices, Operations, and Post Processor setup and working. It isn't "programming" the operations inside NX where I'm having my issues.
I'm looking for some sample NC Code that works with a RAH attachment. Specifically, I want to use CRC (Cutter Radius Compensation) while milling with the RAH.
The current way that we are programming the RAH is abysmal. I'm picking up an old job that was programmed by someone else, and their method was not ideal. Currently we are only entering a G43 Hxx value. This has the effect of putting the "Driven Point" of the machine as the main spindle centerline, in XY, with the Z height compensated to the centerline of the RAH tool. But the XYZ coordinates of the NC Code, being driven on the machine, is the center of the RAH attachment.
Based on the way that the prior programmer set this up, we have "Transformed" the toolpath "back to" this position, based on the "Tool Offset", or the distance from the RAH Tool Tip, to Centerline of the machine spindle. Every time the operator has to mount a new tool in the adapter, our setup guy has to re-measure the Tool Length, and we have to re-post a new NC Program, to account for the new tool length!
I don't think I've had to do anything this archaic in a while. If I can program a RAH on a Fanuc with a combination of G43, G45/G46, and G18/G19 (with G41/G42 for CRC), then I'm pretty confident we can do this on a 840D control, which to me is infinitely more powerful...
Here are some questions I’ve got about the process, and could use some guidance on:
Thanks for any help or insight you can provide.
Solved! Go to Solution.
You can use tcarr (with D code) to get the offset from the attach point of the head out to the end of tool tip. Tcarr is a static version of traori (which is dynamic.) You have to put in the lengths and angles (in tcarr variables) but the tool length can come from the tool data (D code.) So - one tcarr setting for the head and then any tool can be used in it. I have not used CYCLE800 or looked at it much. ROT's can decide your "frame" and a cutter comp can be used in that frame. We used CUT2D. My recollection is 6 years old and I would have to find examples for better (or even accurate) specific advice.
Thank you for the reply. I did see the TCARR variables mentioned in the documentation, and was able to find the 3 specific parameters that hold the XYZ offset to the tool tip. I'll keep digging through the documentation to see if I can figure out how to put this all together into useable NC Code. My end goal is to be able to:
Have you tried asking the Siemens (Control group) help about this?
For USA, try www.USA.Siemens.com/CNC4You
Production: NX10.0.3.5 MP16/TC11.2
I'd rather be e-steamed than e-diseaseled
Thanks for the link Ken. That is the kind of contact I was looking for. I'm fairly new to the 840D control. My experience is mainly with Fanuc controls. I sent them an email...
I don't know if this is the "correct" way to do this, but we use the following codes with a 5 axis B Head/C Table machine:
We use CYCLE800 only to handle table rotation, have not done any RAH work with the B axis at anything other than zero. Our machines won't rotate the table if the CYCLE800 rotation is only around the Z axis, the first line changes this behavior so the table will orient. The last line is what handles the frame rotation, with this example the RAH has the tool pointing Y+. Defining the tool as a RAH in the tool table unlocks entry fields for length 2 and length 3. Everything we have done we had the tool pointing Y positive, which translates to a negative value in length 2. Length 1 is from the spindle face to the RAH tool centerline. Length 2 is spindle centerline to tool tip. Drilling cycles, cutter comp, etc. all works with this method for us.
Thank you! This is exactly what I was looking for. I had seen the $TC_CARR37 variable, and remember thinking "This looks like something I'll need for my application", but I had been going through the 840D manuals for most of the day, and my brain was mush by that point. I know the Fanuc Control System really well, and am very fond of their Macro B for interacting with the Machine Parameters and PLC layer, but Siemens takes it to a whole new level with their control language.
This is a Nutating machine, but our B Axis is setup like you describe. When we position B at B0.0, the Tool is aligned pointing towards Y+, and will remain stationary throughout the cut. This is really just 3X motion anyway, since the CYCLE800 does the positioning of the tool prior to the cutting taking place. It is great to know about the $TC_CARR37 being used to permit the Table Rotation, and the use of CROT with $P_PFRAME.
The only trick I've got to figure out is just entering the correct C Axis Table Rotation values. For example, C=20.96581°, or C=206.0°. Our Work Offset location will always be the Center of Table Rotation for these operations.
Thanks again. I'm sure that with your code sample, I'll be able to figure out the correct settings for everything.
One thing I was really pleased to see is that my Control File in Vericut is properly setup to show an error with the Table Rotation when using my CYCLE800. There was something about "Cannot define Vector". The logic that is running is the actual CYCLE800 and Machine Subroutines from our real machine control. CGTech was able to configure our Control by reading the Siemens ARC (Archive) File, so the entire simultion uses the actual logic that is on our machine. I also saw the $TC_CARR variables called out in the .SPF file, so I'm sure that I'll be able to get Vericut to simulate this correctly as well, which will be very cool.
You mentioned "Drilling and Cutter Comp all work". Does this mean that my XYZ Code will now need to be output from NX as "aligned to the feature" now? Meaning that the Tool Axis of the actual cutting tool (at right angle to the spindle), is now aligned to the Rotated Frame's Z Axis? (I'm assuming that is what we just did with that CROT command.)
If so, I think I'll need to change my Coordinate System inside NX for that Operation, to "rotate" the output of the XYZ positions.
Yes, Z is now in line with the physical tool in the RAH. So programming is very straightforward from that point, you can almost forget about the RAH other than some different than usual approach moves.
Glad to see that you got questions answered on this forum. I have seen many of your posts on another forum and was impressed with the advice and support you gave to other users without being an overbearing fanboi. It is always good to have different perspectives brought into any conversation so please keep contributing here.
Thanks for the kind words Eric. This forum, and several others, have been great resources for me in my career. I'm happy to contribute when I can.