Coincidentally I kind of did the same and also shared my post 5 days ago:

https://forum.duet3d.com/topic/7187/problem-with-setting-working-coordinate-systems/9

I run both of them on the same model and they produce very similar results. The only differences I found were the following (when the tool-probing is deactivated):

1. Before the the first operation starts:
   Jacotheron:

; layer 1

; (Slot1)
G28 Z
G0 X10 Y10
M291 P"Insert Tool #1 (Dia:10 )" R"Tool Change - Paused" S3 X1 Y1 Z1
M3 S17000
M291 P"28000 RPM (#5 ~26000-[27000]-29000)" R"Spindle Speed" S3 X1 Y1 Z1

mine:

;SLOT1
M5 ;Makes sure the spindle is off before the tool change
T1 ;Call Tool 1
M3 S28000 ;Start Spindle at 28000RPM
G54 ;Set the working coordinate system

Jacotheron homes the Z-aces first, not sure why. I think normally homing should not be part of a cnc-program. Further he added a tool-change position which can be defined in the fusion post parameters which makes a lot of sense. However I think it should be in absolute machine parameters i.e. something like G53 G0 X10 Y10. Further the max RPMs can be capped using a fusion post parameter which is also cool as well as the comments that are issued regarding the tool change. However I think adding M5 would not hurt as the spindle should be stopped before any tool-change. T1 is missing in my understanding as without calling it the tool-offsets are not set. This might be obsolete if you probe every during the tool change. However I prefer to measure all my tools in before starting machining using tool-offsets. And even when probing during the machining I think it would be more correct to set tool-offsets using M585. Finally I think the right WCS should be called as well.

2. Before the second operation
   Jacotheron:
   ; layer 2

; (2D Pocket1)
M3 S17000

Mine:
;2D POCKET1

The call of M3 S17000 is obsolete as the spindle is already running at the right speed from the first operation. However typically it also does not hurt.

3. Mine is rounding feeds to full numbers as Jacotheron is rounding to one decimal (F333 vs F333.3). Irrelevant...

4. At the end of the program:
   Jacotheron :
   ;
   G28 Z
   G0 X0 Y0
   M5
   ;%

Mine:
M5

I don't understand why G28 Z and G0 X0 X0 should be called here. Adding a G0 X10 X10 (i.e. moving to the tool-change position) would make sense as the tool-change position typically moves the head to a safe place.

Looking at the post-code there are not too many differences as well. So merging the two posts together should not be to hard. I already have mine on github and would be open to do so...

Best regards,

Marc

Thanks, now it is building again!

My findings during the build process for the Duet Wifi were:

1. Getting the right branches (and matching versions):

CoreNG: master
FreeRTOS: master
RRFLibraries: master
DuetWiFiSocketServer: dev
RepRapFirmware: v2-dev

additionally I needed (not mentioned in the howto):
CoreESP8266: dev

2. For the DuetWifiSocketServer and the CoreESP8266 I needed the xtensa-lx106-elf-gcc cross-compiler. I found in a project file that you used one that came with an Arduino package. So I also installed the Arduino Package ESP8266 which provided the corresponding compiler and set the paths correspondingly.

3. I needed to manually add some paths when files could not be found.

Maybe this info is useful for someone trying to do the same.

Hello,

I'm using a duet wifi for controlling my cnc router which works fine so far. However I'm experiencing some problems when using WCS (working coordinate systems).

I move my head to a certain position i.e.
G1 X305 Y965 Z70 F12000
The position I see in the web-interface is accordingly X=305, Y=965, Z=70
Then I want to set my WKS to be zero at that point. Therefore I tried the following two commands
G10 L2 P1 X305 Y965 Z70
and
G10 L20 P1 X0 Y0 Z0
which both result in a position X=0, Y=0, Z=70. I would expect Z to be 0 as well.
Now I issue the following command
G1 Z0
The machine does not move but the position display goes to Z=0 and the machine works as expected.
If I don't issue this G1 Z0 my Z-axis is either offset or I get directly and out-of-limits error when issuing any G0/G1 commands result (I don't understand yet when which of these two scenarios happens).

Further if I'm going from WCS1 two WCS2 by issuing G55 I get the position diplay X=305 Y=965 Z=70 as expected and everything is working fine. However when I go back wo WCS 1 (G54) then I get again the strange behavior from above having the position display showing X=0, Y=0, Z=70 with the same consequences as described above.

For me this looks like an issue about how WCS are set for Z-values not equal to 0. However I might as well miss some of the concepts how WCS should work. I'm happy for any support.

Best regards,

Marc

PS:
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.0(RTOS) (2018-06-05b3)
WiFi Server Version: 1.21
Web Interface Version: 1.21.1

@dc42 Thank you very much for the modifications! I've just tested them and they work perfectly for me

Thank you, that is good to know. Therefore it makes sense for posts not to issue G2/G3 as they do not provide a performance increase over G1.
For me there is no need to configure this segment length as I have much more options in the CAM software to modify the linearization. Anyway for me the segment length is not a suitable parameter in this context. More meaningful would be a segmentation based on tolerance value i.e. one would specify the maximum deviation from the circle allowable and by that the segmentation would be determined individually for each G2/G3.
But anyway I'm not sure how important G2/G3 still are with today's compute power in controls. I think it might be a better investment to make sure that global movements are still smooth despite huge amounts of linear commands (invest into some lower level smoothing on the controller level) as for more complex shapes (already circles not along the main axis) we are anyway down to linear segments.
However speaking of this the DuetWifi I'm using is performing very good for me so far

@dc42: Yes you are right as I already outlined in my second post. I originally started off RepRap Firmware configurator and it gave me G92 which I stayed with... However now I removed it.
However the G92 behavior is nevertheless faulty as after using it the machine limits are not correct anymore.

@droftarts Thank you very much for your feedback. I'm looking at quadrature linear encoders that should be easy to connect to the 1HCL quadrature input. However I still have two questions:

1. Why is a rotary encoder needed as well?
2. There is only 1 quadrature input on the 1HCL. Does this mean the rotary encoder needs to be a magnetic encoder to be connect over the SPI encoder input?

Regards,

Marc

Hello,

I'm currently considering adding linear magnetic scales to a large CNC router with stepper motors and currently running with a Duet2Wifi board. There are two reasons for this modification:

1. Avoiding issues step losses (not happening often but currently holding me back using more aggressive feed rates).
2. Absolute precision: While the repeatability (relative precision) is already satisfying 0.01-0.02mm I'm sometimes struggling with the absolute precision i.e. what is the precision of two features machined like 2m apart. Here I can achieve <0.2mm which is satisfying to me. However the calibration process (some axis rack & pinion, some tooth belt) is quite annoying and it basically has to be re-checked every time I need that precision.

So I was considering replacing the current Duet2 board with a Duet3 plus 1HCL expansion boards. However so far I have only seen rotary encoders used with the 1HCL. Is the use of linear encoders also supported by the software?

Regards,
Marc

Thank you for the clarification. I think generally it is hard to define which should be modal and which not for all cases. What about an additional g-code that limits all modal commands on a line to the scope of a macro.
Or even more advanced mechanisms where the user can start and stop a new scope similar to C/C++ (e.g. Gxx.1 starting and Gxx.2 stopping a scope and even a Gyy in front of a modal command to render it global)?

Hello,

is there somewhere an overview which modal commands like e.g. G54, G90, G91... are limited in their effect to the macro scope and which are global?
Currently when testing 2.03RC1 it caught me by surprise that G54, G55.... are not restricted to the macro scope. I thought this was the case with 2.02 but I might be wrong...

Regards,
Marc

1. I switch on the machine
2. Home all Axis
3. G10 L2 P1 -> Origin of workplace 1: X100.00 Y100.00 Z38.50 U0.00 V0.00 (from config-override.g)
4. G10 P1 -> Tool 1 offsets: X0.00 Y 0.00 Z12.15 U0.00 V0.00 active/standby temperature(s): 0.0/0.0 (from config-override.g)
5. G0 X0 Y0 move to the probing point
6. I probe z-level using G30
7. I issue G0 Z0 to check if the tool moves to the probed level -> everything good (note the new probed level is different from the initial one)
8. I issue again G10 L2 P1 -> Origin of workplace 1: X100.00 Y100.00 Z38.50 U0.00 V0.00. This result does not make sense to me. I would expect the Z-coordinate to be different according to the new probed level.
   7 . I move to probe away to maximum Z-level using G53 G0 Z140 -> crash into the mechanical top level endstop
9. After the crash the z-value displayed is Z113.65 which happens to be the maximum value possible with the initial calibration (113.65 = 140 -38.5+12.15)

No, the Z max value set with M208 is 140. So I basically want to send the head all up.
I run all this in G54 which before running G30 was in a state that 113.65 in G54 would have corresponded to 140 in G53 (machine coordinates).

Yes, I built it myself from GitHub. Saw the tag and was not aware that it is not officially out yet.

Hello,

I just tested 2.03RC1 for my CNC router and run into the following issue using a simple switch for z-probing.

1. I calibrate my probe using G30 S-3 and then save the calibration using M500 P31
2. I probe z-level using G30 (so far everything good as expected)
3. I move to probe away to maximum Z-level using G53 G0 Z140. This results in a crash at the z-max level.
4. After the crash the z-value displayed is Z113.65 which happens to be the maximum value possible with the old calibration.

I'm not sure what is the reason for this behavior.

Regards,
Marc

@Guffy : nice work, thanks for sharing. Looks very clean, better than the Mach3 template I worked off from. I will eventually try to change to your PP....

@dc42 ...did you have a chance to look at the icon issue?