Back
[04:19:18] <steve_stallings> steve_stallings is now known as steves_logging
[07:18:55] <alex_joni> cradek: i think you missed emc2/dists/dapper/emc2.3/binary-all
[12:15:11] <micges> good morning all
[12:15:51] <micges> jepler: I have another file with naive cam buggy behaviour
[12:16:06] <micges> in a few minutes I'll post it
[12:17:22] <jepler> micges: are you testing with the patch? cradek brought it to my attention that I only put the fix on TRUNK, not v2_3_branch, and I have not got around to putting it on the branch yet.
[12:17:40] <micges> from TRUNK
[12:20:27] <micges> I've checked it, latest compiled TRUNK
[12:28:07] <micges> and cvs server didn't work
[12:28:37] <jepler> wfm
[12:29:00] <jepler> bbl
[12:40:21] <alex_joni> works here too
[12:40:32] <alex_joni> (CVS I mean)
[12:42:18] <micges> I think my isp sucks again :/
[12:42:34] <micges> can't even pastebin a file
[13:07:12] <CIA-2> EMC: 03bigjohnt 07v2_3_branch * 10emc2/docs/src/hal/pyvcp_examples.lyx: lyx strikes again, fix two dashes converted to long dash
[13:10:12] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp_examples.lyx: lyx strikes again, fix two dashes converted to long dash
[13:59:45] <jepler> huh -- when commanded with a step function, there's an odd anomaly in the acceleration of the feedback position.
http://emergent.unpy.net/files/sandbox/stepgen-feedback-accel-glitch.png
[14:10:09] <cradek> that's a surprising result
[14:39:03] <jepler> the step waveform looks just fine
[14:39:08] <jepler> all in halscope, of course
[14:41:11] <jepler> hmm, and now a halscope bug -- the log doesn't have the step & direction pulses in it. Instead, it has two fields named "(null)" with value 0 ..
http://emergent.unpy.net/files/sandbox/stepgen-feedback-accel-glitch.log.gz
[16:11:37] <jcoby> who was looking at moving to a dvcs? might want to look at the python doc on why they chose hg
[16:11:39] <jcoby> http://www.python.org/dev/peps/pep-0374/
[16:16:45] <jcoby> i think i'd go with git or hg.
[17:19:32] <alex_joni> is hal_joystick still around in 2.3.0 ?
[17:48:07] <jepler> alex_joni: I don't think it's been removed
[17:48:29] <jepler> /usr/src/emc2.3$ grep hal_joystick debian/emc2.files.in
[17:48:29] <jepler> usr/bin/hal_joystick
[17:48:37] <jepler> but it should never be used
[18:19:55] <SWPLinux> which reminds me. jepler, can latency_test see the RTAI latency information at all?
[18:20:05] <SWPLinux> (or I guess any HAL component really)
[18:24:11] <jepler> SWPLinux: I am not sure what RTAI latency information you mean
[18:25:44] <SWPLinux> what you would see fromthe RTAI kernel latency test
[18:26:05] <SWPLinux> the HAL latency test only shows jitter, not actual latency (AFAIK)
[18:26:18] <SWPLinux> which is only half the problem
[18:27:12] <SWPLinux> if that's true, then it's possible to have a slow but consistent machine appear to be a very good performer, when in fact it's not
[18:27:44] <SWPLinux> (ie, 25000 +/- 1000 latency only has 2000 jitter, but you definitely would have a problem with a BASE_PERIOD < 26000 or so)
[18:28:17] <jepler> have a look in latency-module.c from the rtai source
[18:28:33] <jepler> it just calculates this stuff based on periods and rt_get_cpu_time_ns or rt_get_time
[18:28:37] <SWPLinux> ok, will do (If I remember :) )
[18:28:45] <jepler> it's not something that rtai keeps track of
[18:29:02] <SWPLinux> I thought it also looked at the expected TSC (or whatever) value and compared that to actual
[18:29:04] <jepler> maybe it's printing a statistic that's more useful than emc's latency_test, in which case it should be improved
[18:29:23] <jepler> expected += period_counts;
[18:29:24] <SWPLinux> yeah, I don't know. I just know that there are two important numbers, and we only see one
[18:29:26] <jepler> diff = (int) count2nano(rt_get_time() - expected);
[18:30:21] <SWPLinux> hmmm. ok, thanks for looking at it. I'll dig deeper or forget about it :)
[18:30:55] <SWPLinux> hmmm. time to run out for lunch and stuff. bbl
[18:41:54] <BJT-Work_> BJT-Work_ is now known as BJT-Work
[20:15:30] <alex_joni> hmm.. that german user with the 5i20 + stepper problem, reports he's having the same issues with the sample config aswell
[20:16:15] <alex_joni> manual jogging overshoots slightly, then returns to the endpos
[20:16:42] <alex_joni> motors are doing some bouncing while idle (like servo hunting)
[20:39:34] <alex_joni> that sounds a bit like too much gain on the stepgen
[20:53:22] <jepler> ISTR with pluto_step I ended up with a tuning parameter that improved following up to a point, and caused undamped oscillation beyond that point
[20:55:04] <SWPLinux> alex_joni: how recent TRUNK is the German user using?
[20:55:30] <SWPLinux> Seb fixed Mesa stepgens within the last month
[20:56:42] <alex_joni> not TRUNK
[20:56:44] <alex_joni> beta2
[20:57:00] <SWPLinux> ok, I'm not sure if that's fixed (but I'd bet it is)
[20:57:00] <alex_joni> seb reported he completely changed the stepgens between beta1 & 2
[20:57:18] <SWPLinux> yeah - used stepgen pseudo-PID code
[20:57:22] <alex_joni> changed from the previous (his) implementation to the software stepgen implementation
[20:58:47] <SWPLinux> bbl
[22:19:17] <jepler> I sure wish lerman would pop back up
[22:21:17] <jepler> am I missing something here, or is this a very silly set of if statements?
http://pastebin.ca/1380394
[23:10:51] <SWPLinux> jepler: yes, in C that is a silly set of of statements
[23:10:57] <SWPLinux> o c++
[23:10:59] <SWPLinux> or
