@LightBurn
Hi Oz, I know your are a very busy guy so no rush answering this one. nothing urgent.
I learned a lot from you about smoothieware gcode based controllers and what’s their limitations.
I wish to learn more. I have upgraded my K40D with a 32b/100Mhz (LPC1768) controller, other mcu’s might be running a bit faster, the question is: i believe we will soon be seeing like double the speed Smoothie boards running at like 168Mhz or even 200Mhz so i was wondering if i were to improve my rasterizing speeds which are now at their top limit of about 80mm/s @ 254 DPI/0.1 - will I get close to double the speed and/or DPI? are there any other limitations with gcode protocol (putting aside mechanical limitations) that makes these controllers inherently slower than Ruida and such protocols?
That top limit has changed if you have a Cohesion3D board running the Cluster version of Smoothieware I made for them. That version, on that hardware, achieves 250 mm/sec at 0.1mm, and that was just by changing the code to be smarter about how raster data is handled.
Even at 200MHz, a Smoothie controller processing GCode will be nowhere near as fast as a Ruida. Ruida controllers use a combination of chips, including an ARM based CPU + DSP, and an FPGA chip, which is more like the dedicated hardware in a GPU than a CPU running code. They are extremely fast.
A Ruida controller can run a color LCD display that previews the job as it happens, will resume where it left off after a power failure, and will handle 500DPI at 500mm/sec.
Smoothieware is also written in a way that doesn’t fully leverage the power of the chip it’s written for, which isn’t helping matters. On top of that, parsing floating point numbers out of text strings is inefficient, and GCode imposes certain limits, which is why DSP controllers use binary protocols - much faster to parse, and they can include specialized information that makes them more efficient at processing the data.
I have a home built 50 w based on a simple mana se controller and thinking of going for the cohesion board. I guess one should try and match the capabilities of all parts, controller and hardware, motor drivers, mechanics etc. I imaging that going much faster than 250mm/sec on a system like mine would probably be pushing the limits of the whole machine. I would expect to see wobbly lines, or run into current limits if I tried to fully utilise the performance of the Ruida, other than the ability to run the screen in parallel. Mine is 1000 x 650 so it would be great to have more rastering speed, but I think I would need to make big investments in the rest of the mechanics to make full use of the Ruida.
Interesting to hear any other thoughts?
Cheers
David
@LightBurn & @DavidF - Yeah my Lasersaur topped out at around 35mm/s for vector lines and maybe 100mm/s for rastering. It it also had pretty janky motion systems with just plastic wheels on extrusion. If you have any sort of linear rails I’m sure you could do better.
As always, I couldn’t have asked for a better reply from Oz.
I will do my homework if and when I’ll decide to either upgrade my machine again or build my own. I read that PSU response time and how fast the tube follows that is also a factor, but since I’m a hobbyist which still learns and my main objective is to use the laser for my own ideas and tools and art i will look for the best bang for my buck. i see no reason to go faster than 250mms for rasterizing since my laser bed is so small and time is no money for those who are not making any with their machines. I don’t yet see the logic of spending, Shipping, harbor fee and taxes included, about $300 usd for Cohesion3D board and I don’t know if I can run the Cluster fw on my controller (skr 1.3) but rest assure i will check all of my options before taking my next step. i heard a lot of good things about Ruida and it is not that more expensive than Cohesion3D - not sure if that is so but i think it is.
My SKR1.3 with TFT screen cost me $40 USD and that was a HUGE step forward since it allowed me to switch to LB and do so much more, so I can only assume that there will be very cost effective solutions for hobbyists like me in the very near future.
Cheers.
Is the cluster version compatible with genuine smoothieboards, as well as Ray’s?
It should be, yes. There is no code that makes it C3D specific.
Thanks, Oz.
I’ve been reading about the changes. Really great work and now my (5-6? ) smoothie-based machines are going to get their screens and SD back! Yay! 
Hi, I do not have firmware for laser k40, choose which firmware to use for sk 1.3
What firmware are you running? That’s the important part.
Install the k.board skr1. 3 for k40. I don’t know what firmware for laser fire. Recommend me, thank you Oz
I am running this flavor of Smoothieware with my SKR1.3 moded K40 and it works great: https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware-cnc.bin
I am still considering the Cluster flavor but since I am not sure how, if at all, it will work with my SKR 1.3 board I am postponing this to a later date. i need to give this a try. first i need to know what am I getting myself into. it can take time to tune it to how my machine works these days and I would hate wasting days just to end up reverting back to the current CNC flavor that works great though i would like to have faster engraving using the Cluster mode.
In the meantime, I put the board in k40. I joined the opto for switching the solenoid valves and I’m going to continue with the wiring tomorrow. Thank you Pavel very much. Which pin fires the laser
Thank you for the help laser communicates great with lightburn !!! Very good Oz !!! The only thing I haven’t figured out is where to connect the PWM + laser ON OFF to the SKR 1.3 to the motherboard. Pavel
It will work fine with your SKR.
Thank you. I will try this during the weekend with hope for faster engraving.
I will find an image for benchmark and see how fast I can go with cnc vs cluster.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.