I don't know if this is an issue that is present only on my system or does RepRapFirmware struggles with curves in general. To make an analogy, think about a gas engine that runs smoothly, but it misfires once in a while, but only on curves and circles. I made a g-code test file, with a circle as big as my bed, and no infill, one external layer, no extrusion. Speed was about 80mm/s. I was expecting to get smooth movement, but it behaves like the analogy I made. Surface quality does not seem to be affected, it's just really annoying when hearing the printer running.
My Duet is configured for standard Cartesian style.

Regards

If you are running a version of RepRapFirmware earlier than 1.15c, a firmware update may solve this for you.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I am running on 1.15c, that's the thing... Is it only my controller behaving like this, or is it a general issue?

Would you like to share your test file? Is it based on a .stl file? How smooth is the surface of the .stl part?

What kind of steppers do you use? I like the silence and smoothness of my 0.9° steppers with 128 microsteps from my RADDS.
The loudest parts now are the rattling Traxxas joints

Edited 1 time(s). Last edit at 10/03/2016 06:29AM by o_lampe.

Quote
unromeo21
I am running on 1.15c, that's the thing... Is it only my controller behaving like this, or is it a general issue?

Two suggestions:

1. If you are printing over USB then you may be getting data starvation. Preferably print from SD card instead, or at the very least configure your host program to use driver-level flow control instead of waiting for "OK" after sending each GCode command.

2. If you are already printing from SD card, then if the resolution of your curve is low the instantaneous speed change in the X and/or Y direction at the intersection of the line segments in your curve may exceed the maximum jerk setting. This causes the speed to be reduced at the intersection so as to honour the jerk limits. Increasing X and Y jerk settings may help (M566 command).

Quote
o_lampe
I like the silence and smoothness of my 0.9° steppers with 128 microsteps from my RADDS.

I wonder how that compares with my 0.9° steppers and 256 microsteps from my Duet WiFi?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
o_lampe
I like the silence and smoothness of my 0.9° steppers with 128 microsteps from my RADDS.

I wonder how that compares with my 0.9° steppers and 256 microsteps from my Duet WiFi?

Returning to the first post subject: I wonder how smooth your Duet WiFi with your 0.9° steppers and 256 microsteps at reasonably high speeds

Edited 2 time(s). Last edit at 10/03/2016 03:02PM by roboprint.

So you are suggesting that this is specific to my system only ?

No, I am not printing from USB, never did.

The resolution of the circle is high, I created the file for this purpose, to test the movement. Don't worry, I did not created it in Sketchup with 30 something faces. It was created in Autodesk Inventor. Here is the G-code file > [www.dropbox.com]

These jitters / missfires happen on random places on the circle, and only a couple of times per circle, around 10-15 times. I also made a video, I just have to upload it..

Quote
roboprint
Returning to the first post subject: I wonder how smooth your Duet WiFi with your 0.9° steppers and 256 microsteps at reasonably high speeds

At 400mm/sec it's still smooth. This is using 16x firmware microstepping and the 16x interpolation supported by the drivers to provide 256x microstepping. But at high speeds, movement tends to be smooth even with low microstepping, because the motors can't react to individual microsteps.

One of the firmware work items is to implement dynamically-variable microstepping so that we can use true 256x microstepping at low and medium speeds and reduce it at very high speeds. But the interpolation works so well that I don't think it will gain much, so I've moved this down the priority list.

Quote
unromeo21
The resolution of the circle is high, I created the file for this purpose, to test the movement. Don't worry, I did not created it in Sketchup with 30 something faces. It was created in Autodesk Inventor. Here is the G-code file > [www.dropbox.com]

These jitters / missfires happen on random places on the circle, and only a couple of times per circle, around 10-15 times. I also made a video, I just have to upload it..

Sadly I don't have a printer large enough to print that gcode file. Please can you:

1. After printing that file, run M122 and report the two underrun counts in the Move section of the output.

2. Generate a similar circle of diameter 190mm of less centred on (100, 100) for my Cartesian printer, and/or a circle of diameter 270mm or less centred at (0,0) for my delta. Then verify that you see the same issue when printing those files.

Edited 1 time(s). Last edit at 10/04/2016 04:24AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

So, I have "printed" that file again, I get the following in the M122 at the Move section :
Move Diagnostics:
MaxReps: 4, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 4
Before this I made some more tests, do I have to reset the controller before doing the print ?

Now, I also ran the circle.g file that is present in the SD card firmware image, it behaves the same. I don't know the diameter of that one.
Here is a video I made, the phone is almost resting on the Y stepper is it can better pick up the noise. Please note that when the steppers are doing this sound like I was describing, they also slow down the movement and than get back to speed, so the movement is also jerky because of this.

I also made a smaller circle, like you said, 190mm diameter, same story. [www.dropbox.com]

Edited 1 time(s). Last edit at 10/04/2016 04:34PM by unromeo21.

David, would you please chime on this issue ? Is it something known to you, or is it something that only my board is experiencing? I bought the Duet for it's advantages, but if it's struggling to make round moves on a simple cartesian, where an 8 bit board like ramps has no issue, than I'm a little bit disappointed...

It's not something known to me. I have to catch up with paid work before I can look at it again. Hopefully at the weekend.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I tried your file on my Ormerod running firmware 1.15e on a Duet 0.8.5. It moves very smoothly even if I turn it up to double speed. On alternate circuits there is a Z movement or a slight hesitation, always at the same point in the circle. The hesitation is where it switches from the outer to the inner perimeter.

Edited 1 time(s). Last edit at 10/10/2016 11:00AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I tried your file on my Ormerod running firmware 1.15e on a Duet 0.8.5. It moves very smoothly even if I turn it up to double speed. On alternate circuits there is a Z movement or a slight hesitation, always at the same point in the circle. The hesitation is where it switches from the outer to the inner perimeter.

It's good to know that your duet doesn't have the issues that I have. And I am not talking about that hesitation from switching perimeters. If you watched the youtube video with sound, you will notice the strange jerks that the steppers are making around the perimeter of the circle. Can you please help me diagnose this and see what's wrong with my controller ? I have no issues with the linear rails, no binding, everything is moving freely. These issues are only on circles and round surfaces, there are no strange stepper noises and jerks on straight lines.

Thank you

Seems like you are just ignoring me David.... Have I offended you with something ?

Edited 1 time(s). Last edit at 10/12/2016 04:00PM by unromeo21.

@unromeo21 - have you resolved this issue? Seems like you are not alone: [www.duet3d.com]

unromeo21, can you do another video using firmware 1.15e, using the smaller circles that you generated for me? Also verify using the web interface or M115 that you are definitely running 1.15e.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Sure, will do it as soon as I get back from my business trip, in a week or so.

Meanwhile, I can confirm the firmware version :

6:43:11 PMM115
FIRMWARE_NAME: RepRapFirmware for Duet FIRMWARE_VERSION: 1.15e ELECTRONICS: Duet 0.85 DATE: 2016-10-02

And also, I don't know if this helps, but I get the same issues with the integrated test circle.g file that is delivered with the SD image.

Regards,

Is there any chance that the browser displaying the web interface is constantly reloading the page? I can't think why it would, but if it did then that would cause pauses. Maybe you should try kicking off the print and then disconnecting the Ethernet cable, to see if the pauses stop happening.

Edited 1 time(s). Last edit at 10/16/2016 06:10PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Tried to make a new video yesterday, but to my surprise, it didn't exhibited the jerks around the circle any more. I tried with small one, larger one, the integrated circle.g file.
So it seems that this behavior is not permanent, and it might be related to other factors. Setup was the same, web interface was active during the print. Also, there were no changes made to the config.g file.

I will try some different scenarios and see if there is something specific that triggers this strange jerks.