Another acceleration bug

I've uncovered another bug in the acceleration algorithm. If you print the attached gcode using firmware 059-dc42 then the head does some juddering moves accompanied by nasty sounds. I added some debug to the firmware and discovered that it is doing some very silly things, like trying to accelerate from standstill to almost 200mm/sec instantaneously (I have max XY velocity set to 12000mm/minute). One way of triggering the problem is to have a number of short moves after a z-move, as in the example file, but I don't think this is the only way. I recall that some users were having problems when wipe-on-retract was used in slic3r, and this issue may be related because wipe-on-retract does a sequence of short moves.

In case RRP had already fixed this, I tried it with their 0.65d firmware too. The juddering was even worse.

I think I know what's going on, and unfortunately it's not very easy to fix. Ideally, I'd rewrite a large part of the movement code, taking in proper handling of combined XYZ moves in the process.

---

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

Hi DC42,

Thanks for looking into this and pointing it up. Its quite important! I believe your firmware is already much superior to the official one in calculating and performing moves so thanks for the work you did on this already!

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Yes, I've noticed that the judder at first move after layer change was not fixed properly. I've had it cause a stepper to miss a step and ruin the print in rare cases.

It sounds to me after reading several comments about the way the code is implemented that the firmware would benefit greatly by having all the movement variables changed to integers - in fact I see no reason to have any floating point variables in the code whatsoever - 32 bit integers should be plenty accurate enough and large enough if all moves are converted to the closest micro-step of the relevant stepper motor as they are read in, after which that's the only unit worked with by the rest of the code. Of course it's easy to criticise from the sidelines - I've yet to take the plunge and start getting my hands dirty as far as firmware is concerned, and thinking about how I would implement the acceleration algorithms made my head hurt very quickly - it seems very chicken-and-egg in that you need to know what the speeds are going to be X moves ahead in order to calculate when to accelerate or decelerate, but you need to know when those acceleration/decelerations are going to take place in order to calculate the speeds. The only way I came up with was to look a lot of moves ahead and assume a speed of zero after the last move read in, then work backwards to plug in speeds/accelerations for each intermediate move, then shift the list of moves up after each move has been executed and do all the calculations again. The CPU would be fast enough to do that if all the calculations were integer calculations.

Dave
(#106)

Dave,

I agree that there's more use of floating point than necessary at present. In particular, I would like to remove the use of floating point from the ISR. I also agree that it's necessary to look many moves ahead. One of the issues is that the current algorithm may couple a series of moves together smoothly, then when it's to late to go back, find a move that needs to have near-zero end speed because of a change of direction, but the move is too short to decelerate enough. So the look-ahead needs to be far enough to find either the next move which needs zero end speed, or sufficient moves so that the total distance travelled is enough to bring the end speed down to zero.

I would also like to end the classification of move types into xy, z or e moves, with the exception that extruder-only moves are a bit special because of how the feed fate is interpreted. I'd like to work in Cartesian coordinates throughout. This combination would eliminate problems with xyz moves. And I'd like to make the timing of steps of the stepper motors independent of each other so that all the motors are driven smoothly, which is not how it is now for moves involving more than one motor.

---

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 think my approach would be to set up the number of (micro)steps for each motor for every move. Speed will be controlled by setting up a timer interrupt as a separate function, the timer interval being calculated to be (say) 1024 times shorter than the step interval of the fastest axis, and re-calculated at every interval from the acceleration required. Each motor will be stepped after a particular number of timer interrupts (each motor stepping after a different number of interrupts, the values being fixed during each move). So if X must move half the distance of Y, then Y will step every 1024 interrupts, and X will step every 2048 interrupts. To accelerate, the timer interval will decrease every interrupt (calculated separately), to decelerate the timer interval will become longer.

Dave
(#106)

I agree with setting up the number of microsteps for each motor, along with the acceleration for each motor and a few other things. However I don't think your suggestion of generating interrupts at a rate much faster than the fastest step rate is workable, because the rate would be too high. Movement in the X or Y direction at 200mm/sec (the maximum I use at present) requires microstepping at nearly 18kHz, so that need would interrupts at about 18MHz @ 1024 interrupts/step. My plan was that in the ISR I would determine which motor(s) need to be stepped next and when, and schedule an interrupt for that time.

---

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
I agree with setting up the number of microsteps for each motor, along with the acceleration for each motor and a few other things. However I don't think your suggestion of generating interrupts at a rate much faster than the fastest step rate is workable, because the rate would be too high. Movement in the X or Y direction at 200mm/sec (the maximum I use at present) requires microstepping at nearly 18kHz, so that need would interrupts at about 18MHz @ 1024 interrupts/step. My plan was that in the ISR I would determine which motor(s) need to be stepped next and when, and schedule an interrupt for that time.

If you have 4 interrupt timers available, that may be better. But 18MHz is not necessarily too fast, considering that in the majority of cases all the interrupt routine itself would be doing is decrementing 4 counters and setting a flag if any reach zero (a normal asynchronous thread or slower timer interrupt will pick up the flag and actually perform the move & recalculation of variables) - it could be done in an assembler routine on a FIQ. 1024 intervals per step is probably overkill in any case, I except 16 would give plenty sufficient granularity.

Dave
(#106)

18MHz is far too fast, it's less than 5 clock cycles of the SAM3X. I take your point about 16 being sufficient granularity, it would give much smoother action than the current code. However, a single timer can generate all the necessary interrupts using the scheme I have in mind. All that is needed is to let the timer free-run, calculate the count at which we want the next interrupt, and reprogram one of the compare registers to give us an interrupt when that count is reached.

---

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
Dave,
[...]
I would also like to end the classification of move types into xy, z or e moves, with the exception that extruder-only moves are a bit special because of how the feed fate is interpreted. I'd like to work in Cartesian coordinates throughout. This combination would eliminate problems with xyz moves. And I'd like to make the timing of steps of the stepper motors independent of each other so that all the motors are driven smoothly, which is not how it is now for moves involving more than one motor.

This sounds good to me. Treat each axis as if the others didnt exist! There is no interaction that I can see.

Perhaps the code is as it is because it originated from the code for less powerful Arduino microcontrollers.

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Quote
kwikius
This sounds good to me. Treat each axis as if the others didnt exist! There is no interaction that I can see.
Andy

Unfortunately there is interaction, especially between the X & Y axis. If you only consider speed and not acceleration, then with max X and Y speeds of 100mm/s, if there is a move from 0,0 to 100,200 then with Y moving at 100mm/s, X can only move at 50mm/s because it's speed is constrained by Y. But in a move from 0,0 to 200,100 it will be Y's speed that is constrained by X. If you add acceleration into the equation, the relationship becomes more complex (Think of a move from 0,0 to 100,100 followed by a move to 150,200).

Dave
(#106)

Hi Dave, yes I'm well aware of that interaction, which is between all drives including extruders, and I have already written the code to take care of it. But once the correct speeds and accelerations for each drive have been worked out such that all drives are operating within limits, the drives can be controlled independently.

Edited 1 time(s). Last edit at 05/13/2014 10:18AM 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].

Hrm, I was honestly wondering why I got missed steps during a print with "Wipe on retract" enabled - but it makes sense now. This seems to happen quite frequently when retracting over small circles and dc42's explanation puts it in a nutshell.

Quote
dc42
Ideally, I'd rewrite a large part of the movement code, taking in proper handling of combined XYZ moves in the process.

I remember asking Ian about the progress of implementing combined XYZ moves about two months ago, although the background why I asked was somewhat different. At that time, I was told RRP are working on it, but I haven't heard any news about it since then. Ian, if you're reading this, can you give us a rough estimation how long it will take until these changes are implemented? I understand this stuff is quite complex, but if RRP are working on it, it can't take forever - right?

Two updates:

1. I've now got combined XYZ moves working, with all accelerations and velocities within the configured limits; except that the lookahead doesn't work yet.

2. I believe the current lookahead algorithm is flawed anyway. It's fine when the angle between adjacent moves is very small, such as when printing circles with large radius. However, for fast movements with e.g. a 20 degree angle between adjacent moves, it commands high instantaneous velocity changes from the steppers and I can hear a knocking sound. I've done the maths and I can see why. It's only a problem at high print speeds, but I guess I'll rewrite the lookahead code too.

Edited 1 time(s). Last edit at 05/15/2014 11:41AM 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].

Quote
dc42
Two updates:

1. I've now got combined XYZ moves working, with all accelerations and velocities within the configured limits; except that the lookahead doesn't work yet.

2. I believe the current lookahead algorithm is flawed anyway. It's fine when the angle between adjacent moves is very small, such as when printing circles with large radius. However, for fast movements with e.g. a 20 degree angle between adjacent moves, it commands high instantaneous velocity changes from the steppers and I can hear a knocking sound. I've done the maths and I can see why. It's only a problem at high print speeds, but I guess I'll rewrite the lookahead code too.

Brave man! Just thinking about it makes my head hurt! As said, my initial thought was to have a sliding buffer with the current move at the top and the nth move at the bottom. Assume the speeds after the last buffered move are zero, and work the accelerations & speeds backwards to the current move. After that move is complete, shift the buffer up & read in the new nth move, and recalculate the whole chain again. The problem being that it will probably take too long to calculate the whole chain using floating point maths if there are a succession of very short moves (such as when printing a circle), but if 32 bit signed integers are used it would need only 4 or 5 machine instructions per move, so with a lookahead of, say, 20 moves all calculations would easily be achieved in the time of even the shortest move. It sounds as if you are going to have to re-write so much that it might be easier to bite the bullet and convert the lot to integer variables as discussed.

I think I'd enjoy the challenge of writing such code, but I have too many other things to complete first to be able to start on it soon. I have never trusted the move algorithms on the Duet because the movements have never sounded correct for all moves on any firmware so far - there have always been the occasional jerky movements (sharp sounds) compared with other CNC machines I've watched using fast XY movements, and I have a feeling that large circles are printed slower than they need be as well. A good test would be to place a tall, thin and fairly heavy object on the bed, wind the Z axis way up and/or disconnect the X motor, set the highest speed and then find the highest acceleration limit that just fails to topple the object on a long linear Y move. Then send a G file containing a variety of different XY moves at that speed and acceleration and ensure that the object does not topple - the type of move should make no difference if the acceleration limit is always honoured. That would only test that the Y acceleration is not being exceeded, but I'm assuming that any code error that caused excessive X acceleration would also cause errors in Y as the code should be symmetrical. Then check that a circle or oval with a diameter of 200mm prints at least as fast as a square with 200mm sides.

Or run a separate acceleration monitor code just for debug that calculates acceleration from the raw stepper driver timings, and flags if it has been exceeded on any axis.

Dave
(#106)


Dave
(#106)

Hi,

I am using multixtruder firmware branch from T3P3 and I have exactly same problem with short moves. Is there a easy way how to implement your changes for moving algorhytms for multiextruder duet firmware?
Thank you

Quote
dc42
Two updates:

1. I've now got combined XYZ moves working, with all accelerations and velocities within the configured limits; except that the lookahead doesn't work yet.

2. I believe the current lookahead algorithm is flawed anyway. It's fine when the angle between adjacent moves is very small, such as when printing circles with large radius. However, for fast movements with e.g. a 20 degree angle between adjacent moves, it commands high instantaneous velocity changes from the steppers and I can hear a knocking sound. I've done the maths and I can see why. It's only a problem at high print speeds, but I guess I'll rewrite the lookahead code too.

Sounds very positive! I upgraded to your DC42 Reprap Duet firmware some time ago and I already noticed a huge improvement. I managed to print a part then with steep undercuts (in x,y) which had caused missed steps with the original reprap firmware ( why I decided to try yours), so if you do manage to get this done, Ill be very keen to try it out!

EDIT: Will also be great for OpenSCAD users, since radiusing is not easy you tend to make parts with sharp corners!

regards
Andy

Edited 1 time(s). Last edit at 05/31/2014 03:08AM by kwikius.

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Quote
dmould

Quote
kwikius
This sounds good to me. Treat each axis as if the others didnt exist! There is no interaction that I can see.
Andy

Unfortunately there is interaction, especially between the X & Y axis. If you only consider speed and not acceleration, then with max X and Y speeds of 100mm/s, if there is a move from 0,0 to 100,200 then with Y moving at 100mm/s, X can only move at 50mm/s because it's speed is constrained by Y. But in a move from 0,0 to 200,100 it will be Y's speed that is constrained by X. If you add acceleration into the equation, the relationship becomes more complex (Think of a move from 0,0 to 100,100 followed by a move to 150,200).

Dave
(#106)

I believe the mathematical term I was grasping for is that the trajectories in x,y,z are linearly independent.

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

I am not sure that is strictly correct Andy.
If the extrusion rate is fixed at some maximum, the it is the combined XYZ speed which is important - that is, the speed in the X direction could limit the speed in the other two directions.
Greg

---

Ormerod #17

Quote
GregL
I am not sure that is strictly correct Andy.
If the extrusion rate is fixed at some maximum, the it is the combined XYZ speed which is important - that is, the speed in the X direction could limit the speed in the other two directions.
Greg

I am pretty sure what I say is correct, which is that changing the trajectory on one axis will have no effect on the other axes! Each axis has no knowledge of any other axis. It exists in one dimension only. Each stepper has knowledge of one dimension only. Moving the x stepper cannot change the y position/velocity/acceleration. Each one dimensional trajectory can therefore be considered in isolation. This is self evident, else chaos would follow If a 1D trajectory is outside its limits then sure the original 3D (4D with extruder I guess!] vector will need to be scaled to accomodate that limit

The extrusion rate has no effect on the x,y,z trajectories. Its just affects how fast plastic comes out of the nozzle. Pushing more or less plastic out the nozzle will not move any axis. Again this is obvious.

My underlying point is that low level code that applies to one axis shouldnt be taking any notice of what the other axes are doing. I had a quick look at the official firmware souerce and saw that this rule didnt seem to be the case. I assumed this may be what DC42 has been referring to in this and other thread about issues with the trajectory calcs, but dont want to make assumptions as I havent looked in depth into the code

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Each axis will be independent from its own control point of view. However, I think the point being made was that if the extrusion has a maximum rate then that can itself limit the speed at which the nozzle can travel in order to achieve the correct amount of filament being extruded for that speed. The speed is of course made up from primarily the x and y velocities and so there can be some application level coupling between them. So if for example the maximum extrude rate was just enough to cope with maximum x velocity on its own (0 y) then introducing a y component could force one to lower the x component in order to meet the extrude constraints.

I believe that the correct approach is the following, for a combined XYZE move (it's a little different for extruder-only moves):

1. From the extrusion amounts requested, work out the requested extrusion velocities.

2. Look at the requested velocities of all the axis and all the extruders. If any of them exceeds the maximum configured for that axis or extruder, scale them all back by the same proportion, so that they are all within their respective limits but still in the same proportions.

3. The accelerations need to be in the same proportion as the velocities. From the configured maximum accelerations of the axes and extruders, work out which one is the limiting one, then work out what the other accelerations should be.

4. Assuming we are starting from rest, the instantaneous starting velocities also need to be in the same proportion. From the configured instantDv values for the axes and extruders, work out which is the limiting one, and hence what the initial instantaneous velocities should be. [Although I think we could do away with the whole concept of instantDv and assume acceleration from rest instead.]

5. Now we can work out the acceleration profile.

6. Work out the time profile of steps required for each motor. The motors should be driven independently of each other, so that each one gets a smooth series of steps, instead of the current situation in which the interval between steps for a single motor during a steady diagonal movement can vary by almost 2:1.

One consequence of using this approach instead of the current one is that the maximum velocity and acceleration will be the same as for the current approach for moves along the X or the Y axis, but higher for diagonal moves. So rotating a print by 45 degrees could affect the print time and quality.

I have already implemented (1) thru (5) in my unreleased code. I still have to fix the look-ahead algorithm, then I can release it. Later on I will add (6). After that I intend to look at having the extruder motors lead the axis motors by a configurable amount of time, which was suggested in another thread some time ago.

But right now I have paid work to get on with, so all of that will have to wait a while.

---

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

We're looking at this as well, as a matter of urgency. Particularly with all the mutli-extruder code, it was becoming very necessary, so it's Adrian's number one priority at the moment. I don't really have any more detail at the moment, though.

PS I showed him the gcode from the first post running. Brutal! It also nicely shows the full speed move after the layer change, which becomes very obvious when you slow the feed rate down from 12000mm/min to 1200mm/min.

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 05/31/2014 01:30PM by droftarts.

Quote
droftarts
We're looking at this as well, as a matter of urgency. Particularly with all the mutli-extruder code, it was becoming very necessary, so it's Adrian's number one priority at the moment. I don't really have any more detail at the moment, though.

I could save him some time, I've almost got it working.

---

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

Quote
droftarts
We're looking at this as well, as a matter of urgency. Particularly with all the mutli-extruder code, it was becoming very necessary, so it's Adrian's number one priority at the moment. I don't really have any more detail at the moment, though.

I could save him some time, I've almost got it working.

LOL!



Erik

Quote
dc42
I could save him some time, I've almost got it working.

So has he... did you look at the 'vel' branch? And that was a few months ago... Like I said, I don't know where he's at at the moment. Have you got a github branch he can look at? I'll try and get him to update github with whatever he's doing.

There are plenty of other examples of movement code working on ARM processors; the 4pi (based on Marlin/GRBL) and Smoothieboard are the two obvious ones.

Ian
RepRapPro tech support

Ian, I haven't committed the files to github, so I am attaching them to this message. The movement and acceleration rates are all calculated correctly, however the lookahead algorithm needs rewriting for a number of reasons: (a) it is not compatible with the new movement algorithm, (b) it is responsible for the acceleration bug I referred to at the start of this thread, (c) the cosine-based algorithm that the existing lookahead algorithm is flawed as shown by a spreadsheet simulation.

I looked at grbl, however I believe there is a fundamental difference in requirements between CNC machines (for which grbl is designed) and 3D printers. CNC machines mill relatively slowly, so acceleration isn't much of an issue and the motors can be assumed to follow individual steps. A movement algorithm based on Bresenham's line drawing algorithm works well. 3D printers run much faster, acceleration is a much bigger issue, and the steppers can't react to individual steps because of the inertia of the steppers and the bed. Instead, I think each movement needs to be planned as a smooth continuous movement in a straight line and not as a series of zigzags, with the step commands delivered to each motor independently of the other motors.

Edited 2 time(s). Last edit at 06/01/2014 05:25AM 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].

Thanks dc, I'll send a link to this thread to Adrian. I know he has worked out the maths for it, but he was also thinking about how to implement the lookahead. It doesn't look like he has updated the 'vel' branch, or any other, with what he's done recently. We had a discussion about how long the lookahead pipeline should be the other day; if a series of rapid short moves could out run the lookahead and acceleration ramps. I think it's possible if you're printing REALLY fast, as the lookahead pipeline is 16 moves (or 12, I can't remember!), but then we haven't really seen it running out of moves in Marlin on repraps with older electronics. I think we settled on 20 moves, but then it should be easy to adjust this. Adrian's suggested doing an acceleration ramp for each motor for the whole file as the 'proper' way of doing it!

The GRBL code has served well in Marlin and other firmwares and seems to work effectively despite the different requirements of a 3D printer compared to a mill, but the extra power we've got in the SAM3X could be put to better use. I'm not sure I understand what you mean about making movement continuous; stepper motors are always going to step! A more continuous movement of the stepper motors would need a change to the stepper driver chip, for more microsteps, though anything over 10 microsteps is generally wasted (see 'why 10 microsteps' in the geckodrives stepper faq here [www.geckodrive.com] ). Do we need that much accuracy? And we're already having problems with the high frequency EMI these produce; going even higher frequency stepping would be even worse. Maybe you're thinking about a move to servo motors?

Ian
RepRapPro tech support

Hi Ian, yes you can only drive stepper motors in a series of steps, however at high speeds they don't follow individual steps. At these speeds they should be driven with steps at a rate that is virtually constant over a small time interval. So the firmware should work out what continuous acceleration and velocity profile is needed, then generate steps that best approximate that profile. The current firmware does the former but not the latter. However, getting this right is IMO less important than fixing the other issues.

---

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

Adrian has released his version, 0.74, in the 'duet' branch. We're testing the move code at the moment, and it seems to have solved the motor skipping problems... we'll try and work out if it introduces new ones! The lookahead has also been updated, but he hasn't changed the cosine function, but doesn't seem to be causing problems. We have tried dc42's 'ouch' gcode on it (from the start of this thread), and it did that happily, with bed and orthogonal compensation applied. Any comments and feedback would be most welcome, though if you test it out, be aware that the firmware uses different pins for the proximity probe; see this commit: [github.com]

Ian
RepRapPro tech support

Thanks, Ian. I've taken a look at Adrian's movement code in the Duet branch, and I'll merge it into my fork when I get time.

---

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