Welcome to the SeeMeCNC Community

We are trying to determine what people feel what would be a better card for the future in our 3D printers.

I would need to understand the actual implementation on the BB, while it's at least 10x faster than the smoothie board, Linux is a crappy OS for a motor controller, depending on how the PRU's are used, and how much is reliant on tight interrupt timing, it could still be a good solution, but without more details it's hard to say.
This isn't just about hardware.
I'd like to see some real benchmarks including scope captures of the output pulse trains, to get a better understanding of how hey compare.

Well, I decided to go with the smoothie.
just ordered the 5 driver version.
looks to be a simpler option than messing with BBB, Cape, linux, EMC2.
still yet, the gains in smoothness and speed over the Ardudio boards looks well worth the change.

Polygonhell wrote:I would need to understand the actual implementation on the BB, while it's at least 10x faster than the smoothie board, Linux is a crappy OS for a motor controller, depending on how the PRU's are used, and how much is reliant on tight interrupt timing, it could still be a good solution, but without more details it's hard to say.
This isn't just about hardware.
I'd like to see some real benchmarks including scope captures of the output pulse trains, to get a better understanding of how hey compare.

You guys do realize that the BeagleBone can run the Bare Metal Starterware Operating System and forget about Linux completely? The ARM core is clocked 10x faster in the BeagleBone, but it uses DDR3 Memory, and a more advanced ARM core with more pipeline stages, so it is on the order of 20x as powerful even without getting into the Floating Point Coprocessor in the BeagleBone, which could be hundreds of times faster still.

The BeagleBone also has 2 PRUs and those are like separate CPUs that are each 4x as fast as the Smoothieboard's only CPU. It also has Ethernet, and USB-OTG in addition to SD-Card, making more options for connecting to a computer available.

The only question is, how mature the different designs actually are, and what resources they make use of. A poor design can be done on any platform. If you consider that the only thing that a BaegleBone Cape needs is the motor and I/O circuitry, this should be the lowest cost solution, since the CPU board is so inexpensive.

It will be interesting to see if people are capable of harnessing all the power of the Beaglebone, and are not greedy as to charge an arm and a leg for the cape board.

Brian wrote: You guys do realize that the BeagleBone can run the Bare Metal Starterware Operating System and forget about Linux completely? The ARM core is clocked 10x faster in the BeagleBone, but it uses DDR3 Memory, and a more advanced ARM core with more pipeline stages, so it is on the order of 20x as powerful even without getting into the Floating Point Coprocessor in the BeagleBone, which could be hundreds of times faster still.

The BeagleBone also has 2 PRUs and those are like separate CPUs that are each 4x as fast as the Smoothieboard's only CPU. It also has Ethernet, and USB-OTG in addition to SD-Card, making more options for connecting to a computer available.

Yes I'm aware of that, I spent a lot of time working with an original Beagle Board, the issue is you lose access to things like the GPU in starter-ware because the driver is closed source. And as far as I'm aware the 2 attempts to write printer drivers on the Beagle are both Linux based, the one blog I've read on one of them did not inspire confidence in a good pulse train.

It is certainly possible to build a very good solution on top of the Beagle and it is at least 10x faster than the LPC1769 in the Smoothie, but it requires someone make the effort and either port the software, or probably better write something that plays to the strengths of the hardware. Currently if you do uController development there is a weird step from Cortex M3/4 solutions like the LPC or STM, to the Ax solutions like the Beagle and Raspberry Pie, you go from documented hardware to closed source (often buggy) drivers that require an OS to access the features.

Having said that the biggest issue I have against the Beagle is that if TI ever decided to stop making them, I very much doubt anyone else could make them for a competitive price (just count the passive components on the board).

Polygonhell wrote: Yes I'm aware of that, I spent a lot of time working with an original Beagle Board, the issue is you lose access to things like the GPU in starter-ware because the driver is closed source. And as far as I'm aware the 2 attempts to write printer drivers on the Beagle are both Linux based, the one blog I've read on one of them did not inspire confidence in a good pulse train.

Why do you need the GPU, if none of the current solutions uses or requires a GPU? The CPU on the BeagleBone is available in pin compatible variants which don't even offer the GPU, so someone can save a few bucks on a PCB if they wanted. The GPU is only needed for pretty 3D graphics on an LCD screen. I suppose you could use it to make fancy previews of your part or something like that as it prints, but that would be something the other boards can't do either so you can't fault the BB for that. Memory mapped graphics without a 3D accelerator would be just fine for this kind of product.

It is certainly possible to build a very good solution on top of the Beagle and it is at least 10x faster than the LPC1769 in the Smoothie, but it requires someone make the effort and either port the software, or probably better write something that plays to the strengths of the hardware. Currently if you do uController development there is a weird step from Cortex M3/4 solutions like the LPC or STM, to the Ax solutions like the Beagle and Raspberry Pie, you go from documented hardware to closed source (often buggy) drivers that require an OS to access the features.

Do you have information on what hardware features of the AM335x that are not documented in the User Manuals, and which ones are not supported by Starterware? As far as I can see, TI has provided an amazing support infrastructure for this device, and have gone out of their way to make it accessible.

I think bad experiences with the likes of Freescale and ST and their hoorible documentation and support have tarnished the reputation of the ARM Ax families of devices. It's a shame, because people will gravitate to the uC variants thinking they are taking a safe route, when they could be using a much more powerful uP for only slightly more cost.

Having said that the biggest issue I have against the Beagle is that if TI ever decided to stop making them, I very much doubt anyone else could make them for a competitive price (just count the passive components on the board).

Well, we know you don't have to worry about this. TI does NOT make the BeagelBone. It's made by an outfit called CircuitCo. TI has never made them.

Also, there are at least 4 companies who make SOM modules featuring the AM335x that have a similar price point. They are much smaller than the Beaglebone, and plug into your own design. These modules typically have a guaranteed availability you can get from the producer.

Do you have information on what hardware features of the AM335x that are not documented in the User Manuals, and which ones are not supported by Starterware? As far as I can see, TI has provided an amazing support infrastructure for this device, and have gone out of their way to make it accessible.

I think bad experiences with the likes of Freescale and ST and their hoorible documentation and support have tarnished the reputation of the ARM Ax families of devices. It's a shame, because people will gravitate to the uC variants thinking they are taking a safe route, when they could be using a much more powerful uP for only slightly more cost.

The GPU is the big one, at one point I was looking at a solution using the Beagle to do everything including Slicing, with a Slicer that used the GPU for additional work.
It's basically impractical because of the state of the GPU driver, the fact that TI doesn't pay imagitec for the OpenCL driver (which does exist but is unavailable) and the fact that the GPU and LCD interfaces are completely undocumented. I will accept that this particular experience has colored my view towards the platform.

The PRU's are also woefully under documented.

As I've said it's quite possible to do a good motor controller on an Ax series ARM CPU, but I don't think Linux is a big part of that solution. The biggest issue on any new hardware platform is going to be Software, the only reason anyone still uses Arduinos (they are expensive for what they are) is because that's where all the software is. You can't decide on a hardware platform in a vacuum, someone has to provide the software, I think the approach the smoothie guys have taken to the overall solution is better than the people currently trying to provide Beagle based solutions.

Even having said that, even the Smoothie could become abandon ware tomorrow, if the guy writing repetier decides he's done with it and no one takes over primary development, you could use Marlin, or Sprinter or Teacup or GRBL or .......

Could someone give me a brief breakdown on using a smoothieboard 5x with Repetier (latest versions).
Does Repetier recognize the board and if not could you give the very basics of what would need to be done.

Oh Flateric???????? LOL

Why? You put this post in and today, I got my Smoothieboard. See you in a month..LOL

Smoothie work fine in repetier host, or any host I have tried so far actually.

You lose the firmware adjustments from the menu, but making adjustments is a simple matter of editing the text file named "config" on the sd card in the smoothie. For some reason repetier doesn't let you adjust the speed on the fly with the slider, but you can use the m220 s100 command to adjust speed. Same with feed, the m221 sxxx mcode.

getting smoothie up and running was really not at all more eventful then getting a rambo or any other controller up and running.

A BIG plus for the smoothie I think is that it has already got support for delta printers, now.

The movements are much smoother than arduino solutions and to be honest I do not think it can be improved on, faster processing may not get you anything further in improvements at this point.

Correct me if I am wrong but the smoothie solution is a cheaper solution, it's complete. With the BB you have to buy additional parts for 3d printer use.

I don't regret my choice at all. I own just about every controller solution on the market, my old favorite was the azteeg x3, I imagine I will get a x5 as well. It's also smoothie based.

Flateric, would you recommend starting out with a smoothieboard or the Azteeg x5 for someone who is interested in upgrading the controller for the Rostock Max?
Just looking for your opinion since you are one of the few who has done the upgrade. Not looking for in depth article, just which you would choose and perhaps a quick why.

I ended up getting an Azteeg X5 in the mail yesterday and am waiting on a new controller panel for it. What's absolutely awesome about this solution is that the source code is still clean and has a fully functional script to create a local dev environment -- a first for any FOSS I've ever synced!

In retrospect, I liked the idea of having an ethernet port on the smoothieboard so I could play with the printer over my LAN but oh well I'll report once I get the X5 up and running.

Flateric, I have my Mini Kossel all set up with the Smoothieboard and everything is wired and buttoned down (I did put on the max endstop headers and went back to the default pins for max). I have calibrated roughly in Pronterface and everything seems to be close. I wanted to try to connect with Repetier but it won't connect. I created a new printer profile, set the baud rate and forced ascii protocol and made sure to choose the right usb serial port - this is on a mac. But it just doesn't want to connect. Am I missing something? I'm going to try Matter Control now.

Figured it out. There was nothing wrong with the configuration. The Smoothieboard was in some sort of funky state and needed to be shutdown and restarted (reset dod not work).

I am having some learning pains with it though. I'm using it on a new Mini Kossel I built. All done now. Homing still is funky - sometimes home is nice and smooth. Usually the machine makes a clunk noise and seems to over run the endstops. And every time, it homes with all switches depressed. I thought homing was supposed to back off the switches a set (small) amount to leave the switches unpressed? I couldn't find that in the config file.

Editing the config file is intermediate between editing and uploading firmware and the convenience of the EEPROM. After a config file edit, the boar has to be rebooted, which is a bit time-consuming and requires ejecting the CF - at least on a mac.

Michael (mhackney), If you got Repetier host working, are you having the issue I am having on my X5 with the print control panel not updating the extruder temp either in the graphic display or status bar?

Unfortunately I appear to have blown a driver or some other issue on my X5 since my X-alpha axis will not work at all so I am SOL until I hear from Panucatt.

mhackney wrote:Homing still is funky - sometimes home is nice and smooth. Usually the machine makes a clunk noise and seems to over run the endstops.

I noticed the same issue on mine. I turned down the homing speed in the config file and it seemed to help a bit.

I have homing fast at 100 and slow at 10 mm/s.

Repetier is reporting temps fine - the graphical display updates perfectly as well as the status bar.

I had slowed my fast homing down to 100 from 200 in config. Too bad my board is not working or I'd play with it some more

Thanks for checking- I guess my issue with the Repetier host Mac temp reporting is unique to the X5 mini or it has something to do with my setup.

I now have an Azteeg X5 on the way for my mini kossel I am fiddling with. So I will be able to let you guys all know my impressions of each board fairly quickly here. Hopefully by the end of next week.

May I ask which graphical display you guys are using with your smoothieboard or x5?

Eaglezsoar wrote:May I ask which graphical display you guys are using with your smoothieboard or x5?

No display hooked up yet... I bought a Viki that I was going to interface with the X5 then read it sort of works but that I2c is problematic and that its best to use an SPI board like the Reprapdiscount GLCD. I found this hack (https://github.com/wolfmanjm/universal-panel-adapter) which uses an Arduino Nano to convert an I2c board to SPI and think I might try that with the Viki.

The smoothieware firmware stops spewing up consistant data to repetier's temp display during some tasks like performing the PID tuning. Bit odd, but i'd rather it focus on more important tasks I suppose. Since I swapped to magnetic endstops before I swapped to smoothieboard I haven't had issues with homing, but I did increase the backup and slowdown settings for homing.

lordbinky wrote:The smoothieware firmware stops spewing up consistant data to repetier's temp display during some tasks like performing the PID tuning. Bit odd, but i'd rather it focus on more important tasks I suppose.

Strangely, mine works the opposite. It displays fine when doing PID tuning or running a program, but doesn't update when just the print panel is up.

Hey I just noticed that the X5 has 32/micro step drivers onboard, compared to the smoothie 16/micro step drivers.

Just thought I would make a note of that here.

Hey guys, I've got my smoothiboard/Mini Kossel pretty close to dialed in. I seem to be having an odd issue. The print seems to pause/hesitate when printing over USB, I haven't tried printing directly from the CF. I am connected to a USB hub so that could be the culprit. But that is how I have my RAMBo hooked up so I'm curious what others are experiencing?