Print stops in same place twice

You can also try to uncomment

#define ENDSTOPS_ONLY_FOR_HOMING

in Configuration_adv.h

[code]//===========================================================================
//=============================Mechanical Settings===========================
//===========================================================================

// This defines the number of extruders
#define EXTRUDERS 1

//#define ENDSTOPS_ONLY_FOR_HOMING // If defined the endstops will only be used for homing[/code]

This will let the printer continue printing if it accidentially hits an endstop during lagre prints.

I tried this without problems or errors:

[quote=“ichbinsnur”]Just for eliminating possible error sources, try this G-code script.

Code:
G1 X0 Y0 F300
G1 X0 Y200 F300
G1 X200 Y200 F300
G1 X200 Y0 F300
[/quote]

This was already uncommented:

[quote=“ichbinsnur”]You can also try to uncomment

#define ENDSTOPS_ONLY_FOR_HOMING[/quote]

I tried to print the below object from SD card. It failed on the first layer. Not only did it fail, but the controller locked up with bed and extruder heater on. The LCD was unresponsive, so I had to cut power. I checked the driver temps. The x driver was hot to my finger, but I could hold it on the chip without pain. The other drivers were only warm. All motors were cool except the extruder, which was warm/hot. I am going to try it again from repetier to see if I can get any errors, but it will have to wait.

My new controller board will be here on Wednesday. It will be interesting to see what happens with a different board.

[quote=“mpoore”]I tried this without problems or errors:

[quote=“ichbinsnur”]Just for eliminating possible error sources, try this G-code script.

Code:
G1 X0 Y0 F300
G1 X0 Y200 F300
G1 X200 Y200 F300
G1 X200 Y0 F300
[/quote]
[/quote]

How ofthen did you let it run in series?

Ok, let us know if it hepled.

After some delay, I received my new controller. It did not fix the problem.

I also rewired the y axis stepper on a hunch. It did not help either.

I have tried other power supplies. Triple checked driver voltages.

I created some test files to individually test the x and y axis.

For instance, to test the y axis I wrote:

G1 X0 Y0 F9000 G1 X0 Y200 F9000 ;repeated 25 times

then:

G1 X100 Y200 F9000 G1 X100 Y0 F9000 ;repeated 25 times

and finally:

G1 X200 Y0 F9000 G1 X200 Y200 F9000 ;repeated 25 times

I created similar code to test the x axis with y at 0, 100, and 200.

The x axis test completed every time attempted.

The y axis test failed 9 of 10 times, but in different places. It does various things at failure. In other words, the controller might become unresponsive, the z axis might start going up until I shut it off, the y axis might try to go beyond the physical limits of the bed, or the controller might just reset.

I can’t think of anything else to replace except the y stepper. What I don’t understand is why the z axis would just start going up uncontrolled. Could a short in the stepper somehow get back to the controller to cause all of this weird behavior?

Any other ideas? Does this sound like a stepper failure?

Progress!

I removed the y belt and ran the y axis test mentioned in the previous post. The g code is running to completion every time!

I have to conclude this means I need a new stepper although I still do not understand why I was getting all of the strange symptoms.

It will take a while to get a new stepper, so I think I will swap the z and y stepper to see what happens.

Did you leave the y motor connected?

Electrically, yes. I removed the belt. The motor spun during the test.

That leads me back to my earlier assumption, that the wiring has an intermittent failure.
I think if the y axis is moved along there is a short or open circuit caused by moving the wiring that connects to the
Headbed or XY carriage. That would also explain why it works when you remove the Y belt.

If the wiring has an intermittent short, tis may cause the processor to lose or dip power for a short moment,
leaving it in a unexpected state aferwards and that leading to the strange behavior.

As mentioned previously, I replaced the wiring on the y axis including the stepper and end stop. The heat bed power and sensor were unplugged from the controller during all tests (successes and failures) in order to isolate the problem. I unplugged the extruder, fan, and heat bed, and z axis stepper.

If there is an open/short, it seems that it has to be in the y stepper unless I am missing something.

I am thinking that the problem has something to do with putting y stepper under extended load. I have noticed that the failures happen earlier in the test as more tests are run. In other words, the test will go farthest on the first attempt and progressively failure earlier on each subsequent attempt.

Does the y stepper module get noticably hot ?
How is it cooled? If the stepper modules overheat tha cause strange behavior too.

I have mine running in a fan cooled enclosure and glued heatsinks to them to keep them cool.
Since i did that i never again had problems with axis movement.

The problem is solved. Swapping the z axis stepper with the y axis stepper resolved the problem. I ran several lengthy tests after the swap and no failures.

I noticed that the motor that was giving me problems has a coil resistance of 1.8 ohms and the motor that works on the y axis has a resistance of 2.2 ohms. I am not sure what it should be. These measurements were taken from the controller connector and I did not factor wire length. Perhaps the lower resistance caused the driver to work too close to the limit when doing those long movements.

Regardless, it is working. Thanks ichbinsnur for all of your ideas, suggestions, and even trying a test print for me.

I am going to see if I can find some heatsinks.

I wonder if the Pololu DRV8825 Stepper Motor Driver is a drop in replacement on this controller. I read that in some cases it is on other controllers. The DRV8825 will handle 1.5 amps without cooling. I can’t understand why it isn’t standard equipment in the reprap world instead of the A4988. The cost difference is minimal when considering the overall cost of a 3d printer. There must be some reason for the A4988 popularity, but I don’t understand it.

Hey, no big deal, nice that it works now!

[quote=“mpoore”]
I wonder if the Pololu DRV8825 Stepper Motor Driver is a drop in replacement on this controller. I read that in some cases it is on other controllers. The DRV8825 will handle 1.5 amps without cooling. I can’t understand why it isn’t standard equipment in the reprap world instead of the A4988. The cost difference is minimal when considering the overall cost of a 3d printer. There must be some reason for the A4988 popularity, but I don’t understand it.[/quote]

I think it should work, afaik the modules are pin compatible.
Although you have to watch the microstepping set on the 8825 as it supports 1/32th too whereas the 4988 only does 1/16th.

from the Pololu site :