Rostock printer ignores acceleration and jerk between travel moves

[luke321]

When using the avoid crossing perimeters feature I always get lost steps when using my standard travel speed of 300 mm/s with an acceleration of 1000 mm/s^2.
To avoid this I have to reduce my travel speed to 100mm/s

Sometimes slic3r generates gcode that moves the nozzle in one corner of the print and than instantly back in the same direction.
Instead of slowing down the printer tries to make an instant direction change from 300mm/s to -300 mm/s ignoring my xyjerk of 20 mm/s and my acceleration and loosing steps.

Lowering acceleration only helps because the printer won't reach the full 300 mm/s, lowering Jerk does nothing and reduces print quality.

I think the printer should move in the same way when switching from a travel move to a print move, slowing down then accelerate up again.

I will upload a video where you can see and hear this behaviour very clearly.

[repetier]

Having currently no Rostock this really requires your help. Are you using 0.82.2? There I fixed an error when reaching high speeds. But I don't think it is the root of your problem as it has nothing to do with direction changes. Looking forward to the video, which perhaps explains more.

[luke321]

I will upload the video in the next 40 minutes or so...
Maybe the problem is a miscalculated junction speed?

[repetier]

I have to check that when I'm home. Could you also copy a gcode sequence matching your problem, so I can calculate what may happen there and perhaps why the jerk is not taken into account.

[luke321]

Here is a link to the gcode: https://www.dropbox.com/s/7og8iviypgw8tnj/test_gcodes.gcode

A picture of one of the layers: http://www.ld-host.de/uploads/images/588a242cf9153c30f41414d466156fe2.jpg
The printer tries to make fullspeed turns in the corners of the pins.
Their is no problem if the travel move ends in an print move or in a z move.

Maybe the Extruder Jerk does limit speeds when switching from travel to print?

Video with 100mm/s

http://www.youtube.com/watch?v=iVEleEpT_Ms&feature=youtu.be

Video with 300mm/s, printer looses steps in the end

http://www.youtube.com/watch?v=119RIg6QhDQ&feature=youtu.be

If you find something you could post the necessary changes here and I will try them out.
I'd really like to use higher travel speeds to reduce blobs on my prints.

[kyrreaa]

This is exactly the same issue as I have.
Rapid moves causing sharp corners are ran at full speed with insane jerks.
https://github.com/repetier/Repetier-Host/issues/182
I posted it under wrong section...

I made a simple code with triangles getting narrower and it happens on the last ones but is dependant on queuing. I expect some path planning is involved in avoiding it on the early blocks.

[repetier]

@kyrreaa So you are also using a delta printer?

Have just run the code on my non delta printer and it worked as expected.
I have also reread the code while I refactored the code for version 0.90 and the jerk seems to get computed just fine and reduces on reversals correct.

Unfortunately my delta printer is still not build and will get finished somewhere in the summer regarding the amount of programming I currently do.

I think the problem is buried in the delta only code, which was not written by me. I will have an eye on this issue when I refactor the delta code. Perhaps I see how it is possible to make the code ignore speed changes.

[luke321]

Thanks for looking into it, if I had more time I would try to figure the problem out.

One thing you could look at:

The problems only show when you have pure XY movement without extruder or Z movement.

[kyrreaa]

Yes. I've built a cross between the original rostock and the Kossel with my
own changes for 10mm linear rods. I am also getting problems from the new
perimiter code.
Den 29. apr. 2013 17:18 skrev "repetier" notifications@github.com
følgende:

@kyrreaa https://github.com/kyrreaa So you are also using a delta
printer?

Have just run the code on my non delta printer and it worked as expected.
I have also reread the code while I refactored the code for version 0.90
and the jerk seems to get computed just fine and reduces on reversals
correct.

Unfortunately my delta printer is still not build and will get finished
somewhere in the summer regarding the amount of programming I currently do.

I think the problem is buried in the delta only code, which was not
written by me. I will have an eye on this issue when I refactor the delta
code. Perhaps I see how it is possible to make the code ignore speed
changes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/99#issuecomment-17172999
.

[kyrreaa]

One thing that I notice when I start experimenting with accelleration is that my M201/M202 commands are utterly ignored and that I can't set new values to store in eeprom...
The M202 comman for instance sets axis_travel_steps_per_sqr_second while saving with M500 saves max_travel_acceleration_units_per_sq_second.
They don't appear to have any link and axis_travel_steps_per_sqr_second is used in calculate_move via split_delta_move. It thus doesn't appear to be any way of tuning this live and saving to eeprom?

[sousoux]

I saw this problem as well but never tracked it down. Sorry Roland. When I get a moment I will look at it again. 

Sent from Samsung Mobilekyrreaa notifications@github.com wrote:One thing that I notice when I start experimenting with accelleration is that my M201/M202 commands are utterly ignored and that I can't set new values to store in eeprom...
The M202 comman for instance sets axis_travel_steps_per_sqr_second while saving with M500 saves max_travel_acceleration_units_per_sq_second.
They don't appear to have any link and axis_travel_steps_per_sqr_second is used in calculate_move via split_delta_move. It thus doesn't appear to be any way of tuning this live and saving to eeprom?

—
Reply to this email directly or view it on GitHub.

[kyrreaa]

Hmm, looking at the code I start to wonder. The velocity, isn't it always a posetive number? Direction is stored elsewhere?
If so, can the two velocitys cancel out instead of sum as intended in the formula for jerk detection?
When I wrote my own gcode interpreter for my laser cutting setup a few years ago I calculated the angles of motion to calculate the actual vector change. This was ofcource a costly calculation...

[kyrreaa]

In motion.cpp, the code calculating dx and dy for jerk would be wrong assuming speed is posetive as direction is stored in ->dir.
I tested changing the calcs to this:
float dx = (current->dir&1)==(previous->dir&1)?current->speedX-previous->speedX:current->speedX+previous->speedX;
float dy = (current->dir&2)==(previous->dir&2)?current->speedY-previous->speedY:current->speedY+previous->speedY;
Now it moves very smoothly!

[luke321]

I will test this tomorrow! where exactly did you change the calculation in motion.cpp?

[repetier]

With the M201/202 it is likely wrong. There is a routine update_ramps i think (I'm at work now) that converts one format into an other and these commands set only one of 2 versions used.

I think there is also an error in delta code that you need to have steps per mm in eeprom identical to the one in configuration.h. I have to check and solve that, too,

I'm quite sure that speedXYZ contains a sign when computed for the cartesian printer, thus the jerk computation was correct. Possibly the signs are not set in the according delta code. I will check that after work. Would at least explain why it only happens with delta printer and why your fix works, also it would then stopp cartesian printer from working. But knowing what to look at makes a solution much easier. So thanks for your effords and I answer again when I verified the problem/solution at home.

[kyrreaa]

@luke321 if you look in motion.cpp for "jerk" you will see the dx and dy calculations.
I also did the same mods to the z and e calculations but since the e is undocumented in the dir attribute I searched the code and found it used so I know it's right. I'd fork it and do the changes but I am fed up with all open source project being forked to death.

[repetier]

Just a short comment after reading the sources. Your solutions works because you are undoing an other error. When I said speed is signed I was right. The problem comes from split_delta_move. Here the axis_diff is computed:
float axis_diff[5]; // Axis movement in mm. Virtual axis in 4;
for(byte i=0; i < NUM_AXIS; i++)
{
difference[i] = Printer::destinationSteps[i] - Printer::currentPositionSteps[i];
axis_diff[i] = difference[i] * inv_axis_steps_per_unit[i];
}

and in the cartesian computation axis_diff is always positive. So here axis_diff has a sign and for speed computation that sign is changed again. The right solution is to use

axis_diff[i] = fabs(difference[i] * inv_axis_steps_per_unit[i]);

but I'm still trying to understand the rest of the code, to see if sign of axis_diff matters for the delta code.

PS: The code is from version 0.90 so it differs a bit from the current stable version. I will adapt the stable version as soon as I'm through with proof reading.

[repetier]

Ok, there was still another place where axis_diff was computed, but is only used for distance computation, which is sign independend. So I hope the fix works. I've updated the github sources, which also fix the M201/202 problem.

@kyrreaa You are the king of the day for the hint in the right way!

Please report back if the jerk problem is now solved.

[kyrreaa]

I will test soon.
I am just happy I could find such a great firmware/host combo.
Great work on all your efforts with Repetier.

I will be meddling a bit more with it as there is/was something odd about OPS but it may have been ralated.
My plan is to add support for the AD8495 chip which is a cheaper thermocouple interface with built in cold-junction compensation than the AD595. (5mv/°C with 1 or 3°C accuracy)
I'm designing a board for it now that everything is falling in place. I plan on combining it with my inductive heaters and the stepper drivers to make a small single-board solution that I can run on my printer or printers.

[repetier]

OPS seems broken and gets completely rewritten for the next version, so do not spend too much time. Adding the AD8495 should be no problem. There are plenty of types left:-) just give me the code and I put it into the main branch.

[kyrreaa]

Quick note for you on that rewrite...
Add a tunable delay for extruder-lag. When I print at 140mm/s I notice that the first few mm after a retract/move/advance/print sequence can be a bit thin, or indeed missing completely.
I've placed my feeder on the top plate of the delta so the bowden length can be minimized. This helps but still there is a lagg due to pressure in the head.

[kyrreaa]

Just ran the new code and after updating with my hw changes it works very well!
Good work! I'm running 350mm/s on travel with jerk=100 and print accell x/y=2000mm/s and travel accell 4000mm/s.
After measuring the angular slop in short LMxUU's I am using long ones giving me zero z rattle vs +/-0.13mm with short. It's all very tight and smooth!

Have a beer on me!

[luke321]

Working perfectly now!
The speed and feedrate controls also work now without troubles!
Than you guys for the fix!

[seemecnc]

The fix is working great here too Roland. Luke321, noticed the smoother, quieter rapids? Sooo nice!