X-Axis jump, about 1,4mm

Hi all,

today I has printed a larger object and in about layer 75 I had a jump in the X-Axis of about1,4mm. I have no idea where the problem is. In the past I had the same problem on the Y-Axis because of the belt fixing is no perfect and the bed has more mass. Since I fixed the belt with cable ties I have no problem with the Y-Axis.
It looks like a step loss, but the fact that it is round about one belt tooth distance makes me think that the belt has jumped over one tooth. But the toothed belt looks perfekt mounted at all.
Possibly a firmware problem with the stepper ramps/softstart that causes step loss or the tooth over-jump? Sometimes I hear very hard directional changes of the drive while printing so that i wondered that there was not a step loss. But most of the time I don't hear those hard noises.

This was an 8 hour print (I aborted after 5 hours) and I hope to get new ideas to prevent that this will happen again in the next try.

Any ideas?

I'm using the actual dc42 firmware and the Web Control 0,65 and printing with 20mm/s print and travel speed


Thank you, Frank

I'm pretty sure it'll be a step loss on change of direction - it really doesn't look as though both axes slow down appropriately under some circumstances, and you get a full speed reverse along with a bang (as if the controller is ignoring the fact that the direction is changing) - eventually some of these bangs turn into motor stalls - I'm on my fourth reprint of the same model, I've been speed testing, and finally Ive got a speed where it doesn't cause steps in the print,

Cheers

Ray

Did you slide the x-motor screws in the slots to achieve good x-belt tension? Are the screws still tight and the belt still taut?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dc42 - In my case, yes Both X and Y are taut - I could send you a G-code snippet if you'd like to try airprinting this phenomenon, by going faster I can get the skipping to happen on both X and Y when changing direction printing circles - I'm guessing that only one or other of the axes is controlling the acceleration, but of course they're out of phase. A similar phenomenon occurs when printing V excursions in an otherwise straight line.

I need to try to get my head around the dda and other parts in move.cpp (quite some getting up to speed needed for me).

This is a gcode file sliced in Cura )as I suspect Frank's are), I don't see an acceleration setting in there, slic3r has it in the advanced settings, and I wonder if slic3r's acceleration control is masking a lack of it in the firmware? I'll try slicing the same file later, but I gave up after three hours last time while slic3r slowly dribbled the gcode to disc

Ray

There is acceleration control in the firmware, and a M-command to set the maximum acceleration. I'm not sure what happens if you set the acceleration in slic3r higher than the limit in the firmware - something will have to give. Adrian at RRP is making major changes to Move.cpp to sort out issues with combined XZ, YZ and XYZ moves, so I've mostly left that file alone.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Adrian at RRP is making major changes to Move.cpp to sort out issues with combined XZ, YZ and XYZ moves

ah good that's encouraging

Quote
rayhicks

Quote
dc42
Adrian at RRP is making major changes to Move.cpp to sort out issues with combined XZ, YZ and XYZ moves

ah good that's encouraging

I also think it is a firmware issue. These "bangs" are only rarely, the hardware doesn't change and i think 20mm/s is not so fast.

@rayhicks: Would you send me the gcode snipplet to provoke this "step loss", please?

Frank

In another thread long ago, I put this down to what I called impulse [forums.reprap.org], there's a better explanation of the problem here [jamesgregson.blogspot.ca] (second part here [jamesgregson.blogspot.co.uk]) - GTiny uses a similar approach, and there's a video of it exercising a 3D printer here [www.youtube.com] driving the ormerod on similar paths and at these speeds would make it bang and jump off the bench

I presume that the feedrates for X and Y are limited to 50mm/s in firmware, to mitigate the effect

Ray

Quote
rayhicks
I presume that the feedrates for X and Y are limited to 50mm/s in firmware, to mitigate the effect
Ray

But in my case I had this jump while using 20mm/s and I am not losing small single steps from layer to layer or so. There was one jump at a specific (random?) layer. Before and after this jump the positions are perfect and i think there is not one step lost.
If it where a problem because of using the printer at its speed limit, I would expect continous losing small amount of steps.
I think that was a special condition that causes that large amount of steps losing at one time, like wrong timing, missing acceleration or wrong speed at direction change (that "bang").
I hope there will be a firmware improvement soon...

Frank

Edited 2 time(s). Last edit at 02/15/2014 04:30PM by Cash.

I think the problem could be found inside the AccelerationCalculation() function, move.cpp, starting at line number 807:

-----------------------------------------------------------------------------
// At which DDA step should we start decelerating?

d = 0.5*(v*v - myLookAheadEntry->FeedRate()*myLookAheadEntry->FeedRate())/acceleration; // This should be 0 or negative...
startDStep = totalSteps + (long)roundf((d*totalSteps)/distance);
-----------------------------------------------------------------------------

These lines are calculating the point where the deceleration starts.

I think it works as follows:

If, for example, the start velocity (u) and the stop velocity (v) is the same, no deceleration/acceleration will occur. If v = 50, v*v will be 2500. If v = -50, this algorithm will give the same result, because of -50 * -50 is also 2500! The following code thinks, there is no change in velocity if the start velocity (u) is also 50!
A sharp angle which will change the velocity from positive to negative will lead into a hard directional change with no de-/acceleration!

In my opinion, if there are velocity changes from positive to negative, there should be a deceleration to 0 and then an acceleration again in the other direction.

If this situation will be considered in the firmware, i think a much higher printing speed will be possible!


Frank

{edit2}

Quote
Cash
But in my case I had this jump while using 20mm/s and I am not losing small single steps from layer to layer or so.

{/edit2}Maybe so Frank - 20mm/s doesn't show a problem with the "snippet" I promised on my machine, however I've looked into it a little, and i think I've found the problem- rather than sending an as-sliced gcode, I've simplified the snippets - "nobang.gcode" is a simple backward and forward move in Y with a feedrate of 50mm/s between Y=100 and Y=75 (I've increased the feedrate caps on my machine and this doesn't bang at 100mm/s either as the acc/deceleration works as intended). "bang1.gcode" is similar, but includes a very short intermediate step (1mm before the original turning point at y=76). Essentially, the control code doesn't slow down the Y axis movement when it reaches 76, since the next segment is meant to be carried out at the same speed, it then processes the next segment and tries to do the full deceleration to 0 in one mm. Without the intermediate step, it slows down as it approaches 75, so that it can stop and accelerate back.

In bang2.gcode, there are seven repetitions, each with a different sized intermediate segment:

G1 X100 Y100 F3000.000
G1 X100 Y75.2 F3000.000;1
G1 X100 Y75 F3000.000
G1 X100 Y100 F3000.000
G1 X100 Y75.4 F3000.000;2
G1 X100 Y75 F3000.000
G1 X100 Y100 F3000.000
G1 X100 Y75.6 F3000.000;3
G1 X100 Y75 F3000.000
G1 X100 Y100 F3000.000
G1 X100 Y75.8 F3000.000;4
G1 X100 Y75 F3000.000
G1 X100 Y100 F3000.000
G1 X100 Y76 F3000.000;5
G1 X100 Y75 F3000.000
G1 X100 Y100 F3000.000
G1 X100 Y77 F3000.000;6
G1 X100 Y75 F3000.000
G1 X100 Y100 F3000.000
G1 X100 Y78 F3000.000;7
G1 X100 Y75 F3000.000
G1 X100 Y100 F3000.000

marked ;1 to ;7 - ;1-5 bang increasingly hard, 6 and 7 don't bang at all - it looks like some fine-tuning of the lookahead functions are needed.

The features that reproducibly cause banging in sliced code for me are changes of direction in curves - particularly on tangents to x and y - I presume that the steps in the tangential axis are about the right size for the deceleration to fail.

Ray
[edit - looks like you posted while I was getting my files ready for upload! ]

Edited 2 time(s). Last edit at 02/17/2014 08:16AM by rayhicks.

Quote
Cash

In my opinion, if there are velocity changes from positive to negative, there should be a deceleration to 0 and then an acceleration again in the other direction.

If this situation will be considered in the firmware, i think a much higher printing speed will be possible!

I'd presumed something like that from reading the code, but it does work if there's time for it to slow down (ie direction is accounted for elsewhere) - it's just that if the next move is too short for deceleration but at the same speed, the previous move doesn't seem to bother decelerating and it's all down to the last, potentially too short, move to get rid of all that momentum

Nice! I will try to reproduce this with your gcode!

Possibly dc42 could debug something, because i have not installed the development envirement / toolchain so far.

I have no complete overview of the code at the moment so i am not sure if velocity could really be negative and my statements above are only speculation!

Frank

Edited 1 time(s). Last edit at 02/17/2014 08:45AM by Cash.

Quote
rayhicks
I'd presumed something like that from reading the code, but it does work if there's time for it to slow down (ie direction is accounted for elsewhere) - it's just that if the next move is too short for deceleration but at the same speed, the previous move doesn't seem to bother decelerating and it's all down to the last, potentially too short, move to get rid of all that momentum

I think you are right! In the AccelerationCalculation() function the u and v values are reduced if the move is too short to reach full speed and accelerate/decelerate. But the lookahead function does not decelerate to that expected reduced speed in the move before. That makes sense!

Frank

I think I may have a cure - works for the test case anyhow, am testing with a print at the moment and will put up a link if you'd like to try it (note I don't use the ethernet, and this may not be functional in my builds)

[www.dropbox.com] <- this seems to be working, I'm printing with 75mm/s on perimeters and 100mm/s travel without bangs, I had to slow the same print down to 40mm/s for the bangs not to affect the print quality on the same model previously.

if you use this bear in mind that it's experimental - I've only tested it on my own machine without ethernet, and it is still spitting out some diagnostics in the console.


briefly the change I made was to set the exit velocity to 1.0 in the case that dCross was negative (by default the firmware was recalculating entry and exit velocities , and then dCross if dCross was <=0 - this had the effect that the exit velocity could actually increase, rather than get closer to 0) - there may be a better value to set this to, but 1.0 seems to do the trick for now - could you give it a go and see how it affects your print (particularly the print that kicked)?

The other main (intentional) difference in this build from the base I used (dc42's 57m) is that I've double all of the maximum speeds (eg x and y can run at 100 rather than the previous cap of 50)

Cheers

Ray

Quote
rayhicks
[www.dropbox.com] <- this seems to be working, I'm printing with 75mm/s on perimeters and 100mm/s travel without bangs, I had to slow the same print down to 40mm/s for the bangs not to affect the print quality on the same model previously.

Thank you Ray, i will try it! I think all that code is experimental!

First try looks very good, great work! Also web access is working. I will experiment now with the speed. The failed print took a long time, i could only try this at weekend!


Frank

Edited 3 time(s). Last edit at 02/17/2014 11:49AM by Cash.

Printed the first object (Cura Robot scaled down by factor 0.5) with 60mm/s all speeds with no bang heard! Very happy!

Frank

Great - I'll drop RRP a line and see if they want to incorporate something similar as an interim fix (dc42 mentioned that they're reworking the whole move.cpp ) - in the meantime, try setting fill speed to 100 - it's quite impressive

Ray

Nice work Ray, i'll give it a try now.

Interesting that your built .bin is 158k, where as the dc's is 10k larger

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

@Ian/Adrian - here's the amended routine from move.cpp, along with comments - the change is replacing v=sqrt(-u) when dCross<=0.00 and u<0.0 with v=1.0 - on checking initial and final values of u,v and dCross, I found that -dCross increased in magnitude, and v became larger (which meant rather than slowing down before the direction change that caused this to happen, it was actually increasing the speed at which it would enter the direction change for small incremental moves such as those in bang2.g linked above). I set v arbritrarily to 1.0 and the banging went away - I guess that using the appropriate instantdV would be more sensible?

Ray

MovementProfile DDA::AccelerationCalculation(float& u, float& v, MovementProfile result)
{

	// At which DDA step should we stop accelerating?  myLookAheadEntry->FeedRate() gives
	// the desired feedrate.

	float d = 0.5*(myLookAheadEntry->FeedRate()*myLookAheadEntry->FeedRate() - u*u)/acceleration; // d = (v1^2 - v0^2)/2a
	stopAStep = (long)roundf((d*totalSteps)/distance);

	// At which DDA step should we start decelerating?

	d = 0.5*(v*v - myLookAheadEntry->FeedRate()*myLookAheadEntry->FeedRate())/acceleration;  // This should be 0 or negative...
	startDStep = totalSteps + (long)roundf((d*totalSteps)/distance);

	// If acceleration stop is at or after deceleration start, then the distance moved
	// is not enough to get to full speed.

	if(stopAStep >= startDStep)
	{
		result = noFlat;

		// Work out the point at which to stop accelerating and then
		// immediately start decelerating.

		float dCross = 0.5*(0.5*(v*v - u*u)/acceleration + distance);
		

		if(dCross < 0.0 || dCross > distance)
		{
			// With the acceleration available, it is not possible
			// to satisfy u and v within the distance; reduce u and v
			// proportionately to get ones that work and flag the fact.
			// The result is two velocities that can just be accelerated
			// or decelerated between over the distance to get
			// from one to the other.
						result = change;

			float k = v/u;
			u = 2.0*acceleration*distance/(k*k - 1);
			if(u >= 0.0)
			{
				u = sqrt(u);
				v = k*u;
			} else
			{
///////////////////////////v = sqrt(-u);  this is the original line - it was increasing exit-speed rather than making it nearer 0 for small segment moves, doesn't get called for large ones/////
				v=1.0;///////////////my  initial change, might be better to use instantDv?
				u = v/k;
			}

			dCross = 0.5*(0.5*(v*v - u*u)/acceleration + distance);
			
		}

		// The DDA steps at which acceleration stops and deceleration starts



		stopAStep = (long)((dCross*totalSteps)/distance);
		startDStep = stopAStep + 1;
	}

	return result;
}

Edited 1 time(s). Last edit at 02/17/2014 01:10PM by rayhicks.

@Matt - yeah that size difference worried me (and I wondered if it was actually the network stuff that wasn't compiling - I still get a lot of warnings on lwip) - it all seems to work OK though for what I've printed so far anyhow must be a mac v windows v linux thing I hope

let me know how you get on - it shouldn't make any difference for squarish prints, I've mainly had the problem where there are sharp inflections, or if x or y changed direction on the tangent of a circle. Unfortunately the big print I need to do regularly would eventually skip an hour or two in, so I had to slow it down and it took around 8 hours to print, I'll be trying that at 100 tomorrow! (note that you should be able to print and move at up to 100mm/s on this build, the default caps at 50 - also the Z feed cap is changed to twice the default, so if you have a "G1 Z5.0 F5000" at the beginning of your print - which I do in my slic3r output - you'll hear Z growl at the beginning

Cheers

Ray

I've also had problems with this issue, particularly when printing small circles and rounded corners, I can certainly hear the bangs - I've had to throw away a few spoiled prints due to missed steps. I think the speed of the print could be vastly improved without this bug, which would be great with some prints taking most of the day to complete. Has the update made its way into a new release yet - if not, from where can I download a BIN of the modified pre-release please?

Dave
(#106)

Hi Dave, it's here : [www.dropbox.com] let me know how it goes,


Cheers

Ray

Now i have printed 1 full size Cura Robot with 20mm/s and 2 Cura Robots with 60mm/s. No problem, no step loss, only the quality is not as good as with 20m/s.
I am printing actually with 30mm/s perimeters and 100mm/s infill... Very smooth movements!
Before i was not able to print the robot with 40mm/s without a step loss!

Thank you again, Ray! I think i will save a lot of time in the future!

Frank

That's good to hear Frank - remember it's a naive fix (my physics is poor and this is the first thing I've done in C/C++) and there may be knock-on effects (but not bang-on), but hopefully RRP will be able to use something similar in at least an interim release.

If not I'll tidy it up (so it doesn't splurt out the extra info when feedingprinting) and see if I can work out how to use github...

CHeers

Ray

Edited 1 time(s). Last edit at 02/17/2014 02:09PM by rayhicks.

I have reduced now the perimeters to 15mm/s and infill/movement to 100mm/s as "quality settings". That looks really perfect (see attachment). And no bang/step loss so far!

Frank

Edit: Ignore the lower corners, they could not printed very good in the air! But the edges are very good...
Edit2: See second attachment, robots, from left to right, Perimeter/Infill/Moving: 60/60/60mm/s - 20/20/20mm/s - 15/100/100mm/s
Edit3 (sorry!): Attached another picture with different (better) angle

Edited 3 time(s). Last edit at 02/17/2014 03:29PM by Cash.

Quote
rayhicks
Hi Dave, it's here : [www.dropbox.com] let me know how it goes,
Ray

Cheers Ray - I'm printing now (and going home after that!) so I'll not be able to install it till tomorrow. I'll try a print that I know has lots of banging, and let you know if there is any change. The worst are prints that have thin round columns or round corners which cause a bang almost every time when the extruder goes around the corner. Square corners are fine. I discovered that I can print fine at 55 mm/s (at least - not tried any faster yet) if the print has only square shapes in the XY plane, but rounding off the corners with a 1.5mm radius on the same design means the Y axis misses steps above 40 mm/s - always when doing the perimeters, never with the infill even though that has faster direction changes, so I've always suspected that there was sommink amiss with the acceleration calculations.

Dave
(#106)

Nice work, Ray! I'm glad you found a fix.

However, I'm not sure that the system should be trying to reverse the direction in a single move. Does anyone have a gcode file for a small print that shows the problem? If so, please post it and I will look at the problem in more detail.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks dc42 - try the bang2.gcode file above [forums.reprap.org] it does a similar move-set to nobang.gcode, except rather than running full-length from 100 to 75, it has a seperate segment between 76 and 75. It's derived from what happens when a print has a reversal on the tangent of a circle (there are several segments that diminish in length, and ideally speed - I whittled out the X moves and a whole set of Y moves from an offending gcode chunk then arrived at bang1.gcode as the simplest test set, then tried changing the size of the intermediate segment to see what effect that had, which is how bang2.gcode evolved) when the last length before a direction change is too short to allow acceleration and deceleration to occur, the code that catches that actually causes acceleration at the end of the last short segment. If you watch the u and v values before the catching code, and what they are after, you'll see that rather than aid deceleration, the changes made to u and v actually increase the speed immediately before the change in direction - something like the follwoing will show entry and exit values for u and v (it goes in MovementProfile DDA::AccelerationCalculation(float& u, float& v, MovementProfile result)):

if(u >= 0.0)
			{
				u = sqrt(u);
				v = k*u;
			} else
			{
				snprintf(scratchString, STRING_LENGTH, "%f\n", u);
				platform->Message(HOST_MESSAGE, "old u");
				platform->Message(HOST_MESSAGE, scratchString);
				snprintf(scratchString, STRING_LENGTH, "%f\n", v);
				platform->Message(HOST_MESSAGE, "old v");
				platform->Message(HOST_MESSAGE, scratchString);
				v = sqrt(-u); // the original modifier for when dCross is 0 or negative and u is negative on entry
				//v=1.0;  // my change in the code which sets v low and then allows u and dCross to be recalculated from this low end goal [edit 2 to remove "color" bleed ]
                                u = v/k;
				snprintf(scratchString, STRING_LENGTH, "%f\n", u);
				platform->Message(HOST_MESSAGE, "new u");
				platform->Message(HOST_MESSAGE, scratchString);
				snprintf(scratchString, STRING_LENGTH, "%f\n", v);
				platform->Message(HOST_MESSAGE, "new v");
				platform->Message(HOST_MESSAGE, scratchString);
				
			}

			dCross = 0.5*(0.5*(v*v - u*u)/acceleration + distance);

uncomment v=1.0; and comment v=sqrt(-u); and you'll hear a lack of banging from the machine when running bang2.gcode (or other gcodes that cause banging) and see more achievable speeds for starting and ending the segments that precede a reversal in direction while not being long enough to allow full acceleration or deceleration.

[edit 1]You're right though - it would seem more sensible to profile more than one move before and after the current to prevent this last-minute rush - the third order approach used in tinyG that I linked earlier in this thread seems pretty effective, but also might not lend itself to a single general purpose processor with other stuff on its mind... [/edit1]

Cheers

Ray

Edited 2 time(s). Last edit at 02/17/2014 06:20PM by rayhicks.