Dual Endstop board issue

So I finally got around to wiring up the primo last night. I am able to make the machine jog around by sending G01 X00X and it does a decent job when I do 1 mm at a time. Anything really more than that and the machine does like it. I then stated poking around and folks have been asking what M119 returns.
x_min: TRIGGERED
x2_min: TRIGGERED
y_min: TRIGGERED
y2_min: open
z_min: open

I also threw on the non dual end stops version of the firmware to see if the M119 command showed up different and all were showing open. I didn’t attempt to run the motors because they are not wired in series.
x_min: open
y_min: open
z_min: open

I am using an arduino mega with a ramps 1.4 and A4988 stepper motor drivers for Nema 17 Bipolar 59Ncm motors.

Doesn’t seem like the motors or the drivers are the issue but I am wondering if the board is borked. Any suggestions

The first thing that comes to mind is that you wired the end stops incorrectly. For the dual end stop version, the firmware expects all the switches to be normally closed for X1, Y1, X2 and Y2. The Z end stop/touch plate is wired normally open. For Y2, you either wired it correctly, or you have a short in that wiring. You get a different reading for the serial version because the firmware expects normally open for the end stop switches in that version of the firmware. I don’t know if this is intentional or just the default for the Marlin firmware before it was setup for the dual end stops.

Note that normally closed switches is a safety feature so that if a wire is knocked loose, homing for that motor stops rather than the stepper continuing to run until it is physically stopped. If you need normally open for some reason, it is a quick fix in the firmware to make that change.

I dont have the wires plugged in at all though… I would have expected x1, x2, y1 and y2 to read the same

1 Like

If you don’t have anything plugged in, then everything but y2_min is reading correctly for both versions of the firmware. y2_min is a problem. If it is not shorted somehow, then probably the pin itself has a problem. It is possible that the pullup resistor for this pin is not functioning, and that pin is floating. If so, you can fix the problem by wiring a 20k resistor between the S pin and the + pin.

You can safely ignore the endstops until homing. They are ignored in the firmware until you home.

Do you have all 3 jumpers installed under the a4498s?

Have you adjusted the voltage on the a4498?

Regarding the endstops, the y2 doesn’t look right and the Xmin and Ymin both look wrong in the serial firmware, unless you shorted them. But ignore this until you have it moving the right direction and amount for each axis.

The ramps firmware also is configured for drv8825s. The big difference is the steps/mm is twice what it should be. You can fix that with M92 X100 Y100 Z400. And then save that change with M500.

For whatever reason, the configuration of the end stops is different between the dual end stops and the serial version.

Dual end stop version:
#define X_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING true // Set to true to invert the logic of the probe.

Serial version:
// Mechanical endstop with COM to ground and NC to Signal uses “false” here (most common setup).
#define X_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
#define Z_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
#define X_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING true // Set to true to invert the logic of the probe.

So his readings are consistent between the two versions, but Y2 is still a problem. Personally I think there is a good reason to change the serial version to match the dual end stops version. In particular, if someone “accidentally” homes XY on the serial version, the router is driven until it cannot move. If the logic is reversed, the firmware would think that it is already home and only move a tiny bit as it tests home. Plus if someone wanted to add end stops to the serial version, the firmware would already expect NC connections.

1 Like

Ok. You’re right then.

I was mainly using the duel end stop firmware so was using all 5 A4498’s.
based on the calculations i believe my vref should be .9

I was able to get the motors to move 1mm in both directions. I will check the steps and see if that helps in that regard.

When I do the M92 command things seem to get better when jogging the machine, not 100% but certainly better. When I tried the M500 to save the changes i get the following: Error:EEPROM disabled

I am using the following firmware and had reflashed it completely as I wasn’t 100% sure what was on there prior.

any idea on what might be causing this?

I just took a look at configuration…h for the Ramps dual end stop version. Saving to EEPROM is disabled. This is the line:

//#define EEPROM_SETTINGS // Persistent storage with M500 and M501

When I look at the configuration.h for the Rambo version, this line is not commented out, so persistent storage is enabled. I don’t know if this is an oversight, or if there is something particular to the Ramps boards where persistent storage should not be enabled. I’m guessing it is an oversight since both boards are driven by the same microprocessor.

1 Like

Sorry, we must have missed that setting. This is one reason why we started the MarlinBuilder releases firmware. It is more obvious what we have configured or not.

I would flash the newer version (v508) and see if that fixes it. It will at least fix the eeprom error.

1 Like