Marlin: X axis continues to pulse in direction of last move

[626Pilot]

I'm working with Johann Rocholl's experimental branch of Marlin:

Code: Select all

git clone https://github.com/jcrocholl/Marlin.git --branch deltabot

Previously I was using Repetier, and that worked fine. I've used m119 to verify that the endstops are reporting open and closed as they should. The carriages move in the correct direction, and the machine will respond to G28 and G1 commands.

The trouble comes when movement is started or stopped. When the printer is first powered on and there is no last move, the X axis will be still, as it should. However, if I do a G28, the X axis will continue trying to move upwards - even if the endstop is triggered - in short pulses that seem to fire once per second. If I then tell it to move to z100, it will do so, and during that motion it will jerk downwards a millimeter or two once per second at a different speed than it's supposed to be moving at. Once it reaches z100, the Y and Z axes will be still, but the X axis will still pulse downward at 1Hz. If I then move it to Z150, Y and Z will again work properly, but X will skip upwards once per second during the movement and keep doing so after it's supposed to be done.

There is another thread about this problem from a while back. The issue was never resolved there because the user switched to Repetier. I know this is not a wiring issue because Repetier worked fine yesterday, and because a bug that only shows up during or after motion and remembers the direction of that motion after the fact is most likely software. Bad wiring would not send exactly the same amount of reliable PWM over the direction and step pins exactly once per second.

[Eaglezsoar]

If I'm not mistaken most Marlin users use Printrun as the host, have you tried it to see if the problem
goes away?

Also, have you noticed that Windows 7 accesses the drives at a rate of approximately once per second?
You can see it on the drive activity light if your led is bright enough. Point being that if there is a program
running in the background it is possible that it is sending interrupts on the USB that Marlin is sensitive to and Repetier
is not. Just tossing some ideas around. It would be interesting to see what happens without the USB by writing small
Gcode files and executing them from the SD card.

[626Pilot]

It's not that, but you've just said exactly what I needed to hear.

RepRapDiscount LCD support is turned on, but it's broken. What would refresh once per second? Maybe a user interface. What if the thing that's broken is that the pin getting pinged is incorrectly defined, and the pin used is the X step line? If the stepper driver is asserting a direction, driving the X step line with PWM would cause it to jump AND it would ignore the endstop. It explains everything.

I disabled LCD support. The X axis motor isn't jumping anymore, and I probably just figured out why LCD support is broken.

[edward]

You can use pretty much any host software with any firmware. Underneath, they all just send Gcode over serial. For example, I use Repetier-Host with Marlin, because I like the Repetier-Host interface much more than Printrun.

[Eaglezsoar]

It's not that, but you've just said exactly what I needed to hear.

RepRapDiscount LCD support is turned on, but it's broken. What would refresh once per second? Maybe a user interface. What if the thing that's broken is that the pin getting pinged is incorrectly defined, and the pin used is the X step line? If the stepper driver is asserting a direction, driving the X step line with PWM would cause it to jump AND it would ignore the endstop. It explains everything.

I disabled LCD support. The X axis motor isn't jumping anymore, and I probably just figured out why LCD support is broken.

The once per second is what gave me a clue, Windows and its underlying software seems to use the once per second as an interrupt for many
processes. It looks like you are close or have determined the problem. Have fun with Marlin!

[Eaglezsoar]

You can use pretty much any host software with any firmware. Underneath, they all just send Gcode over serial. For example, I use Repetier-Host with Marlin, because I like the Repetier-Host interface much more than Printrun.

Agreed, the Printrun Gui leaves a lot to be desired once you get used to Repetier Host. I was just tossing out ideas for 626pilot to see if any stuck to the wall.
Something appeared to stick because he seems to be on the track to getting the problem resolved. By the way, I do believe that this is the shortest message
you have ever left on the forum.

[lordbinky]

You can use pretty much any host software with any firmware. Underneath, they all just send Gcode over serial. For example, I use Repetier-Host with Marlin, because I like the Repetier-Host interface much more than Printrun.

...
By the way, I do believe that this is the shortest message
you have ever left on the forum.

BWAHAHAHAHAHA... *wipes tears from eyes*
Thank you eagle. It's a very good quality of yours edward....but it's one of those funny because it's true moments.

[Eaglezsoar]

I'm working with Johann Rocholl's experimental branch of Marlin:

Code: Select all

git clone https://github.com/jcrocholl/Marlin.git --branch deltabot

Previously I was using Repetier, and that worked fine. I've used m119 to verify that the endstops are reporting open and closed as they should. The carriages move in the correct direction, and the machine will respond to G28 and G1 commands.

The trouble comes when movement is started or stopped. When the printer is first powered on and there is no last move, the X axis will be still, as it should. However, if I do a G28, the X axis will continue trying to move upwards - even if the endstop is triggered - in short pulses that seem to fire once per second. If I then tell it to move to z100, it will do so, and during that motion it will jerk downwards a millimeter or two once per second at a different speed than it's supposed to be moving at. Once it reaches z100, the Y and Z axes will be still, but the X axis will still pulse downward at 1Hz. If I then move it to Z150, Y and Z will again work properly, but X will skip upwards once per second during the movement and keep doing so after it's supposed to be done.

There is another thread about this problem from a while back. The issue was never resolved there because the user switched to Repetier. I know this is not a wiring issue because Repetier worked fine yesterday, and because a bug that only shows up during or after motion and remembers the direction of that motion after the fact is most likely software. Bad wiring would not send exactly the same amount of reliable PWM over the direction and step pins exactly once per second.

Did you get this working?

[626Pilot]

Did you get this working?

Yuh. Progress is in the sticky thread about leveling in the Rostock MAX forum. Long story short: bed leveling didn't solve my problem but changing the rotation of one of the towers did.