#linuxcnc-devel Logs

Jun 06 2018

#linuxcnc-devel Calendar

01:28 PM rmu: skunkworks: i updated the branch, some additional cases of excessive acceleration should be fixed
01:30 PM rmu: i think i reached the limits of this "explorative surgery" approach, further improvements need stuff to go into the actual trajectory
01:42 PM rmu: exploratory
02:33 PM skunkworks: rmu: no violations at feedrate scale of 1. I did get a 'Bad format unsigned integer'
02:34 PM skunkworks: and it ended without finishing the gcode. (I think you mentioned that)
02:37 PM skunkworks: Wow - great start! would love to see what it feels like on real hardware. Have you tried it on yours?
02:38 PM skunkworks: feedrate scale set to 10 finished with no violations
02:38 PM skunkworks: (3d_chips)
02:40 PM hazzy-lab: Hurray! That sounds like a great start!
02:49 PM rmu: hmm. strange error...
02:50 PM rmu: i didn't try it yet on real hardware
02:52 PM rmu: after looking at some hal scope traces of the trapezoidal velocity profile gen i need to rethink some parts, it seems that some limits i supposed are guaranteed in the "trajectory components" are not guaranteed
02:52 PM rmu: and that's strange
02:52 PM rmu: will have to ask rob e about it
03:13 PM seb_kuzminsky: that's awesome!
03:32 PM skunkworks: 2 plots.. rmu's branch
03:32 PM skunkworks: http://electronicsam.com/images/KandT/testing/rmu/jerklimited.png
03:33 PM skunkworks: master
03:33 PM skunkworks: http://electronicsam.com/images/KandT/testing/rmu/notjerklimited.png
03:33 PM skunkworks: it looks like the jerk is reduced.. but so is the max acceleration.
03:34 PM skunkworks: similarish location
03:37 PM skunkworks: I am assuming ddt'ing acceleration gives you jerk...
03:45 PM rmu: jerk is derivative of accelertion (with resp. to time)
03:45 PM rmu: jerk limited path has to be slower
03:46 PM rmu: constant acceleration means more or less constant "full throttle"
03:47 PM rmu: whereas jerklimited means slowly start accelerating
03:49 PM rmu: with some machines it should be possible to use higher acceleration if jerk is limited
03:50 PM rmu: my branch doesn't yet impose a limit on jerk, so although it is limited, the limit is arbitrary ;)
03:58 PM skunkworks: understood
04:03 PM skunkworks: does it spread the acceleration over a given segment? (currently)
04:06 PM seb_kuzminsky: looks like it jerks accel up to max_accel at the start of the accel phase, then reduces jerk to 0 for the accel version of our old "cruise phase", then jerks accel back down to 0 when we reach the target velocity (this is the beginning of the *actual* cruise phase)
04:06 PM seb_kuzminsky: did i understand the question you were asking?
04:07 PM rmu: this https://forum.linuxcnc.org/media/kunena/attachments/22991/Screenshot_20180531_204204.png vs. this https://forum.linuxcnc.org/media/kunena/attachments/22991/Screenshot_20180531_204051.png explains it all
04:08 PM rmu: that's a move of x-axis from standstill to standstill with a delta of 20 in position
04:08 PM seb_kuzminsky: that's beautiful
04:09 PM rmu: yeah, but thats only an easy example ;)
04:09 PM rmu: the hairy things remain to do
04:09 PM seb_kuzminsky: i love how the jerk peaks come down from infinity to some sensible values that fit on the scope
04:09 PM seb_kuzminsky: sure
04:10 PM rmu: seb_kuzminsky: do you know why trajectory planner creates segments that can't be executed even by the trapezoidal planner?
04:11 PM rmu: (within acceleration limits)
04:11 PM rmu: that seems strange
04:11 PM seb_kuzminsky: i'm not aware of that problem
04:11 PM rmu: i wonder what happens if the planner demands some deceleration that the trapezoidal executor can't follow
04:11 PM rmu: i have a screenshot
04:11 PM rmu: mom
04:12 PM rmu: have to gimp it to mark interesting spots
04:12 PM seb_kuzminsky: if you can reproduce it reliably, please open an issue on github and attach all the relevant evidence, and maybe rob will take a look at it
04:16 PM rmu: it doesn't lead to violation of acceleration limits of the machine
04:16 PM rmu: so it's not a problem per se, probably it's supposed to be this way
04:17 PM seb_kuzminsky: if the segments don't violate the acc limits, what do you mean when you say they can't be executed by the trapezoidal planned?
04:17 PM seb_kuzminsky: *planner
04:17 PM rmu: https://unfoo.net/~robert/Screenshot-trapezoid-weird.png
04:17 PM rmu: this plot is a little crowded
04:18 PM rmu: tc.0.pos shows the "progress" of a segment
04:18 PM rmu: tc.1.pos the "target"
04:19 PM rmu: tc3.vel shows terminal velocity that should be reached
04:19 PM skunkworks: rob talked about the consuming of segments iirc
04:19 PM rmu: and tc0.vel actual velocity as generated by tpTrapezoidAccel
04:20 PM rmu: in the talk on youtube? probably have to rewatch it
04:20 PM skunkworks: there was a youtube video from a tormach get-togather.
04:21 PM skunkworks: maybe.. i communicated with rob a lot... could have been in email to
04:21 PM rmu: so the two spots marked with the red circles show where trapezoidal accel can't follow the segment
04:22 PM rmu: btw, i have email too ;-), just my nickname at the webserver of the screenshots
04:24 PM skunkworks: you have email? ;). i can send you my configs that have the peak panel. i have one for 9 axis too
04:25 PM seb_kuzminsky: rmu: the first red circle seems to line up with the XYZvel maxing out, am i reading that right?
04:25 PM rmu: skunkworks: jeah that would be nice and most welcome
04:26 PM skunkworks: have to add peak jerk also :)
04:26 PM seb_kuzminsky: :-)
04:26 PM rmu: seb_kuzminsky: the "end" where it goes horizontal lines up with xyzvel maxing out
04:27 PM skunkworks: as far as feed hold and feed override. it needs to be respinsive enough. mach had a habit of taking seconds to react..
04:28 PM rmu: yeah, there will be a small delay probably, but only on the order of 10 milliseconds or so
04:28 PM rmu: that should be acceptable
04:28 PM rmu: but i'm not yet completely sure that this approach actually does work ;) maybe i'm missing something important
04:30 PM rmu: so i'm out for today, have a nice day/evening/whatever, tty tomorrow
04:30 PM seb_kuzminsky: seeya!
04:31 PM seb_kuzminsky: skunkworks: if rmu is right an limiting jerk lets you increase the accel limit, then the extra sluggishness may be small or none
04:33 PM seb_kuzminsky: it'll take a bit of extra time to jerk the accel up and down, but if the max accel is higher during the "cruise phase" then you'll reach your new target velocity faster, and those two factors might partially cancel each other out
07:09 PM skunkworks: sure. I hope rmu keeps working on it :)