Welcome to Our Community

Some features disabled for guests. Register Today.

Duet Controller/Fusion 360 post fix

Discussion in 'CAM' started by Alex Chambers, Jul 21, 2019.

  1. Alex Chambers

    Alex Chambers Veteran
    Moderator Builder

    Joined:
    Nov 1, 2018
    Messages:
    928
    Likes Received:
    480
    I ran into a problem recently with the way Ooznest have set up the firmware for the Duet controller on the Workbee. They use (modal) G54 as the machine co-ordinates and G55 as the first workplace co-ordinates. I had run a job the previous day, and knowing the Duet remembered workplace co-ordinate settings I homed the machine, jogged close to work zero and ran the g-code. Before I could hit the emergency stop my machine had dived towards machine zero - where Z zero is below the spoil board surface! Obviously I had not changed to workplace co-ordinates and the problem wouldn't have arisen if I had "returned to workplace zero" before running the g-code. In order to prevent such stupidity in future I have modified the Fusion 360 post processor for the Duet/Workbee to include G55 (change to workplace co-ordinates) at the beginning of the g-code file.

    To edit the post processor I found I had to have a job with a defined toolpath open (Fusion experts can tell us if there is another way). Click on post-process and click on "open config"

    fusin post fix 2.jpg

    Add lines shown below in bold

    function onSection() {

    var retracted = false; // specifies that the tool has been retracted to the safe plane

    writeln("");
    if(isFirstSection()) { // for Alex Chambers 11/05/2019
    writeln ("G55")
    }



    Save the file.
    This works for me, but again Fusion experts can tell us if there is a better/neater way of doing it.

    Alex.
     
    #1 Alex Chambers, Jul 21, 2019
    Last edited: Jul 21, 2019
    sharmstr and GrayUK like this.
  2. sharmstr

    sharmstr Veteran
    Moderator Builder

    Joined:
    Mar 23, 2018
    Messages:
    961
    Likes Received:
    582
    Eeek. The way you've done it is fine. But here's a few suggestions.

    You can edit the post processor by going to the file itself. A pain to do if your post is buried deep in your user folder, so doing it via config button is probably the fastest for most people. (reason I keep mine on the desktop and cloud)


    Does the Duet support multiple work offsets? Like when you want to produce multiples of the same part during a single job and patterning wont suffice? If so, your code wont allow for that (obviously neither does ooznest code). I can get you the code if you want/need.
     
  3. Alex Chambers

    Alex Chambers Veteran
    Moderator Builder

    Joined:
    Nov 1, 2018
    Messages:
    928
    Likes Received:
    480
    The Duet should support multiple work offsets - haven't needed them yet so haven't found out if Ooznest's implementation works - can't see any reason why it shouldn't! I'll face that problem when I come to it.
    Thanks
    Alex.:)

    You can edit the post processor by going to the file itself.

    Yes I know, but figured if people had followed Autodesk's instructions to the letter this was easier than explaining where in appdata the file was hidden.
     
    #3 Alex Chambers, Jul 21, 2019
    Last edited: Jul 21, 2019
  4. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Hi Alex, yes from what I recall of the Fusion posts, that is fine, so long as the G55 is output before any G00, G01, G02 or G03 motion block in the program - Geoff
     
  5. Alex Chambers

    Alex Chambers Veteran
    Moderator Builder

    Joined:
    Nov 1, 2018
    Messages:
    928
    Likes Received:
    480
    It comes straight after the G21, G90 - so well before any move codes.
    Alex.
     
  6. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Hi,
    My first post here. May I thank all (particularly Alex) for the help on setting up my Lead CNC with the duet. So far all my questions have been answered in previous threads.

    I've encountered the problem described by Alex and had taken to manually editing Fusions' output g-code on each post.

    The OOZnest post processor (V1.01) seems to be missing the //WCS section to allow it to work natively with Fusions WCS controls. Copying the //WCS section from another post processor with very slight modifications
    allows this to work. Modifications are listed at the end of the post.

    I've attached an example post processor file. I've attempted to follow the 'G54 are machine co-ordinates' convention and if none are specified it will default to G55 in the post nc.

    This will allow multiple work offsets as described in Byrons Video here . For example you may now cut 5 parts with 3 tool changes instead of 10 and create setups and fixtures for flipping work over.

    I've not added the ability to use the extended offsets (G59.1-3) but if you are advanced enough to need them, adding support will be relatively easy.
    For my particular use I'm also zeroing both G53 and G54 in the homing macros to avoid mistakes when copying from youtube.

    Again heartfelt thanks to this community any information, suggestions, criticism or improvements are welcome.

    Ian





    Additions by line number ref Ooznest post processor V1.1

    Line 82
    var WARNING_WORK_OFFSET = 1;

    Lines 193-210
    // wcs
    // Modified to suit ooznest WCS convention with G54 being machine coordinates.
    var workOffset = currentSection.workOffset;
    if (workOffset == 0) {
    warningOnce(localize("Work offset has not been specified. Using G55 as WCS."), WARNING_WORK_OFFSET);
    workOffset = 1;
    }
    if (workOffset > 0) {
    if (workOffset > 5) {
    error(localize("Work offset out of range."));
    return;
    } else {
    if (workOffset != currentWorkOffset) {
    writeBlock(gFormat.format(54 + workOffset)); // G55->G59
    currentWorkOffset = workOffset;
    }
    }
    }
     

    Attached Files:

    sharmstr and Alex Chambers like this.
  7. Alex Chambers

    Alex Chambers Veteran
    Moderator Builder

    Joined:
    Nov 1, 2018
    Messages:
    928
    Likes Received:
    480
    Hi @ian McFadden, that looks really interesting! I'm away for a few days, but I'll definitely have a play with that when I get back.
    Many thanks, Alex. :thumbsup:
     
    ian McFadden likes this.
  8. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Hi, I've just discovered the latest ooznest beta 1.07 is now using G54 as the default work coordinate space. They suggest we update our macros and follow suit. Suits Me!
     
    Alex Chambers likes this.
  9. sharmstr

    sharmstr Veteran
    Moderator Builder

    Joined:
    Mar 23, 2018
    Messages:
    961
    Likes Received:
    582
  10. Alex Chambers

    Alex Chambers Veteran
    Moderator Builder

    Joined:
    Nov 1, 2018
    Messages:
    928
    Likes Received:
    480
    It's taken me months to get my head around Ooznest's peculiar g-code and now I'm going to have to learn to do things the same way as everyone else! :banghead::banghead::banghead:
    Does the Duet Web Control display machine (absolute) co-ordinates properly? I'm assuming they are using G53?
    Alex. :cry::cry:
     
  11. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Hi Unfortunately it seems a bit buggy (it is beta after all).
    If you home all axis it throws in a G92 to reset you current WCS as well as homing MCS (G53), this can be cured by removing g92 from the homeall macro.
    If you use the set xyz buttons it applies the offset to G54 which may not be your current WCS. This behavior appears to be coded in java so i don't have a solution other than to use g92 at the console to alter the current WCS.:banghead:
    I must say however the layout of the ooznest DWC is the best I've seen, it shows user offset and machine offset on the main page an may well be a joy to use when ironed out.

    :thumbsup: ian
     
  12. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Yes it appears that Ooznest are implementing Absolute Machine Coordinates at 1.0.7, although some changes are needed in the DWC to display both Absolute Machine and Work Offset Coordinates. Presumably the M208 from config.g tells the control the absolute coordinate system in conjunction with the homing macros G1 H1 etc., so I would agree that G92 and any reference to Work Offset should go out of the home macros.
    G54 is active by default at turn on, so a few changes to the Ooznest macros and post-processors will be needed.

    I will also have to change my X & Y limit switches to the maximum end (standard for the WorkBee) when 1.0.7 is mature.

    In the meantime, I'm running my machine very happily with the legacy Ooznest G54 G55 scenario, without any problems.
    - Geoff
     
  13. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Hi @ian McFadden, you said that the DWC displays both Machine and Work Coordinates; is this from a DWC V2.0.0- version? Geoff
     
  14. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Hi @GeoffH
    It's in the DWC provided in the ooznest beta previously linked (forked from DWC2). It's been well modified for CNC and does show both current offset and machine co-ordinates. Ryan has it on github here.

    I've raised a pull request to start a discussion on the buttons and outlined a simple solution, though on reflection it may be better to map the Set xyz buttons to macros. Then we'd all be able to maintain our existing workflows as we wish.

    Back on the subject of Post processors Mwinterm's Fusion PP for the Duet handled multiple workspaces and tool changes so may be good for inspiration.

    Thanks
    Ian



    Screenshot
    worrkbeecontrroll.PNG
     
    #14 ian McFadden, Aug 19, 2019
    Last edited: Aug 19, 2019
    sharmstr likes this.
  15. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Thanks Ian, I haven't seen that screen before, it already looks much better for our Routing needs.

    I've read your Update MovementPanel.vue #1

    I've also been changing my own macros already to use G54 as the first work offset, without the display above using DWC v1.something , I only see the Work Coordinates, so I will get the new interface running now. Yes the homing macros shouldn't have G92 which will override the current Work Offset, but I'm not sure whether I have the correct Machine Coordinates set after the home. It would appear not because G53 doesn't take me to where I'm expecting, I was converting the move to a safe Z height in "Return to Work Zero".
    Anyway I'm off to get the new interface running, thanks for your input.

    Geoff
     
    ian McFadden likes this.
  16. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Geoff, like you i have my x and y home switches at the low end (nearest me with the motors at the back of the machine)
    I struggled at first with the m574 parameters I'd read the wiki the wrong way.
    For clarity i've attached a few snips from my config files.

    Great point on the return to work zero button, could easily be the break my endmill button:blackeye:

    Ian

    In Config G
    ; Drives
    M569 P0 S1 ; Drive 0 goes forwards -x
    M569 P1 S0 ; Drive 1 goes Backwards -y1
    M569 P2 S1 ; Drive 2 goes forwards -z
    M569 P3 S0 ; Drive 3 goes Backwards -y2
    ........
    ........
    ; Endstops
    M574 X1 (low end) Y1 (low end) Z2 (High end) S0 (switch active low) ; Set home directions and active low endstop switches

    .....
    .....
    ; Axis Limits
    M208 X0 Y0 Z0 S1 ; Set axis minima
    M208 X740 Y830 Z94 S0 ; Set axis maxima (set for Lead 1010)


    In Home all

    ...

    G1 H1 Z94 F300 ; send to home in the correct direction and set limit as defined in M208
    .....
     
    #16 ian McFadden, Aug 19, 2019
    Last edited: Aug 19, 2019
  17. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Ah Ian, this morning I moved my limit switches :banghead:, so now I have M574 X2 (high end) Y2 (high end) Z2 (High end) S0 (switch active low), initially I thought like you it was more logical to go the other way. Now I have loaded the new interface, and see all Machine coordinates are -ve.:(
    The reason I changed was that I had a discrepancy with Ryan on an issue that I could only put down to that difference, anyway not to worry, this is what I have now in homeall.g,
    G91 ; relative positioning
    G21 ; Set units to mm
    G1 H1 Z125 F900 ; move quickly to Z axis endstop and stop there (first pass)
    G1 Z-3 F900 ; go back a few mm
    G1 H1 Z4 F300 ; move slowly to z axis endstop once more (second pass)
    G1 H1 X750 Y350 F2000 ; move quickly to X and Y axis endstops and stop there (first pass)
    G1 X-3 Y-3 F900 ; go back a few mm
    G1 H1 X4 Y4 F300 ; move slowly to X and Y axis endstops once more (second pass)
    G90 ; absolute positioning

    This seems to be ok, now I need to see what is happening to the Machine Coordinate display
    Geoff
     
    ian McFadden likes this.
  18. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    if all machine co-ords are -ve try your m208 commands and motor directions. Having the display up front will help no end.
     
  19. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Ian, it's fine now, I hadn't properly started the Duet. Yes, I see that Ryans been working on a modification to DWC v2.0.0
    As you said the Set Buttons and Goto Work Zero are now hard-coded into the javascripts. Ryan just emailed me saying that he's done a lot more changes than those in the update, so I think I'll wait a bit. It looks like what is there now might work for me?? but I'll have my hand on the Emergency Stop for a while.
    If you want more than one Work Offset then it needs an Offset Selection method, but all in all, it's looking like a big improvement for Router users and good to know that Ryan has a handle on things now, rather than relying on Christian from Duet whose obviously focused on 3d printing - Geoff
     
  20. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Glad to know its all working and changes are in hand.:)
     
  21. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Hi Ian, Ooznest v1.0.7 is promising to be a much nicer way of working with a single work offset, most of the old macros are no-longer needed (less is more:):)).
    I'll do some more tests tomorrow.
    Regarding Mwinterm's Fusion PP for the Duet I don't use Fusion myself but I've had a quick scan of the modified OnSection method, and first impressions are that it's unsuitable for a simple machine like mine. Not many comments, I'm guessing that Fusion identifies different workpieces to the PP? So I'm not sure what he's doing without running Fusion and testing it, which I really don't want to do.
    I think Alex has implemented Tool Changes in Fusion but not Multiple Work Offsets?

    Geoff
     
  22. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    I think the ooznest machine interface is the best i've seen for cnc on the Duet :thumbsup:
    Fusion is capable of managing the WCS system and generating code to cut multiple copies of a single model, ordering the cuts by tool.
    It's also useful for fixtures ( I Have a machinist vice on my bed for small parts), with fusion i can control the WCS from the desktop now.
    The simple PP I uploaded earlier will give fusion multiple work offset on the duet, defaulting to g55 (if needed)

    But I'm in total agreement that simpler is better.

    If i can get a working WCS and Alex's tool changes working for me I'll be over the moon.

    I'm still convinced the duet was the right choice. We live in the best of times.

    Thanks
    Ian
     
    GeoffH and sharmstr like this.
  23. sharmstr

    sharmstr Veteran
    Moderator Builder

    Joined:
    Mar 23, 2018
    Messages:
    961
    Likes Received:
    582
    Adding multiple work offsets is only a few lines of code.
     
    ian McFadden likes this.
  24. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Agreed Ian, I can see many Production Engineering applications for Multiple WCS, but not so much for my basic Wood Routing applications. In my situation each program is invariably cutting a single piece of wood, Cutting boxes.JPG so if repetitions are involved, it wouldn't require further offsets, the program will be large, unlike the old days when it was often necessary to produce sub-programs due to lack of NC/CNC memory. In my retirement I'm mostly cutting craft Arty type things, 3d models, and a lot of V bit carving; sad I know:(.
    That said, when you have implemented the multiple WCS, I will be interested to see if it's possible to achieve the same in the Vectric PP.
    Geoff
     
    ian McFadden likes this.
  25. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Hi Guys, WRONG again. I said somewhere that G92 set coordinate values in the current WCS, that's wrong, the G92 sets the Absolute Machine Coordinate values, and then offsets all WCSs accordingly. So the home macros do require G92s in the Ooznest v1.0.7 scenario, although if you omit them the Machine Position is displayed as you would expect, but internally in the control it's wrong.
    Sorry for any confusion caused. :oops::oops: Geoff
     
    ian McFadden and sharmstr like this.
  26. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Thanks Geoff, you've enlightened me. G92 stays in the Macro and should be run as part of the homing.
     
  27. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Thanks Ian, I haven't found any major issues with Beta 1.0.7, all in all, much better than V1.0.6 in my opinion, for my requirements at least. Looking forward to the Release version 1.0.7 now.
    There aren't many macros required with the new Ooznest DWC, which is good news and G54 is only written in config.sys, although I think that may be the default anyway, so the remaining macros operate in the current WCS. However the current Z probe macro specifies G10P.. code that sets coordinates in the specified Work Offset. I see that you propose removing it, so you would need to manually SetZ or SetXYZ afterwards, that's assuming that the Javascript coded Set buttons work in the current WCS. I'm guessing they don't but I haven't tested that, do you know?
    Geoff
     
  28. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    Hi Geoff,
    All the Set buttons are currently bound to G54 workspace and switch to the G54 workspace when prressed.
    For example "`G10 P1 L20 X0 Y0 Z0\nG54\nM500`" is hardcoded to the Set XYZ Button.

    If we change that to "`G10 L20 X0 Y0 Z0\nM500`" (Dropping the P parameter on G10 and losing the G54 command the button) the button will will work on the currently selected WCS instead of putting you back in G54.

    I've built this on github and am currently testing for unwanted interactions
     
  29. ian McFadden

    Builder

    Joined:
    May 7, 2019
    Messages:
    12
    Likes Received:
    6
    oh and although G54 in the config.g is not to NIST spec I can see that it could be a good practice (and drop the number of support calls), i think the resume workflow may need looking at for those in alternate WCS.
     
  30. GeoffH

    GeoffH Well-Known
    Builder

    Joined:
    Mar 11, 2017
    Messages:
    144
    Likes Received:
    97
    Hi Alex, dropping the P address from G10 seems a good idea, but Duet doc and NIST spec. seems to say that it's needed. I've seen other systems where P0 means the active WCS? Are you setting the WCS number through the GCode console?
    I don't know whether Duet maintains the Parameters described in NIST, where 5220 is the current WCS number, ideally it would be nice if the DWC could see the active WCS number and other Parameters?
    I think you will need a display of the active WCS in the DWC to avoid confusion for the User.
    Do you use Visual Studio to build the DWC?

    Geoff
     

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