Y axis not zeroing

[Steve T]

Recently my Y axis is not always zeroing before starting a print. If its allowed to continue the extruder goes off the back of the plate during a print and the table stepper motor is either grinding or skipping teeth on the belt, seems like its trying to push the table forward even though the table is already at its limit. It seems as though if the table is far enough back it will zero but if too far forward it will not move to its home position, like it times out after so many seconds. Scripts read normal to home axis. Any ideas from the forum would be helpful. Thanks!

[Dale Reed]

Steve,

Check the Y-axis stepper motor connections (plugs at both ends) and the Y-axis limit switch connections (two push-ons at the switch and the plug at the RAMBo board) and make sure no connectors or wires are loose. Check that the Y slider and rail are properly lubricated. Check that the Y belt is not slipping through the clip that holds it to the spider/carriage assembly.

Another interesting test you could try is to open the electronics enclosure and swap the X and Y stepper connections AND the X and Y limit switch connections (together). Then issue a Home X command from your machine control panel/software and see if the bed homes properly in Y, and issue a Home Y command and see if the extruder homes properly in X. If the problem moves with the connections, it's the RAMBo or the software. If the problem stays with the Y axis motion (bed/spider motor and limit), it's the connections or the steppers / limit switches or the wiring harness.

Time for some deduction, Mr. Holmes!
Dale

[jsc]

Wait, something in your description doesn't sound right, Steve. You say the table is getting pushed forward, and the extruder goes off the back. Home position for Y is the front left of the bed, so the table should be moving backwards when homing. Maybe you have your Y axis inverted?

[Dale Reed]

Thanks, Jin. Yes, when homing, the bed should move toward the back, toward the limit switch on the back end of the rail. Y- is toward the back and Y+ is toward the front. Take the Y stepper connector on the RAMBo and turn it 180 degrees. (You can't do this at the stepper motor --- the connector is polarized. But at the electronics end, it's not. That's the place to make the flip.)

And if hitting the limit switch doesn't stop the motion, flip THAT connector on the RAMBo 180 degrees, so it makes contact between the center pin and the "other" pin. The RAMBo has connectors that allow the limit switch to close to +V or close to common, depending on the type of switch and the firmware. If you have the limit switch connector flipped, it won't properly pull up or pull down the microcontroller input and the axis won't stop.

Dale

[Steve T]

Hey thanks Dale and Jin for your comments. I'll need to clarify. 1) It doesn't always happen. 2) It seems to happens if at the end of a print I physically pull the table towards the front of the M2 to easily get at the print for removal. If I start a new print with the table extended forward it starts its travel home during the homing process but doesn't completely travel rearward to trigger the limit switch i.e. it doesn't complete the zero sequence before the print begins, but, 3) If I don't move the table from a previous print and start a new print, the table will travel to its homing position and trigger the limit switch. 4) In either scinario, while homing it seems (without clocking it) to travel towards home for roughly 2-3 seconds, stops, then the z-homing begins with or without the Y-position being home. I have found a work around to push the table back an inch or two from its limit switch and has been working well. And just a note, if the table triggers its limit switch normally, the print comes out nice. If it doesn't trigger the switch, that becomes the new zero position for the table. There are no interferences to the table and it moves in/out freely and is well lubed. I haven't changed any wiring on the machine since assembly accept for taking out a faulty Viki LCD panel and M2 has produced numerous prints within its current wiring setup since the removal of the panel. I have not reinstalled the new LCD yet. So the problem is intermittent and seems to be dependent on where the table is positioned right before the homing sequence. If anyone has any more ideas as to what may be going on feel free to interject and thanks!

[jsc]

Ah. Your problem sounds identical to another problem reported earlier: viewtopic.php?f=7&t=36

Skip to the end for the solution (braid the Y endstop wires together).

[Dale Reed]

Steve,

I wonder if it's using the right "home" command. Check the RepRap wiki for the list of G-codes. The correct home G-code will run the axis until it hits the home limit switch regardless of where it is --- it doesn't assume that the axis "knows" where it is -- it is seeking home as if you were doing it for the first time, with NO established position. Perhaps they are sending a G-code to simply move Y to zero. If you move the bed with the motors disabled, the firmware has no idea that you did this. There is NO position feedback --- the firmware keeps track of position by counting the number of pulses it sends in each direction. So pulling the bed forward manually just moves the bed --- the Rambo thinks it sits where it left it.

Try sending the axis homing G-code manually through the "send" box in your machine control software and see how the axis reacts.

If you send G0 Y0 or G1 Y0, it will move to the assumed zero. If you moved the bed, it will step back to what it THINKS is zero.

If you pull the bed forward, then send G28 Y0 it should move all the way to the home limit switch.

Let us know what you find with these codes.
Dale

[Steve T]

Jin,

The machine was new this year so the problem you refer to was probably taken care of during the assemly phase at MakerGear because mine arrived with all the limit switch wires twisted.

Dale I think you hit this on the head and sounds like its what's going on in my case. I don't know enough about G-codes yet to feel comfortable programming them but I know that if I either leave the table in the same position from the previous print, push the table rearward if I pulled it forward, or if I simply click the "Home Y" button in the control panel before starting the print, all these remedies seem to work well. The confusing thing is I can move the "X" axis all the way to the right of the printer and it will always go home at the start. Oh well, it's a simple work around for now until I learn to change the code.

Thanks to you both for helpng me understand my issue!

Steve

[jsc]

What host program are you using?

[Steve T]

The latest Simplify 3D.