Stuttering when homing

[Nicolinux 288]

I had this stuttering of the z-axis sometimes but I could never reliably reproduce it. Until now. Check out the following video (the interesting bit starts at about 0:35):

 

It happens with the z-axis only although I had this with the y-axis once. This is definitely not something mechanical - maybe related to the steppers.

What could it be and how can I get rid of it?

Thanks

 

[nick-foley 5]

Maybe it's skipping steps? You could try upping your stepper current, which is a fairly easy operation of turning the potentiometer on your Z motor driver PCB very slightly counterclockwise.

 

[gr5 2,170]

Wow. Sounds like a firmware bug to me. Maybe related to your colorful LED's?

 

[nick-foley 5]

I guess one other thing I would try is swapping your Z stepper driver PCB with the PCB from a different axis that isn't showing this problem. That would at least allow you to clear the stepper driver of guilt.

 

[calinb 11]

My UM has always stuttered in Z fairly often. I don't have to bottom the stage like you to reproduce the problem either. Moving Z more than 20 mm using my Ulticontroller is always asking for trouble when it homes. Sometimes it stutters after no such provocation too--usually when I start a 2nd print right on the heels of the first print. Like you, I've seen the problem occur very rarely in X/Y. The period of my stutter is longer than your stutter, but my Z speed might be slower than your UM too. The pause in Z-motion is quite long--maybe 1/4 to 1/2 second. It's VERY irritating and forces me to make countless power down resets (the only way to clear the problem), requiring me to reset preheat temps and / or reload the .gcode file from the SD card with the UC.

But my UM and UC electricals and electronics have been VERY irritating, in general and multiple electronics assembly defects have been my major gripe with the machine. I wish none of the electronics had been assembled by UM Ltd., because it would have taken me far less time to assemble the boards and cabling myself than to debug and correct the problems. (I'm speaking as an electrical engineer who transferred two major Intel board products to off-shore manufacturing facilities in Asia). I've spent far too many hours reworking my UC PBA and replacing solder-less crimp connectors that had been incorrectly assembled with solder than I spent assembling the machine in the first place.

 

I had this stuttering of the z-axis sometimes but I could never reliably reproduce it. Until now.

 

[Nicolinux 288]

@Nick: I don't think it skips steps. The stuttering is completely regular. Regarding the steppers - that's what I thought too (and feared). I guess I will have to do it but I don't even know where to look. I didn't wrap my head around the pcb. I just connected everything and attached it to the bottom plate. But it shouldn't be too different from our old Prusa Mendel.

@gr5: The leds are not connected to anything. The have their own power supply.

@calinb: Well I have the rev4 board and I guess they improved it a bit. Right now the stuttering is more of cosmetic nature. I didn't experience any failed prints because of it.

 

[calinb 11]

Same here. No lost prints, because I stop the print immediately when it occurs and I've never seen it begin its stuttering after a print is successfully underway. It's just a nuisance to have to do power-down resets so often and reload all that's required to restart a job, wait for the PID nozzle temp control to stabilize, etc. I'd be more irritated by it if I used the UM to control my heated bed temperature, but I use a bombproof $25 Chinese Ebay PID controller for that. It's far more reliable and more soundly constructed and assembled than any of my electronics supplied by UM, Ltd. and it never gives me a lick of trouble!

 

@calinb: Well I have the rev4 board and I guess they improved it a bit. Right now the stuttering is more of cosmetic nature. I didn't experience any failed prints because of it.

 

[gr5 2,170]

wait for the PID nozzle temp control to stabilize, etc.

 

In Cura I always set the temperature to 0 and set it manually before I print (using either cura or ulticontroller). Then when the temp is "close enough" I start the print.

 

[calinb 11]

I know that trick, but monitoring the temp closely isn't that convenient either. I prefer to direct my attention to manually priming the nozzle until the head homes..

 

In Cura I always set the temperature to 0 and set it manually before I print (using either cura or ulticontroller). Then when the temp is "close enough" I start the print.

 

[calinb 11]

My power supply brick just died (not quite 2 years old) and I replaced it with a higher quality unit. Unfortunately, my hope that the Z stuttering would go away was not realized. Has anyone found the cause of this problem yet? The period of my machine's stutter is much longer than Nicolinux's machine's problem. I also don't have to nearly bottom the stage. It will do it on nearly every print when homing, if I don't power down between prints.

My machine has always been plagued by it. It's actually been plagued by many electrical problems from the day I received it, which have consumed countless hours of my time in the course of correcting them--all except this one, which continues to elude me.

 

[anon4321 16]

Nick, did you increase the feed rate of the Z axis?

My guess is that the Z driver is overheating and in Nicks case increasing the feed rate and moving the bed up and down at that increase rate is overheating the driver (barely). It momentarily shuts down and quickly cools just enough to restart.

For both of you, try DECREASING the current.

 

[calinb 11]

A "master reset" (power cycling--even extremely briefly) clears the problem and it will not reoccur until after the print completes and the next print is started. The stuttering correlates to the termination of one print and beginning of the next print and it is completely reproduceable.

Alternatively, if I power-up the machine from cold and move the stage using the Z-movement control under the "Prepare>>Move Axis" Ulticontroller menu, the stuttering will occur when the machine homes to print the first print. As before, cycling the power will clear the problem.

These symptom don't seem to correlate to a driver overheating to me but, if I can find the adjustment, I'll try to turn the current down.

 

Nick, did you increase the feed rate of the Z axis?

My guess is that the Z driver is overheating and in Nicks case increasing the feed rate and moving the bed up and down at that increase rate is overheating the driver (barely). It momentarily shuts down and quickly cools just enough to restart.

For both of you, try DECREASING the current.

 

[gr5 2,170]

There have been similar problems recently that were fixed by replacing the vertical rods and the bearings that go on those 2 rods. It's probably too late to get a warranty replacement. But there are some new things coming out of UM to be announced probably Sep 19 at MakerFaire NYC... I'd wait until then.

 

[calinb 11]

As it's stuttering on the way home at the beginning of a print job, I can briefly toggle the power switch and quickly re-start the print job with the Ulticontroller. Then it continues on its way just fine, regardless of the position of the Z-stage (regardless of whether it has to travel 200 mm in Z or only 5 mm in Z to finish homing). It NEVER exhibits this problem when a print is started immediately after power-up (again, regardless of whether it has to travel 200 mm in Z or only 5 mm in Z to finish homing.)

I've removed the leadscrew many times and the stage moves with no perceptible resistance on the bearings. I can also easily turn the leadscrew coupling with my fingers and screw the stage up and down manually.

My Ulticontroller had a number of assembly defects, which I corrected. There might still be something wrong with it.I guess the next step will be to disconnect the Ulticontroller and run the printer from my laptop. If the problem remains, I'll probably need to replace my Arduino Mega 2560 board, unless someone here reports experience with a specific component that causes this problem.

 

There have been similar problems recently that were fixed by replacing the vertical rods and the bearings that go on those 2 rods. It's probably too late to get a warranty replacement. But there are some new things coming out of UM to be announced probably Sep 19 at MakerFaire NYC... I'd wait until then.

 

[calinb 11]

I recently stumbled upon a work around for my z-stutter problem, other than power cycling.  It's not any more convenient than cycling the power in most cases but if I use my Ulticontroller to move the the stage down and then up a few 1/10s of a mm (MUST use the 0.10mm selection, because the 1mm movement selection will actually cause stuttering on the next home), then the stuttering never occurs.

This workaround can be done before starting a new print after a print has completed (stuttering never occurs on the first print after power-on) or after manipulating the stage using the 1mm selection, which always causes stuttering. The last manipulation of the stage must be in the UP direction using the 0.1 granularity selection from the UC menu.

Again, this is evidence that that my UMO has always had a strange electrical/Marlin/interaction/bug (from the day I built it and first plugged it in) and I'll probably never get to the bottom of the problem. It's really been a nuisance, however!

Edited May 26, 2015 by Guest

[calinb 11]

Z-stutter update and solution. See:

 

https://community.ultimaker.com/topic/10226-why-does-my-print-have-tiny-zebra-stripes/page/13/?tab=comments#comment-243962