i'm not writing programs tonight, i'm making chips!
debounce component could have counter pin with any pins filtered, that way we can se how dirty signals they are
oh, I see
you can do that with a counter, by using in^out as the enable for the counter, and use in as the count input
(that's in xor out as the enable)
but for me those info could be in debounce
I like too much info without extending hal config
so write it
jepler_ is now known as jepoler
jepoler is now known as jepler
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/install/ (compiling_emc2.lyx installing_emc2.lyx): clear up confusion on some command line examples
I don't have cvs write access ;)
micges: no, but you can send a patch
I know just kidding
ok done, how make usable patch for emc ?
cvs diff -u debounce.c
[12:47:05] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS#Patch_Submission
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
so now I need to stress-test this system with the new patch; it's been very crashy on the old patch
(actually, what I need to do is go in to the office and stop working on this stuff for the day ...!)
bring the A64 computer to the office! :)
[12:56:51] <skunkworks_> http://imagebin.org/27829
you don't even need a case
well, considering the crashing problems you had, I bet he does :)
incidentally, I think this is a cool case for those GOAL3+ boards: http://www.newegg.com/Product/Product.aspx?Item=N82E16811147099
na - I just plugged in the case it is sitting on - problem solved.
(now the case is grounded also.)
it's not the smallest one available, but it's pretty small, has a good size power supply, etc
skunkworks_: bah, I don't want one of those single-core systems
up to 10us jitter in latency-test
(but this is dual cores; I think it does better with isolcpus but I don't recall the numbers)
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 ..
.. but it is contrary to the hal model, because the slow thread and the fast thread would be executing simultaneously
they already execute in a way that's equivalent to concurrence, at least in one direction
yeah it's the other direction that would be "new
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
well I don't see where it's defined but I see there's no zero protection on the divide
right on both counts
so the real question is how does it compile?
does it even build?
every comp has a module parameter named 'count'
so you can have 1000 of them ;)
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
was that original investigation on 2.4 or 2.6?
I'm not sure
it was probably breezy or maybe even bdi
maybe rtai fixed it in the meantime
I know some of it was on BDI
yeah, could be
I remember that - it was right at the end of bdi
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.
or I couldn't run lower base periods.. Something like that..
not timedelta, rtapi_get_clocks (or similar)
hmmm. I wonder if the old method of getting the current time required reading from the timer chip, which uses slow I/O instructions
but with high res timers or TSC or whatever, the reads are on a faster (PCI) bus or internal to the CPU
hmmm. does kins have to deal with joint comp?
no, it's a later stage
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
jmk has a good block diagram of all this, but I fear that it's not in CVS
it's probably vector too ;)
how to use timedelay comp ?
I dont see any docs
in timedelay.c in header there is wrong description:
delay parameters are in seconds not ms
it's essentially debounce with asymmetric turn-on and turn-off
SWPadnos: there is a small typo in that file at line 8
what version of EMC are you using? timedelay is a .comp file in TRUNK
that comment was fixed in December of last year
(before the component was turned into a comp)
I see that now
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?
"run from line"
I thought rflmao :)
or maybe, still, it's not a solution we want