jepler: I don't see how you tracked http://sourceforge.net/tracker/index.php?func=detail&aid=1736182&group_id=6744&atid=106744
to the bug you reported to me
but it seems to run ok now...
well except it errors at line 65 (would esceed liits)
if you reproduced it earlier, would you retest please
well, I've had my test running (with the PC crashed) for nearly 2 hours, and the total deviation recorded by the scope has been 1.2000 uS
this is using a Mesa card, so there's a nice pattern to the traces - showing the 33 MHz PCI bus clock quite nicely :)
sw stepping using the mesa as the I/O
no, simple HAL-only test setup
m5i20 driver and chargepump
set up with a fast base period - 10 or 20 uS
still, the 5i20 is strictly general purpose I/O, nothing HW generatec
I'll save the scope image to disk and upload that, along with the test files once I reboot the machine
it is very strange that I can't ping the machine, but the RTAI/HAL tasks are still running
the RT tasks run under linux
I'd expect other things that are interrupt-driven to also work
most things aren't interrupt driven
sure, the network might use an interrupt to receive a packet, but the rest of the processing (such as generating a ping response packet) isn't done in the ISR
well, this tells me that if we can get the rest of the kernel out of the way, we'll approach the interrupt performance of an AVR with a dual-core 2GHz CPU ;)
the difference is what you can get done during each interrupt
well, there is that
I'm sure the 64-bit math is faster on the A64
cradek: great, I'll retest too
jepler, did you notice any latency difference between the 32-bit and 64-bit kernels?
SWPadnos: I only ran the 64 bit kernel on that machine
and I forget what latency I measured (but maybe I blogged it?)
ok - just wondering if you saw any major differences
have you seen anything close to my smp machine with isolation (~ 8000 iirc)
this A64 gets ~13000 with the 32-bit UP kernel
maybe new machines would be even better
I haven't downloaded all the dev stuff (like source :) ) yer
I think I saw overruns (error returns from rt_task_wait_period) somewhere between 15000 and 17500
I haven't tried twiddling BIOS settings yet - I wanted to see if it makes sense to consider this PC for industrial RT
with BASE_PERIOD that low
cradek: is isolate a boot-time parameter? if so, I can try it ..
I was actually able to run with 10000 period, even with 13000 max latency
jepler: isolcpus=1 iirc
I don't remember whether I had to do anything special...
let me go try it
cradek: did you have to modify the latency test to make it choose the right CPU?
I don't think so
I already up to ovl max 9586 with a glxgears and a find running
that's still a good number
has anyone tried the new nvidia drivers that are supposed to be safer for realtime?
eek, got 118900 on switch from X to terminal
ah, don't do that
cradek: I used isolcpus=1 but both still show up in top. does that match your experience?
yes, but the only thing running on 1 was the kernel processes ending in /1
huh -- on this run I'm doing the same things (except switching to console and back) and I've got 910 (yes, 3 digits) ovl max
I wonder what's different now
oops, went up to 952
that doesn't seem like a real number
RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
RTD| -1549| -1614| -1250| -345| 952| 0
RTD| -1611| -1615| -966| -44| 1865| 0
RTD| -1502| -1615| -960| 21825| 21825| 0
well something finally happened to ruin it all
too bad you can't know when the latency test is done
it's finished when you see a number that's too high ;)
here's the scope trace: http://imagebin.org/9448
the gray lines are persistence from previous traces
what are you triggering on?
that's why there's a gray horizontal in the top right/bottom left
where is the trigger point? offscreen left?
script here: http://pastebin.com/m7556189a
.hal file here: http://pastebin.com/m1dfdbde
yes, it's 18.42 uS to the left (shown at top middle)
[ 1087.874864] CPU USE SUMMARY
[ 1087.875292] # 0 -> 0
[ 1087.875417] # 1 -> 3486021
if I apt-get source yadadyadda-magma, will I get full RTAI source as well?
* jepler wanders off again
hmmm. is this still the place to get RTAI? http://download.gna.org/rtai/testing/v3/
no, those are old
I got it last from some cvs somewhere
they don't release very often, so you generally have to use cvs for modern kernels
[02:18:53] <cradek> https://gna.org/cvs/?group=rtai
I just did a checkout of the magma module
yeah that's the ticket
that link was from the RTAISteps wiki page
(last edited in Dec 2005 by Paul C)
any suggestions on which kernel to try?
on 6.06, possibly trying 64-bit and/or SMP
maybe try the latest 2.6.20.x
hmm. there's a patch for 2.6.22
the RTAI guys make the patches for a specific version
and not many others
maybe try 22 then
right. there are about 50 patches in CVS
it's a total crap shoot
do you know of any troubles using later kernels on 6.06?
heh - I've played that game before (with RTAI)
some later ones have problems in general, but not specific to 6.06
ok. I'll try .22, then fall back to something else if necessary
well bootsplash won't work, but that's minor
did you say at some point that 2.6.17 was bad?
or was that the good one
yes it has a bad keyboard bug
I'm not exactly sure when that's fixed either, it bit me on several versions I think
ok, I'll skip that one
iirc, 18 and 19 are totally busted, which is why I was using 17
.19, .20, and .22 are all supported for both i386 and x64
jumping to 20.x seemed to fix the keyboard
but maybe I haven't used it enough to tell for sure yet
I managed to patch bootsplash into .17 but not .20.x, it's pretty different
so I just turned it off in grub, didn't care if the kernel is just for me
fwiw my deb packages are in /experimental on the website
you could easily just try them on your hardware if you want
are any of those SMP?
I have one question
like I said though, don't bother with the .17
why does anyone give a flying fsck about bootsplash?
because it's pretty
or so some people think
its entirely 100% cosmetic, does nothing at all for the computer
and hides usefull information
I can't seem to get grub to stop turning the damn thing back on
the same is true of cosmetics ...
so I'd rather it works
you have to do menu.lst foo to make it stop
thanks I'll try that next time
its not sufficient to do "# defoptions= <nothing>"
you have to explicitly say no
yep that's what I tried
I found that out the hard way
it fills some defoptions back in next time then
that file's an abomination
defaults in magic comments ... ugh
it could be better than defaults compiled in though
either someone is brewing some strong coffee, or a skunk did something outside my window
hmmm. cradek, did you ever post your SMP config online?
I thought you or jepler had
umm not sure
it's in those debs of course
right. another 40M :)
sorry, can't get to that machine right now
I really wish nv could tell that I have a 1680x1050 widescreen LCD - this 1024x768 is killing me
all the letters are so wide
fix your screen to not zoom it
it's on the menu somewhere
not on this screen
it doesn't have a 1:1 mode?
my dell 2001s have it
the monitor thinks it's in full res mode - the card may be doing the scaling for me
it's a $300 22" LCD - it's bogus all right
* cradek loans swp a crt
got one on the floor - 21" Nokia
scaling really loses the advantages of DVI
CRTs are so much better at displaying various scan rates and resolutions - which is amazing since they switch coils and stuff in and out to do it
variable spot size is very nice
that's why I have a 3-CRT TV
interestingly, that's how they do film scanning at various resolutions
TV - is that the device that's kind of like a monitor but has a large crappy picture?
and shows only advertising?
they illuminate the film with a CRT, and can vary the beam width for different spot sizes
I think so, which is why we watch PBS and DVDs on it
I read today (on some bogus internet thing) that an average american spends one year of his life watching advertising on TV
I suspect that's higher now
gotta be higher
not counting "product placement"
I can see where it could be easily an hour a day for many people
considering watching 3-4 hours of TV a day, which might even be low
I guess I have no idea how much TV "average" people watch
luckily, DVDs have fewer commercials
I love my new PC.... just remembered to restart the farm. All 3 VMs started doing complete builds, all finished in less than 3 mins, and the machine didn't bog down at all
that used to take 45 mins
we won't have to hear you complain either anymore :-)
is this since Fest, or just set up well now?
since the fest
cool. what did you end up getting?
I moved the VMs a week or so after I got home, they
oh, the machine isn't that new
its the core 2 E6600, I had that before fest
ok - it's the dual-core with the fanless nvidia card
cradek: yep, the pcCase-2.ngc now runs for me
I still don't see how it would have caused the problem you saw
well -- it did
and it doesn't now. so there!
how did you make the connection to your test case though?
once I saw that it did continue after that move, I figured it was a mistake in the constraints sent to the planner
based on the debugging information it printed, I found a small program to cause the problem
and luckily it seems to have been the same problem
thanks for finding the easy test case
thanks for fixing it
did you get a chance to check the skipped drilling fix?
will you take care of the report on sf?
no, I only duplicated the original behavior you saw
before my change I hope?
going to work tomorrow?
hmmm. that's odd. I patched the kernel with arch/x68_64/...x86_64...patch, and it patched files in the kernel arch/i386 directory
well, I guess I'll find out tomorrow just how bad it is to have a computer crash while compiling the kernel
Guest657 is now known as skunkworks_
static int emc_pendant(ClientData clientdata,
Pendant read routine from /dev/psaux, /dev/ttyS0, or /dev/ttyS1
huh I have never noticed this code before
I wonder what it's for / can do
where is it?
looks like it's unused
it's exposed as a tcl command "emc_pendant" but that's not used in any tcl program
skunkworks__ is now known as skunkworks
here's my idea for doubling the effective step rate for a given BASE_PERIOD: 1. add a new stepgen mode which is like step+direction, except that step is allowed to be high every cycle
2. add a new feature to hal_parport: pin reset. This has a new mask of pins to reset, a minimum time between write and reset (e.g., 5uS), and a new parport.X.reset function
3. rearrange the parport functions so that they are in the order write, read, other activity, reset.
4. make the "mask of pins to reset" be the same as the "step" pins
setp parport.0.reset_mask 0x55; setp parport.0.reset-min-time 2000
jepler: the 7486 was not a bad approach, a 5us(adjustable length) one shot on each step pin would allow the pin to be toggled very fast ie.. write then reset
to me a solution that doesn't require extra hardware is neater
jepler: true, but built into a breakout board there is little cost.... the software technique will increase the time it takes to execute the fast ~20us code
if step requires 10us hold time, one ends up using 50% cpu time to generate pulses... aka spinlocks
but if it adds 10% that's still 190% the step rate
now if we could just convince people to abandon step/dir for quadrature drive ( cradek and LawrenceG are convinced)
the fast thread I propose would look like: Write (data port); Write (control port); Read (control port); other computations; Reset (data port). If the time for 2 I/O plus other computations is larger than the required step pulse time, then the additional time cost is a single I/O. If the pulse time is long, it might add more time (gecko seems to be among the longest at 4uS)
the problem isn't whether people prefer quadrature or step+direction, but whether the driver/translators accept it
now an 8-pin micro with quadrature input and (flash-time programmable) step+direction output timings and maybe a multiplier would be cool (except you'd need one per axis)
I know... I had a long discussion with Marris about supporting quadrature drive and he couldnt see the advantage.. maybe with his new cpld drives, there may be a chance
getting quadrature in geckos would be very nice
that would put them very far above all the other options
I hear even mach can do quadrature
wonder whether it gets an increased max step rate with quadrature
direction + either-edge-of-step is probably easier to do on a micro, compared to quadrature
attiny13 has "either logical edge of pin" as an interrupt condition
quadrature is just a 2 bit counter that gets inc or dec
LawrenceG: no it's not! that's a common but wrong way to decode quadrature
imagine the sequence 00 01 00 01 00 01 00 01 00. with real quadrature that means no change in position.
talking of encode
+1 -1 +1 -1 +1 -1 agreed... no position change... or pesky noise pulses that have no effect on quad but would trash step/dir
if you use one bit as a clock, and the other as direction, then a counter also works for input, with one addition: you must count on either clock edge, and you must count up on one edge and down on the other
so the 00 01 ... sequence would be +1, -1, +1, -1 ...
and 10 11 10 11 ... would be inverted, so the 0-1 clock transition would count down, and the 1-0 transition would count up
but it's much easier with a lookup table or a few logic gates :)
yeah -- jmk guided me to the lookup table approach when I was playing with quadrature (http://emergent.unpy.net/projects/01149271333
"400kHz Triple quadrature divider for atmega8 and quadrature state table generator")
yup... condition jump into a state transition table is very quick
anyone got emc2 in runnable conditions around?
not me, not me!
alex_joni: sim only
jepler: can you check that I didn't break anything obvious?
* alex_joni did test some cases
alex_joni: what are you breaking?
I'm breaking bugs :P
actually I don't expect the change I just commited to have any impact besides the case petev reported
[19:02:15] <alex_joni> http://sourceforge.net/tracker/index.php?func=detail&aid=1734309&group_id=6744&atid=106744
alex_joni: I was just looking at that
alex_joni: you say it only happens when the program has a %, but petev says it happens when no program is loaded
he did say loaded
"The error seems to
happen when the M2 or M30 attempts to reset the program and no program file
jepler: it happens like this: you open a file with % at the beginning and end
if you abort the file pointer gets reset
aka no file loaded
but the % flag was still active
OK -- yes, I was able to get the error
(before updating to your version)
hmmm looks like it'll take me a minute to get my tree buildtable again
I know how that goes, that's why I asked earlier :P
almost got it..
alex_joni: yes it's also fixed for me after that change
good, I can't think of anything that it might break..
I'll backport it too