What’s even stranger yet is that a 3rd person joined the discussion on the LightBurn forum saying he too had the problem but as long as he keeps the power above 20% or below 18% the problem goes away. Even noticed that it’s effected by cold weather and happens more in cold weather. The original poster said that she’s in the southern hemisphere and is in cold weather but her laser room is not “cold” but is cooler than the rest of the house. She also confirmed that if she increases the power and also increases the speed the effect is greatly reduced.
They are all Ruida based controllers. 2 of the 3 are using LPS-L for Laser-Enable and LPS-IN for Ruida-PWM. One of them tried a 2nd Ruida and had the same issue.
Using the arrow keys I statically stepped through the video and took screenshots.
You can see the random dots being created. Of course, that is not new news but the position of the head is curious.
It appears to me that there are unexpected deliberate movements and single dot fires that are outside of the programmed imaging area.
The laser fires in the programmed area. Moves vertically down the page and then fires an unexpected dot and then back to the programmed sequence.
What do you think?
Seems like a Rudia firmware problem to me.
These captures are time stamped
@ :32 [watch for the random dot to be created in next frame}
I hadn’t noticed deliberate moves to the dot locations and will have to recheck but if that’s the case it would indeed be a firmware issue since the LPS does not control the motion.
I can see the spots being lased but can’t see anything by X axis motion and it seems smooth. I’m using mplayer and the “.” command to step frame by frame on the original MP4 file. Will try again later.
I’m the guy #3 (with the circle test pattern).
I never got to replicate the problem, ran some tests couple of days ago - randoms didnt show.
I mused that it may be LPS temperature related, because my circle test has been done in single digit C ambient room at the time. I still do have some thoughts on temp control issues, but cant do anything about it as its too warm now to try to replicate.
To avoid this problem i just shovel some more coal into powersupply. More (or less) power = clean engraving for me.
My LPS wired like this:
Funny how randoms never appear outside framed work area though.
I am doubtful of this theory because in the video the head actually moves to an erroneous location and fires and then returns to the programmed imaging. The LPS has no ability to move the carriage.
I think this is because the Rudia is actually miscalculating and creating erroneous moves during a job.
Of course, my theories would be erroneous if the video is playing tricks on us.
It would be interesting to see a slo-mo video of your circles being imaged.
An interesting point, that I didn’t see here was that when bi-directional is turned off it’s only on one side of the engraving. I mentioned, to clarify that it was on the leeward side.
There is a pretty long thread, some off topic on what’s been done. Also that a few of them actually changed out the controller and had the save issue. Virtually all the parts except wiring and motors have been replace…
Here’s the thread, so some things won’t be duplicated.
It seems to be collecting more people with that problem… Scratching my head…
I understand it’s apparent with either software package. It’s random, it appears and is % power sensitive.
It really sounds like hardware, but I am clueless as to where to start. IMHO, it keeps sounding like the lps isn’t shutting down consistently. As you slow it down the aberrant ‘dots’ are closer to the actual design. Tells me that the failure time frame may be constant.
She was running about 600mm/s which is pretty quick for a dc excited laser. As a shot in the dark, I advised her to try slower, but help down didn’t help any either. But as expect the area effected was closer to the image.
The interesting part is that a 20% increase in power will stop them… Still sounds like the lps, but it’s been replaced…
Working on this stuff, I’ve gotten plenty of new ‘bad’ parts, so that’s always in the back of my mind…
What is surprising is that there seems to be a number of users with this issue…
Probably related to us moving further into the Age of Aquarius
I am more inclined to believe that this is a “noise” problem. I have not seen where anyone has filtered or isolated the input to the Rudia controller. I would be interested in seeing the results.
There was discussion about filters, doubt they were talking internal filters. Mine was wired as a Chinese rats nest and I don’t have any emi problems. Most of the connection circuitry is low impedance, as far as I can tell, so that it itself should limit emi/rfi issues.
I’ve see a high number of these with a real low rate of this type of issue…
This user is not a technician, has one come out to fix her machine. However I’m sure her tech would like a fix for this…
I can’t get beyond the evidence (video frames above) that the head is actually moving outside the programmed imaging area and firing a single dot? Then it returns to the programmed area and continues.
Do you see any reason the video is fooling me???
This notion is important because it completely eliminates the LPS and the theory of noise affecting the LPS. The LPS could randomly fire but not randomly move and fire.
In fact other than “noise in the controller” it mostly eliminates noise as the culprit. Even then, noise in the controller would have to cause it to create a legitimate move and fire. Noise isn’t usually that intelligent.
What puzzles me about my theory:
… if this is an epidemic problem with the Rudia, why now? Why have users with the same controller and firmware suddenly start seeing this? The firmware has not changed, right?
What does power have to do with it: The effect of power changes on the presence of the problem could simply be that when the power is to low it does not have enough time to burn a dot. Then again there is evidence that the dot is missing at higher powers .
I saw nothing in the video except it’s obviously firing.
I don’t think it’s related to the controller type. One person has a boss, I think with a Leetro controller and others have a Ruida 6442, even a 6445, if I remember correctly. Thread is long…
One of the people had one type of Ruida (I think it was a 6442) and had a spare KT332N he used and still had the issue…
Know a way to search within the current thread? I’d know more specifically about the range of controller types from the thread…
Or they could all have different problems with the same results…
The only thing I could see what the head moving in the axis of the scan, as it was overshooting( due to high speed engraving and acceleration settings) it glitched and briefly fired the laser. And it’s inconsistent as to when during the over-shoot this glitch occurs but it was observed to cluster the glitches close to the actual scan line when the speed is reduced.
I wish I could see the head moving out of line with the scan but since the video was take at an angle to the scan axis it’s not so easy to see when it’s already moving in both X and Y relative to the video framing.
