@dc42 -I've sliced this smile.gcode "smile" which shows the problem at each apex (in a "real world" manner), it's just two layers of semi-circular perimeters. It's sliced with a feed rate of 100mm/s, but does show the effect when run with the default cap of 50mm/s, it doesn't show the effect when run through the revision I posted yesterday (I've also added a picture of it for clarity):


it doesn't seem to be a 2 dimensional issue, setting all X axis points to the same value still causes banging on Y (as demonstrated in the simplified gcodes I uploaded yesterday).

Cheers

Ray

I've taken a look at this and worked out the physics. The values of u and v are never negative on entry. The problem is that this code was incorrect:

Quote

} else
{
v = sqrt(-u);
u = v/k;
}

It should have been:

Quote

} else
{
u = sqrt(-u);
v = u * k;
}

Alternatively, the calculation done a few lines previously can be changed to used the negated acceleration when u < v, then there is no need for the conditional because the first case is always true. I've tested this with bang2.gcode and looked at the values calculated after making this change, and I am certain it is correct.

I'll be updating my binary with this change soon (and I will post here again when I have done that), however there is on other firmware change I would like to complete first.

Thanks again to rayhicks for pinpointing the problem code.

---

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].

I'd wondered why the calculations were different in the two clauses (rather than just negating it before applying the root, or taking an absolute - I'd presumed that the intention was to lower v and recalculate on that when u was negative) the original context is here

if(u >= 0.0)
			{
				u = sqrt(u);
				v = k*u;
			} else
			{
				v = sqrt(-u);// u must be negative to get here, surely? - this is what I changed to "v=1.0" in my naive fix
				u = v/k;
			}

Quote
dc42
The values of u and v are never negative on entry.

surely the program wouldn't get into that else clause unless u is negative?
I'll try the modification you've posted above and check it works on my more egregious prints
Cheers

Ray

Ray, the value of u on entry to the function is never negative, however u gets changed to a temporary value a few lines earlier:

  u = 2.0*acceleration*distance/(k*k - 1);
  if(u >= 0.0)

If u > v on entry then this temporary value is negative.

In fact, the algorithm used isn't ideal and is more complicated than necessary. It reduces both u and v in the same proportion so that the axis can accelerate between them in the distance available. But it is only necessary to reduce whichever of them is greater. So I've now replaced that whole section of code with this:

  if(dCross < 0.0 || dCross > distance)
  {
    // With the acceleration available, it is not possible
    // to satisfy u and v within the distance; reduce the greater of u and v
    // 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 temp = 2.0 * acceleration * distance;
    if (v > u)
    {
      // Accelerating, reduce v
      v = sqrt((u * u) + temp);
      dCross = distance;
    }
    else
    {
      // Decelerating, reduce u
      u = sqrt((v * v) + temp);
      dCross = 0.0;
    }
  }

The binary is available at [dl.dropboxusercontent.com].

Edited 2 time(s). Last edit at 02/18/2014 08:30AM by dc42.

---

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].

great, thanks dc42 I'll grab one now

Right, I loaded Ray's firmware this morning. Yesterday was a wasted day for the Ormerod - 6 hours printing my PSU inlet cover (30m of filament) at 40mm/s with banging at every rounded corner (the noise became annoying). Then at a height of 72mm of the 77mm tall print, the Y motor jumped a step. It allowed me to verify the fit and tweak the component cutouts, but the print is in the bin. Being ever the optimist in anticipation of Ray's efforts, I re-sliced the same job this morning to print at 55mm/s and kicked it off with Ray's firmware ("RepRapFirmware-057rh.bin") about 90 minutes ago. A huge difference right from the first Z movement! (A faster move to bed height.) The Ormerod is running smoothly without jerking as it used to. On every corner I see Ray's debug message "v<instantDv" and it takes the corners smooth as silk. But other moves that do not give rise to a debug message seem better as well, and my hole cutout in the sidewall has smoother edges. Perhaps it's my imagination, but something else appears to have been fixed. I have slight bumps in the X direction at the corners at this speed, which probably means that my X belt needs tightening, but nothing serious. Like yesterday's print, there is some slight warping, but it is lifting both ends of the print equally, giving a slight curve to the front that actually enhances its appearance! If nothing goes wrong I might get home at a reasonable hour this evening for a change!

I look forward to testing how much faster I can print with this firmware.

Thanks, Ray

Dave
(#106)

Hi Dave - glad to hear it's working! - dc42 has made a more rigorous fix (linked above - and his doesn't spew out the numbers ) I'm running that now on a problem print @100mm/s (where previously I had it at 30-40 depending on how brave I felt) and it's going great, no bangs at all and due to print in less than half the time (4 hours rather than 8 and a bit). Time to crank it up to 11!

by the way, in case you'd forgotten or didn't know (I certainly had) it's possible to use g-codes to override the caps on axis speeds/feedrates eg

M203 X6000 Y6000 Z240 E4000

if I'd known this yesterday I wouldn't have bothered changing them in the firmware version I wrote

I had a look at this code, and was inspired to do something. The code looked very strange, so I dived into it a bit to see what it is supposed to do.
I would simplify the code to the following, given its supposed function:

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

if(dCross < 0.0)
{
	// 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.

	// dCross < 0 implies that abs(u) > abs(v); we need to reduce u

	u = sqrt(2*acceleration*distance + v*v);
	dCross = 0;
	result = change;

} else if(dCross > distance)
{
	// dCross > distance implies that abs(u) < abs(v); we need to reduce v
	v = sqrt(2*acceleration*distance + u*u);
	dCross = distance;
	result = change;
}

Hope that helps...

Note in general, that the code assumes that u, v, and feedRate are all positive, and that both u and v are smaller than or equal to feedRate. I trust the calling function takes care of that?

EDIT: sorry, did not see dc42's post above. Happy to see we came to the same conclusion :-)

Edited 1 time(s). Last edit at 02/20/2014 10:40AM by Flyskyhy.