Back
[00:50:58] <jmkasunich> back
[01:31:45] <jepler> jmkasunich: have you started on the 5i20 firmware yet?
[01:32:06] <jepler> (for step generation)
[01:36:29] <jmkasunich> lol
[01:36:42] <jmkasunich> that would be "no"
[01:37:04] <jmkasunich> I'm still working on getting the machine working with software step/dir
[01:37:13] <jmkasunich> (mounting and wiring stuff, etc)
[01:39:09] <jmkasunich> why do you ask?
[01:40:32] <jepler> no reason
[01:40:33] <jepler> just making conversation
[01:40:54] <jmkasunich> * jmkasunich guesses that jepler has it half done already ;-)
[01:41:00] <jepler> nope
[01:41:29] <jepler> I'm still trying to think of something "original" to do with the 5i20
[01:41:54] <jmkasunich> that sound like a fun conversation
[01:42:05] <jepler> I don't have any good ideas yet
[01:42:06] <jmkasunich> requirements I assume are minimal external hardware?
[01:42:54] <jepler> yes
[01:43:04] <jmkasunich> logic analyzer isn't that original.... and you'd need some ram
[01:43:31] <jmkasunich> 100MHz is pretty far from state of the art too... but probably usefull for some projects
[01:44:24] <jepler> I can't remember what it's called -- fenn would -- but there's already a powerful logic analyzer out there to be built from parts
[01:44:40] <jepler> gpl'd firmwares and board designs
[01:44:59] <jmkasunich> ok, not original enough
[01:45:18] <jepler> ah, this thing:
http://minila.sourceforge.net/
[01:45:32] <jepler> 32 channels, 100MHz, 128 kb/channel
[01:47:07] <jmkasunich> put a/d's on it and make a storage scope?
[01:47:22] <jmkasunich> also not all that original, you can buy that for a few hundred $
[01:47:32] <jepler> yeah -- and memory's a problem again
[01:48:25] <jmkasunich> audio effects?
[01:48:36] <jmkasunich> line in jacks to A/D, D/A to line out
[01:48:45] <jmkasunich> and implement some DSP'ish stuff inside
[01:48:53] <jepler> a lot of ideas seem to call for RAM -- maybe I should look at doing a RAM daughterboard that would take one 25-pin header
[01:49:24] <jmkasunich> use PC100 era DIMMs - cheap and huge
[01:49:41] <jmkasunich> since they're DRAM, I bet the address bus is row/col
[01:49:54] <jmkasunich> so you can don't eat up so many bits
[01:49:54] <jepler> yeah
[01:50:03] <jepler> I wonder if ~24 I/Os is enough
[01:50:15] <jmkasunich> in fact, you might be able to mux row/col/data on one set of 16 lines
[01:50:19] <jmkasunich> leaving 8 for control
[01:50:56] <jmkasunich> then a 64MB dimm would give you 64MB, as 32M x 16
[01:51:05] <jmkasunich> oops, no
[01:51:23] <jmkasunich> 64MB x 64 dimm if you only used 16 bits would give you 16M as 8M x 16
[01:53:15] <jepler> data and address are separate on the 144-pin SODIM pinout
[01:54:12] <jmkasunich> I figured - you'd have to use a couple '245s on the board to join them
[01:54:31] <jmkasunich> its a speed/pins tradeoff
[01:54:39] <jepler> yeah
[01:55:11] <jepler> easiest to design it for two connectors
[01:55:36] <jmkasunich> that doesn't leave much I/O
[01:55:59] <jepler> no it doesn't
[01:58:44] <jmkasunich> how about a resolver to digital converter?
[01:59:02] <jmkasunich> (I even have some resolvers you could have)
[02:02:19] <jepler> no thanks
[02:02:20] <jmkasunich> heh
[02:10:19] <jmkasunich> is a 298 a single H bridge. or a dual?
[02:10:37] <jepler> dual H bridge -- one 298 runs 2 servos or one stepper
[02:11:29] <jmkasunich> trying to think of things the might be fun to control, and require bandwidth greater than you'll get from RT code in a PC
[02:11:59] <jepler> hm, needs RAM again, but a video encoding accelerator, specifically for the "motion estimation" step
[02:12:31] <jepler> though PCs are well above real-time at video encoding, so it doesn't matter much
[02:12:55] <jmkasunich> also requires memory: a frame grabber
[02:13:04] <jmkasunich> but again, most webcams manage to do that all by themselves
[02:15:21] <jmkasunich> in terms of computing power, the PC has the fpga beat, unless you are doing something that doesn't tolerate latency
[02:15:34] <jmkasunich> or something that parallelizes really well
[02:15:38] <jepler> motion estimation is very parallel
[02:19:12] <jmkasunich> pc video encoding is a disk -> encoder -> disk thing, right?
[02:19:16] <jmkasunich> so latency doesn't matter
[02:19:19] <jepler> yes
[02:19:30] <jmkasunich> what about camera -> encoder -> disk ?
[02:20:57] <jepler> probably not too different, as long as there's a big enough buffer somewhere
[02:21:13] <jmkasunich> yeah
[02:21:19] <jepler> between camera and encoder
[02:21:20] <jmkasunich> and interfacing to the camera won't be fun
[02:23:48] <jepler> if the hypothetical operation to be performed can be done in one PCI write and one PCI read, it would take at least 60ns (and that's optimistic). In that time, a 2GHz CPU has about 120 cycles.
[02:24:12] <jepler> yeah you're probably right that I won't find anything that can be done faster on a PCI-attached FPGA
[02:24:32] <jmkasunich> so if you're just using it as a coprocessor, it needs to be something that takes a long time to process a little bit of data
[02:24:37] <jmkasunich> or you'll be IO bound
[02:25:49] <jmkasunich> _and_ something that the fpga is inherently faster at (parallelism, since the clock is actually slower)
[02:26:14] <jmkasunich> its gotta be something that interacts with the real world
[02:26:33] <jmkasunich> unfortunately most of the real world is analog
[02:26:39] <jepler> damned real world
[02:26:47] <cradek> crypt?
[02:26:57] <jmkasunich> but why?
[02:27:41] <jmkasunich> its a shame laser pointers have short coherent lengths
[02:27:54] <jmkasunich> interferometry on the cheap would be fun
[02:28:19] <jepler> doing a wall-projected reproduction of classic vector games was on my list a while back
[02:28:34] <jepler> but it looked like it was expensive to get closed-loop galvos
[02:28:49] <jmkasunich> laser pointer, bouncing off of mirrors on the arms of two dead disk drives
[02:29:10] <jmkasunich> oops, no feedback
[02:29:23] <jepler> I suspect you need feedback to do "asteroids"
[02:29:35] <jepler> it does matter where each thing is drawn
[02:29:44] <jmkasunich> yeah
[02:29:52] <jmkasunich> I'm trying to think of a way to do feedback
[02:30:01] <jepler> the resolvers you offered me earlier, of course
[02:30:07] <jmkasunich> not enough bandwidth
[02:30:21] <jmkasunich> they usually use 2500 or 5000 Hz excitation
[02:30:34] <jmkasunich> I doubt the update rate can significantly exceed that
[02:30:39] <jepler> yeah
[02:30:41] <jepler> true
[02:30:55] <jmkasunich> we're looking for pid loops with update rates in the 10s of khz
[02:31:24] <jepler> I think that the older, slower vector games would cross the 1024-position screen in as little as 1ms (1MHz clock) and the later games were faster
[02:31:46] <jmkasunich> disks have average seek times of 5mS or so
[02:31:54] <jmkasunich> dunno how average is computed
[02:32:16] <jmkasunich> 298 can drive the coils
[02:32:34] <jmkasunich> feedback is the key
[02:33:22] <jepler> I figured you'd want to drive it in the analog domain
[02:33:32] <jmkasunich> the coil?
[02:33:33] <jepler> yeah
[02:34:08] <jmkasunich> hopefully its inductance would be a good pwm filter
[02:34:44] <jmkasunich> force = current, not voltage, so stepping the voltage would let you change the torque quickly
[02:35:23] <jmkasunich> but without the servo tracks on the disk surface, feedbacks is the challenge
[02:38:49] <jmkasunich> the other challenge would be computing the paths
[02:39:00] <jmkasunich> because of inertia, you can't draw a sharp corner
[02:39:14] <jmkasunich> you'd probably want loops on corners
[02:39:26] <jepler> not a problem for CRT vector displays
[02:39:30] <jmkasunich> nope
[02:40:34] <jepler> though I suppose those electrons must have some mass
[02:40:57] <jmkasunich> their mass isn't the limiting factor
[02:41:07] <jmkasunich> its the deflection plate capacitance
[02:41:10] <jepler> don't worry I wasn't being serious
[02:41:21] <jmkasunich> ;-)
[02:42:02] <jepler> I wonder how many 8x8 multipliers fit on the fpga
[02:42:20] <jmkasunich> for video encoding?
[02:42:44] <jepler> to do a 1D convolution filter
[02:43:06] <jmkasunich> any particular application?
[02:43:15] <jepler> image processing -- many interesting 2D convolutions are separable
[02:43:20] <jmkasunich> ah
[02:44:14] <jepler> 1 sample in, 1 sample out, many multiply-accumulate operations
[02:44:28] <jmkasunich> bet the PC is faster
[02:44:47] <jmkasunich> FPU can do a mult-acc in a couple clocks
[02:45:01] <jmkasunich> or are you thinking of massive parallelism?
[02:45:47] <jepler> a 64x1 or 128x1 kernel
[02:46:06] <jmkasunich> operate on 128 scan lines at once?
[02:46:50] <jepler> no, operate on a history of 128 pixels
[02:47:11] <jepler> out = in1 * weight1 + in2 * weight2 + ... + in128 * weight128
[02:47:19] <jmkasunich> FIR filter IOW
[02:47:37] <jepler> then shift all "in"s right 1, get new "in1", compute again
[02:48:05] <jmkasunich> thats an FIR
[02:49:17] <jepler> OK -- I've just heard it called a convolution, and the weights are the "kernel"
[02:50:01] <jmkasunich> filtering is probably the term when the signal is X vs time
[02:50:11] <jmkasunich> for pixels, its X vs space
[02:50:16] <jmkasunich> so maybe different terminology
[02:50:39] <jmkasunich> isnt the "kernel" rather small but 2D?
[02:50:50] <jmkasunich> like 5x5 pixels, or 10x10?
[02:51:15] <jepler> that's why I led off by saying many of them are "separable": you can turn a separable NxN kernel into a 1xN kernel for rows, and then a Nx1 kernel for the columns
[02:51:52] <jmkasunich> but if N is small (compared to 128) you don't get the parallism
[02:52:46] <jmkasunich> how much memory is in each of the internal blocks in the FGPA?
[02:52:54] <jmkasunich> enough to store one scan line of pixels?
[02:53:09] <jepler> I forget if it's around 40,000 bits or 40,000 bytes
[02:53:22] <jmkasunich> lets assume bits
[02:53:46] <jepler> I think it's the area of all the multipliers that would kill this idea
[02:54:25] <jmkasunich> you need 8 bits in and 8 bits out, right?
[02:54:33] <jmkasunich> (discard 8 low bits of product)
[02:54:35] <jepler> yes, though 16 would be nice
[02:54:44] <jepler> I don't think dozens of 16-bit multipliers will fit, though
[02:55:01] <jmkasunich> 16 in and out, or 8x8->16 ?
[02:55:13] <jepler> 16 bit input pixel values
[02:56:35] <jmkasunich> where do you get that many bits? digital camera?
[02:56:43] <jmkasunich> I thought they were about 12 bits at best
[02:57:10] <jepler> hm -- by traversing the image cleverly (according to the hilbert space-filling curve) you only need to load N pixels for each output pixel, and you only have to store N^2 pixels, not N rows of pixels
[02:57:29] <jepler> because they run on PCs, the processing programs generally jump from 8 to 16 bit internal precision.
[02:57:41] <jepler> you're right that digital camera RAW formats typically have at most 12 bits
[02:58:09] <jmkasunich> what kind of N values are you aiming for? 5x5? 10x10? 50x50? ;-)
[02:58:35] <jepler> it will turn out video cards are better for this task anyway
[02:58:57] <jepler> this would be for the 10x10 to 25x25 territory
[02:59:23] <jmkasunich> probably right about the video cards
[02:59:45] <jmkasunich> think real world interaction I say....
[02:59:56] <jepler> all you do is 25x25*2 textured triangles and read the result out of the framebuffer
[03:00:09] <jepler> you're right
[03:00:42] <jmkasunich> I liked the projection asteroids idea
[03:00:57] <jmkasunich> but pulling it off would be tough
[03:02:43] <jmkasunich> 60 frames/sec, times 50-100 lines in a frame
[03:02:53] <jmkasunich> 6000 lines per second
[03:03:05] <jmkasunich> gonna be _real_ hard to move mirrors that fast
[03:03:30] <jmkasunich> even a 1/4" diameter thin one on a hard disk arm
[03:04:29] <jepler> others seem to be trying this too:
http://www.linux-laser.org/
[03:04:37] <jmkasunich> the electronics is about 4 orders of magnitude faster than the mechanics
[03:05:17] <jmkasunich> boring
[03:05:28] <jmkasunich> they're using commercial projectors and just doing the interface
[03:06:07] <jepler> yeah but what are the chances I could come up with something better than a commercial projector from spare parts?
[03:06:15] <jmkasunich> none
[03:06:46] <jmkasunich> I was thinking more of "what are the chances you could come up with something that sorta works for 1/100th the price of a commercial projector
[03:06:59] <jmkasunich> I have no clue what they cost, but I bet its >$1000
[03:08:42] <jmkasunich> http://home.att.net/~JEKasunich/vannorman/VN_Home.htm
[03:08:58] <jmkasunich> oops
[03:09:07] <jmkasunich> http://elm-chan.org/works/vlp/report_e.html
[03:09:53] <jepler> "You can get point output rates up to 130,000 pts/sec. Such fast rates are necessary for photorealistic TV-like raster frames."
[03:12:07] <jmkasunich> he describes a feedback sensor that could be adapted to the hard disk servo
[03:13:46] <jepler> I'm reading that part but none of it has sunk in yet
[03:14:00] <jmkasunich> figure 4?
[03:17:24] <jmkasunich> he does the actual servo loop in analog
[03:17:40] <jmkasunich> which makes sense, but doesn't use the fpga
[03:18:44] <jmkasunich> looks like he can deflect 8 degrees and settle in 200uS or so
[03:18:58] <jmkasunich> using peak coil currents of about 5A
[03:20:51] <jmkasunich> too much analog electronics
[03:39:11] <jtr> gotta run, but could you reflect a dot off the mirror onto a linear ccd (?) like from a scanner? Tell what the deflection is?
[03:40:27] <jmkasunich> I was thinking about that actually ;-)
[03:40:38] <jmkasunich> but the readout time from the CCD is too slow
[03:40:48] <jmkasunich> (about 1mS for the ones I looked at)
[03:41:46] <jtr> oh well. Grocery store barcode scanner? 'night, before I get killed.
[03:41:53] <jmkasunich> goodnight
[04:11:15] <jepler> cradek: I dunno if you want to pursue this, but here's a hacked up diff to get rid of the need for latex2html to build the deb:
http://emergent.unpy.net/index.cgi-files/sandbox/nol2h.patch.1
[04:11:35] <jepler> there are other changes in my local tree, maybe I removed some by mistake. here's the diff before I hacked it:
http://emergent.unpy.net/index.cgi-files/sandbox/nol2h.patch
[04:11:39] <jepler> I'm off to bed now
[04:12:23] <jepler> this is beginning to look like a problem that "needs solved" thoug
[04:12:24] <jepler> h
[04:16:54] <cradek> I could just dump that into our repository like I did the few other things that aren't in base
[04:22:32] <jmkasunich> how big is it?
[04:22:41] <jmkasunich> "it" is latex2html, right?
[04:22:57] <cradek> yeah I think that's the only thing not in the base repositories, but I'm not sure
[04:23:23] <jmkasunich> I thought it was only needed to build the docs?
[04:23:28] <cradek> I'll have to look at it tomorrow - I haven't been feeling too great so should get to bed on time
[04:23:45] <cradek> yeah but docs are in the base package so build-dep gives you doc tools.
[04:23:53] <jmkasunich> oh
[04:24:40] <jmkasunich> this only affects developers and others who do builds, not ordinary users then
[04:25:01] <cradek> yeah this is just about building
[04:25:08] <jmkasunich> ok
[04:25:14] <jmkasunich> get some sleep
[04:25:17] <jmkasunich> stay healthy
[04:25:29] <cradek> I'm trying, but all I'm accomplishing is missing work
[04:25:36] <cradek> which isn't all bad I guess...
[04:25:43] <cradek> g'night
[12:32:01] <fjungclaus> Hej!
[12:34:02] <fjungclaus> Does anybody know if there's a nice tool to extract and handle I18N strings in python (like e.g. linguist for QT)?
[13:05:03] <jepler> fjungclaus: in emc2 we use xgettext to extract messages from python, tcl, and C files. in python we use the 'gettext' module to find translations from the message catalog at runtime.
[13:24:11] <jepler> morning ray
[13:24:21] <rayh> Hi Jeff
[13:28:11] <rayh> I like the stuff done with sim (mini). The comp, ddt, hypot are all fascinating.
[13:29:42] <jepler> it is great for debugging the trajectory planner or graphing its performance with halscope
[13:32:16] <rayh> I confess. I can hardly keep up with developments.
[13:35:54] <jepler> :)
[14:30:59] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=254681#post254681
[14:33:37] <rayh> Wah! That sounds very good.
[14:34:18] <skunkworks> seems like a guy that can be worked with :)
[14:34:41] <skunkworks> we need to pick a channel and stick with it ;)
[14:34:49] <rayh> Right.
[14:34:57] <rayh> here is probably the best place.
[14:35:17] <skunkworks> Thanks - it is the least I can do. Emc2 is a wonderful program.
[14:35:38] <rayh> JohnR said he would get ahold of Bryan today and talk it through.
[14:36:04] <rayh> Sounds like he wants to get a system going so he can keep up with emc2 and all his stuff.
[14:36:16] <rayh> That will be a good addition.
[14:39:29] <rayh> Hey skunkworks. Perhaps you should correct John's thought that I made the changes to the email stuff.
[15:33:49] <skunkworks> who is bryan?
[15:36:27] <SWPadnos> could be the software guy that Vigilant sent boards to - it may not be Paul at all
[15:39:56] <alex_joni> I think it's one of Vigilant's guys who will be in charge of the emc2 stuff
[15:40:02] <alex_joni> from their side I mean
[16:21:52] <skunkworks> alex_joni: did you make the email changes to linuxcnc.org? Do you want me to post a correction to the thread on cnczone? Do you care ;)
[16:53:30] <alex_joni> skunkworks: not really
[17:01:40] <jepler> do we still support any platforms that use a gcc 2.x or egcs?
[17:03:55] <jepler> do we still support "BDI-TNG"?
[17:08:03] <jepler> is there any system where it is useful to specify --with-kbuild, or is the automatic detection good enough?
[17:10:22] <SWPadnos> might there be custom systems where detection wouldn't work?
[17:10:34] <SWPadnos> like RH, Gentoo, custom embedded builds ...
[18:21:10] <alex_joni> jepler: was that a retorical set of questions?
[18:21:28] <alex_joni> I don't think that any 2.x or egcs still work
[18:21:36] <alex_joni> and a newer 2.6 won't build on anything older than 3.0
[18:21:55] <alex_joni> so my personal call would be ditch them
[18:27:11] <jmkasunich__> out with the old, eh?
[18:28:58] <jmkasunich__> I notice that rtai makes no attempt at all (I think) to support older kernels
[18:29:10] <jmkasunich__> even older versions of 2.6
[18:32:30] <alex_joni> hi jmk
[18:33:05] <alex_joni> seen
http://pastebin.ca/344664 ?
[18:44:18] <alex_joni> jepler: thanks from a guy from germany, he's successfully using jdi.py
[18:50:00] <jmkasunich__> alex_joni: is that better than our existing pumakins?
[18:50:12] <jmkasunich__> (based on fred's work I see)
[18:54:44] <alex_joni> jmkasunich__: honestly.. I have nfc
[18:57:19] <jepler> alex_joni: I would like to clean out some cruft during 2.2.
[18:58:35] <jmkasunich__> jepler: how much cleaning do you have in mind?
[18:58:54] <jmkasunich__> dropping non-kbuild (non-2.6) kernels maybe?
[18:59:42] <jepler> jmkasunich__: dropping pre-3.0 compilers and old-bdi-specific hacks is what I've done so far
[19:00:53] <jmkasunich__> seems reasonable
[19:01:09] <alex_joni> I plan on some more NML cleanups
[19:01:24] <alex_joni> did a bit for 2.1, but there's plenty more
[19:01:55] <jmkasunich__> dropping non-kbuild kernels will simplify the build system a lot won't it?
[19:05:15] <jepler> no, sim basically follows the non-kbuild method
[19:07:17] <jmkasunich__> the non-kbuild method still built kernel modules tho, sim doesn't do that
[19:07:58] <jmkasunich__> or is the diff between kernel and user less than the diff between kbuild and non-kbuild?
[19:10:03] <jepler> in sim, each component is built into a .so by the same makefile rules that build a kernel .o for non-build systems -- they just have a different $(MODULE_EXT)
[19:10:17] <jmkasunich__> ok
[19:11:13] <jmkasunich__> different libs and headers though I would expect (user headers vs. kernel headers)?
[19:11:25] <jmkasunich__> or do they still use kernel headers?
[19:11:37] <jepler> yes -- all the compiler flags are different
[22:44:47] <fjungclaus> Hey!
[22:54:31] <fjungclaus_> ?
[22:55:53] <jepler> !
[22:56:44] <fjungclaus_> Hey, Jeff. Connection to irc is very instable today ...
[22:56:57] <jepler> sorry to hear that
[22:57:05] <jepler> mine has been fine all day
[22:57:10] <fjungclaus_> Any suggestion for I18N tool to be used together with python?
[22:57:13] <jepler> did you see my answer about I18N and python?
[22:57:25] <jepler> 07:05:03 <jepler> fjungclaus: in emc2 we use xgettext to extract messages from python, tcl, and C files. in python we use the 'gettext' module to find translations from the
[22:57:30] <jepler> message catalog at runtime.
[22:57:34] <fjungclaus_> No, probably the answer was lost ...
[22:58:36] <fjungclaus_> Ok, I'll try that ...
[23:00:55] <jepler> in fact there is a (partial) translation of AXIS to german already.
[23:01:46] <fjungclaus_> I think Florian Hahn has done a lot of this work ...