How much effort estimated: porting GRBL-Soucecode to PropChip (in C or in SPIN)
StefanL38
Posts: 2,292
Hi,
somehow the propeller-chip is still the best...
I bought a small CNC-mill mechanic for milling wood and alu.
step/dir-pulse-creation is done by an arduino with GRBL-firmware.
GRBL is a quite good GCode-interpreter but still with some limitations.
These are: very simple acceleration formula. Not suitable for the combination of microsteps and high endspeeds
the acceleration-values jump out into space if you want fast acceleration making the steppers loosing steps
or if values are reduced takes much to much steps until endspeed is reached.
circular moves G2/G3 are interpolated by arc segments. You can setup the arc-segment-length to very small values (0.01mm)
but for milling a lot of arcs the feeding rate it slowing down a lot. I guess this is caused by the communication-process
Each line of GCode is send to GRBL at 9600 baud. GRBL sends an acknowledge back. Sending the next command waits for the acknowledge.
GRBL has a small buffer for GCode-commands (5 commands) to do ahead motion-planning. If the track to mill is build out of a lot of real short arc-segments
(created by the CAD-CAM-software) with changing diameter the slow datatransfer-rate slows down the whole process because the buffer can't be filled fast enough.
That's where the Propeller-Chip comes in:
The Arduino has only 2kB of RAM and has to use interrupts to do Pulse-creating and serial communication At 16 MHz.
The Propeller-chip with its 8 cogs at 80MHz can do communication in one cog at 115200 Baud.
optimized pulse-generation with very very small jitter using 3 synchronised cogs 1 cog for each axle (like ManAtWork posted a code-example)
Using a bigger command-buffer for better ahead-planning of acceleration/decceleration creating not only 30kHz step-pulses but 100 KHz or maybe even more
Now I myself has NO experience in C or C++. I'm a Delphi and SPIN-guy.
Could somebody with C-experience take a look into the source-code of GRBL and do a rough estimation how much work it would be to
a) port the C-code as C-code to a propeller-chip?
b) if there is a chance to port the C-code to SPIN and still have the more or less same computational speed like the Arduino?
I'm also not familiar with GitHub etc. If somebody could point me to that part of the GRBL-documentation where the concepts
and the math is explained I might can do the estimation myself.
Sure I could do it all myself. Learning optimised C, learning Arduino, learning how GitHub organises sourcecode etc. etc.
Just would take time (I guess 1 Year or so stopping all other things I would like to do)
But I think we are living in a world of divised labor. So for some experts on the fields involved here answering a question is "a peace of cake"
Thank you very very much already know for taking time.
best regards
Stefan
somehow the propeller-chip is still the best...
I bought a small CNC-mill mechanic for milling wood and alu.
step/dir-pulse-creation is done by an arduino with GRBL-firmware.
GRBL is a quite good GCode-interpreter but still with some limitations.
These are: very simple acceleration formula. Not suitable for the combination of microsteps and high endspeeds
the acceleration-values jump out into space if you want fast acceleration making the steppers loosing steps
or if values are reduced takes much to much steps until endspeed is reached.
circular moves G2/G3 are interpolated by arc segments. You can setup the arc-segment-length to very small values (0.01mm)
but for milling a lot of arcs the feeding rate it slowing down a lot. I guess this is caused by the communication-process
Each line of GCode is send to GRBL at 9600 baud. GRBL sends an acknowledge back. Sending the next command waits for the acknowledge.
GRBL has a small buffer for GCode-commands (5 commands) to do ahead motion-planning. If the track to mill is build out of a lot of real short arc-segments
(created by the CAD-CAM-software) with changing diameter the slow datatransfer-rate slows down the whole process because the buffer can't be filled fast enough.
That's where the Propeller-Chip comes in:
The Arduino has only 2kB of RAM and has to use interrupts to do Pulse-creating and serial communication At 16 MHz.
The Propeller-chip with its 8 cogs at 80MHz can do communication in one cog at 115200 Baud.
optimized pulse-generation with very very small jitter using 3 synchronised cogs 1 cog for each axle (like ManAtWork posted a code-example)
Using a bigger command-buffer for better ahead-planning of acceleration/decceleration creating not only 30kHz step-pulses but 100 KHz or maybe even more
Now I myself has NO experience in C or C++. I'm a Delphi and SPIN-guy.
Could somebody with C-experience take a look into the source-code of GRBL and do a rough estimation how much work it would be to
a) port the C-code as C-code to a propeller-chip?
b) if there is a chance to port the C-code to SPIN and still have the more or less same computational speed like the Arduino?
I'm also not familiar with GitHub etc. If somebody could point me to that part of the GRBL-documentation where the concepts
and the math is explained I might can do the estimation myself.
Sure I could do it all myself. Learning optimised C, learning Arduino, learning how GitHub organises sourcecode etc. etc.
Just would take time (I guess 1 Year or so stopping all other things I would like to do)
But I think we are living in a world of divised labor. So for some experts on the fields involved here answering a question is "a peace of cake"
Thank you very very much already know for taking time.
best regards
Stefan
Comments
before starting a big software project I'd like to ask what your final goal is. You simply want to run your mill or you want to promote the propeller chip by offering a better solution to the atmel based GRBL? For the first case there exist lots of ready to use solutions like Mach3, LinuxCNC or Eding CNC that should surely perform better. If you aim for the second case It would probably make more sense to start over alltogether instead of making a 1:1 "compatible" replacement for an existing product.
I have to admit I know almost nothing about how the GRBL really works. I have seen some other similar solutions that take a PC as GUI or fileserver and use an external microprocessor to do the realtime stuff like step+dir signal generation. The basic idea is good because this frees the PC from the task of generating pulses at microsecond resolution which is hard on a non-real-time system like windows. But the implementations I've seen all suck more or less, for the following reason:
To release the PC from realtime requirements you need a buffer. If you make the buffer too small you risk buffer underruns. If you make it too long the reaction time to user interactions or events is too slow. The solution could be to send only "high level" commands (G-code) to the microcontroller and do all trajectory planning there. But this is really hard to do on anything that has no floating point unit. I have done a trajectory planner for integer arithmetic back in 2000 but any motion engine based upon intergers I've seen (including mine) has some trapdoors, e.g. simplifications that can be fooled. In the end they are either too slow or they loose steps in extreme situations.
So even if the propeller might perform better than an arduino I think it doesn't make sense to port a software that has fundamental limitations not only concerning computation power but also in the underlying algorithms that cannot cope with arcs and small line segments because of design flaws. I guess the arduino is limited to a step frequency of several 10kHz. The propeller could probably output 1MHz or more if you use a dedicated cog per axis. You could also push the limits of the 9600bd connection further by using faster communication. But you can also easily make NC-programs that still hit the limit where your buffer runs out because of a bottleneck.
I think I have found a solution to this dilemma but it requires a different aproach. First, calculate motion steps in equal time slices. This way your communication is never a bottleneck no matter how small the line segments in the G-code are. This is no new idea, Mach3 and Eding CNC already do it that way. Second, do NOT include acceleration planning to the motion steps that are buffered. All acceleration ramp calculations have to be done in real time in the target system at the end of the FIFO queue. This is still difficult but because speed is limited and motion is only 1-dimensional along a pre-calculated path it can be done with fixed point arithmetic and limited resources.
Still interested? Then I think we should meet.
I can also offer my assistance with PropWare and using a real IDE. You will want a real IDE for a program this big.
If you choose to go the Spin route though, I'm not your guy.
thank you very much for your offer. ManAtWork (his name is program) is working in the motion-control buissenes.
I can see that he has thought a lot about concepts how to do motion-control for CNC.machines on a professional level.
I like to code for the propeller-chip for personal projects in SPIN or a little assembler if high speed is required.
After looking inside the source-code of GRBL with very few knowledge about C it looks difficult to me to port the code.
I want a CNC-Control with better perfomance than GRBL. MatAtWork has written that some of the performance-limits are caused by design
(not by calculation-power) Now I'm unsecure which way to go.
Porting the GRBL-source-code or coding something new based on the concept MatAtWork proposed:
or buying an off the shelf control for my CNC-Mill.
Swimdude,
me myself I can't estimate how much coding-time the one or the other way will take.
I can bring in my CNC-experience (little above beginner) and my experience in mechanical engineering (somehow advanced)
to help making a propeller-based CNC-Control it reality.
Swimdude if you have also fun porting the C-code back to a basic word-descreption of what the code does
I think I can bring in my experience and maybe bring in new ideas how to improve the GRBL-code.
@ManAtWork: I'm not sure what you mean by "Still interested? Then I think we should meet."
Could you explain a bit more about this?
best regards
Stefan
Unfortunately, it is quite a lot of code.
Fortunately, because it is broken into logical segments with CPU-specific functions segregated from non CPU-specific functions, porting it to the Propeller (in C) will be relatively easy. My initial guess is that only ~20% of the code will need to modified (and the rest can remain as-is with no modifications what-so-ever) because the other 80% is not specific to any one CPU.
If that was unclear, it's like the difference between:
// CPU-specific implementation to blink an LED int myLed = 1; while (1) { DIRA ^= myLed; waitcnt(80000000 + CNT); }and this much better version...
// Well-organized code for blinking an LED int myLed = 1; while (1) { toggle_pin(myLed); delay_in_milliseconds(1000); } // CPU-specific code broken out to function void toggle_pin (int pin) { DIRA ^= pin; } // More CPU-specific code broken out to function void delay_in_milliseconds(int delay) { // Even better is that the clock frequency is not hardcoded! waitcnt(CLKFREQ * delay / 1000 + CNT); }The author of GRBL chose the second block of code. It's very obvious what needs to be done to get this working on the Propeller.
But... because of the sheer size of the code base, I would not recommend porting to Spin. Yes, it is well written - but there's a LOT there. Obviously, just my personal opinion. Maybe someone else will come along and say "I love Spin, this won't be a problem at all!"
Cheers,
David
if you stay inside C it sounds like 10-20 hours of work.
Staying inside C is OK for me if you port it until it runs.
If you would like to port it until it compiles and runs on a propeller-chip
I would be very happy. Without a CNC-mechanic you could test it up to the point of parameter setting.
Then I would love to test the rest with my CNC-Mill.
If you also have fun explaining some basic C-coding rules to me I could do some code-changes.
Especially changing the math of the acceleration-ramp. (as I explained in the initial post)
For improving step-frequencies I suggest to use the assembler-code of ManAtWork.(one cog per axle and cogs synchronised)
But I have no idea how much effort it will be to adapt the code to make the c-code work together
with the assembler-code of ManAtWork.
best regards
Stefan
https://github.com/DavidZemon/grbl
As for your estimate of 10-20, I'd guess closer to 20. Largely because I'm not familiar with Atmega chips so it may take some time to figure out what the hardware-specific functions are doing.
As for your "basic C-coding rules", perhaps PropWare's crash-course in C++ will be helpful: http://david.zemon.name/PropWare/md_CXXCrashCourse.html
Since I do not do C/C++ usually, I completely missed your PropWare effort. Well done, Sir.
As soon as I find some time I will remove the PropWare pages on my site. Sorry to be OT here, but @Swimdude0614 seems to be some nice guy and I want him to know that.
@StefanL38,
Back to the topic. There is a converter program by @David Hein? able to convert C to spin, but I agree with @Swimdude0614 that this code is quite big and might not fit into a propeller if converted to SPIN.
If done in C/C++ this is a smaller problem, since PropGcc is able to use external memory if 32K of Hub Ram are to small for the task.
I also have to agree with @Swimdude0614 that the code itself is well written and commented. So once it is ported to the propeller it may be quite easy for you to insert your changes.
I am pretty sure that the propellerized version of GRLB will be faster then the original Atmel version.
On the other hand @ManAtWork is right. To maximize performance on the propeller you need to program differently as on single core devices.
Anyways, just my two cent.
Enjoy!
Mike
TODO:
- Create a Stepper class.
- Figure out what a stepper class is supposed to do
- Add a new PropWare::UART class that mimics (maybe uses) FdSerial by using a buffer and operating from an independent cog instead of inline assembly)
- Figure out what various other interrupt routines do and mimic them in new cogs
That may not be very many words but they're pretty big tasks. Good news is though, it'll be no where near a total of 20 hours. 10 was probably closer to right - depends how complicated that Stepper class is and whether or not I reuse FdSerial or start over from scratch.Code is commited
macrobeak points out two excellent threads. Too late for me to read them now, but maybe tomorrow (or somebody care to post a tl;dr?)
~David
your PropWare-Site is awesome!
I started reading and enjoy it.
Don't wanna write more at the moment. Want to get back to read more on the propware-site
best regards
Stefan
Thanks! Glad you like it
In preparation for introducing a buffered UART to PropWare, I've significantly refactored my existing UART classes. While doing that and also poking at libpropeller's Serial classes and Simple's FdSerial functions, I've decided to use libpropeller's FdSerial class for GRBL. That is, for all intents and purposes, the same as the FullDuplexSerial Spin object. Maybe down the road, once I've written PropWare's buffered UART class, propeller GRBL can be converted to use PropWare::BufferedUART... but for now, we'll use libpropeller.
as I have never coded in C/C++ before I'm the ideal candidate for all the beginner questions.
If you would answer my questions how to use PropWare I would like to write a beginners guide for PropWare-C-Coding.
I followed your installation-guide and I guess the installation is successfull.
It finished with the message
"Linking C executable SimpleText_Demo.elf
[100%] Buildt target SimpleText_Demo"
Aha. - - - Now I'm lost. (As I have never coded in C before)
PropWare is a "built-system". So does this mean I use a texteditor to write the code and then use PropWare to build the final code?
Sounds complicated.
Using the propellertool is easy. Start propellertool write code hit F11 code is transferred to PropChip and running.
Coding in C seems much more complicated. Lot's of includefiles, a makefile etc. etc.
What would be a good starting point to learn about getting started in coding C for the propeller-chip?
best regards
Stefan
I'm actually going to reply to this in the PropWare thread since it is directly related to PropWare and not GRBL. Just follow the clicky: http://forums.parallax.com/showthread.php/157005-FYI-PropWare-Complete-build-system-and-library-for-PropGCC
http://forums.parallax.com/showthread.php/155226-Porting-Arduino-CNC-code-(Gerber-file-format)-XYZ-axes-into-a-Propeller