Impressions: Duet vs. Smoothie

WZ9V
Printmaster!
Posts: 65
Joined: Sat Jan 25, 2014 8:49 pm

Re: Impressions: Duet vs. Smoothie

Post by WZ9V »

Any idea what the changes are? I just got a PanelDue controller last week, hate to think it's going obsolete so soon.
3D-Print
Printmaster!
Posts: 519
Joined: Mon Jan 05, 2015 9:39 pm
Location: Omaha, Nebraska

Re: Impressions: Duet vs. Smoothie

Post by 3D-Print »

WZ9V wrote:Any idea what the changes are? I just got a PanelDue controller last week, hate to think it's going obsolete so soon.
No idea, I sent an email inquire about availability and all that was mentioned was they were not available until Jan. I will ask.
My 3D-Printing learning curve is asymptotic to a Delta's X, Y and Z-axes
User avatar
Eaglezsoar
ULTIMATE 3D JEDI
Posts: 7185
Joined: Sun Apr 01, 2012 5:26 pm

Re: Impressions: Duet vs. Smoothie

Post by Eaglezsoar »

WZ9V wrote:Any idea what the changes are? I just got a PanelDue controller last week, hate to think it's going obsolete so soon.
It was my understanding that they are modifying the Duet board itself, the Paneldue should not become obsolete at all. I was told the present
Paneldue will work with the newest revision of the Duet once it is released.
“ Do Not Regret Growing Older. It is a Privilege Denied to Many. ”
User avatar
626Pilot
ULTIMATE 3D JEDI
Posts: 1720
Joined: Tue May 14, 2013 12:52 pm

Re: Impressions: Duet vs. Smoothie

Post by 626Pilot »

AFAIK, this is the bed.g I used: https://github.com/dc42/RepRapFirmware/ ... ssel/bed.g" onclick="window.open(this.href);return false;
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Impressions: Duet vs. Smoothie

Post by dc42 »

Things have moved-on a little in the Duet world since the start of this thread, so I'd like to point out what's changed:

- Updating the configuration file: it's always been possible to edit a copy of config.g held on your PC and then upload it and restart the Duet via the web interface, but now there is an even easier way. You can edit the config.g file held on the SD card directly in the web interface.

- You can now upload and install new firmware through the web interface too.

- The use of a bed.g file to configure delta auto calibration has been criticised because it needs to be created. However, it does have one major advantage. You can specify corrections to the trigger height at each probe point. This is useful both for head-mounted probes (to account for small amounts of varying effector tilt with XY position), and with FSRs (to account for the fact that the sensitivity of FSRs supporting the bed varies depending on how close you probe to one of them). I provide a web page to generate the bed.g file.

- Just as a new Smoothieboard is under development, so is a new Duet. The existing PanelDue will continue to work with the forthcoming Duet (and with any other board that provides the necessary gcode support - I hope Smoothieware will soon). The PanelDue redesign late last year was a minor one, to support 7" displays without modification and to make the board a little narrower.

- The build environment for RepRapFirmware has been simplified. My fork now uses a much simpler Eclipse configuration, with the latest version of Eclipse and no need for the Arduino plugin. Chrishamm's and Dan Newman's forks can be built using just a makefile.

- I accept that RepRapFirmware is structured less well than I would like, and less well than Smoothieware. I am gradually improving the structure. More significant IMO is that Smoothieware makes heavy use of dynamically-allocated memory. It is very hard to write reliable real-time systems using dynamically-allocated memory, which is why dynamic memory is banned in the safety-critical software environment that I come from. See http://eschertech.com/articles/items/art100730.html for why. One of the coding rules for RepRapFirnware is (and always was, even before I got involved): no dynamic memory allocation after the initialization phase. This makes the coding a little harder, but the behaviour and the memory usage much more predictable. It also reduces worst-case memory usage. To be fair, the rule is broken in one place at present, when a new tool is created.

I believe that competition is good for the industry, so I am glad that the Duet/RepRapFirmware has Smoothieboard/Smoothieware as a worthy competitor.
User avatar
mhackney
ULTIMATE 3D JEDI
Posts: 5412
Joined: Mon Mar 26, 2012 4:15 pm
Location: MA, USA
Contact:

Re: Impressions: Duet vs. Smoothie

Post by mhackney »

Hey, welcome to the forum David! Great to have you here.

Cheers,
Michael

Sublime Layers - my blog on Musings and Experiments in 3D Printing Technology and Art

Start Here:
A Strategy for Successful (and Great) Prints

Strategies for Resolving Print Artifacts

The Eclectic Angler
User avatar
626Pilot
ULTIMATE 3D JEDI
Posts: 1720
Joined: Tue May 14, 2013 12:52 pm

Re: Impressions: Duet vs. Smoothie

Post by 626Pilot »

dc42 wrote:- Just as a new Smoothieboard is under development, so is a new Duet. The existing PanelDue will continue to work with the forthcoming Duet (and with any other board that provides the necessary gcode support - I hope Smoothieware will soon).
There's code that does this on GitHub, but it's in a "feature" or whatever and I have no idea how to work with that, so I haven't tested it with my own branch. My impression is that the PanelDue code will make it into Smoothie edge sometime this year.

I do plan to bring that code in once it's a part of the main Smoothie branch, and I do have a PanelDue to test it with. However, I've switched to using OctoPrint on a Raspberry Pi instead. With both Smoothie and Duet, I was never able to upload files faster than about 20KB/sec, which I have lost all patience for. I think this is because both the Duet and Smoothieboard use crappy, slow peripherals to write to the card. The same SD card that does 20K/sec on either of those boards will gobble up the same 20MB file in a second or less on a real computer, so I don't buy the "different SD cards have better quality" argument. With OctoPrint, the file uploads are functionally instantaneous. I could throw a 100MB G-code file at that thing, and it would be done in a few seconds.

dc42, if you have a line to whoever does the hardware on the Duet, tell them their next board version NEEDS to use a microcontroller with SDIO, especially if they want to compete with the Smoothieboard 2 - which will definitely have that feature. The PanelDue is nice - REALLY nice - but for about the same money, I can have a Raspberry Pi 3 with a touchscreen. While sometimes more difficult to set up, once it is set up, the interface is just as nice, and the upload speed is perfect. If I have to choose between zero setup with slow uploads, and difficult setup with instant uploads, I will choose the latter every time because I only have to set it up once, and I won't miss the time spent on that once it's in production. The time spent waiting for slow uploads irritated me every day.

In a perfect world, I could upload G-code to the 3D printer controller as fast as I could to a Pi, and use a PanelDue, and not have to deal with setting up Raspbian and doing all the touchscreen setup (which is anywhere from very easy to very difficult, depending on which Pi and display you use). When the Smoothieboard 2 drops later this year, that will be possible. If the Duet is to remain competitive, it needs to not annoy the hell out of its users with 1990-era upload speeds!!!
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Impressions: Duet vs. Smoothie

Post by dc42 »

626pilot, if you are only getting 20Kbytes/sec web upload speed to the Duet then something is very wrong. Most people get around 200kbytes/sec and some get 400kbytes/sec. The Duet uses a 42MHz 4-bit wide interface to the SD Card (the same as SDIO) driven with DMA, unlike all other open source boards. We have proved conclusively that the bottleneck is how fast the SD card will accept new data, umess you are using an unreliable WiFi connection. The SD card does make a huge difference. However, the headline speeds.you see for SD cards are for writing a few Mbtyes of data in a single block, and we don't have that sort of memory available on an embedded processor to use as a buffer (neither will the SmoothIeboard 2, I suspect).

The upload speed you get to RPI is almost certainly the speed of uploading the file into the write cache. You will probably find it is much longer before you can safely remove the card - and that amount of time will depend very much on the card.

We will have more memory on the Duet NG so we do expect to achieve a modest improvement in upload time. But in the absence of having megabytes of write cache available, it will still be dependent on the SD card. I also expect to improve the upload speed to the current Duet a little, and I hope those changes will reduce the variability between SD cards too.
User avatar
626Pilot
ULTIMATE 3D JEDI
Posts: 1720
Joined: Tue May 14, 2013 12:52 pm

Re: Impressions: Duet vs. Smoothie

Post by 626Pilot »

I connected to my Smoothie and Duet controllers with Cat-5 Ethernet. (Which was replaced with a new one, and plugged into a different port on my switch - still 20KB/sec.) There was no noticeable latency pulling up the web interface on either.

When writing a big G-code file from my computer, using a $15 flash drive, the sync operation would complete in a couple of seconds. That means I hit Save, KISSlicer spits out a ~20MB file to the SD card, I type 'sync' in a terminal window, that command completes in a second or two, and I can safely eject the card immediately after. My computer definitely wasn't writing to that flash drive at 20KB/sec. If it had been, the sync command would've taken just as long to finish as if I was uploading it directly to the board.

The only thing I can think of is that it initially wrote out at close to 200KB/sec, but then it slowed down to a crawl after a few files had been uploaded. It never recovered after that. I checked the filesystem to make sure there was no corruption. It may be that the FS implementation is choking because it has to split the clusters between different locations, rather than writing them in a straight line as it would on a brand new SD card. Maybe it's rewriting the entire FAT every single time it does this? I haven't looked into the FS code at all, but my guess is that difference in performance isn't a coincidence. It could also be that it's running at a conservatively slow speed in order to make success more likely on a wider range of SD cards. If I recall correctly, Smoothie does this. Finally, the "headline speeds" you mention from writing a huge block at once - maybe the latency is because the SD card takes longer to answer instructions to change the base address it's writing data to. I don't know how all that works.

The Raspberry Pi Zero costs $5, or is supposed to anyway (in practice the vendors jack up the price by making you buy a bunch of nonsense with it), and it has 512MB RAM. I'm certain you can find a cheap ARM controller with enough memory. If you can't, an external memory chip would be a good idea. This is definitely the place to spend money. Even if you can upload at 200KB/sec, it would still take a minute to upload a big file. Realistically, I can't see quibbling over an additional few dollars on the MCU, on a board that already costs $140.

Another nice thing about the Raspberry Pi solution: You can upload another file while a print is in progress, and because writing the SD card doesn't overtax the CPU or bus, it won't make the print stutter. If the next Duet can do the same thing, it would be helpful.
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Impressions: Duet vs. Smoothie

Post by dc42 »

For info, I have just released version 1.12 of my fork or RepRapFirmware, which has further improvements to the SD write code. I was previously getting around 450Kbytes/sec from my best-performing SD card. Now I get this:

[img]https://dl.dropboxusercontent.com/u/193 ... dSpeed.png[/img]

Measured on a Duet 0.8.5 with a Chrome/Windows 10 client and wired Ethernet throughout. Your mileage may vary - as I said before, the way SD cards behave when you write relatively small blocks of data to them depends very much on the card.
User avatar
626Pilot
ULTIMATE 3D JEDI
Posts: 1720
Joined: Tue May 14, 2013 12:52 pm

Re: Impressions: Duet vs. Smoothie

Post by 626Pilot »

I'll definitely try that if I hook up the Duet again!
bubbasnow
ULTIMATE 3D JEDI
Posts: 1064
Joined: Fri Aug 02, 2013 4:24 pm
Location: Dayton, WA

Re: Impressions: Duet vs. Smoothie

Post by bubbasnow »

dc42 wrote:For info, I have just released version 1.12 of my fork or RepRapFirmware, which has further improvements to the SD write code. I was previously getting around 450Kbytes/sec from my best-performing SD card. Now I get this:

[img]https://dl.dropboxusercontent.com/u/193 ... dSpeed.png[/img]

Measured on a Duet 0.8.5 with a Chrome/Windows 10 client and wired Ethernet throughout. Your mileage may vary - as I said before, the way SD cards behave when you write relatively small blocks of data to them depends very much on the card.
ugg kibibytes..
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Impressions: Duet vs. Smoothie

Post by dc42 »

bubbasnow wrote:ugg kibibytes..
Yes, I don't know why chrishamm uses KiB/s to abbreviate kilobytes per second in DWC. I'll suggest he changes it to Kbytes/s, or perhaps to Mbytes/s if we manage to increase the speed some more.
geneb
ULTIMATE 3D JEDI
Posts: 5362
Joined: Mon Oct 15, 2012 12:47 pm
Location: Graham, WA
Contact:

Re: Impressions: Duet vs. Smoothie

Post by geneb »

He's probably one of those poor, confused, souls that think a kilobyte is 1000 bytes and not 1024 bytes LIKE IT IS. (I blame hard disk marketing people.) :D

g.
Delta Power!
Defeat the Cartesian Agenda!
http://www.f15sim.com - 80-0007, The only one of its kind.
http://geneb.simpits.org - Technical and Simulator Projects
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Impressions: Duet vs. Smoothie

Post by dc42 »

dc42 wrote:
bubbasnow wrote:ugg kibibytes..
Yes, I don't know why chrishamm uses KiB/s to abbreviate kilobytes per second in DWC. I'll suggest he changes it to Kbytes/s, or perhaps to Mbytes/s if we manage to increase the speed some more.
It turns it that you can change the units from kibibytes/sec to kilobytes/sec on the Settings page of DWC. I've done that on my system now.
bob64
Printmaster!
Posts: 89
Joined: Sun Jul 20, 2014 8:45 pm

Re: Impressions: Duet vs. Smoothie

Post by bob64 »

Which page is that setting?
Rostock Max V2 with mods:
E3d v6 with 713maker mount & e3d titan extruder
Tricklaser CF arms, heat spreader, tricktrucks, fly-n-strude, metal carriage & effector
Duet v.8.5.0
24v MeanWell 750w PS & Cydom D1D40 SSR in parallel with stock 12v PS
dc42
Printmaster!
Posts: 454
Joined: Mon Mar 07, 2016 10:17 am

Re: Impressions: Duet vs. Smoothie

Post by dc42 »

bob64 wrote:Which page is that setting?
It's on the General tab of the Settings page, called Use Binary Prefix.
User avatar
bLiTzJoN
Plasticator
Posts: 10
Joined: Fri Nov 20, 2015 10:12 am
Location: Indy
Contact:

Re: Impressions: Duet vs. Smoothie

Post by bLiTzJoN »

Now that it's been a couple years since the write-up would the comparison still lean towards Duet or is Smoothie holding its own? In addition to my RMv2, I have a Tevo Little Monster which came with a Smoothie. It would appear people are flocking to convert it to DuetWifi. Updated thoughts?!
RMv2: HE280 board, EZRStruder, E3Dv6, 713Maker effector, Microswiss nozzles, GeckoTek3D base, Capricorn tubes, steel belts, titanium bearings, curtain enclosure
Tevo LM: TMC2208 drivers, E3D volcano w/pancake stepper, steel belts, aluminum idlers
Xenocrates
ULTIMATE 3D JEDI
Posts: 1561
Joined: Wed Sep 23, 2015 2:55 pm

Re: Impressions: Duet vs. Smoothie

Post by Xenocrates »

I would say that Duet has pulled firmly ahead of the Smoothieboard family at this point. The web interface is stable, mature, and allow for much easier firmware upgrades, the on machine interface is easier to set up (If you use the Paneldue), and allows for external SD cards now, the stepper driver precision and current have improved, the communications options are mature with both Ethernet and Wifi, as well as USB connectivity, The system for using higher precision temperature sensors and higher temperature ones such as PT100s or thermocouples is a huge amount better, with easy to source and install daughterboards that are engineered to work with it specifically, there is both expandibility using a standard header with no minimal crazy daisy-chaining, and the ability to use that to remap the normal axis's to it to use larger drivers or to replace ones that die, the CPU protection fuse is much improved with a self-resetting fuse that has been proven to protect the CPU at this point, and the temperature control algorithms and auto-tune are far more stable and precise, now that there is a feed-forward model in place.


Looking at Smoothieboard V2, which should compete with the Duet Wifi and Ethernet, it's not only MIA, but the Edison socket on the pro model is now rather pointless, as Edison was recently EOLed, making all that development for naught, there is a convoluted connection standard to attempt to daisy-chain expansion (Using the Gadgeteer connector and a CAN-like protocol, IIRC, it's not CAN exactly, but it's also not Gadgeteer, which is a mess IMO), and the CPU, while more powerful, doesn't have the sub-controller to offload to that the Duet's do (The boards have a controller for the communications and web-interface on their module, and the Paneldue is intelligent as well, meaning the main controller needs to do fairly little as far as drawing graphics or outputting anything but a stream of simple status updates and queries to both).

While I have no formal involvement with either, I did, and would again, buy Duet hardware. Until the V2 of smoothieboard is actually available, it's flat out better.
Machines:
Rostock Max V2, Duet .8.5, PT100 enabled E3D V6 and volcano, Raymond style enclosure
Automation Technology 60W laser cutter/engraver
1m X-carve router

Sic Transit Gloria Mundi
01-10011-11111100001
User avatar
626Pilot
ULTIMATE 3D JEDI
Posts: 1720
Joined: Tue May 14, 2013 12:52 pm

Re: Impressions: Duet vs. Smoothie

Post by 626Pilot »

I'll continue to use Smoothieboards because I wrote the heuristic calibration system for them, and it works better for me than Duet's firmware. It gives you a full depth map after the calibration, as well as after setting up Z-only correction (if you want to), so you know what you're really getting. Besides, I spent over a thousand hours on it. I wouldn't be keen to stop using it even if it didn't have those extra features.

The Smoothie devs really need to get the Smoothieboard 2 out the door. It was due last year. They need to ditch the Edison socket if they haven't already, because who cares. The daisy-chained peripheral idea is dynamite to me, and they should keep it. It doesn't have to be "real" CAN, but it might be better if it was. Maybe someone will find CAN peripherals that would work great with the SB2. You never know what someone's going to come up with.

They should also use a microcontroller with at least 1MB RAM. Failing that, just add an external RAM chip. They fell into the Bill Gates trap last time, thinking 64K was "enough for everybody." They were wrong. It's always the wrong decision to get barely enough RAM on a microcontroller that you want to be future-proof, and unless they want to have to redesign it in two years, they need to get more RAM. It's really that simple. Saving 1-2% on the BOM isn't a good decision if it makes it needlessly less future-proof. In fact, if it's cheap enough, I would throw 32 or 64MB of RAM in there, so it can swallow a G-code file whole.

They need to work on their Web interface. Frankly, it sucks, and is a decade behind the times. Duet kills Smoothie there. For me, it doesn't matter because I use OctoPrint on the Raspberry Pi.

Another more radical option would be to simply produce a driver shield for the Raspberry Pi, and port their firmware to run on it. They'd get built-in OctoPrint in the deal. OctoPrint can gobble down G-code files way faster than the Duet can because it has a huge RAM. That alone is reason enough for me not to use PanelDue, even if I was using a Duet. A minimal Linux OS that runs with the filesystem in readonly mode (except when saving G-code or modifying config) should work well. I'm honestly surprised that no one has done this kind of driver board yet. It's so obvious.
Xenocrates
ULTIMATE 3D JEDI
Posts: 1561
Joined: Wed Sep 23, 2015 2:55 pm

Re: Impressions: Duet vs. Smoothie

Post by Xenocrates »

626Pilot wrote:
Another more radical option would be to simply produce a driver shield for the Raspberry Pi, and port their firmware to run on it. They'd get built-in OctoPrint in the deal. OctoPrint can gobble down G-code files way faster than the Duet can because it has a huge RAM. That alone is reason enough for me not to use PanelDue, even if I was using a Duet. A minimal Linux OS that runs with the filesystem in readonly mode (except when saving G-code or modifying config) should work well. I'm honestly surprised that no one has done this kind of driver board yet. It's so obvious.
There's something similar, called the Replicape project, using a Beagle bone black. However, it's behind the Duet project as far as support for a lot of things, and while powerful, it lacks good documentation, and for some things I find near essential (PT100 and thermocouple support), it's poorly documented, and amounts to the same voltage divider hacks to get it working on the Rambo.

That said, if you're invested in either ecosystem, there's not ENOUGH differentiation for me to say you should switch, even if Smoothie 2 (Or a Duet Ethernet 2) came along tomorrow.
Machines:
Rostock Max V2, Duet .8.5, PT100 enabled E3D V6 and volcano, Raymond style enclosure
Automation Technology 60W laser cutter/engraver
1m X-carve router

Sic Transit Gloria Mundi
01-10011-11111100001
User avatar
626Pilot
ULTIMATE 3D JEDI
Posts: 1720
Joined: Tue May 14, 2013 12:52 pm

Re: Impressions: Duet vs. Smoothie

Post by 626Pilot »

I know about the Replicape. They would've had access to a bigger pool of developers if they had used the Pi. I think they used the BBB because of its coprocessors, which they call PRUs, but that was never necessary. The Pi has a DMA controller, and can send waveforms to stepper drivers many times faster than needed with perfect timing. I wrote the first NeoPixel driver for the Pi, back when AdaFruit was saying it couldn't be done. Those things need pulses that are 400nS wide, plus or minus about 10%, and the Pi has no trouble doing that. Way more precision than you need for steppers.
Post Reply

Return to “Duet”