new build, tower motors seem to be ignoring stop switches
Posted: Wed Jun 10, 2015 2:51 pm
Hi there,
I just finished the physical build of a new rostock max v2, and have run in to an interesting problem with the stepper motors when I try to home the machine.
I am using the stock firmware from the downloads section on seemecnc.com, and have only modified the settings for using the Automation Technology stepper motor current settings and inverting two of the axis directions, as the first home test sent the Z and Y towers downwards.
I click on home, and the cheapskates all slide to the top position, but one, sometimes two, of the towers keep trying to drive the cheapskate higher than the stop switch, causing a godawful noise until I power down the rostock. This happens mostly on the Z tower, but occasionally on the Y tower as well.
Belt tension on Z and Y towers feels about the same as on the X tower. Servos are getting 12.03 volts (checked with multimeter.) Other functions for the rambo board seem to work: I have run the PID loop autotune, and bed and hot end preheating appear to work properly. When I tried to do the 'setting z height' stage in the manual, each time I clicked on 'home towers' via the control panel, I was afraid that the steppers would strip teeth off the belts.
Is this normal behaviour before the z height is set? The manual doesn't mention it, and I'd rather err on the side of caution before having to send out for new belts. I would have thought that with the end-stop switches functioning, the rambo board would turn off the stepper motors as soon as that contact was closed.
I have already run the end-stop tests:
nothing pressed:
x pressed:
y pressed:
z pressed:
z and y pressed:
One other thing I have noticed is that when I try to control the motors from within matterControl, sometimes they don't respond to commands. I will see the command be sent via the terminal, but the motors don't move. Then, inexplicably, they start moving again, normally after sending a command to move a different axis. Not sure if this is related at all.
thanks!
I just finished the physical build of a new rostock max v2, and have run in to an interesting problem with the stepper motors when I try to home the machine.
I am using the stock firmware from the downloads section on seemecnc.com, and have only modified the settings for using the Automation Technology stepper motor current settings and inverting two of the axis directions, as the first home test sent the Z and Y towers downwards.
I click on home, and the cheapskates all slide to the top position, but one, sometimes two, of the towers keep trying to drive the cheapskate higher than the stop switch, causing a godawful noise until I power down the rostock. This happens mostly on the Z tower, but occasionally on the Y tower as well.
Belt tension on Z and Y towers feels about the same as on the X tower. Servos are getting 12.03 volts (checked with multimeter.) Other functions for the rambo board seem to work: I have run the PID loop autotune, and bed and hot end preheating appear to work properly. When I tried to do the 'setting z height' stage in the manual, each time I clicked on 'home towers' via the control panel, I was afraid that the steppers would strip teeth off the belts.
Is this normal behaviour before the z height is set? The manual doesn't mention it, and I'd rather err on the side of caution before having to send out for new belts. I would have thought that with the end-stop switches functioning, the rambo board would turn off the stepper motors as soon as that contact was closed.
I have already run the end-stop tests:
nothing pressed:
Code: Select all
->M119
<-ok 0
<-
<-x_max:L y_max:L z_max:L Code: Select all
<-x_max:H y_max:L z_max:L Code: Select all
<-x_max:L y_max:H z_max:L Code: Select all
<-x_max:L y_max:L z_max:H
Code: Select all
<-x_max:L y_max:H z_max:H
One other thing I have noticed is that when I try to control the motors from within matterControl, sometimes they don't respond to commands. I will see the command be sent via the terminal, but the motors don't move. Then, inexplicably, they start moving again, normally after sending a command to move a different axis. Not sure if this is related at all.
thanks!