Problem with circles NX CAM 1

[bassplaya69er]

HI there,

i have recently come across a problem posting circular moves in NX 8 cam to a rather old control, a Bosh cc120, never had the problems before, but it has cropped up a couple of times recently,

Offending code:

G1 X2273.607 Y736.724
G2 X2276.343 Y735.802 I2273. J730.403

after a little research i suspected it may be because the start and end points were not the same distance from the centre, and i confirmed this using G-Wizard Editor, which informs me there just out side the standard tolerance for this ( not sure what tolerance the cc120 has for this)

does anyone know why NX cam does this, and if there is any way to fix it? seems odd to me that a program like NX cam cant do maths correctly or is it a post problem?

have attached the full Posted Gcode, and using something like g-wizard editor you can see the problem reoccurs, because this code is to make 14 of the same parts from one setup.

any help very appreciated

Matt

 

[joycejo]

Have you contacted GTAC?


John Joyce
N.C. Programming Supervisor
Barnes Aerospace, Windsor CT
NX6.0.5.3

 

[markrief]

With NX/Post this should not happen.
If you are using the CLS, then you probably just need to output with more accuracy - i.e. more decimal places.



Mark Rief
Product Manager
Siemens PLM

 

[Tingsryd]

I have come across circular interpolation errors once in a while; certainly not as often as I used to. I just had a couple errors last week, albeit the geometry was from some old file to which I united some other geometry. NX sometimes seems to have difficulty with dirty geometry. I used to experience those issues with z-level profile but haven't had those problems in a while. On our newer controls the G2/G3 errors halt the program but on our older controls the errors can be very problematic; the circular deviation is ignored by the control tolerance, is interpreted and the machine swings wild, huge arcs that can easily scrap a work piece. This is flaw in the control. Thank goodness I don't have to program for those machine much anymore.

The errors I had last week happened when I was using smoothing in cavity milling. Sometimes the errors disappear when I adjust the cavity mill depth of cut or intol/outtol but the recent errors would not go away unless I turned off smoothing. This really bothers me but, in fairness to NX, I know that particular geometry wasn't exactly super clean.

Back when I was first battling this issue years ago, GTAC had recommended to upgrade to the latest (at the time) version of NX and Postbuilder, to re-create my posts (supposedly there were some issues with posts created in older PB versions). GTAC also specified to set the Machine Tool-Linear Motion Resolution in the post to 5+ decimal places to ensure the rounded output is accurate. This isn't to be confused with the number of decimal place output, which is specified elsewhere in the post.

Post arc settings are crucial as well; too small settings can create problems. I recommend taking a look at your minimum arc, maximum arc and minimum arc length. Also you should look at whether your machine can handle full circles or needs circles broken into quadrants. Think about this: if the post's minimum arc is set to .0002", how is a machine with .0001" resolution supposed to execute that? Likewise there can be issues if the max arc is set to 9999.9999" and the arc length is only .002". Newer controls will handle this better than older controls.

NX7.5.5
NX8.0.2

 

[Tingsryd]

I looked up the post settings for one of our older machines that had circle issues. I realize these are very "open" settings but this particular machine is used for heavy roughing and does not require finer settings. G2/G3's that fall outside of these settings are output as linear movements.

Minimum arc is .005"
Maximum arc is 500."
Minimum arc length is .010"

NX7.5.5
NX8.0.2

 

[bassplaya69er]

Hi there,

Tingsryd:

I don't thing dirty geometry should be the issue, as I created the geometry in NX and it's fairly simple, but does contain 2 spline curve's.

I tried increasing the linear motion resolution in the post to 5 decimal points (machine control only handles 3 dp which is designed elsewhere on the post) post builder gives a warning on saving explaining that the word out put for x y z is less decimal places than the machine's linear resolution. I tried it anyway but there was no difference to the code output.

Currently for this part ( 14 of the same part in reality) in an out toll are really slack at 0.2mm but high accuracy is not required for this part and it allows me to get all 14 of the parts in one program rather than manuly setting up loops or fixture offsets. (side note: is it posible to get NX cam to insitence tool paths using absolute / incremental programming & loops?)

Circles definitely don't need to be broken in to quadrants for this machine currently the max arc length and radius are both set to 1mm (sorry metric!) it's only a wood router, the accuracy of the machine is only 0.001mm


Thankfully the machine errors out saying incorrect circle definition ( it does have another error in the book saying incorrect circle centre which I'm surprised it isn't throwing up).

The code in my first post defiantly has the start and end points a different distance from the centre ( 0.00011mm difference if I remember correctly) which is why I thought it may be a rounding error and hoped that increasing the machines linear resolution in the post would fix it as you suggested. But no luck.

I would like to set Up the post to use R rather than I and k really, except for helicticalsa, to help keep program sizes down, my sound ridiculous to those with modern controls but every little helps ( turning spaces and line members off made a huge difference to transfer speed and amount of useful program I could get on the machine.)

Thanks a lot for our suggestions.

Matt

 

[Tingsryd]

I think they added the error message about linear resolution since GTAC had me increase it my posts. I have several post with much finer resolution than 5 places.

That's really throwing me off. If the error is 0.00011mm and your machine resolution is .001mm, I would think that shouldn't be an issue. If you call GTAC they might ask you what the machine control's tolerance is. Still, the output should be accurate from end point to end point.

Another thing you might want to try, before pursuing other settings and whatnot, is to use Heal Geometry on your model before creating operations. It makes another model so you lose parametrics and associativity but if anomalies are giving you problems then you might want to consider it. At the end of the process it displays a window listing of corrected issues. I always get many fixed areas on parts we receive from customers and it has helped me a lot in cases where operation output is not as it should be. In fact, heal geometry is one of the first things our designers do to customer parts.

NX7.5.5
NX8.0.2

 

[bassplaya69er]

hi there,

just double checked the error in Gwizzard G-code editor and its 0.0011 not 0.00011 :

Line 35: X2279.009Y712.655Z13.5I2270.117J723.357 Distance from last move to center = 19.3880
Distance from this move to center = 19.3869
Arc endpoint: 2276.3430, 735.8020, 13.5000
Arc center coordinates: 2270.1171, 723.3570, 13.5000, radius = 13.9155 (determined by IJK)
Arc angles: 84.6 to 58.3(26.3 degrees total)

Time: 0-48.6
ERROR: Distance from each arc endpoint to center differs by 0.0011, more than tolerance of 0.0010.


im not certain what the tolerance of my machine is, but as its throwing errors it must be smaller than 0.0011 i would guess.

have been rather busy recently with other work, but will try heal geometry.

thanks.

Matt