Both x and y. I do have endstops installed and they do seem to be wired correctly, though I don’t know if I have to configure them…?
I wondered if the issue could be belt tension or bearing tension? Where do I start?
Edit: I have the Rambo 1.4 board with the dual endstop setup. I noticed immediately when I first powered on the board/steppers and moved the axis’ that they steppers weren’t in sync even before I tried to home them.
How are your steppers wired?
Some more information about your build would help us understand…what control board, who installed the firmware, etc. My first thought is grub screws. If one the pulley is not tight, it will slip under strain resulting in lost steps for that stepper motor.
My second thought is that only one stepper is running and it is dragging the other side along with it. This would happen if you have the serial/series firmware installed but wired your machine up as dual endstop. You can rule this issue in/out by first moving both the X and Y axes just a bit, then checking both ends of each axes to see if you can move it easily. Once you make a move, the steppers should be engaged and the axes should not move under moderate pressure.
There are few other less likely reasons like the microsteps not being set the same between the two drivers, or you used steel reinforced belts and they broke, but I’d check these two first. Note that if you built your machine wit the V1 specified parts and are using the correct V1 firmware, configuration/calibration should not be required beyond possibly setting the bed size in the firmware.
I have the Rambo 1.4 board with the dual endstop setup. The firmware came preinstalled from V1. I noticed immediately when I first powered on the board/steppers and moved the axis’ that they steppers weren’t in sync even before I tried to home them.
Oh I didn’t realize I need to set the bed size in the FW.
You don’t need to set the bed size, just that if it’s more than 600mm (I think that’s what it’s set for) from the corner in X or Y, homing will fail and you’ll need to try again.
The endstops shouldn’t need configuration, but they do need to be located correctly. X_MIN should be next to the motor that is plugged into the “X” driver, X_MAX should be next to the motor in “E0”, Y_MIN should be next to the “Y” driver motor, and Y_MAX next to the “E1” motor.
If you have the serial wiring firmware, then X2 (E0) and Y2 (E1) motors won’t be powered up, and though they won’t move on their own, they won’t lock either, so they will be dragged along by their counterparts. They CAN be dragged along, though because they don’t lock.
You can check the firmware revision on the LCD when it powers up. 510D shoud be the dual endstop firmware. 510S (or is it just 510?) is for serial wiring, which does not have the dual endstops configured.
The motors should be moving in synch with the standard firmware. If they are not, then something isn’t wired right, or the firmware has been altered.
Do you have a video of it moving? We might be able to spot something easily that way.
Grub screws might be something of a running joke, but it honestly causes more problems than people think, and they can cause a multitude of different problems, including this.
Is the movement smooth and even? Jerky movement that changes speeds is indicitive of a problem. It could be mechanical, such as binding or loose grub screws, or it could indicate a poor electrical connection of a motor to the mainboard. Again, video would be very helpful.
Any noise from the motors? Some is normal, a sort of almost musical whine from the stepper drivers is pretty typical. Grinding or chunky noises are not. Skipping steps makes a pretty raucous noise and you’ll see the belt vibrate a lot.
That is a strange symptom. Not common at all. More common is one motor doing nothing and it just looks like they are moving separately. Here is what I would do:
If they are all rigid and still moving different distances or speeds, then post a picture of the controller so we can see how it is wired and then check the firmware version with M115 and M119.
I can verify that the X2, Y2 steppers are not powered which seems suspect.
Here is the M115
10:56:18 AM: FIRMWARE_NAME:Marlin 418 bugfix-2.0.x (GitHub) SOURCE_CODE_URL:GitHub - MarlinFirmware/Marlin: Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine. PROTOCOL_VERSION:1.0 MACHINE_TYPE:V1 CNC EXTRUDER_COUNT:0 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
I bought the Rambo 1.4 directly from V1 with the firmware already flashed for what I thought was the dual endstop setup.
I did notice that I have my endstops connected as normally open, not normally closed.
< 10:58:27 AM: Reporting endstop status
< 10:58:27 AM: x_min: open
< 10:58:27 AM: y_min: open
< 10:58:27 AM: z_min: open
How long ago? We have been using v510 for a while instead of 418. For over a year, IIRC.
@vicious1 FYI.
The easiest thing is to flash v510 from MarlinBuilder releases.
V1CNC_Rambo_Dual.
Use Xloader if you are using windows and it should be quick and easy.
And I can confirm, that firmware is not dual endstop.
That is odd. How long have you had the board, did I send it recently with really old firmware?
I bought the board about a year ago. Finally getting my build done.
Okay, cool, I was really worried somehow I shipped the last whole batch with old firmware somehow.
The new firmware is very stable now, Sorry you needed an update, glad it went smooth and easy. You really shouldn’t need to change it unless some crazy fancy new feature comes out.
The VSC platform.io integration was super simple. I can definitely seeing myself being able to tweak the FW and update it later if need be. Its leagues better than the old arduino IDE.
Agreed! I use for a lot of things now, and new to me was the find and replace…that is powerful, and other plugins that get suggested for .gcode and things.