Duet3D is useless as a CNC Controller!

[T3P3Tony]

@Atair thanks for your feedback, please allow us to make some configuration suggestons that might help.

Firstly you do not mention which version of RRF you have tried however it is being successfully used by many people in a CNC environment so I expect your experience is at least partly down to configuration. That said we have taken on board a lot of feedback from people using RRF to control CNC machines and have implemented their requests. That is how things like the various workspace co-ordinate systems etc got added.

Too [position reporting can be greatly improved if you enable segmentation:
https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m669-set-kinematics-type-and-kinematics-parameters

This also improves the pause speed and the response to feedrate override (what you call change speed).

If there are issues with G2/G3 in the latest firmware that we are not tracking in a github issue please let me know. (the only one i am aware of is for arcs where 0.1mm segments are too large)

If you have a CAM software that's outputting non standard gcode that there is a good argument to support please provide more details. AFAIK we conform to the NIST standard & then support more than that.

We would be open with discussing CNC specific improvements to the gcode viewer and I know @Sindarius added a feature to render all G1 moves already which might be what you are looking for.

In summary we did make substantial changes thus far and have 1 significant one we are aware of remaining which is Feed Hold.

It would be good if you could test the latest firmware/ DWC/gcode viewer.

[dc42]

@Atair I think this wins the prize for the most hostile first post from a user that I have ever seen. You have made no attempt to engage with us to see if the assertions you have made are actually true.

In fact:

The main problem is: IT IS NOT REALTIME AT ALL!
You dont know where the tool is at any given point in time. The tool position shows some buffer value - it might be there at some point in the future..

In the 3.5.0 beta and release candidate firmware the machine position is updated in near real time (every 250ms).

It can neither be stopped or change speed until the buffer is empty. In CNC Work, with often many long linear moves + circular moves, this might as well be at the end of the program.

That is incorrect. Motion can be paused without the buffer being empty provided that a suitable boundary between moves can be found (which is almost always the case when executing non-travel moves on a CNC machine). If you enable segmentation then motion can also be paused within a move.

It does not understand, or worse misinterprets common commands like ARCS. There are a few topics in the forum about that.

The only outstanding issue we have logged concerning how G2/G3 commands are processed is that RRF does not reject G2 or G3 commands in which the distance between the end coordinates and the arc centre does not match the distance between the initial point and the arc centre. Is that what you are referring to? This is scheduled to be corrected in RRF 3.5.1. Of course it doesn't affect valid G2/G3 commands.

It fails at simplest commands when they are a bit differently formated. E.g. G1 Z-1.0000

RRF processes that command correctly, provided that your minimum Z limit is set to -1 or lower. Perhaps you haven't set the minimum Z, in which case you will be using the default, which is zero.

The Gcode Preview never worked, as it expects Extrusions!

If that's the case then I'm sure we can fix it. We welcome constructive feedback.

[Atair]

@dc42 @T3P3Tony
Thanks for the fast feedback! I guess i have to dig deeper into the parameters to make this controller useable for CNC.

To my hostile first post - i just spend 3 hours failing at cutting a rectangle with rounded corners out of a piece of plywood - and gave up for today. I have hundreds of hours machine time and 15 years of experience - from semi-industrial machines to tiny GRBL controllers - and lets just say - the out of the box experience with duet3d is not ideal. The tone of my post reflects that.

As for the GCode - i went with the default-ish Mach3 postprocessor (using RhinoCam / VisualMill), and there the arcs got messed up (the two 'lower' ones - out of 4 total).

[chimaeragh]

@Atair said in Duet3D is useless as a CNC Controller!:

s for the GCode - i went with the default-ish Mach3 postprocessor (using RhinoCam / VisualMill), and there the arcs got messed up (the two 'lower' ones - out of 4 total).

I think this may be the cause of the issues you are having. A Mach3 postprocessor will not produce g-code that works well with RepRap firmware.

[Atair]

and one additional suggestion - why no option to parse the code? check for soft limits etc. I can only upload it and then run it - any syntax or user errors show only when i am already cutting.. As the preview in my - 1-2 year old version - cant give me any indication of problems..

So even with an update to the latest firmware etc. - i think an option for a sanity check would be in order - which in turn would need a separate method besides run. 'Parse File' maybe?

[T3P3Tony]

@Atair there is the option to simulate a job.

[Atair]

@T3P3Tony Thanks, found all i need after a firmware update (3.5.0 RC). The GCode viewer is a bit erratic, but it works.
What are good value ranges for the M669 Snnn Segments per second? I have it at 10 for now, it works, but still a little laggy.

[jay_s_uk]

@Atair a value of 1 for S and T is fine

[Sindarius]

@Atair Sorry I am late to this, been a bit under the weather the past few days. When visualizing g-code for CNC Routers etc. I recommend setting the following settings.

Force line rendering (Make sure quality is not set to max)

Render G1 - Early on I ran into some cases where slicers were use G1 for everything including travels for 3d printers. I added this flag to help address G0/G1. Though I think with Fusion 360's changes they force all moves to G1 on their hobbyist versions so depending on what you use to generate g-code there could still be render issues.

With those settings you should have a better view of the toolpathing. Here is a sample of some drag knife tool pathing

[dc42]

@Atair said in Duet3D is useless as a CNC Controller!:

What are good value ranges for the M669 Snnn Segments per second? I have it at 10 for now, it works, but still a little laggy.

What is it that you find laggy: the response to a pause command, or something else?

At low speeds the T parameter (minimum segment length) matters too. In your example with S=10 and assuming the default T=0.2mm, if the speed is 2mm/sec or greater then the S parameter will define the segment time (0.1sec); but if the speed is lower than 2mm/sec then the T parameter will define the segment length. For example, at 1mm/sec the segments will be 0.2mm long and will take 0.2sec each. If you want to maintain 0.1sec response time to a pause command then you would need to reduce T to 0.1mm.

[Atair]

@dc42 i see, both parameters are relevant, my question was more in the direction of performance limits. (I am mostly interested in live feed rate adjustments)

Now with S10 it works, although i had two instances of gcode lines being interpreted wrong. I could not reproduce it, but both times it happend, the tooldhead was under load.

It was not lost steps, but the head moving to a totally wrong position.. Could be of course something different, but could also be data corruption.
Edit: and both times it was on the last segment of the gcode.. maybe there is something after all.. If i find out more i will post it.

[Atair]

@dc42 ok i just ran another job.. and this time it did not fail, but also did not finish. main3.gcode
it just does not do the last line - a simple z axis move, and instead just stays there. i have to manually cancel it, and then reboot the controller.

I assume it is because of the S10? or some other thing with the current RC version?
using Duet Web Control 3.5.0-rc.1
thanks

[Atair]

@dc42 ran the same code a second time, this time on the start of the last segment:
Line 423: G1 X263.075 Y-0.997 Z-7.000 F300.0
it never started this line, instead went diagonally towards zero i guess.. so happend 3x in a row - i was lucky that it is plywood and it did not break anything important, but there seems to be a real problem with this latest RC..
It never reached the last line, Line 424: G1 X263.075 Y-0.997 Z10.000 F1200.0, (the Z-Lift)

I also have a second job, here: 4Holes.gcode It runs before the main cut, and never has any problems. I guess the lines are too short to have any effect with the segmentation.

Here my config.g in case that helps (there is also the M669 S10 command)
config.g