Welcome to Our Community

Some features disabled for guests. Register Today.

BugReport: OB F360 post proc. Erroneous parameter usage?

Discussion in 'CAM' started by malman, Aug 7, 2023.

  1. malman

    malman New
    Builder

    Joined:
    Aug 7, 2023
    Messages:
    1
    Likes Received:
    0
    Fresh into this,
    Setting up Fusion to feed a GRBL based plasma cutter, 3 axis (incl Z), using the OpenBuilds Fusion360 PostProcessor.

    Took some time to get to grips with parameters and postproc values to get the result i wanted. (z-axis control from Fusion).

    But noticed that there is a discrepancy in how some Fusion parameters is seen upon from FusionSide, and another from the OBF360PP side. I was looking to raise an 'issue' in github, but that function seams to be disabeled... So I post it here instead in the hope of the pp maintainer notices it.

    As i understand it, the TopHeight defines the normal cutting height, when z-axis is enabled. (as in the Heights Tab of each cutting operation)

    And the PierceClearance in the Linking tab seams to control the PierceHeight. (as long as override pierce height is not ticked on post params.)

    But this later definition seams to be an misuse of the parameter, as Fusion seams to use this to define the sideways offset of the pierce. increasing this value not only increase the pierce height but also adds a sideway extension of the cut line when looking at the toolpath (before post processing). So I believe that the use of this param in the postprocessor for pierce height is unfortunate, and should in my mind be changed.

    (I guess that the work around is to use the PostProcessorParameter 'Override PierceHeight')

    It seams that Fusion has changed a lot of these PostProcessor dialogs and window's lately, so maybe meaning of parameters have changed or evolved?

    In a similar fashion:
    Fusion seams to have altered the plasma tool definition page, It seams old descriptions tells you to define kerf width and a clearance of the whole cutting head. But nowadays the tool parameters are 'nozle diameter' and kerf width'. So Fusion seams to done some rearrangements in the CAM parameters.

    Or at least that's my take of it all...

    Thoughts??
     
  2. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Mar 1, 2017
    Messages:
    14,701
    Likes Received:
    4,249
  3. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,393
    Likes Received:
    1,892
    I have noticed (-:

    Please confirm you have read and followed this
    OpenBuilds-Fusion360-Postprocessor/README-plasma.md at master · OpenBuilds/OpenBuilds-Fusion360-Postprocessor

    in particular the top heights stuff
    • Make sure that the stock is the same thickness as the model, make sure no stock is added on top of the material.
    • On all operations select Top Height as 'Stock Top' and enter the cutting head height for normal cutting (like 0.8mm).
    • On all operations set the Pierce Clearance under Linking, must be greater than the cutting height (like 1.5mm).
    as above, topheight is stock top plus the cutting height offset, I havn't looked at the dialog for a bit, when I wrote the instructions it was obvious where to enter the height but that may have changed <-:
    yes.

    Which is why you can override it to seperate the height from the sideways distance.

    quite probable, like a painting, software is never 'finished' and a product like Fusion360 is always under revision.
    Since I don't own a plasma cutter I don't look at this part of the post often (send me one and I will definitely use it :) and the consequence will be that I have fresh ideas for the post )
    Those may be just terminalogy changes, or they may reflect changes in the way they use the cutting head geometry to generate paths that avoid clamps and so on. I wonder if it was mentioned in a release note.

    I do recall that I had to write some interesting code to make plasma paths behave properly when the setting that makes it go around previously cut patterns is active (forgotten the precise name). This is to avoid hitting the dross on the edges of previous cuts but Fusion had the idea that such moves should be at cut speed rather than at rapid speed. The post solves this, among other internal Fusion funnies.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice