Smoothieboard: Is it worth it?

[TheRealRocketBurns]

I am looking to upgrade my printer this summer (please see this thread for all the upgrades I will be doing: http://forum.seemecnc.com/viewtopic.php?f=59&t=8512), and replacing the RAMBO with a smoothieboard is a consideration. Currently, I have been finding some conflicting sources of info all over the internet, and I am beginning to get confused. First of all, will the smoothieboard work with the stock LCD, or will I have to buy a graphic LCD? Also, how reliable is this board? Are there any major issues? if anyone has any before and after prints, some pictures would be nice. What are the pro's/cons of making the switch?

Thanks in advance!

[Jimustanguitar]

Disclaimer: I own 2 smoothie boards, and know people who run them, but I haven't installed my own yet, so my opinions are based on others' experiences.


The processing speed on the smoothie is way, way more capable than the arduino based boards. For fast moving delta machines, or using 400 step motors, it's got the overhead to do the job.

The firmware is much easier to learn. It's a text file that you just put on an SD card and restart the board to load.

You either need to buy the full graphic LCD display, or use an Arduino to "translate" between the existing display and Smoothie.

I've heard complaints about them not having fuse protection built in, but I also don't know anyone who's cooked one.

I also read recently that somebody didn't like the programming for how it computes its motion, but I don't know enough about that to repeat it well. Was that you, PolygonHell?

[ccavanaugh]

My $.02..

I have one smoothie up and running without issue.

Dislikes
I don't like the stepper connectors as well as the connectors used on the Rambo. They can be swapped out.
No protection on the board to protect against manually moving a stepper too fast. They act like a generator and the Rambo protects against it. I frightened myself by being careless and the board began to boot when moving an axis. No apparent damage detected.

Likes
The ability to create custom M codes to control fans more easily, etc. I have created new M codes to turn a chassis fan on and off.
The ability to mount the SD card over a network to modify the config file, upload gcode files, etc.

I would just purchase the board with a GLCD to keep it simple. Unless you are printing at high speeds, I don't know that it will improve print quality much over a newer Rambo. If you need a new board, them the Smoothie is the lower cost solution.

[TheRealRocketBurns]

You either need to buy the full graphic LCD display, or use an Arduino to "translate" between the existing display and Smoothie.

would this work with any arduino?

I don't like the stepper connectors as well as the connectors used on the Rambo. They can be swapped out.
No protection on the board to protect against manually moving a stepper too fast. They act like a generator and the Rambo protects against it. I frightened myself by being careless and the board began to boot when moving an axis. No apparent damage detected.

I have heard a lot about the fuses, I don't imagine it would be too hard to break out the pins to a separate proto-board with sockets for fuses (I ould use the cheap automotive fuses, not the stupid small ones in the Rambo), would it?

In addition, I have heard about the marvels of auto bed levelling/tramming with smoothie, does anyone here have any experience with this?

[Polygonhell]

I also read recently that somebody didn't like the programming for how it computes its motion, but I don't know enough about that to repeat it well. Was that you, PolygonHell?

I don't necessarily dislike it, I think the corner speed calculation is questionable on a 3D printer, makes a lot of sense for moving a heavy effector say on a mill, though there you'd want to actually cut the corner to maintain velocity.
On an FDM printer for optimum quality you want to ideally maintain constant head speed, because plastic extrusion rate depends on pressure in the hotend, i.e. It doesn't start and stop immediately, so any variation in speed can lead to inconsistent plastic deposition.
The Jerk setting as it's used in most firmwares, as much as it is a hack, does a pretty good job of keeping you close to this ideal, and if you actually print at your jerk setting, it pretty much is the ideal.
Smoothie varies the junction speed based on a supplied constant and the angle between the incoming and outgoing motion, using some approximation for centripetal acceleration. If that calculated cornering speed gets too low, you can end up with over extrusion at sharp corners, as the print head spends too much time there and the pressure doesn't decrease fast enough.
Having said that there is nothing inherently worse in this approximation, and if it lets you increase your acceleration enough it might actually be a win, it's just hard to say for sure, and intuitively I'm not convinced the more complex algorithm is better for machines with lightweight effectors.

I own 2 smoothie boards, one on a Kossel, which is running a very old version of the firmware, and one in a box I bought to upgrade the RMax and have never gotten around to installing.

[U.S. Water Rockets]

Disclaimer: I own 2 smoothie boards, and know people who run them, but I haven't installed my own yet, so my opinions are based on others' experiences.


The processing speed on the smoothie is way, way more capable than the arduino based boards. For fast moving delta machines, or using 400 step motors, it's got the overhead to do the job.

The firmware is much easier to learn. It's a text file that you just put on an SD card and restart the board to load.

You either need to buy the full graphic LCD display, or use an Arduino to "translate" between the existing display and Smoothie.

I've heard complaints about them not having fuse protection built in, but I also don't know anyone who's cooked one.

I also read recently that somebody didn't like the programming for how it computes its motion, but I don't know enough about that to repeat it well. Was that you, PolygonHell?

Thanks for the helpful advice. I do have a question about the display. Is it a software or hardware issue that prevents the smoothie from working with the existing display? The small ribbon cable for the LCD on the Rambo implies it is a serial interface like UART, I2C, or SPI. Is there some reason this is not present on the smoothie? Or is it simply a software issue? We have folks here with experience with these interfaces and working around complex hardware incompatibilities, so it seems completely possible to make the two work without a translator.

[626Pilot]

In addition, I have heard about the marvels of auto bed levelling/tramming with smoothie, does anyone here have any experience with this?

I wrote that code. You can see a thread about it in my sig.

[ramai]

Dislikes
I don't like the stepper connectors as well as the connectors used on the Rambo. They can be swapped out.
No protection on the board to protect against manually moving a stepper too fast. They act like a generator and the Rambo protects against it. I frightened myself by being careless and the board began to boot when moving an axis. No apparent damage detected.

If you move the trucks on the stock rambo the LCD will boot up too. I've done it a few times when friends come over and start messing with it while its off. Do you think it could actually damage it? Has anyone ever reported damage from this?

[ccavanaugh]

Dislikes
I don't like the stepper connectors as well as the connectors used on the Rambo. They can be swapped out.
No protection on the board to protect against manually moving a stepper too fast. They act like a generator and the Rambo protects against it. I frightened myself by being careless and the board began to boot when moving an axis. No apparent damage detected.

If you move the trucks on the stock rambo the LCD will boot up too. I've done it a few times when friends come over and start messing with it while its off. Do you think it could actually damage it? Has anyone ever reported damage from this?

I know some boards can be damaged and I do remember it being discussed on the Smoothie forum. I the Rambo protection depends on the board version.

[DanCurran]

626Pilot

I am curious about your work with smoothie
I am an embedded software engineer ( mostly work with stm32F2's and stm32F4's but just started with a stm32f7)
Though Rambo works I like the idea of using newer devices and the additional functionality these devices have ( e.g. USB host support for MSD) so was thinking of starting a new project using a STMf7 and the ST dspin stepper motor controllers.

I would be using the Keil toolset in conjunction with either keil/ARM/mbed RTX, FatFs,
I can set up USB device CDC and a USB host MSD along with a SDIO SD card access.

One issue is I am mainly a MISRA adhering C programmer.
so while looking over the smoothies source I am a little wary of the fact there is various languages and you have included parts of mbed environment.

What would be your advise once I have a board support package up to move the project forward in terms of the cnc side of the code.

[626Pilot]

If you move the trucks on the stock rambo the LCD will boot up too. I've done it a few times when friends come over and start messing with it while its off. Do you think it could actually damage it? Has anyone ever reported damage from this?

Absolutely. If there is enough current to light up the LEDs, it means significant voltage is being applied. If you move the trucks fast enough, the steppers WILL generate enough volts to really cook something good. The board may become less reliable, if not just fry outright. Some boards have back EMF protection... dunno if it's just diodes or whatever.

I am curious about your work with smoothie. I am an embedded software engineer ( mostly work with stm32F2's and stm32F4's but just started with a stm32f7). Though Rambo works I like the idea of using newer devices and the additional functionality these devices have ( e.g. USB host support for MSD) so was thinking of starting a new project using a STMf7 and the ST dspin stepper motor controllers. I would be using the Keil toolset in conjunction with either keil/ARM/mbed RTX, FatFs, I can set up USB device CDC and a USB host MSD along with a SDIO SD card access.

One issue is I am mainly a MISRA adhering C programmer. so while looking over the smoothies source I am a little wary of the fact there is various languages and you have included parts of mbed environment.

What would be your advise once I have a board support package up to move the project forward in terms of the cnc side of the code.

If you want to contribute to or fork Smoothie, it's just straight up C++. There is a bash script that installs the ARM version of GCC. You execute the build shell in order to set up all the paths and environment variables, and then type "make" and it compiles, then "make upload" to flash it to the board's EEPROM. It's trivial. The installer and build shell scripts do all the tedious crap for you.

I don't know whether it's MISRA compliant because I never heard that term before seeing your post. If it isn't, then you have to learn the Smoothie way of doing things and potentially violate whatever you like about MISRA. (But you usually have to give up some of your preferred way of doing things, when working in someone else's codebase. I like 1TBS, but maybe the maintainer insists that I put all the braces on their own lines.) You could go to the Smoothie IRC channel and talk to wolfmanjm about it, if you're curious. He knows just about everything about the software, and he is usually quick to respond, assuming he's at a keyboard.

I do know they're actively working on a new board with some kind of hybrid processor. It has high and low speed cores. The high speed core runs all the UI/housekeeping stuff, and the slow one does all the real-time motion control routines that mustn't be interrupted. If Smoothie isn't a MISRA project, and you think it should be, this would be the time to make the case, as they already have to port all the platform-dependent stuff anyway. Even just applying some of its principles imperfectly might be a step in the right direction.

If you want to help the area where it's most needed, figure out a way to make the SD card mounting & FS synchronization less terrible. Right now, it's barely functional. Writing files over USB is S-L-O-W. A big G-code file can easily take a minute or longer, even if it's 20 megs. It also fails to resync the filesystem, so you write something over USB, but Smoothie's file allocation table doesn't get updated and it will crosslink your files if you try to save the settings with M500. It is the messiest, most annoying part of the everyday user experience with Smoothie, by far.

[bot]

Dang... what about file transfer over the network? Via the website console?

[626Pilot]

I don't know about the network. The web console might be OK. I never tested either. I definitely know that if I M500 after editing config over USB, something's going to get trashed.

[ccavanaugh]

Dang... what about file transfer over the network? Via the website console?

I've gone both. The plan 9 FS on Linux seems to be reliable in that it's not broke yet. The html upload is considerably slower.

Most days, I just use an SD card inserted into the GLCD without issue.

[Eric]

Thanks for the helpful advice. I do have a question about the display. Is it a software or hardware issue that prevents the smoothie from working with the existing display? The small ribbon cable for the LCD on the Rambo implies it is a serial interface like UART, I2C, or SPI. Is there some reason this is not present on the smoothie? Or is it simply a software issue? We have folks here with experience with these interfaces and working around complex hardware incompatibilities, so it seems completely possible to make the two work without a translator.

Both. If you have enough interface lines, certainly you can make some or all of the lcd assembly hardware work. The rest of it is in software, and the right person could make that work. However, how much effort is it worth to reuse a display assembly worth about $15? (http://www.ebay.com/itm/LCD-2004-contro ... 418c9916a8)

Here's the schematic for that thing: http://reprap.org/mediawiki/images/7/70 ... scount.pdf
The LCD alone requires 4 data lines, 2 control lines, power and ground. That's still considered a parallel interface, even though you could argue it's sending bytes in a serial fashion. A true serial interface would only have one data line.

[TheRealRocketBurns]

Would this: http://www.ebay.com/itm/New-3D-Printer- ... 2ecef2b5fa
GLCD work wth the smoothieboard if I bought this: http://shop.uberclock.com/collections/s ... lcd-shield
???

[KAS]

Would this: http://www.ebay.com/itm/New-3D-Printer- ... 2ecef2b5fa
GLCD work wth the smoothieboard if I bought this: http://shop.uberclock.com/collections/s ... lcd-shield
???

I was able to get a GLCD clone working on the smoothiboard by flipping the ribbon cables 180. Also I had to solder a little resistor on the PCB to get the GLCD brighter. The picture in that ebay link appears to have corrected the ribbon cable issue. As for the brightness, it's a gamble if it works right out of the gate.


Topic on the forum: http://forum.seemecnc.com/viewtopic.php?f=82&t=8312


This was the GLCD I purchased. http://www.ebay.com/itm/LCD-12864-Graph ... 2a40821815

[TheRealRocketBurns]

I also read recently that somebody didn't like the programming for how it computes its motion, but I don't know enough about that to repeat it well. Was that you, PolygonHell?

I don't necessarily dislike it, I think the corner speed calculation is questionable on a 3D printer, makes a lot of sense for moving a heavy effector say on a mill, though there you'd want to actually cut the corner to maintain velocity.
On an FDM printer for optimum quality you want to ideally maintain constant head speed, because plastic extrusion rate depends on pressure in the hotend, i.e. It doesn't start and stop immediately, so any variation in speed can lead to inconsistent plastic deposition.
The Jerk setting as it's used in most firmwares, as much as it is a hack, does a pretty good job of keeping you close to this ideal, and if you actually print at your jerk setting, it pretty much is the ideal.
Smoothie varies the junction speed based on a supplied constant and the angle between the incoming and outgoing motion, using some approximation for centripetal acceleration. If that calculated cornering speed gets too low, you can end up with over extrusion at sharp corners, as the print head spends too much time there and the pressure doesn't decrease fast enough.
Having said that there is nothing inherently worse in this approximation, and if it lets you increase your acceleration enough it might actually be a win, it's just hard to say for sure, and intuitively I'm not convinced the more complex algorithm is better for machines with lightweight effectors.

I own 2 smoothie boards, one on a Kossel, which is running a very old version of the firmware, and one in a box I bought to upgrade the RMax and have never gotten around to installing.

Just was poking through the smoothie firmware config options page (http://smoothieware.org/configuration-options) and found this:

junction_deviation - 0.05 Similar to the old "max_jerk", in millimeters. Defines how much the machine slows down when decelerating proportional to the vector angle of change of direction. See here and here. Lower values mean being more careful, higher values means being faster and have more jerk

would this be the jerk setting you are talking about?

Also, I found the acceleration setting

acceleration 3000 Acceleration in millimetres/second/second. Higher values make your machine faster and shakier, lower values make your machine slower and sturdier. This is generally proportional to the weight of the tool you are trying to move.

[Polygonhell]

junction_deviation - 0.05 Similar to the old "max_jerk", in millimeters.

Yes smoothie replaces what was "Jerk" which is not jerk in the mathematical sense but rather a way to encapsulate allowed instantaneous changes in velocity, with junction_deviation which in effect assumes the corner is cut by following a circle that touched both the incoming and outgoing edge, and has a radius such that the maximum deviation from the intended path is the specified value. The actual junction velocity is them limited such that the cetripetal of this theoretical acceleration does not exceed the set acceleration.

The reason I'm not convinced by this, is two fold, the first is that the cornering velocity is now dependent on the angle of the incoming and outgoing paths, which means the tighter the corner the slower the motion, this means your printer will deposit too much plastic at tight corners, the second is I think the argument that this calculation is based on some physical reality is specious. If the firmware actually did cut the corner which is what high end motion controllers do then yes it's a good approximation, but all it's really doing is applying a heuristic based on the dot product of the in and out vectors.
It will likely allow you to increase acceleration over what the old "Jerk" setting would, but it's hard to know if it's an actual win.

As I said on a mill it makes a lot of sense, because the inertia would force you to pretty much set jerk to 0, so the new calculation is a clear win, but Printers are not mills in general the effector mass is tiny. I've built axis for printers where you can reliably instantaneously transition to 100+mm/s at a 180 degree transition points.

[TheRealRocketBurns]

junction_deviation - 0.05 Similar to the old "max_jerk", in millimeters.

Yes smoothie replaces what was "Jerk" which is not jerk in the mathematical sense but rather a way to encapsulate allowed instantaneous changes in velocity, with junction_deviation which in effect assumes the corner is cut by following a circle that touched both the incoming and outgoing edge, and has a radius such that the maximum deviation from the intended path is the specified value. The actual junction velocity is them limited such that the cetripetal of this theoretical acceleration does not exceed the set acceleration.

The reason I'm not convinced by this, is two fold, the first is that the cornering velocity is now dependent on the angle of the incoming and outgoing paths, which means the tighter the corner the slower the motion, this means your printer will deposit too much plastic at tight corners, the second is I think the argument that this calculation is based on some physical reality is specious. If the firmware actually did cut the corner which is what high end motion controllers do then yes it's a good approximation, but all it's really doing is applying a heuristic based on the dot product of the in and out vectors.
It will likely allow you to increase acceleration over what the old "Jerk" setting would, but it's hard to know if it's an actual win.

As I said on a mill it makes a lot of sense, because the inertia would force you to pretty much set jerk to 0, so the new calculation is a clear win, but Printers are not mills in general the effector mass is tiny. I've built axis for printers where you can reliably instantaneously transition to 100+mm/s at a 180 degree transition points.

Ah, okay. I'll do some more digging to figure out if I can fix this or hack my way around it. I am pretty sold on the smoothieboard overall, however.

[Generic Default]

I'm just wondering about that junction deviation thing. In the picture above, suppose the nozzle of the printer is supposed to trace the square corner exactly. Would Smoothie make it trace the curved path or the diagonal path as junction deviation? I'm assuming that setting junction deviation to 0 would either cause an error or make the machine decelerate to zero velocity and then re-accelerate to full velocity on the new vector. Is that how it works?

[Polygonhell]

I believe it traces the original path exactly, BUT, it restricts the velocity as if it were following the curve.
The idea is that it's a better approximation than Jerk.

[TheRealRocketBurns]

junc deviation.jpg

I'm just wondering about that junction deviation thing. In the picture above, suppose the nozzle of the printer is supposed to trace the square corner exactly. Would Smoothie make it trace the curved path or the diagonal path as junction deviation? I'm assuming that setting junction deviation to 0 would either cause an error or make the machine decelerate to zero velocity and then re-accelerate to full velocity on the new vector. Is that how it works?

Well it looks like this forum shows the problem exactly with a test cube that has obvious over-extrusion on the corners (It looks like you were there, Polygonhell). te problem appears to have been solved by increasing the junction deviation from the default .01 to .05, and then was improved more by increasing it to .2-.35
http://forum.seemecnc.com/viewtopic.php?f=82&t=8463

[626Pilot]

I think I set mine to 0.2.

Unless the slicer or firmware is smart enough to cut filament flow below what it "should" be, the printer can't help but over-extrude at corners. You have to account for the fact that the filament is not free to expand in the direction of the inside of the turn, so it HAS to slop outwards. I saw the math for that a couple years ago, but I don't know how commonly it's implemented, or whether Smoothie does it at all.

[TheRealRocketBurns]

I'm pretty convinced, I think I will roll the dice on a smoothieboard! I will probably put up a build log/tutorial that details the upgrade process.