Back
[04:57:46] <garage_seb> i'm not writing programs tonight, i'm making chips!
[04:57:47] <garage_seb> wheee
[12:15:12] <micges> debounce component could have counter pin with any pins filtered, that way we can se how dirty signals they are
[12:15:58] <SWPadnos> oh, I see
[12:16:31] <SWPadnos> you can do that with a counter, by using in^out as the enable for the counter, and use in as the count input
[12:16:43] <SWPadnos> (that's in xor out as the enable)
[12:17:44] <micges> I see
[12:18:35] <micges> but for me those info could be in debounce
[12:19:24] <micges> I like too much info without extending hal config
[12:19:41] <jepler_> so write it
[12:19:44] <jepler_> jepler_ is now known as jepoler
[12:19:46] <jepoler> jepoler is now known as jepler
[12:21:27] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/install/ (compiling_emc2.lyx installing_emc2.lyx): clear up confusion on some command line examples
[12:23:43] <micges> I don't have cvs write access ;)
[12:24:27] <alex_joni> micges: no, but you can send a patch
[12:25:32] <micges> I know just kidding
[12:34:52] <micges> ok done, how make usable patch for emc ?
[12:35:14] <SWPadnos> cvs diff -u debounce.c
[12:47:05] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS#Patch_Submission
[12:53:10] <jepler> OK, having finally taken the time to go back and check, it's the change to turn on CONFIG_CPUSETS that changed the kernel ABI incompatibly on amd64 .. just updating to the rtai 3.6.1 kernel patch doesn't
[12:53:27] <jepler> so now I need to stress-test this system with the new patch; it's been very crashy on the old patch
[12:53:43] <jepler> (actually, what I need to do is go in to the office and stop working on this stuff for the day ...!)
[12:54:04] <skunkworks_> bah
[12:55:17] <SWPadnos> bring the A64 computer to the office! :)
[12:56:51] <skunkworks_> http://imagebin.org/27829 you don't even need a case
[12:57:16] <SWPadnos> well, considering the crashing problems you had, I bet he does :)
[12:58:43] <SWPadnos> incidentally, I think this is a cool case for those GOAL3+ boards:
http://www.newegg.com/Product/Product.aspx?Item=N82E16811147099
[12:59:02] <skunkworks_> na - I just plugged in the case it is sitting on - problem solved.
[12:59:15] <skunkworks_> (now the case is grounded also.)
[12:59:16] <SWPadnos> it's not the smallest one available, but it's pretty small, has a good size power supply, etc
[12:59:18] <SWPadnos> heh
[13:55:20] <jepler> skunkworks_: bah, I don't want one of those single-core systems
[13:56:04] <jepler> up to 10us jitter in latency-test
[13:56:42] <jepler> (but this is dual cores; I think it does better with isolcpus but I don't recall the numbers)
[13:59:23] <jepler> I wonder how much of emc breaks if the threads can run concurrently. you could run the fast thread on one core and just busy-wait from period to period, and run the slow thread on a core shared with regular linux. that should get you a very fast base_period with essentially no jitter ..
[13:59:55] <jepler> .. but it is contrary to the hal model, because the slow thread and the fast thread would be executing simultaneously
[14:01:30] <SWPadnos> they already execute in a way that's equivalent to concurrence, at least in one direction
[14:01:40] <jepler> yeah it's the other direction that would be "new
[14:01:41] <jepler> "
[14:01:45] <SWPadnos> yeah
[14:38:18] <jepler> hm -- can you spot the bug in this component regarding 'count'?
http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/timedelta.comp?rev=1.5;content-type=text%2Fx-cvsweb-markup
[14:39:40] <cradek> well I don't see where it's defined but I see there's no zero protection on the divide
[14:39:52] <jepler> right on both counts
[14:39:58] <SWPadnos> har har
[14:40:37] <SWPadnos> so the real question is how does it compile?
[14:40:43] <cradek> does it even build?
[14:40:48] <jepler> every comp has a module parameter named 'count'
[14:40:55] <SWPadnos> oh, indeed
[14:41:10] <SWPadnos> so you can have 1000 of them ;)
[14:45:18] <jepler> incidentally, I notice that using rtapi_get_time() (returns time in ns) on this system doesn't take a particularly long time to execute; the timedelta function takes on the order of 150-300 cycles. this is contrary to what we saw long ago on a different rtai kernel altogether
[14:45:46] <SWPadnos> was that original investigation on 2.4 or 2.6?
[14:46:09] <jepler> I'm not sure
[14:46:24] <jepler> it was probably breezy or maybe even bdi
[14:46:29] <jepler> maybe rtai fixed it in the meantime
[14:46:37] <SWPadnos> I know some of it was on BDI
[14:46:40] <SWPadnos> yeah, could be
[14:46:41] <skunkworks_> I remember that - it was right at the end of bdi
[14:49:22] <skunkworks_> didn't you guys write the timedelta function bacause of that? I seem to remember things running really slow until this problem was figured out.
[14:49:48] <skunkworks_> or I couldn't run lower base periods.. Something like that..
[14:50:00] <SWPadnos> not timedelta, rtapi_get_clocks (or similar)
[14:50:58] <SWPadnos> hmmm. I wonder if the old method of getting the current time required reading from the timer chip, which uses slow I/O instructions
[14:51:22] <SWPadnos> but with high res timers or TSC or whatever, the reads are on a faster (PCI) bus or internal to the CPU
[14:51:57] <jepler> beats me
[19:11:58] <SWPadnos> hmmm. does kins have to deal with joint comp?
[19:13:35] <jepler> no, it's a later stage
[19:14:18] <SWPadnos> opk
[19:14:20] <SWPadnos> -p
[19:14:25] <jepler> joint offsets (including compensation and backlash) are applied to the output of inverse kinematics to get motor positions, and the reverse is applied to motor feedback before forward kinematics is run to get cartesian position
[19:14:44] <jepler> jmk has a good block diagram of all this, but I fear that it's not in CVS
[19:14:55] <SWPadnos> it's probably vector too ;)
[19:15:04] <jepler> of course
[19:51:17] <micges> how to use timedelay comp ?
[19:57:07] <micges> I dont see any docs
[20:04:52] <micges> in timedelay.c in header there is wrong description:
[20:05:25] <micges> delay parameters are in seconds not ms
[20:05:43] <micges> timedelay.c:8:
[20:19:11] <SWPadnos> man timedelay
[20:19:49] <SWPadnos> it's essentially debounce with asymmetric turn-on and turn-off
[20:27:23] <micges> SWPadnos: there is a small typo in that file at line 8
[20:28:18] <SWPadnos> what version of EMC are you using? timedelay is a .comp file in TRUNK
[20:30:30] <SWPadnos> that comment was fixed in December of last year
[20:31:01] <SWPadnos> (before the component was turned into a comp)
[20:31:03] <micges> 2.2.6
[20:31:08] <micges> I see that now
[20:31:34] <micges> sorry
[20:32:30] <SWPadnos> no biggie
[20:49:39] <cradek> jepler: if I check in my rfl changes will you help me resurrect some kind of verify so as not to break the other guis?
[20:50:18] <alex_joni> rfl?
[20:50:55] <jepler> "run from line"
[20:51:09] <alex_joni> ah..
[20:51:24] <alex_joni> I thought rflmao :)
[20:52:32] <cradek> or maybe, still, it's not a solution we want