So not a Guru

Screwy arc output

Recommended Posts

MC is outputting this for an arc:

 

G1 Z.9476 F25.
G41 D17 X-4.2967 Y4.0874 F8.25
G3 X-4.2968 Y4.0874 I.3388 J-.1742
G1 G40 X-4.1189 Y3.9959

The result being that the machine cuts the lead in & lead out only, no arc.

Anyone know is this an MC issue, or a post issue?

Share this post


Link to post
Share on other sites

Try going into the control def >> arcs and let it break arcs...

also, in Mastercam, with backplot set to show distance moves, not endpoint moves, is it actually going around in an arc?

Share this post


Link to post
Share on other sites

Try making the diameter an even value. It looks like it's rounding funny

Share this post


Link to post
Share on other sites
43 minutes ago, JParis said:

Try going into the control def >> arcs and let it break arcs...

Whoa! Allowing break arcs at 180° changed to output to cut in a completely different location, I shifted the work offset up & sure enough, it would have cut the hole in the wrong location.

 

G1 Z.8349 F25.
G41 D17 X-4.4971 Y4.0399 F8.25
G3 X-4.4971 Y4.0399 I.3388 J-.1742
G1 G40 X-4.3192 Y3.9484

Share this post


Link to post
Share on other sites

Do you have the shorten lead in checked?

Share this post


Link to post
Share on other sites
57 minutes ago, So not a Guru said:

MC is outputting this for an arc:

 

G1 Z.9476 F25.
G41 D17 X-4.2967 Y4.0874 F8.25
G3 X-4.2968 Y4.0874 I.3388 J-.1742
G1 G40 X-4.1189 Y3.9959

The result being that the machine cuts the lead in & lead out only, no arc.

Anyone know is this an MC issue, or a post issue?

If you output as R is it the same issue?

Share this post


Link to post
Share on other sites
2 minutes ago, Leon82 said:

Do you have the shorten lead in checked?

Do you mean the "Adjust start/end of contour"? If so, then no I do not.

Share this post


Link to post
Share on other sites
7 minutes ago, Thee Byte™ said:

If you output as R is it the same issue?

Apparently, I would have to modify the post for this, changing it in the CD had absolutely no effect on the output.

Share this post


Link to post
Share on other sites
5 minutes ago, So not a Guru said:

Apparently, I would have to modify the post for this, changing it in the CD had absolutely no effect on the output.

What operation is responsible for this?

Share this post


Link to post
Share on other sites
18 minutes ago, Thee Byte™ said:

What operation is responsible for this?

Contuor

Share this post


Link to post
Share on other sites
40 minutes ago, So not a Guru said:

Contuor

So the lead in is the issue?

If its set to pct maybe set it to a rounded value instead.

 

Share this post


Link to post
Share on other sites

can you upload that mastercam file ... just that contour

also, what post are you running??

it must be a very old post if it does not respect Control Def edited on the Arc page

Share this post


Link to post
Share on other sites
9 minutes ago, gcode said:

can you upload that mastercam file ... just that contour

also, what post are you running??

it must be a very old post if it does not respect Control Def edited on the Arc page

Here is a zip2go of just the arcs. It's a Postability post, about 4 or 5 years old, but we opted not to pay maintenance.

for CC.ZIP

Share this post


Link to post
Share on other sites
2 hours ago, So not a Guru said:

Whoa! Allowing break arcs at 180° changed to output to cut in a completely different location, I shifted the work offset up & sure enough, it would have cut the hole in the wrong location.

@JParis, I'm a dumba$$, I forgot to uncheck the "Allow 360 degrees arcs" box. I've already hand edited the original code, so we can get the parts out, but it looks like this might work.

  • Like 2

Share this post


Link to post
Share on other sites
2 minutes ago, So not a Guru said:

@JParis, I'm a dumba$$, I forgot to uncheck the "Allow 360 degrees arcs" box. I've already hand edited the original code, so we can get the parts out, but it looks like this might work.

Yeah, it seemed to me a control def setting, that was why I asked about the backplot move too  :)

:cheers:

Share this post


Link to post
Share on other sites
Just now, JParis said:

Yeah, it seemed to me a control def setting, that was why I asked about the backplot move too  :)

:cheers:

It still outputs a different end point than the start point though.

G1 Z.9476 F25.
G41 D17 X-4.2967 Y4.0874 F8.25
G3 X-3.6192 Y3.739 I.3388 J-.1742
X-4.2968 Y4.0874 I-.3388 J.1742
G1 G40 X-4.1189 Y3.9959

Share this post


Link to post
Share on other sites
13 minutes ago, So not a Guru said:

It still outputs a different end point than the start point though.

G1 Z.9476 F25.
G41 D17 X-4.2967 Y4.0874 F8.25
G3 X-3.6192 Y3.739 I.3388 J-.1742
X-4.2968 Y4.0874 I-.3388 J.1742
G1 G40 X-4.1189 Y3.9959

That's just a rounding error...take it out to 5 places and you'll see the difference

  • Like 2

Share this post


Link to post
Share on other sites

Check your Geometry Zeke.

Not at 4 Decimal Places, but at 7 Decimal Places.

Is your Arc "perfect"? Make sure the Center Point Location, Radius, and Arc Sweep values are perfect.

I always double check my geometry now, at about 100 times the tolerance that I will be outputting to.

Remember, a 89.999431 Arc Sweep, could be interpreted as "90", due to rounding. At the actual "arc" location, you may be within a tenth, but once you've offset by the radius of your cutter + lead in/out values, you can see some of those rounding errors creep into your NC Code.

Anytime I'm getting a "1-tenth flutter" in the position output of my NC Code, the first thing I check is the quality of my geometry "input" to the system.

In rare cases, your geometry can be "perfect", but right on the edge of a rounding error itself.

Take the value 1.00045. Is it 1.0004 or is it 1.0005, based on rounding to 4 decimal places?

Well, you have to understand that your computer does not store any of your values as true rational numbers. All of the numbers are stored as 'floating point values', so occasionally there can be issues with Windows and the routines it uses to round the values internally. For these situations, there is a Post Variable 'round_opt$', which can be used to influence the rounding of these close values, to make sure they either round up, or round down, or are properly truncated.

 

  • Like 1

Share this post


Link to post
Share on other sites
19 minutes ago, Colin Gilchrist said:

Check your Geometry Zeke.

Not at 4 Decimal Places, but at 7 Decimal Places.

Is your Arc "perfect"? Make sure the Center Point Location, Radius, and Arc Sweep values are perfect.

I always double check my geometry now, at about 100 times the tolerance that I will be outputting to.

Remember, a 89.999431 Arc Sweep, could be interpreted as "90", due to rounding. At the actual "arc" location, you may be within a tenth, but once you've offset by the radius of your cutter + lead in/out values, you can see some of those rounding errors creep into your NC Code.

Anytime I'm getting a "1-tenth flutter" in the position output of my NC Code, the first thing I check is the quality of my geometry "input" to the system.

In rare cases, your geometry can be "perfect", but right on the edge of a rounding error itself.

Take the value 1.00045. Is it 1.0004 or is it 1.0005, based on rounding to 4 decimal places?

Well, you have to understand that your computer does not store any of your values as true rational numbers. All of the numbers are stored as 'floating point values', so occasionally there can be issues with Windows and the routines it uses to round the values internally. For these situations, there is a Post Variable 'round_opt$', which can be used to influence the rounding of these close values, to make sure they either round up, or round down, or are properly truncated.

 

I would've thought that this section would ensure there was no mismatch.

 

      #Check for mismatched arc data
      if xyarc,
        [
        arcrad1 = sqrt((fmtrnd(xcabs)-prv_xabs)^2+(fmtrnd(ycabs)-prv_yabs)^2)
        arcrad2 = sqrt((fmtrnd(xcabs)-xabs)^2+(fmtrnd(ycabs)-yabs)^2)
        ]
      if yzarc = 1,
        [
        arcrad1 = sqrt((fmtrnd(ycabs)-prv_yabs)^2+(fmtrnd(zcabs)-prv_zabs)^2)
        arcrad2 = sqrt((fmtrnd(ycabs)-yabs)^2+(fmtrnd(zcabs)-zabs)^2)
        ]
      if xzarc,
        [
        arcrad1 = sqrt((fmtrnd(xcabs)-prv_xabs)^2+(fmtrnd(zcabs)-prv_zabs)^2)
        arcrad2 = sqrt((fmtrnd(xcabs)-xabs)^2+(fmtrnd(zcabs)-zabs)^2)
        ]
      if fmtrnd(arcrad1) <> fmtrnd(arcrad2),
        [
        #if arcwarnflg = 0, result = mprint(sarcwarn)
        #spaces$ = 0
        #pn, pspc, sm00, " ", scomm_str, sarcwarn, scomm_end, pe
        #spaces$ = sav_spc
        #arcwarnflg = 1

        #result = fexist(snircmd)
        #sparams = 'speak text "' + sarcwarn + '"'
        #if result, result = launch(snircmd,sparams)
        ]
      if hel_lead = 1, pcirout2
      else, pcirout1

Share this post


Link to post
Share on other sites
29 minutes ago, Colin Gilchrist said:

Well, you have to understand that your computer does not store any of your values as true rational numbers. All of the numbers are stored as 'floating point values'

Not all values are stored as floating point types.

You have the whole number types short - int - long - long long, which all store different sizes of numbers.

Floating point numbers would typically be float(7 decimal places) or double(15 decimal places).

Share this post


Link to post
Share on other sites
12 minutes ago, Thee Byte™ said:

Not all values are stored as floating point types.

You have the whole number types short - int - long - long long, which all store different sizes of numbers.

Floating point numbers would typically be float(7 decimal places) or double(15 decimal places).

All values in Mastercam are stored as Doubles.

Share this post


Link to post
Share on other sites

Unless they recently made a change to the underlying data structure in Mastercam, but that would be a recent development, if they did. Historically, all 'reals' are stored as Doubles, and Strings are stored as Strings, up to the 'Windows MAX PATH' value, which I believe defaults to '2048' on 64-bit systems...

Share this post


Link to post
Share on other sites
1 minute ago, Colin Gilchrist said:

Unless they recently made a change to the underlying data structure in Mastercam, but that would be a recent development, if they did. Historically, all 'reals' are stored as Doubles, and Strings are stored as Strings, up to the 'Windows MAX PATH' value, which I believe defaults to '2048' on 64-bit systems...

That's interesting, you would know better than me whats under the hood. Are you referring only to the contents of the database or..

Share this post


Link to post
Share on other sites
1 hour ago, So not a Guru said:

I would've thought that this section would ensure there was no mismatch.

 

      #Check for mismatched arc data
      if xyarc,
        [
        arcrad1 = sqrt((fmtrnd(xcabs)-prv_xabs)^2+(fmtrnd(ycabs)-prv_yabs)^2)
        arcrad2 = sqrt((fmtrnd(xcabs)-xabs)^2+(fmtrnd(ycabs)-yabs)^2)
        ]
      if yzarc = 1,
        [
        arcrad1 = sqrt((fmtrnd(ycabs)-prv_yabs)^2+(fmtrnd(zcabs)-prv_zabs)^2)
        arcrad2 = sqrt((fmtrnd(ycabs)-yabs)^2+(fmtrnd(zcabs)-zabs)^2)
        ]
      if xzarc,
        [
        arcrad1 = sqrt((fmtrnd(xcabs)-prv_xabs)^2+(fmtrnd(zcabs)-prv_zabs)^2)
        arcrad2 = sqrt((fmtrnd(xcabs)-xabs)^2+(fmtrnd(zcabs)-zabs)^2)
        ]
      if fmtrnd(arcrad1) <> fmtrnd(arcrad2),
        [
        #if arcwarnflg = 0, result = mprint(sarcwarn)
        #spaces$ = 0
        #pn, pspc, sm00, " ", scomm_str, sarcwarn, scomm_end, pe
        #spaces$ = sav_spc
        #arcwarnflg = 1

        #result = fexist(snircmd)
        #sparams = 'speak text "' + sarcwarn + '"'
        #if result, result = launch(snircmd,sparams)
        ]
      if hel_lead = 1, pcirout2
      else, pcirout1

I mean, I guess not right!

Is this a big problem for you Zeke?

Share this post


Link to post
Share on other sites
28 minutes ago, Thee Byte™ said:

I mean, I guess not right!

Is this a big problem for you Zeke?

Actually, this is the 1st time I've had this issue. So, hopefully not.

Also, it looks like that snippet is for testing the junction between 2 different arcs not the issue I'm having. I could be wrong though, I am always struggling to interpret what the variables represent.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us