Welcome to the SeeMeCNC Community

Who's got two thumbs and just put his money in for an ARM board?

*THIS GUY*


http://www.kickstarter.com/projects/log ... on-control

December (hopefully no delays) can't come soon enough.

Gotta believe that it will help unleash the full potential of the MAX.

I'm very interested to see how the next year or so pans out for new, specifically Delta-related, controller boards. There are so many possible offerings right now it's a bit hard to choose.

Personally, I'm betting on the BeagleBone (Black) with one of the CNC capes. I've just ordered a BeBoPr+ for mine. Using LinuxCNC offers so many more potentials than a fully embedded controller due to its Hardware Abstraction Layer and Python scripting abilities.

cope413 wrote:Who's got two thumbs and just put his money in for an ARM board?

*THIS GUY*


http://www.kickstarter.com/projects/log ... on-control

December (hopefully no delays) can't come soon enough.

Gotta believe that it will help unleash the full potential of the MAX.

What is the advantage of these boards over the Rambo besides they run faster?

What about the Arduino TRE? 1Ghz, full linux, and print from the board itself. All in one solution.

Eaglezsoar wrote:What is the advantage of these boards over the Rambo besides they run faster?

Are you sure you want to ask me? Haven't you seen how much I type?

For Deltas, because the coordinate system which is used to describe the motion of the end effector does not match the coordinate system of the actuators, we need a transformation that involves A LOT of trigonometry with nearly every step. This is very taxing on an 8 bit CPU. Well, not every step, but the more times you can convert the Cartesian coordinate position into the Delta coordinates, that is, the position of the carriages along their axis, the smoother your motion will be. Do you recall ever seeing the preprocessor defines, DELTA_SEGMENTS_PER_SECOND? This tells the firmware how many times per second to convert from Cartesian to Delta coordinates. Ideally we want this number at infinity so that there would be essentially no difference between the two coordinate representations, as far as the motion is concerned. The number was presumably chosen by Johann at 200 to be a trade-off between smooth motion and the processing capabilities of the Arduino. Practically, there is finite value of diminishing returns that would provide the optimum conversion rate, based on the physical limitations of the steppers and other machine aspects. This limitation is one reason why the motion becomes a bit less smooth at higher speeds, because for each unit of distance the effector moves, the fewer times the carriage positions have been properly computed.

Each time you want to convert between coordinate systems, which is in a routine called something like calculateDeltaPositions(), three double-Pythagorean-theorem calculations are performed (this is my term; what I mean is that two right triangles are solved, where the result of the first is substituted symbolically into the second). Each of these computations requires calls to the square() and sqrt() functions, which are basically multiplications. Because we're tracking steps, we need big numbers, or long integers (as Repetier uses; I think Marlin uses floats to track millimeters). These are represented as 32 bits, which take four 8 bit bytes to fully store. So, every time a multiplication is performed, some complex substitution in and out of several registers is required to cover the entire 32 bits of each number. This takes something like 30+ clock cycles for each multiplication (I may be way off, this is coming from old, dusty, memory...my point is, it's a lot).

Hopefully you are starting to see why the increased power is exciting for the advances of the Delta platform.

All of the ARM offerings are 32 bit architectures. This means we can do all of these math steps in fewer clock cycles in addition to just plain faster. Go even further and you'll see that the chips that Texas Instruments are offering come with an additional processor called a Programmable Real-Time Unit (PRU). The PRU can be, ready?...programmed...to handle time-critical tasks, which is excellent for step generation, providing yet another improvement lending to smoother motion. Something like a PRU won't just benefit Deltas, though, because it could be used to improve the acceleration routines in general, something that inertia dominated machines like most Cartesian bots need.

So we'll be able to have much more complex supervisory motion planning, resulting in smoother motion. Native arcs? Sure, if the slicers can detect them. Complex, speed and temperature based extruder control? Absolutely, and we all have seen how much this could make a difference in print quality. Blended, "RGB" style extruders (aka Rich-Rap)? Yes again. Have you ever considered the idea of more than 3 axes of motion for the print head? Yet again absolutely possible, with the only "real" restriction being the slicing software.

I've been parroting the term LinuxCNC because of its modularity and massive customization potential. I've used it on a couple of larger CNC machines and it is as good as any CNC controller I've personally encountered (I'm not talking machining centers, but simpler CNC vertical mills and lathes). It already has a stable and well tested GCode processor and motion planner. Some 3D printing-related functions are probably missing, but with the ability to create ladder logic or scrips using arbitrary input devices, all of that becomes very easy and very pluggable.

lordbinky wrote:What about the Arduino TRE? 1Ghz, full linux, and print from the board itself. All in one solution.

I saw the TRE announcement today myself. AFAIK it is the a very similar processor to the BeagleBone Black, including the PRU. That means it should be quite simple to get a full blown RTOS on it and use LinuxCNC. Even better because it has the standard Arduino shield pinout, in addition to something like 48 additional. Plus ethernet, USB host, and HDMI out. For the chips operating at those ~1GHz speeds I think you will absolutely need an operating system, as bare-metal programming just won't make full use of the power available, and is quite a bit more complex.

cope413 wrote:Gotta believe that it will help unleash the full potential of the MAX.

I would say you are correct. The Delta platform is ripe for performance gains due to motion control improvements.

^^^Again what I would have gone along and said although perhaps not as well stated.

The only and largest roadblock here is that whatever happens we will need delta support. Not all of the newer boards coming down the pipe will have delta support. Atleast not from the getgo.

Edward, that was a great writeup and I even understood most of it (for once).
Thanks for the lengthy explanation.

This is the best way, without getting into the math and all of that fun stuff, to explain the difference between an ARM board and all the 8-bit boards driving printers right now...

8-bit boards....
ARM Boards...

Did you draw those? They're great!

They are great, but I cannot take credit for them.

http://smoothieware.org/howitworks

Is this going to produce some improvement where I can print something with a RAMBo and something else with a Smoothie board and be able to point out specific, unambiguous improvements in the latter? That might make it worthwhile.

Absolutely yes. It may not be on every print (I can't imagine there will be a noticeable difference on a calibration cube if you have your printer tuned to print that within 50 microns or so), but certainly on prints with complex/detailed movements and/or arcs. It will also increase the speed of the printing while allowing for the same, if not higher, precision because of the superior acceleration planning.

Is there any hard evidence of this? I don't mean to bust your chops, I just want to make sure I'm not farming money into something that says it will do X!!! but actually just does x. (But if it actually delivers on these promises, I will get one.)

You guys are the heavy hitters and have the understanding. Would you agree with me in that the average 3D printer user should wait until these ARM cards have been on the market for awhile
and the bugs worked out?

Eaglezsoar wrote:You guys are the heavy hitters and have the understanding. Would you agree with me in that the average 3D printer user should wait until these ARM cards have been on the market for awhile
and the bugs worked out?

Unless they want to pick up another hobby for their 3D printer, correct.

For me it's sorta a performance thing.

I am disappointed that most of the current hardware developments have been to try to make things cheaper, but not really a measurable improvement in performance while maintaining quality.

Physical hardware limitations aside (arm choices, sloppiness etc) the electronics and controllers going cheaper is not what I am after. I would far more prefer to pay 2 or 3 times more for a controller that has more overhead power, and does not bog down, empty is cache, end up waiting for comms, over heat easily, not be modular (for replaceable subsystems that fail). My current favorite choice is the AzteegX3 with it's viki LCD panel. It uses different USB chip for its comms, is very nicely built. But in the end it is esentially a glorified Ramps board with nicer wheels on it. Not a real leap forwards. Arm controllers should be a real genuine leap forwards.

Good things are coming however, I just hate waiting, LOL.

Well said. As I've mentioned I have the BeagleBone Black already and BeBoPr+ bridge in the mail. I expect quite a bit of work to get it running, even with the pre-made images available for that platform.

Bleeding edge is never plug-n-play.

Edit: Missed 626pilot's earlier question.

626pilot wrote:Is there any hard evidence of this? I don't mean to bust your chops, I just want to make sure I'm not farming money into something that says it will do X!!! but actually just does x. (But if it actually delivers on these promises, I will get one.)

Hard evidence? Not really; probably not yet. These controllers are still so young that there isn't a very large sample size beyond the board developers. Even more immature is the software. But, for those familiar with the 8-bit AVR architecture they will simultaneously respect and awe the performance achieved with the current firmwares. There is *no* room left for motion control improvements, not on the order of those capable with significantly more processing power. I suppose an absolute "No way!" isn't the best response, but at least not without completely abandoning the current block buffer planner and developing something else (I'm not suggesting that alternative, it's just that I quite familiar with the block buffer method and it is maxed out). You can try to push things more, but my bet is that you will very soon start to run into timing issues (i.e., stuttering), as there isn't any kind of "real-time" supervisor, just several approximated internal timer interrupts (that obey an unchangeable priority list) controlling the step generation. The main interrupt routine is already quite large, flying in the face of nearly all good programming practices w.r.t. interrupt routines.

Some of us look forward to experimenting with these sorts of things. If you aren't comfortable providing feedback to a developer, that is more than "My printer doesn't work...," and/or modifying the firmware yourself, I would suggest that you be content with your current AVR setup. Maybe consider getting an Arduino DUE and trying that on the 0.90 development version of Repetier as the core firmware isn't too much different. Problem there is, even though it is pin compatible, the RAMPS board isn't 100% electrically compatible as it was designed for 5V TTL and the DUE is 3.3V, and while I think there is a DUE compatible RAMPS clone, I haven't seen where to get one.

Oh, and I just pushed my Rostock to 150mm/s (80mm/s jerk) and my problem with a single wall print is that it can't calculate enough points per second to keep up the speed and provide decent lines. *sigh* I'd go faster if I could!

edit: it's fine with cubes and simple geometries, but anything complex it is obviously taking a shortcut.

Let me put it this way. Do our steppers have enough resolution that something like this can give us nicer looking walls? There is always some kind of chatter going on, straight walls or curved, and the chatter changes when the layer configuration changes. If this thing has a shot at giving us smoother walls, then it would be worthwhile to upgrade.

The rule of thumb is to find the software that does what you want, then buy the hardware it will run on. Buying hardware the software doesn't exist for is pretty useless to most people, no matter how powerful it is. The exception would be someone who has the skills and motivation to port some existing software to that platform or write something new. Cost also is a factor, especially in the hobby industry, hence the popularity of open-source solutions.

626Pilot wrote:Let me put it this way. Do our steppers have enough resolution that something like this can give us nicer looking walls? There is always some kind of chatter going on, straight walls or curved, and the chatter changes when the layer configuration changes. If this thing has a shot at giving us smoother walls, then it would be worthwhile to upgrade.

I had for a short time swapped over my stepper on my machine to 400 steps per rev (0.9 degree step angle), switched back down to the 14 tooth (belt eaters as some call them) and run 32 microstep drivers all at once. This resulted in a firmware setting of 457 steps permm, compared to the stock values of 80 steps per mm for rambo 1.0's and 160 steps per mm for rambo 1.1's. So a significant resolution difference that even considering nozzle size and flow did show improvements.

I could infact get this setup to have a noticable improvement in print quality (oh these are also dual damped steppers as well which help in settle speed and smoothing as well, by dual damped I am referring to a shaft mounted damper as well and the damping isolator on the mount)

I had a few problems.

The smallest but not insignificant problem is that the stepper need more voltage and IMO will also have to be actively cooled in order to be run for longer time periods especially at higher speeds.

The second and not resolvable issue (yet anyways) is that at high speeds and with even moderately smooth movements the steppers ate through the buffer and drained it really fast. I might even guess that the buffer under-runs were occuring 4 to 5 times faster than before. (perhaps faster than this even)

With bigger simpler prints without sudden small closely pack movements things really cooked along nicely for a bit but even then underflows and heat would soon end the party.

So I have currently got my 32microstep drivers running the standard 200 step motors (1.8 degree) with the 14 tooth pinions. And my steps per mm are set at 228.57. I have been tweaking the firmware for some time now and yes I still hit that damned underflow that halts everything for up to 10 seconds while in the the hotend sits there drooling a blob until things get rolling again. But I can get some prints to go all the way through without the pausing. I also have totally removed my LCD from the printer. I save overhead and space used by the firmware to support it, I also have far fewer noise issues. I do however miss having it very often. The trade off would not likely be needed with better ARM hardware along with much more processor overhead for fast calculations and even more unthought of cool features that will undoubtably come along.

I have been very hyped on this topic for quite some time now, can you tell! LOL

Flateric: Are you printing from SD or over serial?

I find in my current setup I am doing fine strictly through the USB, although the Azteeg does have a microUSB onboard the main board that works nicely too. I still prefer the control USB and repetier host give me during the print.

I'd be curious if with those high resolution settings printing via SD eliminates the buffer issues...