What is the procedure for setting up the rotary setup on the 6445G?
I am having two strange problems with it. For one, my 6445G was a replacement controller for a previously installed 644XG. Once I replaced the controller I cannot get lightburn to recognize its a 6445G. It still says its detected as the 644XG for some odd reason.
When I first tested the controller with lightburn, it recognized that it was a 6445G before it was ever installed with the old systems drivers, PSU and everything that was previously placed in the machine. I don’t know if its a fault error that is preventing it from recognizing what controller it actually is, but this is highly annoying.
The next problem is when I set the rotary in the machine and plug up the rotary unit then try to open “setup rotary” I apply as follows.>
The driver being used is set to its max 3200 micro steps.
So I applied everything I believe would be correct as pictured.
However, once I hit test, the Y axis just runs off to the bottom of the machine and bangs against the face like it forgot its set endpoints. SO WTF! Anyone have any issues like this?
As far as the model string, I think LB just reads it from the device. I don’t think seeing 644XG is a problem.
As far as the rotary, what axis is it connected to? Original 6445G did not support rotaries on the U axis, you had to use the Y axis. Some later versions do internal switching of the Y axis the the U axis to support rotaries
You already have the 644XG shown in your list. If it’s the only laser you have, LightBurn would have auto-connected to it when you started the software. Using ‘Find my Laser’ when it’s already connected doesn’t work - it’s like grabbing a 2nd phone and trying to call someone you’re already talking to.
For the rotary, the Y axis is the rotary axis on nearly all Ruida controllers, and the ‘Test’ button in LightBurn sends commands to jog the Y axis by the correct amount. If you have a U-axis version of the controller, the test function won’t work correctly, and it’s likely that the in-LightBurn frame buttons will do the wrong thing too, as they also just send X/Y axis commands to the controller.
I swapped the controller from the 2G to the 5G and nothing changed, which I understand why now.
However the reason I was under the impression that something wasn’t working right because when I had the controllers hooked up to RDworks, there is an actual model list that denotes the 2G from the 5G and list it specifically as such, rather than just using an X for both series.
I might have figured this out and realized it wasn’t a problem if the rotary would have worked like I was under the impression the 5G was supposed to do according to what I read about it.
But now from what you’ve said, apparently not all 5G controllers have that feature even though all these controllers have a U axis port. My LightObject T9 has a U axis port that does in fact work as it is supposed to without the need to highjack the Y axis for it.
The problem with that is you guys never made LB compatible with that controller, which forced me to buy a Ruida unit for a client I built a machine for.
It’s honestly hair pulling insanity trying to get a reliable source of information from these card manufactures and resellers on what features actually work like they claim they do. Never mind the fact which revisions of which controllers there are to sort through.
That being said, it there actually a controller out there that your software fully works with?
Or are some of the features in LightBurn broken in one way or another on all of them as well?
I honestly just want a unit that is fully functional on all axis’ that has software “preferably LightBurn” that also fully works with it. Does that actually exist or is there a specific firmware that I need to look into, etc? I read a post on here from a while back claiming there where firmware updates from thunderlaser and another one possibly that corrects the U axis, is this available from an open download source?
Feature request: Bespoke Lightburn DSP for laser systems.
The Lightburn team does an amazing job of engineering around un-documented, buggy, and changing vendor hardware. Other than Lightburn having the occasional (rapidly fixed) oopses in their code, they are beholden to whatever the vendor provides for hardware capability. If the vendor doesn’t provide it, it’s not available. If the vendor changes the functionality, it needs to be re-engineered in Lightburn. I wouldn’t consider that “broken”.
When I say “broken”, it was not to place blame on LightBurn. But if various or even just one feature doesn’t work or fails compatibility in some way or another, what else would you call it?
And believe me, I probably realize what LightBurn has to deal with as much as anyone in this regard. After spending months and months going back and forth with controller companies and their programming engineers to figure out why their CorelDraw export plugins wouldn’t work with anything past X7 on both the LightObject T9 UI software as well as with the Ruida RDworksV8 versions out at the time.
I was finally able to crack the issue with the plugin installers myself by figuring out the plugin installers where incorrectly distributing the scripts, .dll and other files into the wrong folders and/or just missing things the later versions of Corel needed to recognize the macros.
Ironically the whole thing took me no more than a couple days, while the “programmers” couldn’t seem to figure it out in almost two years.
That being said, I was told some the Chinese programming engineers that work for some of these companies are many times not the original code writers which leaves the new guys to have to back engineer things in similar ways that LightBurn has to. I don’t know if that is true or not, but it would make sense as to why there are all these complications, errors, glitches and misspellings found all over these things. Like in the 6445G DSP setting screen it says “Manufactory”??? Jesus… I can’t understand for the life of me how these sort of things never seem to get fixed.
Does LB play with the “fixed” versions of the 6445Gs? They claim rotary support on the U-axis, but what I think they really do is switch they Y axis to the U axis internally. I have no idea how that is implemented.
As of tonight, according to Marco of LightObject, he is going to be getting a downloadable firmware file we can play with very soon to find out if it’s hardware or just a simple firmware install for all 644XG (EC) units to make the U axis function as needed for the rotary devices.
That being said, he did mention that it is a possibility that his specific rebranded (6445G) “R6 controllers” might be proprietary in said firmware support, but would need to confirm that with the programming engineers. If that is the case, this would likely indicate there very well may be an internal hardware modification involved. I’ll report when I have more info on this.
I believe so, but I will need to check on that to be sure.
Regardless I did get it installed and running on an 6445G EC I bought from cloudray last year.
The firmware installed perfectly and everything works like normal with X and Y.
The bad news is this didn’t work.
The laser won’t fire and the rotary doesn’t move at all. The Y axis doesn’t run away anymore however, so it did take care of that part.
Unfortunately it looks like this is an internal hardware thing as joel1 suspected it might be. Unless it’s just an early version of my specific controller that prevents it from fully working.
I am in a live discussion with Marco about this now and he is testing some things to relay on.
I’ll keep you all informed on what we figure out if anything.
Marco confirmed, the firmware will not work with the 6442G controller. Only the 5G model for what ever reason.
But it really doesn’t matter either way if the rotary fuction is ultimately still broken.
On another note, I found it interesting how the firmware update did fix a few other things when in “rotary mode”.
Previously, (as most of you probably know) when the rotary U axis was engaged, the Y axis would emulate the U axis set count as if it where the rotary. I would move very very slowly an creep across the bed until it was stopped with the controller panel’s stop button.
While the stop button does ultimately stop the machine from any further action, you still could not use the controllers key pad to move the Y axis any faster than it would creep along when “rotary” was engaged during a job.
Now however, this isn’t any longer the case.
Since I installed the new firmware patch, the Y axis now acts completely independent of the rotary U axis function, in such a way as to hold position when you place it, with only the X axis doing it’s thing as it should. The keys on the controller is also fully functional at speed as is the stop and reset/home functions.
All that being said, it looks like the firmware did in fact improve a few things in this regard in now being able to differentiate the U from the Y and allow the Y axis to act independently as one should expect from a separate axis port. But the rotary and laser firing is broken unfortunately.
Now only if the dang laser would fire and I couldn’t get the U axis rotary to move again we’d be golden!
Looks like I am going to be hiking my current controller for now to get an R6 unit from LO that is already factory tuned for it
That’s interesting. What I originally heard was that the 6445G with the special firmware just internally switched the Y axis to the U axis pins. If the new firmware truly supports rotary on the U axis independent of the Y, I’m interested.
This is now a working firmware patch with the R6 sold by lightobject. Everything works! I posted about it in the Ruida section on this forum. Here is the patch if you want to try it with non LO branded 6445G controllers. I can’t promise this will work with them, but I am going to test it myself as well>