Z Endstops Ignored - Megatronics 3.0 - Homing Dual Endstop LowRider2

Hello!

New here. Fairly well versed with 3D printer builds (RepRaps). I was preparing to post my LowRider build, however, I ran into issues getting Z to home and I’m not quite sure how to resolve it. Trying to adjust from 3D printer to CNC mindset, while being careful to not breaking things.

I’m using a Megatronics 3.0 board, with Marlin 2.0.7.2, uploaded via PlatformIO.

I made the changes that I know to make, comparing them with the V1 firmware config.h and adv. files.

I inverted the endstop logic, so my switches show ‘open’, not triggered in pronterface when the machine is not touching them. I’m not exactly comfortable with them the other way around during initial testing; trying to avoid bashing axes. What’s the point NC/triggered, when the switch isn’t physically closed? It’s not logical; especially when you can invert the behaviour in the firmware anyway?

I have X and Y working properly; both move and home.

Z is set to home by moving up (using pronterface + moves it down and - moves it toward home/up). I leveled the endstops on the machine the best I can for testing purposes, bumping the machine down 1mm until both switches closed. Sending M119 reflects open/closed states correctly. Went to home Z for the first time and it bashed the axis, I pushed the emergency stop :crazy_face:

I moved the axis 40mm from home, triggered movement, and pushed the endstop switch… it doesn’t stop the motor; same behavior exhibited on Z2.

So the switches work, motors work, but the switches don’t stop the Z motors.

I searched the forums, but didn’t find a specific example. Seems not many people are using the Megatronics board.

I’m suspecting it might be some issue with pins relating the endstops to the motors on the Megatronics board? Or some very simple mistake in the config or adv file. Limited knowledge of changing the pins; I know where to find them for the motors, for example, but I haven’t messed around with it.

I know some of you are pros at Marlin and have a greater knowledge of manipulating it than I do, so here’s my current config, config_adv, pins (unmodified) for the Megatronics3.0. Overview and links to documentation for the Megatronics 3.0 is here.

Config.h
Config_adv.h
Pins for Megatronics

Steppers are currently wired Z, Y, X, E2=Z2, E1=Y2, E0=Unused

My endstops match those in the instructions provided by V1. Wiring to the Megatronics

Physical endstop setup (same on both sides)

What Pronterface shows for endstops in terms of labeling
endstopspontertroubleshooting

I hope that helps with troubleshooting, if other files are needed, please let me know.

Thanks!

The reason for wiring the switches NC is because that arrangement is more tolerant of electromagnetic noise. When wired NO spurious “triggered” signals are much more likely. Wiring NC and inverting in firmware will be more reliable.

This is opposite of CNC convention, and may be the source of your problem. If the switches are wired as per V1 instructions than the controller is looking for a triggered Min switch as it is moving in the negative direction, but the switch it is hitting is wired as the max switch. Unplugging the Z steppers and rotating the plugs 180* should invert the logic.

Can you take a picture of the other side of your end stops for me as i have a feeling they the type that need to be powered. Also if you have a meter check for continuity across the terminals with the switch pressed and not pressed and report back.

Thanks for the replies/help!

@Paradox_Pete
I remember running into EMI with endstops early on 3D printing; cleaned up the wiring and the issue stopped. I take it is because there is more wiring with CNC machines the chance for interference increases significantly when compared to 3D printers?

I’ll invert the logic in the firmware and try to confirm they are wired NC and ground; I haven’t done that before, so I likely screwed that up (see comment to @Britboard below).

Instructions indicate that the machine is to home with the gantry at max height? I figured this is so that it’s easier to load materials and probe material height?

Hitting home in pronterface currently moves the gantry in the -/home direction, upwards, and toward the endstop that’s fixed on the lower bit of my z tubes. Earlier today, prior to my initial post, the gantry was going the other direction, away from the endstop when clicking the -/home button. I flipped the stepper wires to reverse this to avoid homing indefinitely downwards and slamming the gantry into the lower Y carrier plates.

I can swap it back to test the endstop switches and see if the behaviour changes, however, that would make the homing button for Z in pronterface useless (unless there’s a way to invert it in pronterface, so you can still home). Otherwise I would think the issue rests with the endstops/firmware?

@Britboard
I wired the switches with green (signal) wire and black to (ground).

They’re just the standard mechanical makerbot type (3 pin); as far as I know they do not have to be powered to function unless you want to use pull ups. Cut the red wire off. All 5 test as functional in pronterface when open/triggered.

Connecting the signal (green) and ground (black) wire does not have continuity when the switch is open and does when it is pressed.

Connecting the red wire and ground (black) wire has continuity when the switch is open and does not when it is pressed.

Thus, it sounds like I goofed up and wired the switches for NO and not NC as they should be if I intend to invert the logic as recommended by @Paradox_Pete to avoid EMI?

Cool, at least we know the switches work as they are supposed too, i have got some here that won’t pass through unless they are powered thought you might have similar ones.
Z- should be towards the bed, not up. You should be able to switch the direction each axis wants to home in the firmware and also state it has a Z-max end stop switch.

Yeah! I’ve seen those endstops on the market and try to avoid them. I’m going to sort the homing issue before rewiring the to NC and invert logic; as I’ve wired them to NO by accident/habit.

Sounds like there is consensus that I’m homing in the incorrect direction by going up instead of down, yet there are multiple examples of both approaches. I set my Z endstops to home ‘up’ like those on @kzdesign’s machine. Z is also noted as homing up in Ryan’s setup docs, which is another reason I initially went that route and thought it was normal to ease material loading and probing operations on the lowrider.

I find it strange that pressing either Z1 or Z2 endstop switches won’t stop a Z motor, but I’m also use to only having three min switches. If the firmware is looking for Zmax then Xmax I could see why it might not trigger. Still learning…

I’ll confirm that the Z1 and Z2 endstops are on the right ports for the given motor tomorrow and try flipping the motor wires as recommended by @Paradox_Pete and @Britboard. Homing direction in firmware is already flipped. I’ll let you know what happens!

I don’t know about configuring the firmware for this, as I don’t use Marlin myself, and I don’t use the dual end stops either.

The issue with the end stops not stopping the Z travel is due to the switches being configured as Z_max switches, but the machine moving in the negative direction means it is expecting a Z_min switch to get triggered.

I’m sure it is possible to home up and in the positive direction. Hopefully someone familiar with configuring this will be along. I’m sure @vicious1 could help. Hopefully he will be by.

I flipped the motor wires this morning and pressed the endstops during motion, in both directions; still failing to stop the motors.

Changed the homing direction back to -1 ( -1 for all axes like it is in Ryan’s firmware file), tested with the motor wires flipped both ways, and triggered the endstops during motion, in both directions; still failing to stop the motors.

It’s like the switchboard person between the endstop switch and Z motors is out to coffee!

My Z motor is plugged into Z1 (Z motor, Zmax/+) and Z2 (E2 motor, Xmax/+). E0 is unused. Z1 should definitely trigger, but it is not.

I have a spare Megatronics board, stepper, and endstop switch. To avoid breaking the machine, I’m going to bench test and explore solutions in the mean time!

Mate, you were onto something!

Bench testing for a while now. Almost gave up. I decided to enable the //#define ENDSTOPS_ALWAYS_ON_DEFAULT line in config.adv — the behavior of the switch/motor finally changed. Pressing it turned the motor on, letting up, turned it off.

I decided to disable the above and hook up the VCC/+/Red wire and sure enough — if you hit home and press the endstop switch the motor stops. The supplier apparently sent me switches that must be powered to function, instead of ones that can be operated without VCC/+/red connected.

They’re still wired NO. To wire them NC, I simply need to reverse the signal (green) and ground (black) wires?

I double checked all of the axes, using powered endstops, hitting home, and then pressing the endstop switch. Here are the results:

X = working
Y = working
Y2 = working
Z = not working
Z2 = working

I tried both sets of pins for Z and tried swapping the motor wire each way, while homing (considering the commentary above); neither worked.

Later this evening, I had a hunch that maybe Z1 is waiting on signal from the probe (which I don’t have or have anything connected to) it’s mapped to Zmin. I moved the Z1 endstop wiring to Zmin, tested it by homing; depressing the endstop switch now causes the motor to stop!

Z1 endstop is on Zmin, not Zmax — despite Zmin being enabled as the probe in Marlin
Z2 is on Xmax

It looks like you can designate an endspot pinout for the probe in ‘probe settings’ to correct it? I’m assuming one could simply use the Zmax for the probe instead? A probe is not required (could be disable it entirely), but might be nice?

Updated config and config.adv files.

Beginner users sometimes home the machine without endstops. It is better that they trigger and stop. Experienced users (like yourself) can set it how they like. Also, if a wire comes loose, the machine won’t go anywhere on a home.

First, set Z+ to up. All the CAM software assumes this. If you want to home up, check out the configs we have for DualLR in MarlinBuilder releases. We have the home dir +1 and then set up G38.2 probe on zmin.

Make sure you have Z1 motor lined up with the Z1 endstop. If they are switched, one will continue forever.

If M119 is correct, everything else is in Marlins hands.

Don’t flip wires, bad idea for lots of reasons, should be wired (red to power, black to ground, green to signal), flip the true/false’s to get them to read correctly.
I’m at work right now and in a different time zone UK, leave everything and give me a chance to get home and scan the configs you posted and i’ll get back to you.
In the mean time measure the physical dimension of your tables cutting limits and enter them into the “Bed size” in config h.
Where are you based as this may be simpler if we chat via a video call whilst you are at the machine.

OK, been on the case and looked through your files,
First thing, can i establish if you have a display attached or are you interfacing with a computer via Pronterface etc?, if you have a display with a control knob connect it (you may need to include u8glib in you firmware) this will allow me to write some command codes that you can use to do things (homing/positioning etc) with a 1 button presses.
What i you need to do for me first is connect all the motors and limit switches and check the motor directions/travels are good, positive numbers move away from 0,0 X,Y positive numbers move away from the bed on Z. I would suggest you make your homing position bottom left near your controls.
Then check your end-stop switches are all working i.e correct motors stop during homing when pressed.
Put Z max end-stop on Z-MAX pins on your PCB,
Put 2 wires from Z-MIN (signal and ground) and make it so you can touch the ends together for testing purposes.

If you look at your firmware codes you will see that it wants you home towards the bed, that’s fine, we can change that if you are insistent on it homing max, but if you have the display i feel it would be better to reference it to the bed or part and then add a script to make it then retract to a distance you require.

Set all the items to the values i have listed, if it homes towards the bed (and it should) on Z touch the 2 Z-MIN wires together it will back off then slow home touch them together again and that will be Z home. so if you make a homing plate and 1 wire goes to the plate and the other crocodile clips to the tool bit you can home using that. we would need to set the homing plate height into firmware to compensate, but we can deal with that when you have made a plate.

Try all this and let me know if it all worked, then if you attach a display, post a picture so i know what we have and how it works and i can start scripting for you.
Good luck

CONFIG “H”

962 #define Z_CLEARANCE_DEPLOY_PROBE 10 // Z Clearance for Deploy/Stow
963 #define Z_CLEARANCE_BETWEEN_PROBES 0 // Z Clearance between probe points SIMON
964 #define Z_CLEARANCE_MULTI_PROBE 0 // Z Clearance between multiple probes SIMON
965 #define Z_AFTER_PROBING 0 // Z position after probing is done SIMON

1118 #define X_HOME_DIR -1 //HOMES TO MIN CORRECT
1119 #define Y_HOME_DIR -1 //HOMES TO MIN CORRECT
1120 #define Z_HOME_DIR -1 //HOMES TO MIN CORRECT

1125 #define X_BED_SIZE ??? //SET TO YOUR SAFE TRAVEL/CUTTING DISTANCE X
1126 #define Y_BED_SIZE ??? //SET TO YOUR SAFE TRAVEL/CUTTING DISTANCE Y

1145 // Min software endstops constrain movement within minimum coordinate bounds
1146 #define MIN_SOFTWARE_ENDSTOPS // JOSH CORRECT
1147 #if ENABLED(MIN_SOFTWARE_ENDSTOPS)
1148 #define MIN_SOFTWARE_ENDSTOP_X
1149 #define MIN_SOFTWARE_ENDSTOP_Y
1150 //#define MIN_SOFTWARE_ENDSTOP_Z // JOSH CORRECT
1151 #endif
1152
1153 // Max software endstops constrain movement within maximum coordinate bounds
1154 //#define MAX_SOFTWARE_ENDSTOPS //CHANGE THIS IT STOPS CRASHES SIMON
1155 #if ENABLED(MAX_SOFTWARE_ENDSTOPS)
1156 #define MAX_SOFTWARE_ENDSTOP_X
1157 #define MAX_SOFTWARE_ENDSTOP_Y
1158 #define MAX_SOFTWARE_ENDSTOP_Z
1159 #endif

CONFIG ADV “H”

656 #define HOMING_BUMP_MM { 7, 7, 3 } // (mm) Backoff from endstops after first bump SIMON
657 #define HOMING_BUMP_DIVISOR { 4, 4, 5 } // Re-Bump Speed Divisor (Divides the Homing Feedrate) SIMON
658
659 #define HOMING_BACKOFF_POST_MM { 2, 2, 2 } // (mm) Backoff from endstops after homing SIMON

lines that may be of interest.

1107 //#define NO_MOTION_BEFORE_HOMING // Inhibit movement until all axes have been homed
1108
1109//#define UNKNOWN_Z_NO_RAISE // Don’t raise Z (lower the bed) if Z is “unknown.” For beds that fall when Z is powered off.
1110
1111//#define Z_HOMING_HEIGHT 4 // (mm) Minimal Z height before homing (G28) for Z clearance above the bed, clamps, …
1112 // Be sure to have this much clearance over your Z_MAX_POS to prevent grinding.
1113
1114//#define Z_AFTER_HOMING 10 // (mm) Height to move to after homing Z

1 Like

@jeffeb3

  • Implementing NC endstops
  • Set Z+
  • Used a mid-2020 ‘Dual LR_T8_32step’ firmware release as a reference (I can’t get the newest firmware from V1 to compile in PlatformIO IDE; missing library and possibly other error/s)
  • Will build a probe once homing is sorted.
  • Endstops are all aligned and calibrated (adjustable for squaring).

@Britboard
Cheers for your efforts and taking a peek in my firmware files. I will definitely implement as much of your code changes/comments above moving forward.

I’m in Ohio, USA. Swiss American, ancestors stopped in London, so a touch of British. I went to university in Melbourne, Australia and work in international research. Culturally flexible, collaborative, and easily entertained. My machine is in the basement, snow on the ground here, so it’s a bit cold; I escaped to bench test in the warmth!

Implemented:

  • Not playing with the wires, to avoid frying the mega.
  • Bed size set to 1270,1270, 150 (conservatively set Z at 130-150, 178 max)

I messed around with the endstop switches a bit more today using my multi-meter to find that they can ONLY be wired NO; they will absolutely not function as NC switches. I have bare switches like Ryan sells on hand, so I tested them on the bench (Signal as COM and GROUND as NC) and they check out using multimeter and M119 results with the appropriate logic set to false in firmware. For anyone confused with NO/NC wiring this is an excellent video.

I need to manufacture mounting plates and install them on my machine before moving ahead.

I have SD/LCD support disabled. I’ll be directly interfacing the LowRider with a old laptop/Raspberrypi via pronterface/Fusion360/CAM software. Wiring an LCD to the Megatronics V3 board sucks; some non-standardized pin out.

@Britboard will implementing some/all of your code without an LCD create significant issues?


GOOD NEWS
Late last night, I discovered/realized that Z1 failing to home had something to do with the ‘Z Probe Options’ and a Megatronics 3.0 use specific conflict. I also found this thread on GitHub, which seems to follow the or some of the issues presented by my machine.

Disabling the probe entirely, caused ZMAX to finally work as the endstop for Z1.
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

I read the probe settings and found that the default pin for ZMIN is set to PIN32, which is for RAMPS, NOT Megatronics 3.0. I re-enabled the probe (above) and defined the line in the section below to reflect PIN19, which is ZMIN on Megatronics 3.0 according to the pins file (located under mega) in the Marlin library.

/**

  • Z_MIN_PROBE_PIN
  • Define this pin if the probe is not connected to Z_MIN_PIN. // Maybe bad advice * **If not defined the default pin for the selected MOTHERBOARD
  • will be used.** Most of the time the default is what you want. // NOT TODAY…
    • The simplest option is to use a free endstop connector.
    • Use 5V for powered (usually inductive) sensors.
    • RAMPS 1.3/1.4 boards may use the 5V, GND, and Aux4->D32 pin:
    • For simple switches connect…
    • normally-closed switches to GND and D32.
    • normally-open switches to 5V and D32.

*/

#define Z_MIN_PROBE_PIN 19 // Pin 32 is the RAMPS default; Pin 19 is Megatronics 3.0

Upon testing, this fixed my Z homing issue on the bench. ZMAX now functions as a homing endstop, YMAX functions as a homing endstop, and triggering XMIN while homing Z causes the motor shaft to move a small distance (half a turn maybe, pretty sure it’s related to whatever the probe touch/retract distance is set at).

This is something @jeffeb3 might be specifically interested in as I found this topic to be helpful in troubleshooting the issue/s.

I will implement new NC endstops, manufacture a probe (sounds like I might need one anyway), flash my bench tested firmware, and carefully test homing on all three axes with the machine, and report back!

Probably wise to report back before attempting to go probing things…

Great to hear your making progress, cheering you on :grinning:
Swiss American, do you ever get back to Switzerland, Love the country myself so much that i lived in a place called Beatenburg just north of Interlaken for about 10 years until the money ran out. would love to go back for good.

1 Like

FIXED

@Britboard Cheers! I’m over here working like crazy to finish the machine up. I haven’t made my way back to Switzerland, but I was accepted as a doctoral applicant a couple years ago at EPFL in Lausanne. Unfortunately, the multinational project funding flopped and there were data availability concerns surrounding Bhutan. Beatenburg and the Interlaken area are gorgeous. If you can get in, it’s a great place!

Implemented:

  • Replaced NO switches with NC switches and mounts
  • Programming changes from bench and topic to @Britboard’s code above
  • My previous post above marked as solution

I did end up swapping homing to +1 and flipping the motor wires to sort the direction due to the setup of my machine as recommended by @jeffeb3

Firmware configuration files with solution for Megatronics 3.0 (fix may work for other boards exhibiting similar issues)
Configuration
Configuration Advanced

Successfully Homing
https://youtu.be/-57Xxx8PT_0

Planning to manufacture a probe tomorrow and work to implement some of Simon’s code above. Will let you know how it goes! Hopefully I can get the probing behavior sorted a well! Thanks for the help everyone! Much appreciated!

Probe manufactured!

@Britboard I’ve done the following to implement your code into the firmware. Your advice is going to be embedded/enshrined as ‘// britboard/simon’ as will ‘// @jeffeb3’.

CONFIG “H”
FIXED: 962 #define Z_CLEARANCE_DEPLOY_PROBE 10 // britboard/simon
FIXED: 963 #define Z_CLEARANCE_BETWEEN_PROBES 0 // britboard/simon
FIXED: 964 #define Z_CLEARANCE_MULTI_PROBE 0 // britboard/simon
FIXED: 965 #define Z_AFTER_PROBING 0 // britboard/simon
MODIFIED #define Z_PROBE_LOW_POINT 0 // to avoid probing below probed point due to fixated bed/workspace

FIXED: 1118 #define X_HOME_DIR -1 //HOMES TO MIN CORRECT
FIXED: 1119 #define Y_HOME_DIR -1 //HOMES TO MIN CORRECT
FIXED: 1120 #define Z_HOME_DIR +1 //HOMES TO MIN CORRECT // Jeff!

FIXED/SET: 1125 #define X_BED_SIZE 1340 //
FIXED/SET: 1126 #define Y_BED_SIZE 1250 //
FIXED/SET Height Size set to 100 // Safe play range! 120-121 is max before crashing into Y!

SECTION RETAINED
1146 #define MIN_SOFTWARE_ENDSTOPS //
1147 #if ENABLED(MIN_SOFTWARE_ENDSTOPS)
1148 #define MIN_SOFTWARE_ENDSTOP_X
1149 #define MIN_SOFTWARE_ENDSTOP_Y
1150 #define MIN_SOFTWARE_ENDSTOP_Z // enabled after nearly crashing Z
1151 #endif

1153 // Max software endstops constrain movement within maximum coordinate bounds
FIXED by enabling section, correct?
1154 #define MAX_SOFTWARE_ENDSTOPS //CHANGE THIS IT STOPS CRASHES SIMON
1155 #if ENABLED(MAX_SOFTWARE_ENDSTOPS)
1156 #define MAX_SOFTWARE_ENDSTOP_X
1157 #define MAX_SOFTWARE_ENDSTOP_Y
1158 #define MAX_SOFTWARE_ENDSTOP_Z
1159 #endif

CONFIG ADV “H”
FIXED 656 #define HOMING_BUMP_MM { 7, 7, 3 } // (mm) Backoff from endstops after first bump SIMON
FIXED 657 #define HOMING_BUMP_DIVISOR { 4, 4, 5 } // Re-Bump Speed Divisor (Divides the Homing Feedrate) SIMON
RETAINED > 659 #define HOMING_BACKOFF_POST_MM { 2, 2, 2 } // (mm) Backoff from endstops after homing SIMON

Lines that may be of interest.

ENABLED FOR SAFETY 1107 #define NO_MOTION_BEFORE_HOMING // Inhibit movement until all axes have been homed

RETAINED 1109 //#define UNKNOWN_Z_NO_RAISE // Don’t raise Z (lower the bed) if Z is “unknown.” For beds that fall when Z is powered off. (Better Z is lifted than running over a board/clamps in workspace

ENABLED FOR SAFETY - may increase to further avoid material/clamps and reduce upward homing times 1111 #define Z_HOMING_HEIGHT 25 // (mm) Minimal Z height before homing (G28) for Z clearance above the bed, clamps, …
1112 // Be sure to have this much clearance over your Z_MAX_POS to prevent grinding. (How’s that going to work with my upward homing orientation? If my Z height is set to 150mm, does setting the above add 25mm to my ‘homed’ Z height (the max, which will likely get constrained by the endstop limits above)? It’s worded a bit oddly in Marlin)

RETAINED due to upward homing orientation 1114//#define Z_AFTER_HOMING 10 // (mm) Height to move to after homing Z

Do you put the thickness of the probe into Marlin or is it only sent in gcode prior to starting a job? My probe plate is 1.60mm. Basic process as far as I know is to home the machine or simply move endmill to work piece benchmark, hook up probe, send something like the below, unhook probe, and start a given job?

G28 Z

G92 Z1.6

G0 Z5 F480

I’m going to hook up a marker and just use the machine to draw/plot for a while until I have the movement spot on, logical, and safe. It will give me time to choose a router and further improve my skills in Fusion 360, Rhino, and CAM. Adept at sketchup, but it’s time to move onto something new.

I’ll make my config files available here once it’s working well. I’ll post my build in the coming days :hammer_and_wrench:

Update: First output! Crown test works! Figured out how to set relative origin with G92 X0 Y0 Z0 after accidentally drawing on the table. Some issues sorting depth at file save on the first two crowns and my cardboard pen holder for testing wasn’t an entire fail

@Britboard @Paradox_Pete @jeffeb3

Thanks for your help! Everything seems to be sorted now and working well more or less.

Preparing to post my build in the builds section!

3 Likes