Back
[06:48:57] <skunkworks> using the velocity from the encoder now is right - but ddt'ing that has very high acceleration still
[06:58:33] <skunkworks> when it should peak at 20 - it peaks at 130-150 in/sec^2
[06:58:47] <skunkworks> must be timing issue
[06:59:12] <memleak> tempted to try PREEMPT_RT scheduler with RTAI...
[06:59:35] <memleak> any thoughts on this besides it being crazy?
[07:08:12] <memleak> wonder how many conflicts it would be anyway.. i mean it is just a scheduler, and RTAI is somewhat independant from the in-kernel scheduler chosen, whether PREEMPT or server
[07:21:00] <mozmck> memleak: I never tried PREEMPT_RT, but it seems like I did get better results with PREEMPT than other schedulers.
[07:27:40] <skunkworks> Increasing the step/inch helped.. (not it peaks at 100 in/sec^2)
[07:27:53] <skunkworks> *now
[07:37:10] <memleak> RTAI math support is completely hosed again, hooray
[07:37:27] <memleak> and all RTAI development comes to a dead halt..
[07:38:06] <memleak> mozmck, ah good to know!
[09:32:57] * skunkworks wonders how to more acuratly calculate the acceleration
[09:33:09] <skunkworks> and spell
[09:35:53] <skunkworks> lowering the base period makes it works.. which make sense
[09:39:45] <memleak> yeah if that didn't makes it works it wouldn't makes sense at all :P
[09:40:12] <skunkworks> I would think the ddt would have to take into account the exact time the velocity was reak
[09:40:13] <skunkworks> read
[09:42:30] <pcw_home> actual acceleration or TP acceleration?
[09:44:12] <skunkworks> actual acceleration
[09:44:30] <skunkworks> pcw_home, did you see
http://www.youtube.com/watch?v=qo74moJ30H4
[09:48:40] <pcw_home> is that actually running anything?
[09:49:14] <skunkworks> the left computer is running the right computer.. (other than that - no)
[09:50:07] <skunkworks> I am using the encoders on the 7i80 to read the step/dir as feedback to the right computer.
[09:51:14] <skunkworks> I was hoping that I could read the actual peak acc and vel from that left computer. The velocity works just fine (reading the velocity encoder pin) but the acc peak is way more than it should be.
[09:52:30] <skunkworks> which is using ddt in hal from the velocity pin. But I assume the timing is off and the ddt calculates from the period not the read time of the 7i80
[09:52:36] <skunkworks> (just guessing)
[09:54:27] <skunkworks> so maybe there needs to be a acceleration pin in the hostmot driver?
[09:54:30] <pcw_home> d/dt of the velocity pin should be OK (the encoder velocity should factor out the sampling time error)
[09:55:50] <skunkworks> hmm. then something is off... the left computer acceleration is set to 20in/sec^2 but the right reads it as close to 100 peak
[09:56:36] <skunkworks> 5000 steps/inch - 1khz thread
[09:57:07] <pcw_home> noise spikes or average wrong?
[09:57:08] <skunkworks> it got better when I increased the steps/inch
[09:57:50] <skunkworks> I am not losing or gaining steps that I can see
[09:58:14] <pcw_home> maybe just quantization error
[10:00:21] <pcw_home> is the stepgen in quadrature mode?
[10:01:33] <skunkworks> no. it is set to step/dir (count-mode is set to true)
[10:04:37] <pcw_home> I'm not absolutely sure the velocity estimation is correct for step/dir mode through reversals
[10:05:19] <pcw_home> is th error just short spikes of is the average off
[10:05:50] <skunkworks> oh.. wait - that would be an easy test - I could change the stepgen to quadature.
[10:07:02] <pcw_home> BTW a more direct way to measure stepgen accel is to d/dt the PID output
[10:13:31] <pcw_home> actually if you read the acceleration on a different machine (at the same thread rate)
[10:13:32] <pcw_home> you can get a 2x accel reading error due to lack of thread synchronization
[10:15:39] <pcw_home> (you have to consider that the actual stepgen acceleration is infinite, that is stepwise changes in velocity)
[10:21:57] <skunkworks> changing to quadature didn't help. still shows close to 100in/sec^2
[10:22:12] <skunkworks> the stepgen max acc is set to 25
[10:24:00] <skunkworks> well - this may just not be an easy thing to do.
[10:39:51] <skunkworks> this was really just an exersise in academics..
[10:40:14] <skunkworks> (I was hoping I could then compare paths and peak acc/vel from mach...)
[10:40:29] <skunkworks> I guess I can to vel and paths - just not acc
[10:40:37] <skunkworks> (which was what I really wanted to see...)
[10:42:09] <skunkworks> plus it tested the 7i80 a bit.
[11:04:57] <pcw_home> Are the errors short peaks or long time errors?
[11:05:10] <skunkworks> let me graph it
[11:05:51] <pcw_home> No sure if stepgen maxaccel does anything in velocity mode
[11:10:31] <skunkworks> pcw_home, the software stepgen on the computer (left) is running position mode
[11:10:59] <skunkworks> http://imagebin.org/291143
[11:11:26] <skunkworks> it is all funky while accelerating - then seems to beat..
[11:16:24] <pcw_home> Yes sure both hardware and software stepgens have step changes in the velocity at the servo thread
[11:16:25] <pcw_home> velocity update times. to see reasonable numbers you would have use a longer delta time or low pass filter
[11:16:27] <pcw_home> the servo thread d/dt of velocity
[11:22:57] <pcw_home> I guess both the software and hardware stepgens could incorporate acceleration
[11:22:58] <pcw_home> (software stepgeg update velocity every base thread with segment accel calculated at servo thread time)
[11:23:08] <pcw_home> stepgen
[11:23:38] <skunkworks> the velocity looks nice - maybe it just needs to be smoothed a little bit..
[11:34:20] <pcw_home> that beat is because of the unsynchronized thread as I mentioned (so a 25 IPS/S accel looks like 50 one sample and 0 the next)
[11:59:27] <awallin_> blah, I'm getting ImportError: libboost_python-py27.so.1.49.0: cannot open shared object file, for all my boost-python libraries lately - anyone seen that recently (I'm on ubuntu 13.10, and should have boost 1.53 installed)
[12:01:18] <pcw_home> skunkworks: that is you are asynchronously sampling a staircase waveform at roughly the staircase rate
[12:01:19] <pcw_home> assuming the measuring computer is using the same thread rate as the computer that is
[12:01:21] <pcw_home> running the stepgen so you may get accel * 0, 1, or 2 depending on the exact sample time
[12:03:26] * skunkworks wonders how hard it would be to add ddt to hostmot..
[12:03:55] <pcw_home> doesnt really belong in the driver
[12:04:12] <skunkworks> you have velocity out - why not acc? :)
[12:04:38] <pcw_home> accell can be done with DDT of velocity
[12:05:24] <pcw_home> the spike you have are not a problem with DDT but the fact that the velocity function is stepped
[12:06:01] <skunkworks> ah - so smoothing may help - but that probably causes all kinds of other problems..
[12:06:42] <pcw_home> well and measuring synchronously
[12:06:44] <skunkworks> would you lowpass the acceleration or the velocity going into the ddt?
[12:07:57] <skunkworks> so if I could increase the step/inch by a factor of 100 it would probably help a ton too.
[12:08:06] <pcw_home> accel probably (or add accel to the stepgen)
[12:08:21] <skunkworks> but software stepgen won't do that...
[12:08:41] <pcw_home> software can do it just like the hardware can
[12:09:19] <pcw_home> (add accel_frac to velocity every base thread invocation)
[12:11:52] <pcw_home> Oh you mean software stepgen wont go that fast
[12:12:40] <pcw_home> but both hardware and software stepgens _could_ avoid the steps in velocity
[12:48:58] <skunkworks> hmm - I don't think there is an easy way to make this work.. Low passing rolls it off too much without getting rid of the spikes
[13:00:42] <pcw_home> try ddt over greater T
[13:21:03] <skunkworks> wow - that seems to work.. I set the ddt in a 10ms thread.. A little cource.. but workable and no huge peaks. maybe 5ms would work
[13:26:53] <pcw_home> the lesson today is that higher derivatives of real world signals degenerate into noise...
[13:38:26] <pcw_home> But if you can find a way to instrument Mach's (or other software's)
[13:38:28] <pcw_home> step/gen output that would be really interesting.
[14:06:33] <skunkworks> wow - I have the slow thread running at 50ms and it is finally peaking at the stepgen acc limit (33in/sec^2)
[14:07:15] <skunkworks> (just over)
[14:09:32] <skunkworks> again - linuxcnc is awesome!
[14:09:55] <skunkworks> you would have to run the program multible times to get the peaks I would think
[14:10:00] <skunkworks> peak peak
[14:11:04] <pcw_home> yeah theres a combination of steps in the velocity (infinite accel), sampling jitter, and quantization
[14:11:05] <pcw_home> noise from both the stepgen and encoder velocity estimation so measuring accel is rough
[14:15:18] <skunkworks> http://imagebin.org/291169
[14:16:01] <skunkworks> so the stepgen is set to 33in/sec/sec and the ddt is running in a 50us thread. vs the 1khz base thread.
[14:16:15] <skunkworks> (y is the axis doing all the movies)
[14:16:27] <skunkworks> the scaling is upside down and backwards
[14:16:30] <skunkworks> :)
[14:16:45] <skunkworks> multible runs
[14:17:36] <pcw_home> I wonder if Mach has a servo thread equivalent (that sets the velocity update rate)
[14:17:46] <skunkworks> for grins I should set the stepgen max acc higher.. say 40... (the axis acc is 30)
[14:26:10] <skunkworks> http://imagebin.org/291171
[14:26:37] <skunkworks> I could increase the slow thread and see...
[14:26:49] <skunkworks> like 75ms
[14:32:33] <pcw_home> at some point you will not have any segments with full accel
[14:32:35] <pcw_home> for the averaging period so the actual profile generated peak accel will not be displayed
[14:33:54] <pcw_home> (at 75 ms d/dt thread time you are measuring the average accel of 75 ms time segments)
[14:34:01] <skunkworks> right
[14:35:15] <skunkworks> it is peaking at about 31in/s^2
[14:35:50] <skunkworks> so somewhere around 50+ms maybe...
[14:37:30] <pcw_home> that probably good (since testing you control the gcode so you can choose gcode that has long sections of peak accel)
[14:38:15] <pcw_home> since you are testing
[15:04:52] <skunkworks> I increased the acc to 40 and 43 stepgen. at 50ms ddt it peaks at 43.
[23:10:53] <KGB-linuxcnc> 03Dewey Garrett 05master 658dfbd 06linuxcnc 10src/Makefile 10tcl/bin/halshow.tcl halshow: make it available as standalone utility * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=658dfbd