Full Spectrum Laser RDC6445G-MOD5 Conversion Home Issue

[Crispy001 (Chris M)]

Hi,
I’m encountering an issue with homing in Lightburn while swapping from the stock controller to a RDC6445G-MOD5. I’m new to Lightburn.

Issue: In Lightburn, when the home button is pressed on the move tab, the machine runs through the limit switches and crashes X/Y.

When the HMI is connected to the controller at powerup, the machine homes automatically and the process completes successfully. When the HMI is not connected at powerup, the machine does not automatically home. The homing process for the controller appears to be different depending on whether the command source is the HMI (at boot) or from Lightburn.

Things I’ve done:

• Updated the controller settings for correct home direction, step size, and switch polarity. The HMI and Lightburn jog commands match what happens physically.
• Set Lightburn origin in back right (matching the physical endstop positions)
• Verified switch function electrically. Indicator lights on the controller & HMI show the endstops change state when reached.
• The machine is configured to home to -X and -Y, with 0,0 in the back right corner. I tried bridging the limit switches to their respective +dir as well (tripping the sensor would simultaneous trigger the min/max endstop on the controller) in case Lightburn and the controller somehow had a different expectation of the home direction. Still crashes.
• Z and U axis limits are not connected. Homing is disabled on these axes in configuration.

Machine: ~2013 Full Spectrum Laser 36x24 CO2. Stepper driven.
Controller: RDC6445G-MOD5
Controller firmware: 00152710 (self reported on HMI)
HMI Version: 08.00.01 (self reported on HMI)
Lightburn Version: LightBurn-v2.1.00-RC-1-c84582b
Connection method: USB

Thanks for any suggestions.

[ednisley]

@Crispy001

when the home button is pressed on the move tab

From what I understand, LightBurn does not issue a firmware Home command on DSP controllers. Instead, it moves to the (0,0) coordinates corresponding to the home position.

So it’s possible the controller has reported the wrong coordinates or LightBurn is misinterpreting them. Both seem unlikely.

Several previous discussions suggest other folks have encountered the same problem, but with no resolution:

HELP! Limit switches changed & working but laser not respecting limits!

I have a co2 80w Chinese red and black with ruida controller RDC644XS about a year ago, on start up/when homing to the top right corner, the laser head would just bang into the rails and I’d just hit esc a thousand times to get it to stop. This happened a few times, then it was working perfectly again - until it didn’t, and has started to do this again. I was heavily pregnant at the time and had no ability to get down to change the limit switches (after asking for help on laser fb group, we su…

Ruida 6432G homes properly from controller, but homing from lightburn ignores limit switches

Hi all, I’ve just upgrades the M2 Nano on my chinese laser to a Ruida 6432G. Going through the configurations and and I’ve hit a small wall with homing. Laser homes in the right direction (upper right corner), I managed to get it to auto-home on boot (thanks to: RDC6432g will not home - #6 by oddwick ). So, my issue is as follows: When I home from Lightburn, the laser ignores the limit switches.It homes in the right direction, just doesn’t stop when the limit switches are triggered. But, and…

Home command drives laser too far

When I click on Home in Lightburn, my laser drives too far in both the X and Y coordinates. The limit switches do light up, and I can see that the signal is being received by the Ruida controller, but Lightburn just keeps driving the laser into the side of the gantry. I’ve destroyed two limit switches from this so far. What setting do I have incorrect? EDIT:: If its relevant, I have a chinese 60W with a Ruida controller.

Gathering some information will be helpful …

After the machine has homed when you turn it on, report back on these:

• Does the machine display show XY = (0,0)
• Does LightBurn Get Position report XY = (0,0)
• What happens with Move to Position set for XY = (10,10) millimeters, then hit Go
• Ditto for (0,0)

LightBurn can be use either metric or inches in both the device settings and the workspace settings. The other reported problems predate that separation, but trying all four combinations will be informative (and tedious).

@LightBurn: This feels like a controller-to-LightBurn mismatch.

[jkwilborn (Jack Wilborn)]

Are you familiar with this model? I understand it has some ability to use open source for hdmi configurations, but I don’t seem to be able to pin it down what works and what doesn’t.

I can’t imagine a Chinese product like this to have any way for a user to mess it up, at least firmware wise.

I’m thinking it’s only the hdmi that’s configurable, not the Ruida itself, but I don’t know.

–-

---

These two links came from this Reddit post, probably by the same person who posted here.

Ruida 6445G-Mod5 | Best Co2 Laser Controller

https://www.dwin-global.com/5-inch-hmi-lcd-modulemodel-dmg80480c050_03wcommercial-grade-product/

[Crispy001 (Chris M)]

Thanks for the replies.

The boot home takes it to 0,0, the HMI and light burn position match. Move to position commands on light burn appear to work correctly, I can move to an arbitrary position and back to 0,0. The HMI position matches throughout. “Go to origin” on the laser tab also appears ok.

I believe I read somewhere that Ruida controllers ignore the endstops states unless they’re actively homing. Do you have visibility into if the home command on light burn might be issuing a large negative move such as -9999,-9999 and relying on the controller?

That is my reddit post but thus far I’m still on the stock HMI and controller firmware. I haven’t received a response from Ruida or the reseller I purchased from regarding getting a copy of the HMI source.

Might be on to something with the inches/mm. I configured the machine from mm to inches in the Devices menu and sent some manual move to position commands. The UI lagged for a moment and it switched to metric when going to a previously saved (metric) position (?!?!). The x/y home commands are taking it to 0,0 on the move and laser tabs now. I know it’s not doing a true home command since I have a 10mm offset programmed in for x/y. “Go to origin” on the laser tab moves to 10,10, but I think this might be the (empty) job origin instead of the absolute origin.

To be sure I power cycled the machine and restarted Lightburn. The homing still works! While I’m glad it appears to be working now, I’m a little concerned that the unit of measure affects the homing behavior. Is there additional testing I can do to help the dev team identify the problem?

[jkwilborn (Jack Wilborn)]

@Crispy001

Ruida controllers ignore the endstops states

When a stock Ruida homes, it only looks at the - inputs on the controller. You can press the ESC key to abort a home operation. After a successful homing operation is complete it will look at the + inputs for the head going outside it’s specified configuration or limits.

I usually refer to them as home, specifically for home (- inputs) and limit switches specifically for going out of bounds.

To use limit switches you need to allow the head to go outside of the defined work area resulting in a smaller work area.

To properly use limit and home switches, it takes 6 switches. One on each end of the gantries travel and two for homing operation.

@Crispy001

-9999,-9999

As far as I know the Ruida doesn’t do negative numbers. You can move it to less than the default 10,000, but can’t go below 0. So I’m not 100% sure of what you mean or your actual question.

@Crispy001

(empty) job origin

Unlike many grbl machines, the Ruida stores it’s operation mode, so if you set a user origin, it’s set within the Ruida.

The Ruida also has a return value, set within the controller, that’s used after it homes, such as absolute, user or current origin. After a boot operation or home, it will home, then put the head to it’s proper location as defined in the controller.

@Crispy001

with the inches/mm

Again as far as I know the Ruida deals in only a metric mode, as Lightburn does everything internally in mm.

Many grbl controllers need to have, both, the software and the controller set up for the same metric, mm or inches.

[ednisley]

@Crispy001

Do you have visibility

Not from my Comfy Chair. I’m a civilian with no connection to LightBurn other than being a customer.

@Crispy001

relying on the controller

Opinion: Given the undocumented / reverse engineered nature of the whole DSP controller thing, I’m reasonably sure this is a case of “it’s worked on everything so far, but this one is different”.

As in, the KT332N controller in my machine responds differently than a KT332NZ in somebody else’s machine:

Monport Onyx R ; Z seemingly switched with U axis

This thing has a Ruida KT322NZ controller. Everything works for the most part, and this is somewhat of an oddity, which I think might be a bug in lightburn (or rather, a workaround for a different laser not applicable to the onyx R, but which can’t be disabled, as far as i can tell) In the ‘Move’ window, the reported Z position is actually the U axis position. The U axis position shown in the move window is 0.0 (which is fine, there is no U axis in this machine). The Z axis position shown in…

So, yeah, anything is possible.

@Crispy001

a little concerned that the unit of measure affects the homing behavior

That looks like an error from here, but I have no clue where it might take place.

@LightBurn: What further info would be helpful?

[jkwilborn (Jack Wilborn)]

@ednisley

@Crispy001

a little concerned that the unit of measure affects the homing behavior

That looks like an error from here, but I have no clue where it might take place.

I believe the Ruida and probably your KT322 both work only in mm, not inches. There should be no effect on a homing operation.

I know of no way to change the Ruida unit of measurement. Do you?

[Crispy001 (Chris M)]

This level of knowledge/support from volunteers is amazing, thanks Ed & Jack! I sincerely appreciate the effort. We’re lucky to have you.

More testing is needed on my end for diligence. I explored the in/mm combinations this afternoon and was not able to reproduce my original problem. The Ruida controller has no toggle for unit of measure. When saved as inches in the Lightburn Devices setup page, it shows as mm if I go back and edit the entry. I suspect this is a feature from Lightburn to override a known incorrect user input for the controller type.

I’ll run more tests tomorrow. My earlier conclusions were likely based on faulty assumptions about how the Ruida controller and Lightburn both operated. My current thought is Lightburn has been functioning as expected and the real root-cause of the crashes was the way I worked towards a valid configuration. The great news is even when operating Lightburn with the reckless abandonment that can only come from a new user, I have not managed to cause another crash.

Some key learnings on my part:
On this controller, true homing is only completed at boot when the HMI is connected.
In my first tests with the machine, I aborted the startup home since the axis direction and switch polarity were not configured yet. In some cases I didn’t have the HMI connected, and it wouldn’t home automatically without it. I believe this may have caused crashes since the absolute origin wasn’t defined and Ruida’s controller seems to have no protective measures if initialization isn’t completed. I’ll spare you my commentary on how ridiculous it seems to not utilize the endstops unless actively homing.
Lightburn does not (can not?) issue an equivalent home command for this controller.

Lastly, I’ve been assuming the Ruida controller is fully reinitialized when 24v power is reset. I think this is correct but I should verify so I’m not obfuscating results by having the USB connected.

[ednisley]

@jkwilborn

no way to change the Ruida unit of measurement

To my complete & utter astonishment, the KT332N has a switch for that:

Given @Crispy001’s findings, I put flipping that switch in the same category as cutting the red wire.

[jkwilborn (Jack Wilborn)]

@Crispy001

shows as mm

You can configure the software for inches, but still select and use mm from the edit screen, so it shows with whatever is currently selected.

You can actually enter some fields with something like 50mm while in inch mode and it’s converted.

@Crispy001

feature from Lightburn to override a known incorrect user input for the controller type.

I really doubt this.

@Crispy001

likely based on faulty assumptions about how the Ruida controller and Lightburn both operated

Very likely as all of the Ruida documentation is in Chinglish and has translation issues where it doesn’t translate properly in an English understandable fashion.

@Crispy001

not managed to cause another crash

Lightburn should not crash in any event, bad controller of screwed up configuration of the controller or Lightburn.

@Crispy001

commentary on how ridiculous it seems to not utilize the endstops unless actively homing

Don’t want to sound derogatory, but it seems ludicrous for you assume you know all about the engineering that these dsp machines encompass. It might be something simple like they want to know where the machine is operating before it starts looking at limit switches. I’ve had over 5 years dealing with these and I won’t make assumptions on how/why these are built like they are.

These are built in China for use in China at a commercial level. I don’t think we can do anything but guess on the requirements, but I do know they have no need to deal with inches as a unit. There are a lot of KT series controllers out there, and Ruida claims they make them and they may operate differently.

@Crispy001

Ruida’s controller seems to have no protective measures

What do you expect it to do that other controllers do, just halt? That would be a terrible thing if there was a home switch failure, nobody could control it enough to figure out the issue. Even grbl machine have no real state unless they home or you take the default, which is pretty much what these dsp processors use.

When a machine homes, it identifies which quadrant it’s operating within, no home, it’s totally lost. Asking again, what do you expect it to do if it fails to home that any other controller doesn’t do?

@Crispy001

assuming the Ruida controller is fully reinitialized when 24v power is reset

These are built to go into any cnc machine, so the factory has defaults that likely don’t meet your machines requirements. All vendor information is stored on the controller, so I don’t know what you mean by full reinitialized.

The more I read about this, the more I think the only thing configurable is your hmi, not the actual Ruida. It’s only a guess, but I can’t see how you’d reprogram a dsp type controller, especially with no source to start with.

Your best bet it to realize we don’t know how they work in detail and they aren’t going to tell us either.

I suspect the KT series was designed as a low cost exportable controller. Maybe buried inside mine is a way to change units, but somehow I doubt it. They’ve surprised me before.

I suggest you switch to Ethernet if possible, USB has many complaints.

@Crispy001

Lightburn does not (can not?) issue an equivalent home command for this controller.

As far as I know, there is no way to remotely invoke the home function, so Lightburn doesn’t do it.

Good luck.

[jnse (jns)]

@jkwilborn

I believe the Ruida and probably your KT322 both work only in mm, not inches. There should be no effect on a homing operation.

If only it were that simple Ruida controllers internally use 35-bit (5 * 7) integer values representing micrometer units (microns), mm or inch is just an user-interface niceness.

[jnse (jns)]

@ednisley

To my complete & utter astonishment, the KT332N has a switch for that:

That just changes the display units on their touch screen gizmo - it doesn’t affect anything in the laser or the protocol it talks. At the protocol level it’s all micrometers. The remote control touch screens talk over ethernet to the machine just like lightburn would (except, there’s a separate udp port for it), at the end of the day, inches vs mm is a function of the software talking to the laser, be it lightburn, or the touch screen controller firmware, not the laser itself.

(Not that the nuance makes a difference practically for anyone here, but i thought i’d clarify - i’ve been way too deep in to reverse engineering these things lately hahaha)