Why RuiDa

I’ve been trying to figure out what makes a RuiDa controller so special. I mean I keep hearing that from users of them but way too often I find those users have not used other laser control systems. So far I have not found much online and I’m hoping to not only find out more but also hear from others who might have dug into the workings of RuiDa controllers AND the other 3DP based controllers(Cohesion3D/Smoothieware, GRBL, Duet, etc ).

When I asked that, my recollection is that “faster image easter engraving than with gcode” would be a fair summary. This is why I was considering Klipper for the #monocle and you suggested LinuxCNC with an offload processor.

This is a conversation going on here and wanted to continue it here instead of the post about glitching laser cutter machines: Laser glitching around text - #63 by jkwilborn

I’m not so sold on that belief… 3D printing has been around for about 40 years but 3 companies kept that locked up and away from the public using patents. Once those expired, a few guys started the RepRap project and started building an inexpensive 3D printer but it was fully open source from hardware to software. Within 10 years others iterated on their ideas and improved it to the point that a home machine which used to be a $100,000 “commercial” machine was under $500. FDM machines are under $200 while their commercial counterparts were 10s of thousands of dollars.

Lasers have come along for the ride mostly because the 3D printer motion platforms and control systems have become so inexpensive and thanks to the K40 and K50 machines 10s of thousands are being sold regularly and prices for CO2 tubes and power supplies have also decreased in price. I just don’t think much of it had to do with commercial vendors and it really was done in spite of commercial vendor market controls.

I don’t quite follow the idea that commercial interfaces are always the simplest and I question why would a laser controller be the most expensive part on a laser? Moore’s Law has been around and validated since 1965 and so the cost of DSP hardware, and most all other electronics, have dropped in price considerably while also becoming much more powerful. Just in the 3D printer space the RepRap group designed their own controller boards and used 8bit 8MHz micro-controllers since 16 and 32bit controllers to run a CNC machine were hundreds of dollars just over 10 years ago but now, less than $50 will get you a powerful 32bit ARM based controller running over many hundreds of MHz.

Most everything was an analog control and slowing things moved more and more to digital control since that is essentially the native language of computers. Seems logical the higher power things like spindles would continue being analog until higher power control circuits became inexpensive enough to switch the control interface to a digital control. Many times PWM(Pulse Width Modulation) based but sometimes commanded with higher level serial communications protocols like CAN, RS485, and even USB.

I’ve had a difficult time finding exactly how long the RuiDa controller has been around but the K40 goes back about 10 years. I don’t really think that is relevant though since the stock K40 controller is one of the first things replaced exactly because of how limited it is with regards to laser power control. It literally had a knob you would turn and adjust for each laser operation you were doing. But the inexpensive 3D printer controller boards were fully capable of driving a laser power supply and the 2 or 3 axis motion platforms. Their firmware was based on supporting the well defined GCode standard( used for CNC control ) so using spindle speed adjustments to control the laser output became popular. Initially there wasn’t much unique in the 3D printer firmware for lasers and things like velocity advance was already implemented for 3D printing. This prevented excess plastic when the 3DP head slowed to make corners then accelerated back to speed for straight sections. This was used for lasers and later a few laser specific adjustments were added.

Having GCode( laser files ) stored on the controller is not new or unique to RuiDa but not all 3DP boards or firmware support that as not all 3DP boards come with enough memory to store these files. Some do via SD or uSD cards and with a graphical display add-on you can select a file from the SD/uSD card and run the laser without a desktop/laptop computer connected. Others who are from the 3D printer segment have used a $30 Raspberry Pi board connected to the laser and using software called OctoPrint/OctoPi to free the computer from needing to be connected to the laser at all times. No doubt one of the added expenses of the RuiDa controller is how much filesystem memory/storage space they have to put in the system to support this print-from-controller capability. But it’s not unique to RuiDa just a standard feature of RuiDa.

if you’d like to know how the K40 M2Nano controller works, David Olsen the author of the MeerK40t software made a great video explaining it. How the M2Nano Works. - YouTube

So if I understand this, LPS-L as commanded by the RuiDa is strictly and On/Off signal so no matter if the laser line being put down is grayscale or a fixed power this LPS-L line is asserted for the length of the line. BUT, what you are calling pwm( LPS-IN ) as commanded(output) from the RuiDa controller this pwm will vary it’s pulse duration for a grayscale line or remain at a fixed period for a fixed power line? This part is not so clear to me.

One of the reasons I’m not clear on this is the fact that our 3DP controller boards only have 1 output to the LPS and get design control and power control and not just dithering. We set the LPS-IN to a fixed value which is the maximum we ever want the laser output current to be, as measured on an amp meter on the laser output line. So LPS-IN is fixed and the 3DP firmware only controls the LPS-L input line. And it’s very confusing to hear that it’s so much better to have a PWM control on LPS-IN yet none of the 3DP firmware developers have bothered to use one of the many available outputs on the boards to do PWM on the LPS-IN input. :confused:

Controller boards can label their outputs what they want but if they use COTS LPS units the inputs there are typically L and IN but sometimes L is accompanied by it’s inverted pair, H. The L stands for active Low( or assert Low ) while the H is for active High(assert High). Not doubt ttl+ and ttl- are other names for the same thing.

Don knows these laser power supplies quite intimately and never have I heard him once mention sticking a tweeker(non conductive screw driver used in TV tube adjusting) into the side of the LPS to adjust the power output. He has mentioned a number of times using LPS-IN to set the laser output power level. So I think there is a disconnect between what you are talking about for adjusting the LPS output and what Don has been saying about LPS output. I think…

So the protocol is what’s faster and therefore the machine can be faster? I’ve heard of people doing 1000 mm/s raster engraving but have now seen anyone validate the machine was moving that fast. They’d only stated the settings were set to that speed.

If this is the case, ie the protocol is faster then I would think a 32bit 3DP board running at 400MHz would be 2x faster and at some point they should be able to match the DSP in the RuiDa since eventually hardware and mass will be the limitations.

Regarding LinuxCNC for laser and 3DP control, it’s just not capable of doing velocity adjustments without backporting some software from 5+ years ago. Without velocity control the laser will burn deeper on corners and the 3D printer will ooze plastic on corners. Both machines need this type of output control for the accuracy I expect from them. I’d like to try RepRap Firmware since it supports both lasers and 3DP. Klipper is predominantly for 3DP only.

I think you’re overthinking it. The bottom line is simplicity of use. A Ruida is just about a plug and play controller. Most other controllers need a bit of knowledge to tweak. It’s popularity is not about how good it is, but how easy it is to use and as LightBurn has shown, to be able to use a third-party software that is just plug and play.

Just as an Arduino is adequate for most projects, there are other choices that would be better but do not have the support.

Most of the time it’s all about quantity and ease of use versus quality.

Just my 2 cents.

2 Likes

If I understand you here, yes that’s correct.

When it’s doing scan the pwm layer is a single % power level. So the pwm is constant for the complete layer.

If it’s a gray scale, there is a ‘ton’ of data sent to the Ruida since it has to continuously vary the pwm. See this with grbl also. The file generated is ‘large’…

If it’s a vector the hardware modifies the pwm in relation to speed and the layers maximum/minimum power settings.

The Ruida computes that overscan for the job before it’s executed. It will display an error (‘slop’) and halt if it will be driven out of the machines defined work area. It gives you the option to continue or cancel the run.


I think in the end, different ways to skin a cat…

:smiley_cat:

Maybe I can convince you of it.

I set the period of my machines pwm to 1mS (1/1000 of a second) along with the power to 50%.

I set a single line to 500mm/s and I get a brown line.

I now do the same thing at 1000mm/s. The line is dashed.

The head is moving 1mm in 1mS, at 50% pwm the machine will lase for 0.5mS every 1mS. It is lasing for 1/2mm. Off for 1/2mm.

I have gotten it up to 1650mm/s, I think the acceleration is somewhere in the 65,000mm/s^2 on the X axes. Upper limit for the X axes is 1700mm/s in the configuration.

Also with a dc excited machine, the lps response time can be an issue at even medium speeds.

Even the little computers can outrun most of the this mechanical stuff and some of the electronics, so speed isn’t everything…

When I was fiddling with the Ruida, at times it sounded like the a car crash. The fields move faster than the motor can respond. Makes a notable noise.

:smiley_cat:

1 Like

I can only guess that you are talking about engraving/scanning using the Dither methodology where the power level is constant and the dot positioning and density is what gives the illusion of gray coloring levels.

I believe you are talking about power adjustment based on velocity changes. The take away I get is that LPS-L is all about ON/OFF where the pixels are being burned and no matter what type of engraving or cutting there are power level changes going on( varying PWM ) on LPS-IN.

The 2nd take-away from your statements is that Ruida firmware consumes the entire design in the controller and stores the command stream before it even starts burning. THIS is completely different from the open source 3DP firmware where the GCode is or isn’t stored on the controller but either way the GCode is shoveled to the firmware and via look-ahead buffers they handle the acceleration, velocity and power level changes while running. VERY different ways of processing the design.

Thanks for helping clear that up.

The Ruida takes the complete job and somehow processes it internally. It will identify anyplace that it could go out of bounds and will warn you when you try to ‘start’ it.

Only when you vector cut, does the pwm change with speed. This is the only place it slows down and speeds up… going around corners and such… If you do an image, then it will compute the overscan and ensure it can reach the selected speed while still being within the work area.


The period is 1mS, so the pwm is running at 1kHz.

I’m drawing a single line. I can see the laser turn off and on within that 1mm space. Nothing to do with dithering, directly, just the machine turning off and on… and the head is moving fast enough for you to see it do that.

If you look at the 500mm/s and the 1000mm/s the ‘burn’ is about the same shade, another example that you can’t control the lasers power. That is lps current specific.

:smiley_cat:

Jack, go back and look at the context for the quote I had specified and why I mentioned dithering.
You’ll see it was not referring to your discussion on speed. I was trying to figure out what you meant by “scan” and why the pwm would be fixed for a “scanning” operation. Only in/with dithering is the power level fixed so I made that statement. And as long as there was plenty of room for overscan after the design the pwm( LPS-IN ) makes sense to be a fixed power level.

BTW, now I have to figure out how does the open source firmware do this with just one control line( LPS-L ) and have both grayscale and dither capabilities. The 2 signal method you described for the Ruida makes sense so there has to be a reason why the other firmware is not doing it that way.

Why would it not do power level adjustments when doing scanning of a grayscale image? If it does not scale the power and keeps the pwm(LPS-IN) at a fixed power level then how does it present the effect of grayscale engraving?

What I was trying to point out was that during one ‘period’ the laser is on for 1/2mm and off for the other half of that mm. It’s not dithering, it’s the machine operating properly following the pwm.


Grayscale is different for both grbl and Ruida, however they both generate lots of code for the controller because with a grayscale it will vary all the time across the image, so you have to tell it when to vary the power. How it internally handles this is a mystery to me, along with many other Ruida things.

Grbl has no hardware that computes the power levels for speeds or can apply it as a correction to the pwm. We might see this in the future, but as far as I know it’s rather limited with the current grbl machines.

This is usually seen with burnt corners or points in the design where the head is changing direction and moving at it’s minimum speed.

Some one who uses their grbl machine more than I can probably answer that better for grbl types and lasers. I used a 30 watt NEJE for a very short while, then received the co2 and never went back. The little machines are used to make printed circuit boards.


My Ruida input for water protect has failed, I get the signal to the controller and I can see it on the display led on the controller, but the Ruida internally doesn’t see it. I moved it to my door protect input and enabled that. It stops the machine, but displays ‘door protection’ error…

Did this help or hurt?

:smiley_cat:

THIS is what I was referring to… you say “When it’s doing scan” and go on talking about how the power level is constant. The only scenario where this makes sense is when one is engraving an image where the Image Mode in the layer configuration is set to one of the dithering options as opposed to grayscale.

I’m making a single line with constant power, that is a scan line, it is also a vector. When you make a single line are you ‘dithering’?

If you draw 1 line, are you not ‘scanning’ that line at a specific speed/power?

Is it not the same as a fill operation, many lines at a specific speed/power…

Or I don’t understand the query.

:smiley_cat:

So previously, in the context I quoted previously when you used the word “scan”, you were telling me that when a single line is drawn that the power set by the pwm(LPS-IN) is unchanging? That just seemed odd since you’d not mentioned anything about the 1ms 500mm/s line drawing at that point. Ok but it confused the hell out of me mentioning something before you described what it was and used a generic term, “scan” while doing it.

:poop: Sorry… I’ll try and clarify.

I also think you are complicating this in your mind. Dithering is a totally different idea.


Maybe we should define scan.

If you fill a box at 120 lpi, there are 120 scans/inch to produce this… each line is a scan. It is scanning, but the pwm isn’t changing, so you get a constant (hopefully) burn line. All of these lines or scans make up the fill for the box.

A dither is an algorithm that interprets an image into a kind of pattern. This pattern is only where the laser will be on. It’s like a news paper, only black is printable. It has nothing to do with the pwm.

Help or hurt?

:smiley_cat:

I know what dithering what I could not figure out what what you were calling a “scan”.

So you differentiate scanning from engraving… interesting. Sounds like you call a “scan” as a fixed power engraving operation and I can only guess that you accept that an engraving operation can have and often does have varying power levels across the scan line?

except that the Ruida controller has 2 outputs to the LPS and one if them is what you called “pwm” and is used to set the laser power level. Dithering is burned dots and the dot density is what gives your eyes a look of grayscale even though the dots have the same level of intensity. BUT, even with dithering, The Ruida controller sets some power level for the entire dithered design and it sets that power level on the pwm line( LPS-IN ). It’s just not dynamically changing during the engraving operations…

I think it’ll just be easier for me to connect up a Ruida controller on the bench, fake the end stops, run a 30-day DSP version of LightBurn to get a design sent to the controller and monitor what is going on with the 2 Ruida outputs which would connect to the LPS-L and LPS-IN inputs.

If you are going to use the Ruida, I’d suggest you connect it like that described in the documentation for the device.

If you don’t it probably isn’t going to operate correctly without some details changed.

If the pwm is connected to the lps via the L connector, the laser will lase continuously and will not stop firing until the job ends.


I was ‘trained’ by a large manufacturer on different types of cnc machine, back in the previous century. When the wire wrap tool ‘moved’ to another pin, many times it was referred to as ‘scan to the position’, rarely it was referred to as ‘move to position’.

At that point in time, I was used to a crt or other type of device that uses ‘scanning’ as part of it’s primary operation.

Who decided this eludes me, but that’s how it was laid out to me.

If you draw a line at any power, whether the laser is on or not it’s scanning to do this. It generally refers to operations like fill or an image. To me there is no difference between drawing a single line such as a vector or doing a fill or an image. The head scans the area, an image or fill. Even when it’s doing a gray scale the head is ‘scanning’ across the area…


I view this at a low level … If you are doing a dither, generally it isn’t one dot or filled, although it can be no dots and empty. The pwm is usually running much faster than the laser ‘on’ signal. So the laser ‘on’ will be asserted when it needs to lase and as long as it needs to lase.

I guess it’s all relative, but I think I’m not communicating exactly what I mean…

See if this helps.?

Need to make pizza dough for tonights dinner, talk at you later… :crazy_face:

:smiley_cat:

for specs of the Ruida hardware I’m finding the following interesting chips in the 6442S. There are other support chips like an 10/100 Ethernet controller and USB2.0 not listed but you can probably find them in the image below. Info: RDC6442S/G | RuiDa Controller

TI 320C6747 DSP 456MHz

Intel Cyclone 10 10CL006 FPGA

Samsung 028 K9F1G08U0F 1Gx8bit flash memory - 256MB x32bit

Bordison BS4M16A 4Mx16 DRAM