I found that the horizontal alignment is off when cutting wide projects at times. It wasn’t consistently off though which was weird. I found that when I initialized the machine, there is often a small gap on one side of the rail versus the other side which is touching.
Now, after initializing and part of my depth finding, etc, I jog the machine a few times all the way forward. Then both sides touch and it’s straight horizontal aligned again.
Not sure of another solution.
Cody, have you checked your mechanics? Belts and v-wheels would be the starting point. Slipping motor pulleys are another area. Based on what you mentioned, a loose belt is high on my check list.
If your rails are not aligned (check by measuring the diagonals) then there are several good posts on how to square those depending on your machine.
Also, when I am doing critical work - I push the X axis rail all the way to the back of the machine so it is touching. I hold it there and power on the machine to lock the steppers. It fails the first homing cycle, but will complete the second. This is probably overkill, but it makes sure the two Y motors are aligned to a known source. (FYI - I’m on a SO3 XXL, so may be different for your machine.)
2 Likes
That was the first thing I looked into but it didn’t seem to work. My solution is about the same as yours. I just ensure it’s all the way front versus all the way back. I created a square joint for 2x4 where one side has a squarish peg and the other a squarish hole with hidden shoulders so you see no end grain. It’s so tight when put together, I have to use a mallet to break them apart. When I went to longer stock, the little deviation made the pieces not fit. Hence I did lots of testing, etc. I could square it up but later use it would be off again. It seems like it only occurs upon start up. Once aligned, it stays aligned through multiple uses until turned off. If it were belts, etc, it should be off more consistently throughout use.
That’s my logic anyways.
Tbh, initializing should be taking care of this but it doesn’t.
1 Like
As there is only 1 sensor for the Y-limit stop, the machine cannot tell if the X-rail is square or not. The SO5’s are the first machines to incorporate dual Y-limit sensors to ensure consistent squareness of the X-rail at initialization. Believe me, I wish Carbide3D had an upgrade for the SO3XXL’s & ProXXL’s to add this feature - maybe they will eventually, but it may entail installing a new controller board.
1 Like
The grbl firmware actually allows this. That was a big part of the 1.1h update. It reuses the Z pins since Z homes first. You just need an additional hall effect sensor on the left side. Need to update your firmware settings which requires a flash (not to complicated, I documented in this post if you need it).
This should be independent of whatever gcode server you use (CM, CNCjs, gSender, etc) since homing is a function of the grbl board not the software.
Need to see if Carbide will sell just one sensor and mount kit 
@Nazarethii of you’re confident the belts are good, measure across the diagonals of your machine to see if it’s square. Even if you implement a second homing switch, your still tracking on a parallelogram if the machine is not square. The problem your describing is almost certainly a mechanical issue that is correctable, just need to hone in on where it’s starting.
1 Like
Doesn’t that also require a 4-axis controller?
I thought the Carbide Motion controller used only 1 axis for both Y-axis motors and has one reversed in the circuitry on the board.
I’m pretty sure that adding this feature will require updating to a new, 4-axis controller.
1 Like
If you need to move the 2 Y axes independently, then I would think yes.
But couldn’t you hook 2 limit sensors up in series so they both have to be activated to signal limit hit?
Then to square up the machine you would adjust the limit sensors.
Or would this be bad for the drive motors to intentionally lose steps each time you initialize?
@WillAdams Not sure on the circuitry of course, but they look like completely separate controllers for Y1 and Y2. I’m curious now! I’ll test this in the next week or so by flipping the firmware flag and see what happens. (have to go back and read all my instructions again, it’s been three years - lol)
But really, dual sensors are meant to correct a few microsteps of precision and small differences in belts, etc to increase the precision of a machine that is very close to alignment. If your machine is noticeably off, then adding a sensor will change how it is wrong, but not correct why it is wrong. Same with alignment on a car - I can make it steer “straight” by unbolting the steering wheel and recentering it. For you as the driver it looks fixed, but mechanically still not right. Going back to the OP, there is definitely a mechanical issue that could be addressed.
2 Likes
I would surmise that it is just the firmware of the controller linking the 2 Y-outputs together to step in synch. So it should be entirely possible to un-link them for limit-stop calibration.
I agree that a properly squared machine is a must - the design of the machines makes it very hard for them to be out of square by much. The stepper motors though, add a bit of randomness on power up - one can make a step forward while the other goes back. So a 2nd Y-limit sensor enables reliable correction for this & means that when you power down & restart your machine, you are more likely to continue exactly where you left off from.
That’s my thinking as well. For smaller projects, maybe a foot long, you really can’t tell. Go 3ft wide and it’s off about an 8th. Trying to tune something that is off a little one time but not the next for the same 3ft work piece means you can’t really tune it. Note: I did follow some tuning videos and ways to check it. When I knew it was squared and it was off again the next time I booted it, I knew it was not a straight forward tuning issue. I’m thinking it must occur during initialization because my current mitigation keeps it align the rest of the time I’m using it. If a belt or mechanical issue was present, I would think it would be thrown off consistently. A randomness of the stepper motors during power up could explain what I’m seeing. Having a sensor on each rail, furthermost back or forward, would be a definitive way to square it up via software. It’s no different than using the software and sensor to determine bit length.
Note: The sensors would be attached to the end of the fixed rails. The moving part (not sure what it’s called) could come forward until it presses the sensors and then the software manage the squaring.
One of these may help
1 Like
Okay - so I went a bit down the rabbit hole on the dual y-axis squaring. I flashed my config.h file with the new parameters to enable dual axis homing (lines 641: #define ENABLE_DUAL_AXIS and 644: #define DUAL_AXIS_SELECT Y_AXIS). Did some test runs, figuring I’d fake the second sensor by tripping the current Z sensor, and homing failed each time. After digging a bit, it may require a mod to the pins on the board, … and it may just not be possible with this board as @WillAdams notes.
@DanStory mentions in this post that he is running dual axis homing, maybe he’ll chime in with how he got it working.
I’m speculating it might require moving two pins on one Y motor to the D12/D13 pins on the board. But haven’t gone deeper than that…
And realistically, my machine is as square as can be with all the tests I have done. When i want to be extra sure - I do the crash method of powering on with the Y-axis pushed to full stop on both sides. So now it’s an exercise of “Will It Blend” curiosity.
This topic was automatically closed after 30 days. New replies are no longer allowed.