Refugee from Fusion 360 looking for advice

[gcode]

5 hours ago, RecceDG said:

1. O0000 on first line

In the Toolpath manager

Select all operations

Right Click

Edit selected operations/Change Program number

enter the desired program number... do not use the "O"

the post will add that 

 

 

 

[RecceDG]

I've made a bunch of progress.

These changes:

#region Start of file

psof0$           #Start of file for tool zero
      psof$

psof$            #Start of file for non-zero tool number
      probe_head$
      pcuttype
      toolchng = one
      if ntools$ = one,
        [
        #skip single tool outputs, stagetool must be on
        stagetool = m_one
        !next_tool$
        ]
      pbld, n$, *smetric, e$
      if convert_rpd$, pconvert_rpd
      # Changed by DG 01/01/2022 to get rid of spurious G0 and G80
      # pbld, n$, [if gcode$, *sgfeed], *sgcode, *sgplane, scc0, sg49, sg80, *sgabsinc, [if gcode$, *feed], e$
      pbld, n$, [if gcode$, *sgfeed], *sgplane, scc0, sg49, *sgabsinc, [if gcode$, *feed], pwcs, e$
      inhibit_probe$
      sav_absinc = absinc$
      if mi1$ <= one, #Work coordinate system
        [
        absinc$ = one
        pfbld, n$, sgabsinc, *sg28ref, "Z0.", e$
        pfbld, n$, *sg28ref, "X0.", "Y0.", e$
        pfbld, n$, sg92, *xh$, *yh$, *zh$, e$
        absinc$ = sav_absinc
        ]
      pcom_moveb
      pcheckaxis
      uninhibit_probe$
      c_mmlt$ #Multiple tool subprogram call
      ptoolcomment
      comment$
      pcan
      # Changed by DG 01/01/2022 to inhibit tool call because GRBL doesnt like it
      # Might be an idea here to output an optional stop in case we have multiple tools in a file
      # Instead of one tool per file as is my personal practice
      # Even better if somehow a comment can pop up in UGS or other sender programs
      # Although the best way would be for GRBL to support M6
      # Or for UGS to catch it and do something reasonable
      # For now, we just ignore the tool change, which has potential for disaster
      # pbld, n$, *t$, sm06, e$
      sopen_prn, "REMOVED A TOOL CHANGE ", *t$, sm06, sclose_prn, e$
      # Move spindle and speede to here DG
      pbld, n$, [if nextdc$ <> 7, *speed, *spindle], e$
      pindex
      if mi1$ > one, absinc$ = zero
      if use_rot_lock & (cuttype <> zero | (index = zero & prv_cabs <> fmtrnd(cabs))), prot_unlock
      if convert_rpd$, pconvert_rpd
      # Changed by DG 01/01/2022 to move spindle speed and coordiantes earlier and eliminate some spurious stuff GRBL doesnt like
      # pcan1, pbld, n$, [if gcode$, *sgfeed], *sgcode, *sgabsinc, pwcs, pfxout, pfyout, pfcout,
      #  [if nextdc$ <> 7, *speed, *spindle], pgear, [if gcode$, *feed], strcantext, e$
      pcan1, pbld, n$, [if gcode$, *sgfeed], *sgcode, pfxout, pfyout, pgear, [if gcode$, *feed], strcantext, e$
      if use_rot_lock & cuttype = zero, prot_lock
      result = force(feed)  # Force output of feed next time it's called for output
      # Changed by DG 01/01/2022 to eliminate the tool length call
      # pbld, n$, sg43, *tlngno$, pfzout, pscool, pstagetool, e$
      pbld, n$, pfzout, e$
      absinc$ = sav_absinc
      pbld, n$, sgabsinc, e$
      pcom_movea
      toolchng = zero
      c_msng$ #Single tool subprogram call

#endregion

 

Now produces this:

 

%
(O0000TEST)
(DATE=DD-MM-YY - 01-01-22 TIME=HH:MM - 17:59)
(MCAM FILE - M:\DOCUMENTS\DENNIS\SOLIDWORKS PROJECTS\MILL CONTROL PANEL\MILL CONTROL PANEL.SLDPRT)
(NC FILE - D:\DOCUMENTS\MY MASTERCAM 2022\MASTERCAM FOR SOLIDWORKS\MILL\NC\TEST.nc)
(MATERIAL - ALUMINUM MM - 2024)
( T2 | 1/4 SPOTDRILL | H2 )
G20
G17 G40 G49 G90 G54
( REMOVED A TOOL CHANGE  T2 M6 )
S27153 M3
G0 X1.3118 Y1.9291
Z.5
G1 Z-.075 F27.17
G0 Z.5

Now I just need to examine the end-of-file stuff and see what makes sense.

I'm using as light a hand as I can on the generic FANUC post processor and preserving a ton of extraneous features - I can't help but wonder if it would be worthwhile to do a stripped-down GRBL post that doesn't provide the opportunity to accidentally turn on stuff GRBL does not support.

[Colin Gilchrist]

You're on the right track. Also make the same edits to 'ptlchg$'. The block 'psof$' is only the "first tool change".

Find the similar line > 'pbld, n$, t$, "M06", e$'

And try replacing it with something like this:

sopen_prn,  *t$, sclose_prn, "M00", e$

 

[Leon82]

Linux CNC is the same way. It doesn't want an Oxxxx program number.

 

[RecceDG]

#region Tool change / stage tool
ptlchg$          #Tool change
      pcuttype
      toolchng = one
      if mi1$ = one, #Work coordinate system
        [
        pfbld, n$, *sg28ref, "X0.", "Y0.", e$
        pfbld, n$, sg92, *xh$, *yh$, *zh$, e$
        ]
      inhibit_probe$
      if prog_stop = 1, pbld, n$, *sm01, e$
      if prog_stop = 2, pbld, n$, *sm00, e$
      pcom_moveb
      pcheckaxis
      c_mmlt$ #Multiple tool subprogram call
      ptoolcomment
      comment$
      pcan
      result = newfs(15, feed)  #Reset the output format for 'feed'
      # Changed by DG 02/01/2022
      # Same deal - need to trap and inhibit tool change
      # We will issue a hard stop here as this subroutine is called for toolchanges
      # Other than the first
      # pbld, n$, *t$, sm06, e$
      sopen_prn, "REMOVED A TOOL CHANGE - STOPPING ", *t$, sm06, sclose_prn, e$
      pbld, n$, sm00, e$
      pindex
      sav_absinc = absinc$
      if mi1$ > one, absinc$ = zero
      if use_rot_lock & (cuttype <> zero | (index = zero & prv_cabs <> fmtrnd(cabs))), prot_unlock
      if convert_rpd$, pconvert_rpd
      # Changed by DG 02/01/2022
      # Same deal with spindle speed and mixing other codes with G0
      #pcan1, pbld, n$, [if gcode$, *sgfeed], *sgcode, *sgabsinc, *sgplane, pwcs, pfxout, pfyout, pfcout,
      #  [if nextdc$ <> 7, *speed, *spindle], pgear, [if gcode$, *feed], strcantext, e$
      pbld, n$, [if nextdc$ <> 7, *speed, *spindle], pgear, e$
      pbld, $n, *sgabsinc, *sgplane, pwcs, e$
      pcan1, pbld, n$, [if gcode$, *sgfeed], *sgcode, pfxout, pfyout, [if gcode$, *feed], strcantext, e$
      if use_rot_lock & cuttype = zero, prot_lock
      pbld, n$, sg43, *tlngno$, pfzout, pscool, pstagetool, e$
      absinc$ = sav_absinc
      pbld, n$, sgabsinc, e$
      pcom_movea
      toolchng = zero
      c_msng$ #Single tool subprogram call
      !xnci$, !ynci$, !znci$

Done. Thanks!

[RecceDG]

Oi, back to the lathe today.

I have a Kaiser Thinbit toolholder and insert thingy that I use for groove-turning. I decided to try modelling it in 3D, so I modeled it in SW, exported it as STEP, brought it into MC (standalone, as I figured out that you cannot build 3D tooling in MC4SW) and after a TON of trouble getting the insert oriented right, successfully brought it in to MC4SW and created a groove toolpath that worked.

Although for some damned reason it came in upside-down and ran the spindle backwards, defeating the purpose of modelling the holder because now it was facing the wrong way.

At least - because the insert is symmetrical - the toolpath still worked.

When editing the tool, I wound up using that gnomon tool a lot - is there a way to get it to switch axis? Like if I'm on XY, can I hit a key to get it XZ, then YZ?

Then, it turned out I modelled the part with the origin chuck-side (the back of the part) instead of tailstock-side (the front of the part. So Where I'm used to cutting Z negative, this was all Z positive. OK, no problem, I'll just move the WCS and T plane - and while I could get the gnomon to point in the right direction and be in the right place, NOTHING would make those toolpaths recognize the new origin point. NOTHING.

I wasted SO MUCH TIME trying this.

Eventually, I gave up, touched off the front of the part, jogged Z back to the back of the part, and set Z zero on the machine (which worked) but Dear Sweet Lob the Lobster God why would this not work?

[crazy^millman]

15 hours ago, RecceDG said:

Oi, back to the lathe today.

I have a Kaiser Thinbit toolholder and insert thingy that I use for groove-turning. I decided to try modelling it in 3D, so I modeled it in SW, exported it as STEP, brought it into MC (standalone, as I figured out that you cannot build 3D tooling in MC4SW) and after a TON of trouble getting the insert oriented right, successfully brought it in to MC4SW and created a groove toolpath that worked.

Although for some damned reason it came in upside-down and ran the spindle backwards, defeating the purpose of modelling the holder because now it was facing the wrong way.

At least - because the insert is symmetrical - the toolpath still worked.

When editing the tool, I wound up using that gnomon tool a lot - is there a way to get it to switch axis? Like if I'm on XY, can I hit a key to get it XZ, then YZ?

Then, it turned out I modelled the part with the origin chuck-side (the back of the part) instead of tailstock-side (the front of the part. So Where I'm used to cutting Z negative, this was all Z positive. OK, no problem, I'll just move the WCS and T plane - and while I could get the gnomon to point in the right direction and be in the right place, NOTHING would make those toolpaths recognize the new origin point. NOTHING.

I wasted SO MUCH TIME trying this.

Eventually, I gave up, touched off the front of the part, jogged Z back to the back of the part, and set Z zero on the machine (which worked) but Dear Sweet Lob the Lobster God why would this not work?

Without a way to follow along with the stand alone Mastercam file not much I can do to help. I don't have MCFSW and I was reading it is being sunsetted in 2024 to no longer be supported so might think about focusing more and more on the stand alone.

[RecceDG]

1 hour ago, crazy^millman said:

Without a way to follow along with the stand alone Mastercam file not much I can do to help. I don't have MCFSW and I was reading it is being sunsetted in 2024 to no longer be supported so might think about focusing more and more on the stand alone.

 

As I understand it, MC4SW is more-or-less standalone MC running in a SW instance, so all the UI elements, shortcut keys etc should be the same.

But I have to use MC standalone to edit 3d tools, so that's moot.

Anyway, here is an example. This is the holder for the tool in question. I rotated in in SW before exporting as STEP so that it would be oriented the same way in the machine - that is, the origin in the lower left is oriented the right way, with the long axis of the tool in X, Z+ going right, and Y+ going up.

The lathe in question is a CNC converted bench lathe, not a slant lathe, so the spindle is left and the toolpost is on the near side.

The screenshot shows the step where I define the machine connection.

Now the tooltip shows the X left and the Y down, so I rotated it accordingly... but I do not understand why it wants THAT orientation - should it not match the lower-left axis orientation?

Is there a way to change the dynamic gnomon (the one on the back of the tool) to control different axis?

 

[crazy^millman]

36 minutes ago, RecceDG said:

 

As I understand it, MC4SW is more-or-less standalone MC running in a SW instance, so all the UI elements, shortcut keys etc should be the same.

But I have to use MC standalone to edit 3d tools, so that's moot.

Anyway, here is an example. This is the holder for the tool in question. I rotated in in SW before exporting as STEP so that it would be oriented the same way in the machine - that is, the origin in the lower left is oriented the right way, with the long axis of the tool in X, Z+ going right, and Y+ going up.

The lathe in question is a CNC converted bench lathe, not a slant lathe, so the spindle is left and the toolpost is on the near side.

The screenshot shows the step where I define the machine connection.

Now the tooltip shows the X left and the Y down, so I rotated it accordingly... but I do not understand why it wants THAT orientation - should it not match the lower-left axis orientation?

Is there a way to change the dynamic gnomon (the one on the back of the tool) to control different axis?

 

Well the problem is how has the post configured to handle spindle rotations with the lower left axis combination? All of these depending on the post are configured for each machine and if they have not been configured correctly will give you all kind of problems. The 3D tools has numerous ways to define them and yes for a beginner IMHO can be some what over whelming. It seems like you have a grasp on how to do it, but again if the post was not configured correctly then all that effort would be for not since your machine more than likely is different than a standard configuration.  Here is where to look just to give you a place to start seeing what might work.

# --------------------------------------------------------------------------
#Machining position turret/spindle settings
# Switch strings based on turret position top/bottom-left/right and cut type.
# Turret position is based on the Mastercam settings (see lathtype).
# Strings are re-assigned for output in the routine psw_str_mult.
# The string variable sw_string holds the place position value to determine
# how to assign the strings.  Planes are relative to the view from Mastercam.
# Assign the 17 digit string following the alpha columns below:
# A - C axis, 1 = axis winds, 2 = axis signed, 3 = indexer, 4 = shortest direction
# B - Spindle direction, 0 = normal, 1 = reverse
# C - Plane 0 arc/comp, 0 = normal, 1 = switch
# D - Plane 1 arc/comp, 0 = normal, 1 = switch
# E - Plane 2 arc/comp, 0 = normal, 1 = switch
# F - Plane 0, 0 = G17, 1 = G19, 2 = G18
# G - Plane 1, 0 = G17, 1 = G19, 2 = G18
# H - Plane 2, 0 = G17, 1 = G19, 2 = G18
# Decimal (required)
# I - Plane 0, X axis, 0 = normal, 1 = switch sign from basic
# J - Plane 0, Y axis, 0 = normal, 1 = switch sign from basic
# K - Plane 0, Z axis, 0 = normal, 1 = switch sign from basic
# L - Plane 1, X axis, 0 = normal, 1 = switch sign from basic
# M - Plane 1, Y axis, 0 = normal, 1 = switch sign from basic
# N - Plane 1, Z axis, 0 = normal, 1 = switch sign from basic
# O - Plane 2, X axis, 0 = normal, 1 = switch sign from basic
# P - Plane 2, Y axis, 0 = normal, 1 = switch sign from basic
# Q - Plane 2, Z axis, 0 = normal, 1 = switch sign from basic
use_only_tl  : 1     #Use only Top turret/Left spindle settings (below) for
                     #all Mastercam turret/spindle selections
                     #When configuring for multi-spindle/turret set to 0

#Columns-       ABCDEFGH.IJKLMNOPQ #Turret/Spindle            #Path Type
scase_tl_c1  : "10000222.000000000"  #Top turret/Left spindle, Turning cut
scase_tl_c2  : "11000012.000000000"  #Top turret/Left spindle, Right Face cut
scase_tl_c_2 : "11110012.000000000"  #Top turret/Left spindle, Left Face cut
scase_tl_c3  : "10010102.000000000"  #Top turret/Left spindle, Cross cut
scase_tl_c4c : "10000111.000000000"  #Top turret/Left spindle, Y axis subs. Cycle
scase_tl_c4  : "10000222.000000000"  #Top turret/Left spindle, Y axis subs.
scase_tl_c5  : "10000222.000000000"  #Top turret/Left spindle, Multisurf Rotary

#Columns-       ABCDEFGH.IJKLMNOPQ
scase_bl_c1  : "10000222.000000000"  #Bottom turret/Left spindle, Turning cut
scase_bl_c2  : "11000012.000000000"  #Bottom turret/Left spindle, Right Face cut
scase_bl_c_2 : "11110012.000000000"  #Bottom turret/Left spindle, Left Face cut
scase_bl_c3  : "10010102.000000000"  #Bottom turret/Left spindle, Cross cut
scase_bl_c4c : "10000111.000000000"  #Bottom turret/Left spindle, Y axis subs. Cycle
scase_bl_c4  : "10000222.000000000"  #Bottom turret/Left spindle, Y axis subs.
scase_bl_c5  : "10000222.000000000"  #Bottom turret/Left spindle, Multisurf Rotary

#Columns-       ABCDEFGH.IJKLMNOPQ
scase_tr_c1  : "10000222.000000000"  #Top turret/Right spindle, Turning cut
scase_tr_c2  : "11000012.000000000"  #Top turret/Right spindle, Right Face cut
scase_tr_c_2 : "11110012.000000000"  #Top turret/Right spindle, Left Face cut
scase_tr_c3  : "10010102.000000000"  #Top turret/Right spindle, Cross cut
scase_tr_c4c : "10000111.000000000"  #Top turret/Right spindle, Y axis subs. Cycle
scase_tr_c4  : "10000222.000000000"  #Top turret/Right spindle, Y axis subs.
scase_tr_c5  : "10000222.000000000"  #Top turret/Right spindle, Multisurf Rotary

#Columns-       ABCDEFGH.IJKLMNOPQ
scase_br_c1  : "10000222.000000000"  #Bottom turret/Right spindle, Turning cut
scase_br_c2  : "11000012.000000000"  #Bottom turret/Right spindle, Right Face cut
scase_br_c_2 : "11110012.000000000"  #Bottom turret/Right spindle, Right Face cut
scase_br_c3  : "10010102.000000000"  #Bottom turret/Right spindle, Cross cut
scase_br_c4c : "10000111.000000000"  #Bottom turret/Right spindle, Y axis subs. Cycle
scase_br_c4  : "10000222.000000000"  #Bottom turret/Right spindle, Y axis subs.
scase_br_c5  : "10000222.000000000"  #Bottom turret/Right spindle, Multisurf Rotary

Column B is what controls the spindle direction and M3 on your machine for Mastercam might need to be M4 or vice verse.

[RecceDG]

...and I just redid the tool, and the new version doesn't work - "unable to find intersections" - so I clearly missed a step somewhere.

Here's my zero problem.

Planes setup. Picked a plane on the part front. Set the offset. Gnomon is is correct position at the origin I want.

But the toolpath uses the origin at the part base - the home position for the tool here is Z=0, which makes it easy to see.

4 minutes ago, crazy^millman said:

Well the problem is how has the post configured to handle spindle rotations with the lower left axis combination? All of these depending on the post are configured for each machine and if they have not been configured correctly will give you all kind of problems. The 3D tools has numerous ways to define them and yes for a beginner IMHO can be some what over whelming. It seems like you have a grasp on how to do it, but again if the post was not configured correctly then all that effort would be for not since your machine more than likely is different than a standard configuration.  Here is where to look just to give you a place to start seeing what might work.

Column B is what controls the spindle direction and M3 on your machine for Mastercam might need to be M4 or vice verse.

It's screwed up even before it gets into post - comes into MC in the wrong orientation (upside down).

...but that might be in the tool definition. I just redid it, and checked some different boxes to ensure left spindle/bottom turret, but now it doesn't like it at all.

[RecceDG]

Back to XCarve.

I need to do a better job of setting up machine definitions so I can easily tell MC which machine I'm on - especially because I can go for months without using MC. I wound up using the default mill definition for this job which doesn't use my GRBL post processor, so I had to hand-edit a bunch of the gcode.

This was a basic engrave job. Do the lettering in Adobe Illustrator, export as DXF, pull that into SW as a sketch, extruded cut, 2D flat mill out the pockets. Not a "vcarve" engrave job with a chamfer bit; a flat-bottom mill job.

Mastercam refused to recognize the faces at the bottom of some of the letters as closed chains until I changed the chain tolerance from 0.0001" to 0.001". Not at all sure why.

 I prefer to have my work zero be the top of the stock, usually front left corner. One thing that Fusion does very well is it makes setting the WCS origin super easy as part of the stock definition. MC, I need a new plane, so go to Planes Manager, "Add New Plane", grab the geometry that is the top of the stock, name this plane "Stock Top", set it as WCS, G, and T. Display shows the gnomon in the right spot.

...but then the toolpaths are offset by 0.75" (the thickness of the stock), like the Z zero was the bottom of the stock. WTF?

And that's when I find as option in the pocket operation to pick the zero plane... Set that to "stock top" and now everything works as expected. Why does this not reference the WCS plane in the plane manager? Why in the name of Lob does the pocket op have a separate plane select option?

But I got my code exported and it cut fine, so huzzah!

[Leon82]

If you program your depth with incremental it will be correct when you change the plane and then Regen.

 

[RecceDG]

1 hour ago, Leon82 said:

If you program your depth with incremental it will be correct when you change the plane and then Regen.

 

Can you post a screenshot so I can see what you mean?

[Leon82]

5 minutes ago, RecceDG said:

Can you post a screenshot so I can see what you mean?

 

if you duplicate a main plane the tool plane will always snap back to the main when you change views.

 

IE, make a copy of top and don't change the origin

[RecceDG]

OK, thanks. When I get home I'll see what I have set.

[JParis]

3 minutes ago, RecceDG said:

OK, thanks. When I get home I'll see what I have set.

Here's the thing to remember...the incremental depth is the Z position of where your dri ving geometry is located, ie...

The top, Z0.  of your part...if the geometry that you chain is located at say, Z-.250 and that is at the depth that you want to cut, your incremental depth will be Z.000

If the chained geometry is located at to of the part Z.000 but you want a dpeth of .150....your incremental Z depth will be Z-.150...

Just need to rememebr that it is the difference from where the chained geometry is located.

[cncappsjames]

FWIW 99.9% of the time I use incremental. Because if I ever have to change a plane depth or change workholding stack height (which changes my simulation stuff) or something like that,, I want to be able to change it and regen everything without having to reset depths. I 100% of the time will miss something somewhere... guaranteed. Incremental helps me miss less.

[Leon82]

48 minutes ago, cncappsjames said:

FWIW 99.9% of the time I use incremental. Because if I ever have to change a plane depth or change workholding stack height (which changes my simulation stuff) or something like that,, I want to be able to change it and regen everything without having to reset depths. I 100% of the time will miss something somewhere... guaranteed. Incremental helps me miss less.

yes a 3d contour forced to 2d always stays from what i have seen. have to fix that one manually.

[RecceDG]

I feel like I'm missing something here, in that I'm not following the last couple of posts.

So I'm going to do a part with a 2D pocket in it. Sketch stock X/Y extents in Solidworks, extrude up Z, sketch pocket on upper Z face, extrude cut down to depth.

In this case I'm not doing a facing cut or anything, just the pocket, so stock extents are part extents. Go into the Mastercam tab, define stock extents as geometry extents, and I think I have to click on a corner to get the stock to line up with the geometry instead of being centered on it. I also have to pick a plane, so I use whatever plane gets me +Z as "up" (I think it is Mastercam Top, might be Mastercam Front)

So now I have the gnomon on the left front (X/Y) corner where I want it, but Z0 is on the bottom of the part and I want it on the top. So Planes Manager, Add New Plane, From Geometry, pick the top face of the part, call it "Stock Top" and check WCS, T, and G.

Now the gnomon is correctly located on the top face, left forward corner like I want.

New Pocket operation. Select the bottom face in the pocket for geometry. MC generates a chain around the edge at the bottom of the pocket.

Back to cut parameters. Fill in tool, speeds, feeds, roughing steps, yadda yadda. Preview cut and it's what I want.

Post code. Examine code, and instead of Z values being negative (down from zero) they are positive (up from part base). Curse. Swear. Tear hair.

Back to pocket parameters. Discover an option to pick WCS plane (why is this not inherited from planes manager?). Set WCS plane as "stock top". Regen code. Toolpath is identical. Post code, Z heights are negative, as expected.

Nowhere did I mess with "depths", incremental or not.

What did I miss?

[Leon82]

And maybe a setting with the gear at the top of the plane manager set your tool equal to construction plane.

 

He slept all your ops and hit edit come and perimeter go to planes you can set them all to your desired WCS.

[cncappsjames]

My 1st look would be WCS/T/C plane conditions in the Operation. After that if it checks out I'd make sure that absolute/incremental switch in Misc. Reals/Int. is correct since backplate is good to go from what you say. Next, I'd change the depth of the feature to absolute and re-pick a point on the feature and see if it matches the number I'm getting in my code. After that... I'd have to give it some more thought.