Duet Controller/Fusion 360 post fix

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

 

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;
}
}
}

 

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!

 

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.
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.

ian

 

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

 

Hi @ian McFadden, you said that the DWC displays both Machine and Work Coordinates; is this from a DWC V2.0.0- version? Geoff

 

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

 

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

 

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

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
.....

 

Ah Ian, this morning I moved my limit switches , 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

 

if all machine co-ords are -ve try your m208 commands and motor directions. Having the display up front will help no end.

 

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

 

Glad to know its all working and changes are in hand.

 

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

 

I think the ooznest machine interface is the best i've seen for cnc on the Duet
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

 

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

 

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. Geoff

 

Thanks Geoff, you've enlightened me. G92 stays in the Macro and should be run as part of the homing.

 

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

 

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

 

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.

 

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