Control Board wish list

[Tonkabot]

As an embedded system designer, I am already thinking that I could design a better control board.
Better as in has more features that people want, simplifies wiring, handles higher resolution, ....

Anyway, What I see is making a board like the Smoothieboard with an ARM, and various improvements. Does anybody use a Smoothie board?

Other improvements I am thinking about are distributing the driver chips to be close to the steppers - not a big deal on the 3 axis steppers, but for the extruders running the step signals through 3 or more feet
of wire is problematic, especially if one is going to handle things like that fancy color mixing extruder - the final target they are shooting for requires 6 extruder steppers for the CMYKWA.

What is it that people want in a control board?

[Jimustanguitar]

It seems that just about everybody has a mention in their known/past issues list about USB power vs 12v from the power supply and having a ground loop or drawing motor current through a USB cable... I don't know a ton about it, but this would be something worth avoiding from the start.

Make sure there are test points (or some sort of built in interface) for checking motor current.

Higher current fets for heated bed and hot end.

Non surface mount (ie user serviceable) fuses.

More processing power. Beaglebone Black class processing instead of arduino based. Something that could run Linux CNC.

[Jimustanguitar]

Almost forgot...


Ethernet connectivity!

[Tonkabot]

Almost forgot...

Ethernet connectivity!

Wireless? or is a cable okay?

I was also planning on using a processor with floating point.

[joecnc2006]

Almost forgot...

Ethernet connectivity!

Wireless? or is a cable okay?

I was also planning on using a processor with floating point.

Wireless you will not have a fast enough data transfer to keep up with the g-code transfer in line codes the only way is to have a look ahead feature in software which is a different story.

[Cosmic]

I would do a shield ( Arduino ) or cape ( beaglebone ) rather than a controller board.

It's easier to upgrade the controller as they become faster and with more features year after year. It's cheaper to replace in case things break.
You may have a larger selection of boards to chose from: Beaglebone(Black) , Arduino Tre (coming soon) , PCDuino , Udoo. All powerful and feature rich.

[Cosmic]

Almost forgot...

Ethernet connectivity!

Wireless? or is a cable okay?

I was also planning on using a processor with floating point.

Wireless you will not have a fast enough data transfer to keep up with the g-code transfer in line codes the only way is to have a look ahead feature in software which is a different story.

Wireless has very high speeds these days. Wireless has a problem that you could drop the connection for various reasons.

[Tonkabot]

I would do a shield ( Arduino ) or cape ( beaglebone ) rather than a controller board.

It's easier to upgrade the controller as they become faster and with more features year after year. It's cheaper to replace in case things break.
You may have a larger selection of boards to chose from: Beaglebone(Black) , Arduino Tre (coming soon) , PCDuino , Udoo. All powerful and feature rich.

Actually the whole shield concept is one that I don't like because of all the .100 headers and sockets.
My idea for motor drivers is to have the motor modules all be on a tiny board (about the same size as the A4988 type shield modules) that uses the card edge as the connector,
and it plugs into a PCIE-36 connector on the controller board. You'll find that a PCIE36 is the cheapest edge connector out there, and people don't have to be soldering .100 pin headers and don't have to worry about plugging in backwards. With 36 connections there is the capability for all sorts of other modules and auto-detection. (I don't acutally use the PCIE pinout).


Yes wireless is fast enough, and I was planning on having local SD card storage so you could download the entire file and not have to worry if the connection breaks during print.
Problem with wireless is that it is expensive and a PITA to set up - sometimes.

Having a linux based control board seems problematic to me. It needs to be realtime, and just seems wrong for the G-code printer. Yes the board should be able to talk to the network world -
I imagine that it could have a web-based interface - once it has the G-code file and the 'start' command, it should be self contained and driving steppers until it is done.

Having a raspberry PI or beagleboard or whatever just seems like a way to replace the character LCD and UI with a LCD monitior and keyboard - things I have aplenty and don't need to dedicate to the printer.

[Polygonhell]

The issue with wireless is more about having enough of a buffer to live with the latency.
Having said that if your using a uController with ethernet support you probably have at least 1 MTU's worth of data which is likely enough.

FWIW one of the issues you'll run into is software, ethernet drivers on LPC176x or STM32x0x tend to require multiple somewhat large buffers, usually multiple MTU's for each direction. And be careful, on the LPC1768 board I used, the sample code for the ethernet device is not just crap, but incorrect in the way it initializes the device (it just happens to work with crippled performance).

FWIW Ethernet is a MUCH better connection protocol for the way the connection is used for 3D printing than USB, but it's not entirely trivial to tack onto existing firmware.

There is a lot of work in building a competitive printer controller from scratch, and most of it is in the software.

[Tonkabot]

The issue with wireless is more about having enough of a buffer to live with the latency.
Having said that if your using a uController with ethernet support you probably have at least 1 MTU's worth of data which is likely enough.

FWIW one of the issues you'll run into is software, ethernet drivers on LPC176x or STM32x0x tend to require multiple somewhat large buffers, usually multiple MTU's for each direction. And be careful, on the LPC1768 board I used, the sample code for the ethernet device is not just crap, but incorrect in the way it initializes the device (it just happens to work with crippled performance).

FWIW Ethernet is a MUCH better connection protocol for the way the connection is used for 3D printing than USB, but it's not entirely trivial to tack onto existing firmware.

There is a lot of work in building a competitive printer controller from scratch, and most of it is in the software.

I figured that I could port the smoothie board software to this new board fairly easily. That's why I am wondering if anyone is using a smoothie board.

I was thinking to use the freescale K20 (no ethernet) or K60 (with ethernet). They are an arm M4 (instead of M3 like the LPC) and they can have floating point. Plus they are cheaper and I think have more memory (ram) There are of course many variations (it's freescale!). Plus I have used them before, and also the MQX operating system is pretty lightweight and has an ethernet stack and SD card file system stuff already.

But I agree, software can be more work than hardware, hence the hope to start with something compatible with software that works already.
Did I mention that I wonder if anyone has had success with the smoothie board and software????

[Polygonhell]

My personal preference for cortex M4 right now is the STM32F407 or 417.
The discovery boards are pretty awesome for prototyping, the packages available are pretty amenable to DIY, and the GPIO support is better than the LPC etc.
A couple of people are running smoothie boards, I haven't looked at the code, but porting Smoothie, is probably not a huge deal, doing things like changing tit to support Ethernet as input on the other hand might be.
You can get toy firmware up and running pretty easily, the one I wrote took a few weeks from scratch, including writing the Ethernet driver, but it's nothing like as full featured as any of the existing firmwares, there is a lot of work in firmwares like repetier/Marlin etc.

[Tonkabot]

My personal preference for cortex M4 right now is the STM32F407 or 417.
The discovery boards are pretty awesome for prototyping, the packages available are pretty amenable to DIY, and the GPIO support is better than the LPC etc.
A couple of people are running smoothie boards, I haven't looked at the code, but porting Smoothie, is probably not a huge deal, doing things like changing tit to support Ethernet as input on the other hand might be.
You can get toy firmware up and running pretty easily, the one I wrote took a few weeks from scratch, including writing the Ethernet driver, but it's nothing like as full featured as any of the existing firmwares, there is a lot of work in firmwares like repetier/Marlin etc.

So, do you think porting one of the AVR based firmwares to the ARM would be worthwhile? Doable in reasonable time?

[Polygonhell]

So, do you think porting one of the AVR based firmwares to the ARM would be worthwhile? Doable in reasonable time?

Repetier has an arm port for the arm based Atmel CPU's, so it probably wouldn't be too bad a port.
In general it's probably a lot of work and not necessarily the right long term solution. Many of the ways the problems are approached in existing AVR based firmwares are because of the limited CPU budget (the delta implementation being a case in point), repetier for example has the ability to output multiple steps per interrupt, but that results in an uneven pulse train. The bulk of the features are controlled inline with #defines, which makes figuring out what's actually being compiled painful.

All of the existing firmwares I am aware of are based on grbl although they have diverged a lot from the original code base.

They all bit bang the step pin, which could be a problem with faster processors, especially if you want to use an alternative stepper driver, it turns out with the pololu drivers and similar it's not really an issue, despite what the datasheet says, according to my scope at least they seem to trigger on transition to logic 0 and the pin never has to actually reach logic 1. i.e. even at 70Mhz, you can toggle the pin on and off and it's enough to trigger the driver to step, that might not be the case at faster speeds.

If your looking to build something which is superior I'd probably look at the smoothie code as a starting point, there is at least some effort to make things modular, which ought to make porting easier.

[Tonkabot]

If your looking to build something which is superior I'd probably look at the smoothie code as a starting point, there is at least some effort to make things modular, which ought to make porting easier.

Ah, I looked at your blogspot and the ARM motion control part 1 and 2 were an interesting read.
I had an idea last night that I'll be working on , but I think it solves not only the various speed and accel issues for syncronizing many steppers, but actually allowing many distributed steppers to be syncronized.
I have to keep thrashing out how to do that, but reading your blog entries make me feel like I am on the right track.

Another memory that your blog tweaked was fast forward differencing, a technique I heard about many years ago (like 1980). I looked it up and here is one of the first links I found on it: http://www.scratchapixel.com/lessons/3d ... ferencing/
It was something that the original silicon graphics machines had microcode (machine language instructions) for, and is a way to precompute curves so you can step them out without floating point.
(and the divides are by 2 or by 6, which are quickly done with a shift or two shifts and a subtract).

Actually I just looked at that link more and I think they are making it sound more complicated than it is - however it looks like they cover the theory behind it first - you can see the code near the end is pretty simple.
I wrote a screensaver in the days before floating point using FFD, and it was pretty impressive how fast you could draw curves, versus say just using bresinghams line algorithm.

[Polygonhell]

Sure you can do any degree of curve with enough DDA steps, the issue very rapidly becomes setup.

The real advantage that Bresenham has is that it requires no divides at all including setup, a basic fixed point DDA requires no division while drawing (just a shift to get the output position), but it requires one divide for setup. Bresenham basically removes this by multiplying through and accumulating an error term. You can do the same basic thing for Arcs, but you have to deal with the reflected quadrants independently.

My Toy driver works pretty well, and will support arbitrary numbers of axis, it has a cool continuous jog from the touch screen as well. I do try and ensure all the step pins are on a single GPIO port, because I can write them all with a single instruction and get 0 Skew but that's more me being anal than a necessity for the application. The only critical part though is dealing with acceleration, you have to be careful that the acceleration doesn't introduce errors between the axis. The "easy" way to do that is to scale the base interrupt rate rather than trying to adjust step spacings independently on the axis, it keeps the line/arc algorithm from having to deal with none linearities and differing rates of error accumulation.

There is a secondary issue, with none linear systems like delta bots, ideally for 3D printing the firmware should apply velocity and acceleration restrictions to the carriage motion rather than the effector motion, because in general that's the mechanical limitation. Current firmwares do this as a side effect, because they break down the delta moves into many small linear moves then execute those. My intention was originally to directly evaluate the requires moves (they are all basically rational quadratic curves for linear motion of the effector), but if you do this applying velocity constraints to the carriage motion is actually hard.

Implementing various curves seem like a good idea until you try and figure out where they come from, obviously GCode only supports lines and 2D circular arcs, but even without that restriction, STL only supports flat polygons and even if you went straight from the source format, the types of arcs supported by varying modeling packages aren't consistent.

[Tonkabot]

Okay. It was just that you triggered my memory of the Fast forward differencing stuff. Of course if the G-code doesn't have curves it would not be useful here.

How does the current repieter (I can't spell, and spelling words I can't pronounce is even worse ) do steps?
does it stack 4 step and direction pairs into one byte wide IO port and then interrupt every time one of the values should change?

So is the step rate limited by timer interrupts and such? I am trying to get a handle on how it is currently done so I can tell if my idea would be better, worse, or the same.

[Polygonhell]

Okay. It was just that you triggered my memory of the Fast forward differencing stuff. Of course if the G-code doesn't have curves it would not be useful here.

How does the current repieter (I can't spell, and spelling words I can't pronounce is even worse ) do steps?
does it stack 4 step and direction pairs into one byte wide IO port and then interrupt every time one of the values should change?

So is the step rate limited by timer interrupts and such? I am trying to get a handle on how it is currently done so I can tell if my idea would be better, worse, or the same.

Haven't looked at it in a while but basically there is a timer interrupt at about 16-20KHz, it basically sends the steps, if multiple steps per interrupt are enabled (I don't believe they are by default) it basically loops instead of paying the interrupt overhead for each one.
Outside the interrupt it basically reads the USB port, updates the Hotend output, updates the display and preps moves and queues them for the interrupt. Delta moves are also broken down here, G2 and G3 are also dealt with the same way as the delta moves, hough no slicer I'm aware of outputs them.

Maximum rate is a function of the code in the interrupt, and the associated overhead, but it's more complicated than that for a delta printer, if the interrupt is called to often it starves the code breaking down the moves into small line segments, and you get jerky motion.