I have a StingRay from TTP Laser running a Ruida 6445G controller.
Several issues occurred tonight. The first time I thought I did something wrong, the second time I know I did nothing wrong.
The first time I tried to run my project the laser suddenly went all the way to the front of the machine and started burning the Honeycomb grate even though it was set for user position and I set the Origin for the back right corner.
The second time I noticed that there were random horizontal lines being engraved, in addition the cut lines were completely off from where they were supposed to be and then suddenly while the machine was cutting it suddenly moved diagonally across the whole project to the back right corner and beyond, I ended up hitting the emergency stop button. I am not sure whats going on but something is not right.
Hello everybody!
I have to say I have the same problem!
It happaned to me couple of times alreadyâŚwhen I finally stopped crying about it I got angry, because it ruined quite expensive material. I cannot work like this!
With that in mind, though, several reports of failed Ruida controllers have surfaced here in recent months.Whether itâs a real problem or just coincidence is hard to tell.
Assuming your machine is under warranty, run your problem up TTPâs flagpole right away, because all the symptoms point to a failed controller.
Talked to TTP this morning and ran the same file in RDWorks and zero problems it engraved and cut fine so its not the controller its definitely Lightburn
In Lightburn the laser head would move left to right horizontally then suddenly stop burning go way out of range in a square motion of the area to be burned and then would resume. Basically it was like someone hitting the frame button but it was not going around the actual perimeter of the file.
In RdWorks the laser head went left to right line by line it never did what was happening in Lightburn
Glad to be (probably) wrong about the controller, but âŚ
Was the RD file created by LB? In other words, you created the RD file using LBâs Save RD file, then transferred that file to the controller using RDWorks.
AIUI, both LB and RDWorks transfer the entire file to the controller, then tell the controller to run it. Unlike G-Code files run on little dinky microcontrollers, where the sender must trickle the file line by line, thereâs no communication after the initial transfer.
Also AIUI, thereâs not much error-checking built into the RD file transfer protocol, so itâs possible to wreck the file during the transfer without either side noticing, then have the controller (attempt to) run a damaged file, with ensuing hilarity.
If you can create an RD file using RDWorks that runs successfully, but fails when LB sends that same files, then suspicion falls on how the RD file gets to the controller: something is different about how LB does it.
Or have I misunderstood whatâs going on? (again)
At this point, a DXF file converted by RDWorks behaves as you expect, but a similar SVG file converted by LightBurn does not.
Thatâs quite a distance from the original problem statement.
What happens when you run the DXF file through LB?
Apparently RDWorks canât import SVG files.
It would be interesting to try other formats to see how they behave in each program.
At this point, Iâd be willing to believe the hole is not in LightBurnâs end of the boat, because graphic file conversions are always fraught with peril due to the myriad versions / specs / undocumented features / outright errors found in the source files.
In fact, the DXF and SVG files are likely converted from whatever format the original design program produced, so RDWorks and LB are actually re-converting (or possibly re-re-converting) those files.
LB may be doing exactly what the SVG file is telling it to do, because a previous conversion broke the SVG in an unknown manner and LB is doing the best it can with the pieces.
Because the files are purchased items and canât (well, shouldnât) be posted here for general inspection, contacting support@lightburnsoftware.com for their view on the matter seems the best way forward.
With all that in mind, Iâm still really glad to be wrong about the controller!
I have to be hones this statement that you made seems to imply that I am changing the original problem statement or being misleading in some way.
The only reason there is a difference between when I first posted and now is I have more information at my disposal. When I first posted this I had not spoken to TTP laser. Doing the test with RDWorks was what TTP had me do which is when it was discovered that in Lightburn it does not burn properly and in RDWorks it does
So the problem still is that lightburn is not behaving properly.
My apologies: I did not intend for it to seem that way.
One of the best ways to isolate a problem is to keep digging, revealing new information along the way and changing whatâs known about the situation.
So itâs more a matter of me trying to look through your eyes, which then causes you to see new things and we both get a different view.
I now understand it really wasnât âthe same fileâ behaving differently through RDWorks and LightBurn, but two different layout files produced in some way from the same ancestral geometry.
Cross-checking the behavior of all possible file format and program combinations may not be practical, but would certainly reveal other information. Such testing would be useful to the folks at LightBurn who know the details of their file parsing algorithms, because I definitely donât know what Iâd do with the data.
Because LB can (AFAICT) import far more graphic formats the RDWorks, it would be revealing to import the design from all those formats to see if the outcome changes. Iâd definitely tweak the cutting parameters to chew up my pile of scrap cardboard, rather than anything significant, for the first pass with each format!
I think @ednisleyâs point was that with the new information that the new understanding of the problem was dramatically different than the original reading and that there was nothing indicating such in the meantime. The impact being that it changes the domain of problem areas to explore if the actual conditions are different from a troubleshooting perspective. I had the same revelation when reading it through.
Letâs be charitable in our reading. Keep in mind that as receivers of this information we can only know whatâs communicated since weâre not there to actually experience it.
Is this a reproducible problem? If so, can you share a file where this occurs?
If itâs not, how are you connected to the laser? This has some of the characteristics of a communication issue.
Running a DXF of a file in RDWorks and an SVG of a file in LightBurn is not the same, unfortunately. Unless you take an RD file exported from LightBurn and run it from RDWorks it isnât really a true test because:
Converting an SVG to a DXF changes the structure of the graphics themselves, very likely converting curves in the SVG to short line segments in the DXF
Unless you are extremely careful, the settings between the two will be different
RDWorks will order the graphics differently than LightBurn will
Iâm not trying to say thereâs no chance itâs our fault, just that there are too many variables at this point to say that conclusively.
If you can take the LightBurn project file youâre working with and email it to our support, we can try running it on a system here, and look at the file to check for settings issues.
You can also try changing from âSerial/USBâ to âPacket/USBâ in your device setup (or vice versa), as some computer systems seem to do better with one or the other, though Iâve not found a pattern as to why.
I tried contacting support, I sent them the file both the original SVG and the lightburn file and to be honest it wasnât very helpful. Basically the issue with lightburn was blamed on user error even though I made no error. Because twice when running lightburn it malfunctioned. The first time I did not use user and just set origin on the machine itself. The second time I set for user in the software and set the origin on the machine both times the laser stopped going across side to side and suddenly stopped burning and moved the same way it does when you press frame except I did not press frame. And it did not frame to the size of the actual job it did a smaller square movement that went outside the current frame and was smaller than the current frame. And then would continue at the line it left off at. It also burned random lines that were not part of the file at all.
I am failing to see how this is user error
Also support asked me how it looked in my preview window, it looked fine as far as i can tell.
How did you get on with trying âPacket/USBâ as connection method?
The first thing you should try is whether you can reproduce your problem after changing this.
Something I would like to know isâŚdid you start the job at your machine using the âStartâ button within LightBurn?
If so, Iâd be curious if you could reproduce your issues if you use âSendâ instead?
Using âSendâ is a more robust method since you will receive feedback if the whole file makes it such as, âFile send successful: 914 Kb @ 314.6Kb/secâ
âŚwhich is what I saw when sending your âwinebox_â file to my ruida controller as a test. I didnât run your job file as itâs bigger than my laser allows, but the job itself looked fine, and looked fine at the preview on the control panel screen also.
Worth mentioning here, is that (for DSP controllers) if you hold Shift when clicking âSendâ, that will auto-start the file after it is fully uploaded to the laser, as opposed to âStartâ where the controller will immediately start the job as soon as it has received just enough of the job in itâs memory buffer - with no regard to consequences if the tail end of the job doesnât quite make it!
Speaking of memory, it is also good practice to clear the ruida file memory from time to time, because when the controller memory gets too full it becomes slow and glitchy.
This is not the impression we want you to receive. I assure you, the team is now all over this. Please do take Oz up on his suggestion, and resubmit an email ticket with the files he requested for review. Thank you.
)
