510S Homing Issues with Mini-Rambo

[CTurner]

Good Morning Ryan,

First off, thanks to you and all the folks at V1 Engineering for the Low Rider 2 design, hardware and software engineering.
I’ve been using the Low Rider 2 for over a year and am sincerely impressed with its functionality and precision.
Since purchasing the hardware and assembling the machine I’ve been trolling the forums and have been able to avoid opening any new topics thanks to feedback from you and other users.
I regret that needs to change today and apologise if I’ve missed a relevant post.
Again, thank you for putting this technology within reach of this old retiree.

My machine has the Ultimachine Mini Rambo 1.3a board with single endstops (limit switches) and was working fantastically on the Marlin 425 2.0.5.3 firmware.
Yesterday I compiled and uploaded the 510S 2.0.7.2 firmware and was having some difficulty with the x and Y homing features:
When I requested either of these axes to home, they would physically jog +5mm ,update their zero position on the controller and stop.

I am not a coder, but after using M119 and reviewing the configuration.h file for both versions I noted the following differences:

Marlin 425 2.0.5.3 Homing Logic Definitions
648 // Mechanical endstop with COM to ground and NC to Signal uses “false” here (most common setup).
649 #define X_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
650 #define Y_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.

Marlin 510S 2.0.7.2 Homing Logic Definitions
658 // Mechanical endstop with COM to ground and NC to Signal uses “false” here (most common setup).
659 #define X_MIN_ENDSTOP_INVERTING false
660 #define Y_MIN_ENDSTOP_INVERTING false

After changing lines 659 and 660 from “false” to “true” and re-compiling this version seems to works well now on my machine. Is this worthy of a change to the GITHUB image?

I have two questions for you at your convenience:

1. Could this change implemented by someone who DOES NOT undestand all the logic in the code (me) have other negative ramifications to the operation of the machine?
2. Is there any simple way to change the polarity of the knob on the Full Graphic Smart Controller? In 510S, the knob requires a CCW turn to effect positive motion
   on any axis. This was not the case in version 425.

Again, many thanks for your dedication to this technology.

In Him,
C Turner

[vicious1 (Ryan)]

Thank you for all the niceties!

@CTurner

Is this worthy of a change to the GITHUB image?

Most people using the “S” version do not use endstops so the setting is irrelevant. Homing one side is not accurate in any way.

@CTurner

Could this change implemented by someone who DOES NOT undestand all the logic in the code (me) have other negative ramifications to the operation of the machine?

No I do not think so. We plan on moving away from the “S” version since the mini’s are no longer carried. So I will be testing all of this very soon.

@CTurner

Is there any simple way to change the polarity of the knob on the Full Graphic Smart Controller? In 510S, the knob requires a CCW turn to effect positive motion
on any axis. This was not the case in version 425.

Odd, I will need to look at that it should be reversed already, but the change is in Teh configuration file further down from the endstop inverting. There is an LCD section, and a reverse all directions setting. If I remember right, just under the Enable SD card setting.

[CTurner]

Thanks for the quick response.

I’ve ordered the Rambo card with the intent of adding dual endstops to the z and y axes.

Should I download the V1CNC_Rambo_Dual 2.0.7.2 / 510 that is recommeded on the firmware page?

Thanks

[vicious1 (Ryan)]

That only works if you have the dual endstop wire set (individually wired steppers and all 4/5 endstops.

[CTurner]

That’s what I’ve got coming.

Thanks again for your help, Ryan.