Welcome! Log In Create A New Profile

Advanced

I don't think Marlin is optimally coded.. and here's why

Posted by thetazzbot 
I don't think Marlin is optimally coded.. and here's why
June 12, 2015 01:18PM
I've read a lot about "32 Bit is the only way to go because the 8 bit micros can't handle the math"

But the truth is, and having looked through the Marlin code, the code itself is poorly written and does not utilize any assembly language routines at all, and no math optimizations.

There have been numerous articles written on using floating point calculations on the 8 bit micros and getting much faster times using optimized assembler instead of straight C math operators. These algorithms use bit shifting instead of standard multiplication and division operators.

Additionally, it would have been a better design architecture to offload the SD Card and LCD support onto a secondary AVR (doesn't have to be a mega) and use I2C to communicate at 16mhz. you would also save on pins (which simplifies wiring)

Looking at the electronics landscape, it seems that $100 min. is the buy-in for 32 bit boards. The Azteeg X5 has built in stepper drivers which is good. But! only has four steppers, so no dual extruder.

The existing Ramps+Arduino+Polulu sandwich is $30

Although I really don't like the Ramps sandwich, it is dirt cheap.

Yes, naturally 32 bit faster better stronger but really we're talking about code bloat. Programmers that really aren't skilled in the art of writing for small micros end up wasting memory, cpu cycles, etc. The question then is, if the code were optimized for the math, would it negate the "need" for 32 bit cpu architecture...

When you're building printers to sell, these type of costs are important barriers.

Edited 1 time(s). Last edit at 06/12/2015 01:19PM by thetazzbot.
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 01:58PM
Another though... the host should calculate all this math and just pass the numbers to the board to convert to pulses for the steppers. Truth is the board should just be a digital to analog converter.

But then again.. Gcode is a sorta standard and thats a good thing. Better to have choices across software and hardware ratther than locked in to a software that works only with x hardware

Edited 1 time(s). Last edit at 06/12/2015 02:05PM by thetazzbot.
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 01:59PM
So you know about teacup right?

[reprap.org]

There are plenty of choices, so you can pick one that suits. My best guess is that it isn't worth the effort of optimizing Marlin just as the the world is moving to 32 bit.
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 02:07PM
Right but were talking about costs. While one board is $100+ for one printer what if youre building 100 printers.

Ack. No i didnt know about teacup... Thanks for the tip...

Edited 1 time(s). Last edit at 06/12/2015 02:08PM by thetazzbot.
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 02:40PM
A few points:

1. There are 32-bit boards costing less than $100. For example the Duet costs $80 from Replikeo, and the AZSMZ Mini costs $65 AFAIR. Both have on-board SD card socket and native USB (not USB-over-serial as on Arduino/RAMPS). The Duet also has Ethernet and 4 drivers on board. RepRapPro are using it in their £199+tax delta printer kit.

2. There is scope to manufacture a 32-bit board at less cost than Arduino/RAMPS, if the volume ever got high enough. The Arduino Mega uses a relatively expensive processor, costing around double the price of a more capable 32-bit processor, and contains some components that would not be needed on a dedicated 3D printer controller board. I have a budget 32-bit design on the drawing board, which I may get to finish one day.

3. Even with additional optimization, I doubt whether the 8-bit Arduino would have enough processing power to run a delta printer well.

4. While it is generally possible to hand-optimize code to run better on a processor that is inadequate using un-optimized code, there are far better uses of developer time. For example, earlier this year I implemented segmentation-free delta movement and precise delta auto-calibration using a single set of probe points. These were only possible because I had processor power to spare and I didn't have to spend too much time optimizing code.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 02:41PM
I believe 32-bit boards are still in the $80+ range because the demand for them is so small still. Supposedly components wise, they are cheaper to manufacture then 8-bit boards. The difference is that China is full of factories producing low-quality 8-bit boards. Quality built 8-bit boards are still in the $80+ range.

You are probably right that there is room to improve the coding of Marlin. I think there is even a project on-going to clean up the code if not also to optimize some of it. However, the only printers really pushing the limits of 8-bit hardware right now are Delta's and possibly CoreXY users looking to max out their print speeds.

32-bit development is more about evolution and cheaper processors then it is about the limits of 8-bit processors. At least in my opinion.
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 02:48PM
Cost isn't really a great way to compare 8 vs 32 bit. Modern boards have more features and higher build quality.

The 328 is ridiculously expensive for its capabilities and the only reason it is even in production is due to hobbiest demand. Modern 32 bit chips are cheaper and orders of magnitude faster.
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 03:19PM
Yeah thinking more about it, the longer we try to keep the 8 bit paradigm alive, the slower we adopt the 32 bit paradigm.
Re: I don't think Marlin is optimally coded.. and here's why
June 12, 2015 03:32PM
Quote
Kurzaa
I believe 32-bit boards are still in the $80+ range because the demand for them is so small still. Supposedly components wise, they are cheaper to manufacture then 8-bit boards. The difference is that China is full of factories producing low-quality 8-bit boards. Quality built 8-bit boards are still in the $80+ range.

I agree. I think the main reason is that the kit manufacturers are nearly all still shipping Arduino/RAMPS with their kits, probably because it is cheapest. RepRapPro are showing the way here, they have now changed all their kits over to 32-bit electronics.

Edited 1 time(s). Last edit at 06/12/2015 03:33PM by dc42.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: I don't think Marlin is optimally coded.. and here's why
June 13, 2015 07:05AM
Quote
thetazzbot
I've read a lot about "32 Bit is the only way to go because the 8 bit micros can't handle the math"

That's a phrase owners of 32-bit boards like a lot, obviously. Fact is, there are printers, like Deltas, which can take advantage of faster MCUs. Fact is also, for a straight bot, like e.g. an i3 with 1/16 microstepping, ATmegas are simply fast enough.

Quote
thetazzbot
But the truth is, and having looked through the Marlin code, the code itself is poorly written and does not utilize any assembly language routines at all, and no math optimizations.

I don't think the amount of assembly language is a good indicator for optimisation. C compilers are very good and it's also possible to measure the resulting performance.

For example, this series of taking measurements nicely show how the best performing code is found: [github.com] [github.com] [github.com] [github.com] [github.com]

Quote
thetazzbot
There have been numerous articles written on using floating point calculations on the 8 bit micros and getting much faster times using optimized assembler instead of straight C math operators.

Teacup firmware uses not floats at all, they're slower and less accurate. Floats have a precision of 23 bits, integers have 31 bits. Other firmwares use floats only in the less performance critical parts, like G-code parsing.

Quote
thetazzbot
Additionally, it would have been a better design architecture to offload the SD Card and LCD support onto a secondary AVR (doesn't have to be a mega) and use I2C to communicate at 16mhz.

Firmwares have to use the hardware available. A few years back ATmega based controllers with 20 MHz instead of 16 MHz appeared. They got almost no attention, because these Arduinos are so extremely popular. A 25% performance gain for free caused probably not a single printer owner to swap his controller. People are not exactly performance aware, as long as they can say "it prints".


Quote
Kurzaa
The difference is that China is full of factories producing low-quality 8-bit boards. Quality built 8-bit boards are still in the $80+ range.

Exactly. And these factories need a "standard", something they can safely assume to get the boards sold.

The RAMPS design is actually pretty costly, with all the connectors, useless tracks and the double PCB. A Sanguinololu would be quite a bit cheaper. But Sanguinololu lacks the "extremely popular" tag, so it's no choice for the cheapo mass manufacturers. The landscape of 32-bit boards is even a lot more fragmented, so it's unlikely we see a cheapo one soon.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: I don't think Marlin is optimally coded.. and here's why
June 13, 2015 07:20AM
Quote

The landscape of 32-bit boards is even a lot more fragmented, so it's unlikely we see a cheapo one soon.

However the market for the generic arduino boards is much larger, so we already see cheap Due clones. Eventually it seems likely that a clone Due +shield +lcd setup will come to dominate the cost sensitive part of the printer market.
Re: I don't think Marlin is optimally coded.. and here's why
June 13, 2015 11:41AM
I personally like the AVR32 architecture. Traditionally Atmel designs require fewer external components and they have a single instruction cycle for everything except certain float multiplications which are two cycles. This nets the AVR 3 to 5 times the speed of Arm3 in raw cycles. Add in the numerous PWM channels and timers, and overall for the purpose at hand it seems ideal. The established embedded development comcommunity Atmel has built up is immensely useful.
Re: I don't think Marlin is optimally coded.. and here's why
June 19, 2015 06:22AM
Ramps-FD shields aren't that expensive anymore, neither are Arduino Due boards.
And if you want to have it even cheaper, it's not that complicated to convert a Ramps shield to 3.3V.
Re: I don't think Marlin is optimally coded.. and here's why
June 19, 2015 07:34AM
What's the status of the RAMPS-FD boards? I seem to remember reading that there were problems with them - or maybe I'm confusing it with a different board. Is there an LCD+SD that works with it to give a complete replacement for a mega2560/ramps/lcd+sd setup?
VDX
Re: I don't think Marlin is optimally coded.. and here's why
June 19, 2015 07:47AM
... have you seen the RADDS board?

I have one with LCD for testing with Marlin4Due, but not for a RepRap-configuration ...


Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]
Re: I don't think Marlin is optimally coded.. and here's why
June 19, 2015 07:52AM
Quote
JamesK
Quote

The landscape of 32-bit boards is even a lot more fragmented, so it's unlikely we see a cheapo one soon.

However the market for the generic arduino boards is much larger, so we already see cheap Due clones. Eventually it seems likely that a clone Due +shield +lcd setup will come to dominate the cost sensitive part of the printer market.

That may happen. I prefer the all-in-one 32-bit boards because they offer additional features that I wouldn't be without, such as digital stepper motor current control and a web interface. The prices are coming down, for example Duet costs $80 from Replikeo, and some of the Smoothieware-compatible boards cost even less.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: I don't think Marlin is optimally coded.. and here's why
June 19, 2015 12:37PM
Quote
thetazzbot
I personally like the AVR32 architecture. Traditionally Atmel designs require fewer external components and they have a single instruction cycle for everything except certain float multiplications which are two cycles. This nets the AVR 3 to 5 times the speed of Arm3 in raw cycles. Add in the numerous PWM channels and timers, and overall for the purpose at hand it seems ideal. The established embedded development comcommunity Atmel has built up is immensely useful.

Following up on my own thread...

So, I had a lengthy conversation with guys at avrfreaks about AVR32/AT32UC3 chip vs Arm. Naturally there are ARM Fan boys, just like there are Smoothieboard/Duet fan boys here, but the general consensus is, industry-wise, ARM is the current and future of 32 bit microcontroller architecture. It seems overkill to me, but not everyone has the same needs.

For example, I don't need ethernet on my printer. I also don't need a touch screen lcd panel. Nor wifi. Probably not a web interface. I could use my raspberry pi with Octoprint for that.
All I really need is it to print smoothly and not cost me an arm and a leg. Now, for anyone that does not have a delta, this 32 bit discussion is of no use, because really you aren't going to need that horsepower for cartesian/corexy/hbot printers. What it really boils down to is a software problem, not a hardware problem.

You'll read people saying that the Atmega256 is running at max, but how do they measure that? What proof do they actually have? I know the math routines in Marlin need work. Teacup addresses that. But Teacup lacks way behind Marlin in features. I'm sure Teacup author is going to address that or maybe needs additional developers to pitch in.

Most of us at a minimum need an LCD, SD Card reader, and smooth printing on Deltas. Just because I have a Mini Kossel doesn't mean I want to spend $200 for dual extrusion controller when I have that already with Arduino/Ramps for < 50 because I don't need to print at 5 million mm/s smiling smiley

Edited 1 time(s). Last edit at 06/19/2015 12:38PM by thetazzbot.
Re: I don't think Marlin is optimally coded.. and here's why
June 19, 2015 04:57PM
Quote
thetazzbot
Now, for anyone that does not have a delta, this 32 bit discussion is of no use, because really you aren't going to need that horsepower for cartesian/corexy/hbot printers. What it really boils down to is a software problem, not a hardware problem.

This isn't really true. The reason why it seems to work great on 8 bit controllers is because a huge number of optimizations and shortcuts have been used.

The entire acceleration implementation in GRBL is a hack and the maximum step rate is pretty awful. There is also more jitter than you would get from higher performance solutions.

The effect of these issues is hard to quantify but I suspect that together they create a material affect on print quality and speed.

Unfortunately most 32 bit boards are based on GRBL trajectory planning so you need LinuxCNC or similar for proper acceleration.


I can't really tell what you are arguing against. In 5 years it is incredibly likely that the base arduino model will be 32 bit and the Chinese will be pumping out 32 bit 3d printer controllers for even less than they cost today.

Edited 1 time(s). Last edit at 06/19/2015 04:58PM by 691175002.
Sorry, only registered users may post in this forum.

Click here to login