Delta Segments per Second

So I've been experimenting and trying to build my own delta for a few months now. And I needed some help with Marlin. I've reduced the Delta Segments per Second to 120 from the default 200, and it prints fine and I have no issues with the Delta stuttering, but the downside is that the printer is now printing much faster than what it was printing with 200 segments. Is this something that is normal from Marlin?

I previously had a smoothie based board and irrespective of the delta segments on smoothie the speed of the effector remained constant. I gave up using smoothie because of the horrible windows driver support and its continuous problem of locking up. I am also aware that duetwifi is a really amazing board, but I'm trying to make a relatively low cost printer and frankly the duetwifi is too expensive to fit into the budget.

Its a neat printer apart from this speed complication.

You can define max. speed and acceleration with Marlin without changing the firmware. Just add M201 and M203 lines in the slicer startcode.
Only yerk setting needs to be addressed in firmware.

Sure, the problem the speed settings I was using with smoothie have to be halved when changing to Marlin with 120 segments, or else the printer is just all over the place and my extruder cant keep up. Is this normal?

IDK, I don't use Marlin for Deltas anymore. Also I'm no expert with smoothie. Maybe they set the speed in mm/min and Marlin needs mm/s?

Why on earth are you running 8-bit Marlin on a Delta? If you're having issues with smoothieware locking up with a Windows host, just stick a OctoPi host in the loop instead, or were you using one of the MKSBASE variants? Also, since when is more speed a downside?

This thread reminds me of the time in late 2014 when I first started planning how to add delta printer support to RepRapFirmware. In looking at how other firmwares supported delta printers, I was disappointed to see that all of them used the segmentation kludge to approximate linear XYZ movement. It was - and still is - my opinion that no end-user should be expected to play around with the segments/second value. That's why I calculated a closed-form solution to the movement of the carriages of a delta printer for linear movement in normal space, and implemented it in RRF. So it's one less parameter that users of RRF need to worry about. I was able to do this because RRF targets 32-bit processors exclusively, not 8-bit processors like the atmega2560 which are obsolete for this type of application in both cost and engineering terms.

To be fair to Marlin, although its support for delta printers was dire a year ago, it seems to have improved in more recent releases. But fundamentally, 8-bit processors don't have the computing power to run delta printers at high speeds. You have the choice of low print speeds, or a low segments/sec setting that may cause visible artefacts at high print speeds.

Edited 2 time(s). Last edit at 01/30/2018 02:43PM 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].

Delta segmentation is not a big issue (at least if you do not use LCD). I run my printer at 120 mm/s printing speed and 250 mm/s non-printing moves often and never found artifacts I could attribute to delta segmentation. Here are examples of delta segmentation error at 120 mm/s and segments per second equal 80.
marlin:

repetier:

If you already have 8-bit electronics then there is not much reason to replace with 32-bit one. If you are buying a new electronics then definitely get a 32-bit one.
If you want to run you printer quickly you definitely will have much bigger issue with belt and smooth rod flexibility than with segments per second. If you run your printer slowly and see artifacts you want to attribute to segmentation then it is a good chance the the problem is stepper driver decay mode instead.

That being said it is great to eliminate delta segmentation errors. It is just not really needed. There are other much bigger problems at high speeds; and therefore with high accelerations because increasing speed without increasing acceleration does not make much sense. And at low speeds segments per second can be really low.

So my problem is with 120-130 segments it prints fine without any issue of stuttering, but with lower segments the apparent speed of the print is increased drastically. I was using the cheap MKS board with smoothieware and the it printed fine with 60mm speeds and 120mm travel speeds. Shifting to the 8 bit board with 120 segments with the same print profile makes it impossible for the extruder to keep up and the hotend to spit out enough plastic, and 200 prints at roughly the same speed as smoothie (smoothie was setup with 200 segments as well).


I also get that 32-bit boards are the future, but frankly, my idea is for a low cost assembled printer to be sold locally and a top notch board like the duetwifi or the azteeg x5 mini will just make the printer way more expensive than what I can sell it for here in India. The cost trade off is pretty large when you add on import duty and shipping to India.

Also for what its worth, the mks board works fine with my laptop running Ubuntu 0 issues but with windows its like it has a mind of its own, with continuous lock ups etc.

Just lower segments per second to some value in the range 80 - 100.

LCD can be a hog of MCU power too. If you have LCD and printer shutters sometimes then try to lower LCD refresh rate. Or try to disable it temporarily to see whether it causes problems.

How quickly an extruder can feed plastic is unrelated to segments per second setting. That is a feature of your extruder and its stepper driver only.

I switched to Marlin 1.1.7 and it seems to be perfect and as expected, I realized I had some no-name Chinese nema 17 motors which were also the source of the stuttering, my old Ultimaker motors were smooth. New motors are in the post and should be here soon.

This reminds me of the time when I had really bad stutter problems with Marlin on an 8-bit board. The vase mode I was printing turned into an interesting piece of art that would be difficult to reproduce. In the end, the solutions were to either reduce the segments per second, or just don't print through USB. Printing via SD card was fine so I've been going that route since then.

The 8-bit boards are getting pushed to the limit with so many expectations. If you really want to run Marlin, you can do that on a 32-bit board now and see if all these problems go away.

I guess changing the motors to a low inductance motor helped. I have been using them with TMC2100 and I guess they disagreed with the no name Chinese motors. Mine prints fine with LCD and segments as high as 160 anything higher it starts to stutter, I'm sure using no LCD I could bump it up further, but I'm happy with the result. Attaching a photo of something I printed yesterday.

Cheers guys.

Yeah I'm not sure segments per second will affect printer speed. 8bit marlin can work with deltas as long as you want modest speed. My microdelta uses Rich Cattels marlin from 3 years ago and works fine (and quietly) at 1/32 microstepping on lv8729 drivers with 1.8 deg motors. It only has a 90mm bed.

My XL runs duetwifi and happily moves at 400mm/s using 1/16th and 0.9deg motors. This would not be possible with 8 bit boards. It will print at 180mm/s but then the extruder struggles. RRF can now do non linear extrusion which I have not tried yet but it should be capable of maintaining correct extrusion a little beyond those speeds.

Edited 2 time(s). Last edit at 02/04/2018 09:37AM by DjDemonD.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Ah well, somehow my DIY delta with lower acceleration settings and same speed settings ends up completing prints 1/4 faster than my ultimaker . Other than the obvious printer style difference, the profiles are identical. Something that takes 1 hour on my ultimaker with 60mm print speeds and 100mm travel gets completed in 40 on the delta, even though the delta is configured with 1000mm of acceleration moves while the ultimaker is at 3000. My guess is arm length plays a factor. On a carteisan print head moves 100 mm on either axis to move a 100 mm in actual. In a delta its a mix of different arms and possibly neither moves the entire 100, hence its quicker. I maybe wrong. I changed to 32 bit ustepping for the extruder and 16 for the arms and yes it stutters very very little during infill which is at 60mm but with the outer shell speed is down to 40 there are virtually no visible trace of stuttering, prints come out clean.