Marlin Firmware on propeller ?
Igor_Rast
Posts: 357
Anybody ever tried to port the marlin firmware for running 3D printers over to an propeller ?
Suppose to run on an arduino
Igor
Marlin
https://github.com/ErikZalm/Marlin
Suppose to run on an arduino
Igor
Marlin
https://github.com/ErikZalm/Marlin
Comments
Im currently building an opensouce Pick&place / 3d printer named FirePick Delta
There is allot of info on the github pages about the build and the project, and a google groups where the chatting happens.
Anyway. Its been kinda a standard that when a diy 3d printer is build, u use a RAMPS board.
althouth this works , we have made a custom board to push the edge a bit (20MHZ clock on an atmega1284p) an it looks a bit better.
But beeing a delta robot , its having a hard time with the calc. something I think the propeller can handle pretty good.
the special part is that the prop can do it in parallel . where with the atmega its one after another. at high speeds it does matter.
We have a working board now so its not the fist thing to get done.
But if I could get some help to port the Marlin code over a bit , some things will need to change after all .
I could turn out a board to test out how that works.
it may be a big place for propellers to get used. Plus we get a faster board that can better handle the calculations.
Big questions still , I would love to hear some advice on it .
Some foto , Links cause they were too big
https://plus.google.com/u/0/photos/104321386040779156964/albums/6088844932089724721/6088844934836363970?pid=6088844934836363970&oid=104321386040779156964
Some info on pics of mu build(not completed yet)
I have been wanting to get the prop to do 3D printing for a long time. I have done pcbs and have built most of a smaller scale Prusa I2. A couple of weeks ago I bit the bullet and ordered a Ramps board so I can at least get this printer running as I have all the parts. Then maybe I will find the time to port the software.
Looking forward to following your progress, and perhaps I might just find some occasional time to help.
What a great looking delta you have there.
After a quick look over the Marlin repo what would worry me is that the shear amount of code is too much for the Propeller. The first thing I would do is get the thing compiled with propgcc. Provide empty stubs for any external library functions if it need them to link correctly. Whatever, just get it compiled and check the size of the code.
If it won't fit in the 32K of the Props HUB memory I would give up. One can use external memory with propgcc but that is going to be really slow.
And we can do even better!
I do agree.
If wrangling Propellers is your hobby, which it is for many of us, then by all means have a go. We attempt all kinds of crazy stuff around here.
However if your hobby is something else, like getting delta bots to work nicely, then there are a ton of things to consider to make the compute part as simple and painless as possible.
If the code is big and it's C and it's a monolithic single CPU single thread affair then running it on a Prop with external memory will perhaps be too slow to bother with. Splitting it up over multiple Props will be "interesting" but will also end up with a slow system.
The Prop is great if your code can be be split into 8 tiny parts that can be run in COG and need intimate interfacing to the outside world. Or split into more tiny parts and spread over COGs in additional Props.
As soon as your code needs more space it ends up in hub and execution speed drops by at least a factor of four.
If it needs more than 32K space then you are sunk speed wise. Adding external memory drops speed by another factor of 4 or 8 and partiioning over Props is going to need communication overhead.
All in all it might be easier, quicker to develop and faster in execution to port the thing to an ST32 F4. Which is also very cheap.
Horses for courses and all that.
In our main form a guy named Joshua did some speed check on some different controllers and posted the commands .
The speeds look
As a follow up to discussions the other day about floating point speed on various MCUs, here are some tests running 100,000 iterations of the calculate_delta() function from Marlin:
Arduino 2560: 23,807 ms [1]
Intel i7: 1.1 ms
RPi Model B: 20 ms
Allwinner A10: 50ms [2]
NXP LPC1768: (ARM Cortex M3 @ 100 MHz): 3,321 ms
STM32F407GV: (ARM Cortex M4 @ 168 MHz): 3,467 ms [3]
Unfortunaty He did not do a prop test
The Marlin code is indeed kinda big , that was what I was mostly afraid of.
I would try to make a start to port it in a few days. but ill see what the other guys on the form are also saying
the delta It goal is kind to not make it super expensive , but it does need to be able to handle smooth stepping
SO I think to use 2 propellers will probably not be the best idea. Do know its gonna work.
Started as a low buget pick & place machine, but we missed the hackaday price it was competing for
so now its kinda lost the lowest price motto, and going for the one machine does it all solution with most thing handled is softwarre
If you guys are intersted i Would say take a look over at the FirePick pages
CPU speed post --> https://groups.google.com/forum/?hl=en#!topic/firepick/h1MVTFuol6I
Github --> https://github.com/firepick-delta
Google Groups --> https://groups.google.com/forum/?hl=en#!forum/firepick
Official site --> http://delta.firepick.org/
Igor
It mostly depends of what you mean by Arduino code.... Uno, Duo, or whatever.
Even then, it depends on what you mean by Arduino code.... code written specifically and solely for an Arduino, or code written for an AVR that has been ported to some sort of Arduino or code that by-passes the Ardunio compiler completely and just loads to the hardware.
My own experience earlier this year with trying to port Teacup resulted in a merry chase as the range of topics expanded just because an Arduino is not just one device or just one approach to code.
My conclusion was that most code was coming at Arduino from so many different directions that a simple port of C++ code to a Propeller 1 might very well be impossible. I held out hopes that a Propeller 2 would fill the bill, but I have not seen the Propeller 2 get close to being a reality.
Marlin code and many other 3D printer codes may indeed be just too larger to fit a Propeller 1. Features in the code have apparently outgrown the space in an Arduino Uno and it that board is not supported, the code may require 256K or larger program storage inclusive a ample RAM.
Of course, there are people here that might find a way to make GCC on a Propeller 1 handle the job with clever use of an SDcard or other phyical memory extensions. I am just not that savy to do so.
Well to be honest I am a tru newbie on the arduino thing. Have used the prop to do all kinds of small things but the marlin driver is kinda new a big app to get to know how it works fast.(im working on that)
The thing is , to speed up develpment for the pick and place machine it was chosen to go with an already working platform, (Marlin)
This setup was the marlin driver with a ramps board.
to juze things up a bit , there was a custom board made , usning an atmega1284p with an 20MHZ clock , on a custom board.
steppers used are pololu DRV8825
THings have been ported back and fort for the firepick marlin fork of the code, and marlin has been run on a few different arduino s if I can remember ( havent followed the arduino movement duo to using the propeller) so it seems its not just an arduino thing
custom bootloader etc. So I think it works in most AVR (globaly thinking).
but thats still having a hard time with the added delta calculation (inverse kinematics )
https://github.com/firepick-delta/Marlin
https://github.com/firepick-delta/Marlin/blob/dev/Marlin/Marlin_main.cpp#L2584
we are working on offloading the calculations to a host pc that will be connected to the delta , kinda solves that problem
but I stil wonderd what the prop could mean. meaning delta calculation can stay in the microcontroller , no connected host needed.
The sheer big size of the marlin is indeed an issue , but due to it beeing an code to kinda work on all the things with an xyz axis , just adjust the settings
you can get rid of allot of unused data. but splitting it up among the cogs does need to happen , off cource this was the hole idea to get each axis delta cals in a different cog running in tru parallel.
Igor
There is something really strange about the results you have posted.
I can well believe that a Pi is ten or twenty times slower than an Intel desktop CPU. I have seen that many times myself with different programs.
What I find hard to believe is that an 168MHz STM32 F4 is 170 odd times slower than a Pi.
A slow down proportional to clock speed plus another factor of 2 or 4 due to architecture I could understand.
I'm not saying it's a wrong result but it is surprising enough that I might have to check for myself.
Either way the Propeller will be off the scale on slowness here. As soon as you talk about floating point in the Propeller you are stuck in the mud.
that was what i also was thinkin, but if an 8bit controller can do it the prop must be able
ether way its looking to be way more work to get working on a prop than something else faster
its gonna be some time before i try some of it out cause i already have a working board now
but thanks for all the info guys
Igor
P.S. I cant vouch for the numbers , its a copy past from the other form, havent seen exactly how he determined those either .
think of it as a starting point
I have always thought the prop could shine here. After all, it should be better than an ATMega providing the code can fit into memory. The actual running commands can be held on a file on an SD card and the prop can handle this easily.
So the idea would be to split the "common" routines out into cogs and do it in pasm.
The floating point calculations are just one issue in competitive 3D printing code. If and when the Propeller 2 arrives, 3D printing on a Propeller may catch up. But trying to deploy a Propeller 1 to do what the larger Arduino boards now do is never going to happen.
BTW, there are simple ways to avoid floating point in 3D printing. You are going to have to pre-compile a printer file that provides slices.... all the data could be converted from floating point to actual integers. But that plays havoc with some of the other down-stream sophisticated 3D printer features; such as acceleration and deceleration of the print head.