Aren’t these standard NPN sinking switches? That is, when the base is sourced (in this case the base is sourced by detecting metal), the emitter / collector is closed, the controller sees a closed contact from LmtX / LmtY to ground.
It does use an npn pulldown but this, like some other prox sensors I’ve used, has some sort of internal pull-up resistor to the 24v supply. I don’t know why but it drops to 0v when tripped so ok, as long as the ruida input can tolerate 24v when untripped
Ok here’s the weird part. I’m at the machine, but not using the prox sensor at all. I’m manually grounding the ylimit+ input. The doesn’t make the ylimit+ button on the diagnostics panel light, BUT… I just noticed it makes that diagnostics panel flicker every time I touch it. What gives?
Led #4 on the ruida lights up when I ground the ylimit+ ruida input. The diagnostics panel still only flickers the whole display (not the red indicator on screen though) So the hardware input is just fine, but the config is somehow confused even at the diagnostics panel which should be low-level
Oh crap. I just had a thought. Since this is a bulky 1610 machine, the panel cable won’t reach and I extended the ruida cable a few feet. What if it’s got data integrity probs? And their cable protocol weirdly consistently craps on this bit every time and not others?
Happen to have an unmodified original ruida cable here to. Same prob- diagnostics screen flickers like a screen redraw when the input is grounded but no actual indicator on the diagnostics panel.
System info says version rdc-v15.01.10
What HMI version do you have? Ruida has this available for an HMI update (although I never got it to work)
Also, check how you have set the limit polarity in the vendor settings.
Display panel says rdc-v15.01.10, so I think it’s most recent.
I pulled out the panel for the second RuiDa and plugged it in. It didn’t throw any compatibility complaints and shows same version rdc-v15.01.10. But the same prob- triggering Y+ just makes the Diagnostics display redraw, but always indicates YLIMIT+ as “off” even though the LED4 sees it’s on.
The HMI has an independent firmware over the controller.
I’m concluding this RuiDa RDC6445G here is just defective. Does that ever happen?? I’m still baffled how it could light the LED but only redraw the Diagnostics panel. Like the LED is driven by a working comparator that buffers the input correctly but somehow the stage is only capacitively coupled to the MCU/FPGA input pin and can only create a transient response when pulled low, it triggers a redraw on the Diagnostics panel but changed back too fast to indicate “red” on that panel.
Do the status lights on the controller reflect they are operating or not? Those are your best visual, probably better than a voltmeter.
It’s questionable that it has an intermittent or sounds like it has one, which has to be fixed before you continue any diagnostics.
If you have to, move the keypad the ‘standard’ distance, (remove the extension) to see if that will fix the issue.
Can’t look at an led and tell how fast it’s toggling.
I had to move my x axis limit, so chased it down.
I run my hall effect limit switches on 5v, the input/output of it will handle the placarded voltages. Since the inputs of the Ruida were designed for either mechanical or electrical limit switches, the Ruida will pull those inputs high and wait for you to pull them active (low.)
The 5v runs the electronics on my switches, and it just completes the path to ground when active.
They don’t produce a voltage, they sink current.
This read correctly when changing to another rd6445. And can be configured to home now. So the controller could somehow light the LED but couldn’t actually read the pin
It’s just an indicator, there is more electronics after the led, but it’s better than a guess to where the problem is.
Good luck, take care… What are you going to do with the old controller? I’m in Arizona are you in the US? I would love to take it apart, it’s probably not fixable, but you never know. It’d be good education material for the right person.
Good luck, glad you’re up
Take care
Oh I’m taking it apart first!
OK I’m guessing this is an opto-protected input inside the Ruida to protect the microcontroller pins from 24V, reverse voltage, or ESD events, and, now that I think about it, an opto is about the only thing that will fail this way. The internal LED has a busted bondwire barely making contact and will flicker once as power is applied, then the bondwire kicks away from the pad and and it won’t light again. Your standard flickering busted LED.
Fortunately the opto won’t be on a microcontroller or FPGA or integrated into anything except a package with more than one opto. So, this should be replaceable.
So, BTW, on the NEW controller, this only finally worked when I switched the homing sensor on the far side of Y to the “YLimit-” input. This made no sense to me, since Y=0 would usually be on the near side and Y+ is going further away, so this should be “YLimit+”. But, it works, and the jog pad “UP” arrow moves the gantry away from me, so I’m going with that
On the other hand, this indicates to me I can still use the “broken” controller if I just use the YLimit- input, since that seems to actually do what I want. On my other machine, the YHome switch is on the far side of the machine too.
Which side of the coupler is the led on?
I’d guess it’s on the ‘other’ side of the coupler from where you can get to it… otherwise you’d have to deal with 24v across it…
Look at the controllers display and move the y axis towards the front of the machine. Is Y increasing or decreasing?
The definition of LmtX- and LmtX+, - indicates 0, + indicates max.
Ok you’re right, y homes ok that way, y-up button moves the gantry away to rear and but numerically y is decreasing when I press y-up
I moved the switch on the rear of y to ylimit+, changed settings back and forth and right now I’m stuck in that yup button moves away from you, and y coordinate increases, both good, but homing moves gantry TOWARDS me
I found under machine config there is “y home” and I changed to “above” and back to “below” and it changes nothing with either
Dir polarity=pos
Keying direction=positive
Lmt polarity=negative I have npn normally open inductive prox sensors
Enable limit trig yes, enable reset yes pwm rising edge v no
Anything I change or sets of changes seems to just mess it up worse, what’s the magic settings? I was sure machine config y home=above should work but I flipped back and forth and it makes no difference, y tries to home towards me with either setting
If one of the axes is going the wrong way at reset you can change “Direction polarity” for that axes.
I couldn’t follow all of what you tried to tell me.
Looks like you’re ok.
I would set the ‘limit trigger’ to false. Mine are set that way and it home properly. To home requires limit switches, only servo systems know where they are at power up.
The manual is not very helpful with
“Enable limit trigger: Whether used for enabling the axis of the hard limit protection function.”
The “hard limit protection function” is only mention in the previous page, with no explanation.
At this point, we, I, may be missing something. Let do one issue at a time.
BTW, don’t use any of my numbers… I’ve got the rotary on it and most of the movements are suppressed so I don’t throw my cups around…
I couldn’t follow all of what you tried to tell me.
I just can’t get it so Y-up button moves the gantry away, and Y increments away from you, and it will stop on the YLIMIT+ which is physically on the far side. Seems like I tried all iterations and can’t get all 3 at once. Y-up moves towards me, or decrements Y as the axis moves away, and/or isn’t homing to YLIMIT+. I thought the “Y HOME=Above” was the obvious missing piece but it seems to do nothing at all.
If one of the axes is going the wrong way at reset you can change “Direction polarity” for that axes.
If I do that, the up-arrow still increments y, but it physically moves to the front, wrong dir. My interp is it just inverts the dir at the Ruida output itself, low level. Same as swapping 2 wires on an open loop stepper or inverting dir in the external hardware stepper driver’s config.
I’m operating off the Ruida 6445 panel, I feel we need to see that work first before bringing LB’s interface layer.
I would set the ‘limit trigger’ to false. Mine are set that way and it home properly. To home requires limit switches, only servo systems know where they are at power up
So, we don’t know what hard limit is? I think it’s saying it’s not for homing, but an emergency stop. Like I might home with LIMITX-, but still include a LIMITX+ switch that should only be hit if something is horribly wrong and it’s crashing the axis and we need to abort the job. But it’s not individal LIMIT+/-, is it? Maybe it means the LIMIT input that is NOT for homing should be an emergency abort thing?
Actually a limit switch is in ‘theory’ an emergency stop. That is old technology, today most use them for initial location, or where absolute 0, 0 is.
Don’t think anyone puts a switch behind a switch in case the first one fails. Not to mention you have now made the machine size smaller. The Ruida won’t recognize one of the switches while moving, but most grbl boards generate an error if it happens. It being Chinese, maybe you can parallel them?.. I will pull one low and see what happens next time I think about it. It mus have some use I’m unaware of. In my machine they are not true and it homes properly.
I’m not sure what the end product here is. Are you trying to operate in a specific quadrant?
Theoretically you should be able to home in any corner for any quadrant. However I’ve read about lots of people pulling their hair out doing this. What you need is someone that’s done this and can give you better information on what must be modified.
This comes up so much, I’ve looked into buying a Ruida for my desk and the CNC3018 I have.
It has hall limits on both ends of all axes, which would make it a great test bed. It would also make it easy to switch each hall to Lmt - or + inputs. It would also cost me about 350 bucks… 
Currently trying to setup my lps for my tubes current limit. 
Take care.
