I’m trying to better understand the Ruida controller and its relationship with LB.
It would help enormously if I knew more about how LB talks to Ruida. GRBL is documented but Ruida is not GRBL, what data format does Ruida use to be controlled?
Ruida’s use a proprietary binary protocol. It’s not human readable in the slightest.
LB’s implementation of that protocol is reverse engineered from RDWorks data captures.
OK is there any way I could find out more about it, or is LB keeping their discovery work proprietary?
I understand why you’d want to do that, but I am more of a bleeding edge user than you probably realize, and this would help us both.
Case in point, I’m seeing a real benefit to requesting LB move away from square pixels on the rastering. The square pixel issue is holding back on some amazing capabilities. But that might be a Ruida limitation and not even something LB can do, but from what I see it does appear to be a LB software design choice.
There are public open reverse engineering efforts for Ruida available. Try a web search for “Ruida reverse engineering”.
Keep in mind that this would likely disqualify you from participating in any independent clean room reverse engineering efforts if that mattered to you. I’m not a lawyer, however, so take it for what it’s worth.
Cool! I kinda remember seeing the RE efforts before, but apparently forgot about them.
[quote=“berainlb, post:4, topic:57848”]
Keep in mind that this would likely disqualify you from participating in any independent clean room reverse engineering efforts if that mattered to you[/quote]
Sorry, could you clarify what a “independent clean room reverse engineering effort” is? I’m just a guy looking to push the bleeding edge on one side and ultimately make it easy/straightforward for common users as well.
OK I’m most interested in how Ruida is taking in raster data. I’m trying to do a feature request for LB to improve its rastering, and I see this would be much more productive if I understood the Ruida’s data format so I know if what I’m asking for is even possible. I think it is. I believe the quality of the outcome of such an endeavor is going to depend on best exploiting that data format from the start.
I see the Wiki. I’m looking for how raster data is formatted, but I’m not finding that yet.
It just means you likely could not start a separate reverse engineering effort and claim it as an independent work. You’d potentially be tied to any IP terms if any from the other RE efforts. But this is all very complex legal territory and different countries have different rules around this.
It’s not clear to me that the controller itself is even aware of what a raster is but I have no real insight here. My basic understanding was that the entire burden of determining the laser path was on the software. The controller just takes the path specified and runs with it. So vector or raster doesn’t matter once LB has processed those things into a laser path.
You can see how LB interprets final laser path by zooming in on Preview and looking at the individual laser path lines. Alternatively you can use the Edit->Convert to cut (debug) on a selection to convert to the cut lines.
The biggest thing preventing the implementation of your (or anyone else’s) pet feature is time, and since I can already get fantastic results with LightBurn using the built in tools I’m not in a massive rush to rewrite the imaging engine to support a feature based on an unproven claim like this.
We did, at one point, allow the horizontal scanlines to be much more dense, but found that it contributed next to nothing to image quality, increased the size of the output data to the machine, and choked GCode systems, so it was removed.
I also had code in place that adjusted the length of output lines / pixels to reduce overburn and dot overlap, and a number of users fought it tooth and nail because they weren’t able to get exact results from a given input image. I did some comparative runs and when your image / interval settings are correct, it really didn’t make a difference, so I removed that too.
It wouldn’t be fantastically difficult to write code that adjusts the length of an output run based on pixel brightness, but it would take time away from current tasks that have much higher priority.
[quote=“LightBurn, post:8, topic:57848”]
We did, at one point, allow the horizontal scanlines to be much more dense, but found that it contributed next to nothing to image quality, increased the size of the output data to the machine, and choked GCode systems, so it was removed.[/quote]
Hey, is there any way I can get that old rev and try it out?
I don’t have a version that did this - it was just early code. It would be several years back at this point.
I see the info online about the transport format for vectors to Ruida.
Raster data has me curious, but I see no info online about how that was transmitted, but obviously Lightburn has it figured out. I know that’s quite different than vector.
Can @LightBurn share anything about that? If not, please just let me know it’s “secret” and I will at least know to stop asking about this point. But the things I’m wanting to request may hinge upon what’s practical to do within that format so it matters. Also we can take it private if that helps.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.