This error seems not to be documented anywhere, bought this brand new and just finished installing. Started with a basic rectangle with fill (120mm x 16mm) - if the speed is set at >380 mm/s it stops early in the job and gives me Not enough buffer space. If I change the speed to anything lower it works
I installed RDworks and it does the same thing… Not sure what this could be, I bumped up the speeds to make sure it isn’t hitting some internal limit. I tried streaming and downloading to the controller and starting from there and the same results running from local storage.
Is there some sort of limit to the number of moves this controller can take in a file…and would just a box exceed this?
Taking a stab in the dark but is it possible that the storage is full from factory? Possibly with test files? Maybe take a look to see if there any files and get rid of them if possible.
i wonder if this is a rewording of the “slop space” error message, where the overscan on one side of the engraving / fill extends beyond the machine’s travel limit:
When you position the rectangle dead center in the work area, does the error magically Go Away™? If so, then it seems like an overscan issue.
Correct, from idle, trying to run a file. This is a conversion so there are no official vendor settings, but I have it pretty close, I thought it might be hitting some sort of acceleration limit so bumped those up to see if it helped but it did not. And the file has nothing other than a square set to engrave -attached BufferError.lbrn2 (3.3 KB)
No - just the one file I uploaded thinking it may be a streaming issue, and its very small (just the one box). Also if I slow it down it does accept it
You seem to be onto something. If I move it to the middle it works, and I notice the X is moving almost double the length of the box width - so its like a 100% overscan level. If I set it to cut or use the box function (or slow it down) it is the true size. Where would this be set?
I see others complaining about the same thing - looks like it uses your max acceleration settings to determine overscan. I may have lowered those too much in my config. Will play with it a bit. I guess the take away is they are using the term ‘buffer’ to mean overscan space. I interpretted it to mean some sort of memory buffer related to the move actions
The hint was having the error Go Away™ at a slower speed, which reduces the overscan distance at a constant acceleration.
You want to crank in as much acceleration as the hardware can withstand, without having it shake too much when it settles down at the next position. Ditto for the maximum speed, which should be as high as possible without losing steps due to the lower torque at higher speeds.
I have yet to convince myself the factory settings make any sense on my OMTech 60 W red/black, so your homebrew values may not be very wrong at all.
Follow up - it seems this is influenced most by the acceleration user settings - not the ones in the vendor config (although they may act as a hard limit to the user settings) so you may need to increase them both to get the behavior you are looking for. In my case i have DC servos with encoders so don’t need a large overscan
I did not get a slop error, but its definately due to the overscan exceeding the machine limits. The mention of slop error was the speculation in this thread that it’s a rewording of the ‘slop space’ error in the newest firmware. I only have this device so can’t confirm any prior error messages. I can tell you that " Not enough Buffer space" on a Ruida seems to be a new message, no amount of searching I did could find a reference to it.
I have learned not to be surprised with variances in Ruida controllers… That is why I asked, as I’ve only seen an error like that when it was dealing with loading a file.
I don’t upgrade firmware unless there is a specific reason. It’s too bad they change the error messages to something that has multiple meanings.
