Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Screwy arc output


So not a Guru
 Share

Recommended Posts

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

Link to comment
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?

Link to comment
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?

Link to comment
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

Link to comment
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 1
Link to comment
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:

Link to comment
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

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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).

Link to comment
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.

Link to comment
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..

Link to comment
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?

Link to comment
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • 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

×
×
  • Create New...