Does anyone know if there’s a way to increase the internal memory of a controller (passed the 79,000kb) or whatever the exact number is. Or on the other hand, anyone know how to avoid maybe sending these bigger jobs to the laser to run. Whenever I’m doing photo engraves, I always send my job to the laser first because as I was told in this forum, (which worked) it was the only way to keep a file from not stopping halfway through the engrave. Which has worked great, but lately I’ve been doing a lot of 4 foot picture engravings that are too large for the lasers memory.
For the Ruida to work, it has to have the complete file in memory…
I know of no way to increase the memory size of the Ruida… they claim no user serviceable parts, which is probably generally true…
Are you using grayscale? This eats up lots of memory…
Just dither. I can get it to a small enough size if I drop the dpi to the 250ish area. But most engravings I run around 450-600 range
Ruida 6442 has 256MB of onboard storage. Are your files really larger than that? Or do you have other files stored that are taking up memory that you could remove to reclaim some storage.
Alternatively, I wonder if you could save the rd file to usb storage and then run from there.
I’ve never run off the usb drive, cables in a box somewhere…
I would assume the Ruida would have to load the file first… as that’s the only way for it to compute things like overscan…
I understood when you clicked on ‘start’ it sent the file to the Ruida, then just started it… the whole file had to be on board the Ruida…
To make use of 600dpi, you would need to make a dot < 0.05mm … even 450dpi requires a dot < 0.06mm, what kind of lens system are you using…? and on what?
I was curious about this. I’ve never run off USB so not sure if it first transfers to internal storage before running but I don’t see any reason why it couldn’t stream directly from USB since it’s directly addressable from the controller.
Anyway, thought worth trying.
It’s a disk drive, so it isn’t directly addressable by the controller… in fact I’ve come to the conclusion that Ruida implementation of usb is pretty sad …
The controller could not give you a ‘slop’ error without having the entire code ‘bundle’ available for the hardware to interpret…
Imagine how fast it could run through the code if there were no mechanics involved… there is a similar mode in grbl, where it will run the code and check for any ‘out of bounds’…
The controller could walk through the file block by block looking for out of bounds conditions without having the entire file in memory. The 256MB of non-volatile storage shouldn’t be physically that different from USB storage. I’m not certain but the non-volatile storage likely also has a filesystem structure of some sort.
Keep in mind we’re not talking about RAM here.
I’ll try a test here sometime over the weekend unless someone else gets to it first.
What is this?
It doesn’t have a direct path from the cpu to the memory on the stick, so it’s external memory like a disk…
I’ve completely give up on the Ruida have some kind of logical operation … To think it does something ‘smart’ is delusional… it’s going to do the minimum with a usb stick… we’re lucky we can write to it…
I’m not questioning that it’s addressed as a disk. I’m saying that the internal non-volatile memory is likely similar.
I’m saying that the entire file doesn’t have to be loaded into RAM to process. It can be processed in chunks. I’m not saying it does that, only that it’s possible. My initial intuition is that files from usb disk should be handled similarly as internal storage but not certain.
Will report back on my findings once I run a test.
So from what I can see there’s no provision to run directly from USB. It only offers some file operations: copy to internal storage or delete from drive.
I created a file over 300MB which would exceed the internal storage and sure enough, it complained that the file was too big to copy to internal memory.
Bottom line looks like file size is indeed limited to internal storage capacity.
Looks like most Ruida controllers are limited to 128MB or 256MB. Curious if there are any high capacity storage controllers.
In any case, I had to create a 10,800 Megapixel image to get to a 349MB RD file. I’m questioning if the file size is genuinely getting that large or if other files are taking up space.
Most of my files I’ve edited and dithered in photoshop, outside of lightburn. But no matter how I save the file, in what format or resolution rating, ligjtburn seems to always tell me a completely different file size from what the file size actually is. Also I make sure to always clear my controller of old files. Seems to only happy when I reach engravings over 3 feet. I end up using my friends laser for larger engravings he’s got a full spectrum that runs on their own branded program. Looks similar to RD works actually, but he just clicks start on his and goes to work with no issues. On the other hand I’ve always had to send photo engravings to the laser first and if I didn’t, it would stop half way through.
I think lightburn is a way better program than the one my friend is forced to use with his laser, but not sure why he doesn’t need to send files to his laser like I do with lightburn, when we have the same controller.
Where are you seeing what LightBurn sees as the file size?
Can you upload or link to a sample image file that you’re dealing with? Also, a .lbrn file that holds the image. I suspect you’ve got something going on, possibly a very high DPI setting that’s artificially inflating the file size.
When you have your friend run your file is he taking your file straight?
If you have the same controller the program almost certainly has to be RDWorks. And should support LightBurn if that was desired.
Would seem to invalidate the ‘code can be done in chunks’… ?
My dealings with the Ruida, nice controller for the laser end, but dumb as a rock, especially with it’s i/o handling of USB, memory stick and also it’s Ethernet port … it’s so dumb it’s interface is ‘static’ and UDP …
The size of your image on disk is not the size of the command stream send to the controller. The data has to be converted into engraving instructions, and those instructions may end up being significantly larger than the source data.
“Send” is typically necessary when engraving high-DPI images, or engraving at high speed. The controller has a limited amount of CPU time available, and if most of it is taken up by doing the engraving job, it can miss incoming data. If you use ‘Send’, you’re not having it do two things at once.
I was only postulating what was possible, not how it actually worked. Tested to confirm and sure enough, as you say, not so smart.