Back
[00:01:20] <jepler> (oh, and Tcl is not GPL software. I believe its license is the "BSD style")
[00:01:31] <jepler> now let's talk about something else, not software licences
[00:15:22] <robin_sz> jepler, but, you can distribute GCC and your own non-gpl code togehter
[00:16:02] <robin_sz> assuming gcc is used to compile your code, not as an extension to gcc obviously
[00:16:55] <robin_sz> anyway ..
[00:17:03] <robin_sz> the xilinx stuff is awesome ...
[00:17:13] <robin_sz> really REALLY nice ide
[00:33:39] <jepler> hi cradek!
[00:34:45] <jmkasunich> hi guys
[00:34:54] <jepler> hi jmkasunich
[00:35:11] <jmkasunich> jepler: the fpga4fun website indeed looks like fun
[00:36:16] <jepler> jmkasunich: yeah but most of their stuff is altera -- that parallel-port jobby is, for instance
[00:36:32] <jepler> and I haven't found whether I can do altera for free on linux yet
[00:36:46] <jmkasunich> yeah, that is the key
[00:37:02] <jmkasunich> I'm seriously thinking about getting a m5i20, but only if I can hack the FPGA
[00:37:13] <jepler> that'a xilinx
[00:37:42] <jepler> do you have FPGA experience already?
[00:37:45] <jepler> I have zero...
[00:37:52] <jmkasunich> I have almost zero
[00:38:05] <jmkasunich> I did some rather extensive FPGA stuff at work....
[00:38:16] <jmkasunich> in 1992-1994
[00:38:34] <jmkasunich> which might as well have been vacuum tube work for all it will help now
[00:38:44] <jepler> surely it's just higher speeds and more gates now
[00:38:50] <jepler> or have things changed in some fundamental way?
[00:39:03] <cradek> jepler: hi, I'm back home for a while now
[00:39:25] <jmkasunich> when I was doing it, it was basically schematic entry, with functional blocks like adders and such, and plain old gates
[00:39:29] <jepler> cradek: good.
[00:39:51] <jmkasunich> now the gate counts have gotten so high and systems so complex, that the main tools are VHDL (I think)
[00:41:20] <jepler> I don't have even a rough idea of how much functionality 1 'gate' is
[00:41:30] <jmkasunich> 1/4 of a 7400 ;-)
[00:41:43] <jepler> i.e., how many (kilo?)-gates would something like a quadrature counter take?
[00:42:01] <jmkasunich> how many bits wide do you want the counter to be?
[00:42:06] <jepler> let's say 24
[00:42:24] <jmkasunich> most of the FPGAs don't count gates anymore, they use some kind of other "chunk"
[00:42:40] <jmkasunich> because they are mostly matrices of "chunks", not random gates
[00:43:24] <jepler> this parallel-port altera board says it is "10,000 typical gates, 56,000 maximum system gates, 576 logic elements, 3EABs"
[00:44:08] <jepler> and it says a 16-bit accumulator is 16 LEs
[00:44:15] <jmkasunich> for example the 4000 series Xilinx I used way back when - each chunk (they called em CLBs) had two 4 or 5 input blocks that can generate an arbitrary 1 bit output function (basically a 16 or 32 x 1 lookup table) and two flipflops, plus a few muxes that let you do things like drive the FFs with the LUT output, or use the FF and LUT separetely
[00:44:38] <jmkasunich> LE sounds pretty much like a CLB
[00:44:43] <jepler> so I guess a 24-bit quadrature counter would be at least 24 LEs
[00:44:57] <jmkasunich> your 24 bit counter, plus quadrature decode, is probably about 30 or so
[00:45:18] <jmkasunich> personally, I'd make the counters shorter
[00:45:59] <jmkasunich> as long as it doesn't count more than 1/2 of the overflow limit before you read it again, you can extend it in softrware very easily
[00:46:17] <jmkasunich> a 16 bit counter read every mS can count to 20MHz with ease
[00:47:22] <jmkasunich> bummer:
http://www.fpga4fun.com/DesignSoftware.html says that the free version of the Xilinx tools are dose only, gotta pay for the linux version
[00:47:30] <jmkasunich> of course that might be out of date
[00:47:37] <jepler> so 4x quadrature, 4xpwm or 4xstepgen, and epp communication might fit just fine in this "576 logic elements"
[00:47:47] <jepler> jmkasunich: i'm downloading/installing some xilinx thing for linux right now
[00:47:56] <jmkasunich> oh good...
[00:48:00] <jepler> I didn't see that it wasn't free but maybe after I finish the 1GB download it will ask me for a serial number I don't have
[00:48:22] <jepler> "ISE(TM) WebPACK(TM) is the industry's only free, downloadable logic design solution for your Xilinx CPLD or medium-density FPGA with support for both Microsoft Windows and Linux."
[00:48:35] <jmkasunich> ok, this info must be out of date
[00:48:41] <jepler> http://www.xilinx.com/webpack/
[00:48:52] <jepler> It says it's for RHEL but so far it is installing OK on Ubuntu Dapper
[00:48:53] <jmkasunich> it says the free version of ISE webpack is only 140M
[00:49:40] <jepler> there was a note in the installer that the communications portion only works with RHEL, so it must have a kernel module or something
[00:49:43] <jmkasunich> this page also says that you typically have to email them to request a license, and then they send you an unlock code
[00:50:08] <jmkasunich> anyway back to counting LEs
[00:50:46] <jmkasunich> the encoder part could be done in 15-25 LE's per channel, depending on the register length you want/need
[00:51:16] <jmkasunich> although an additional register to latch the value might be costly (i don't know how many flipflops are in an LE)
[00:51:55] <jmkasunich> pwmgen and stepgen have a lot in common (actually it would be freqgen, not stepgen)
[00:52:18] <jmkasunich> but freqgen is a little more complex, because you need some additional logic to ensure setup and hold times for direction, etc
[00:52:55] <jmkasunich> the algorithim I used in the HAL modules scales well to hardware - its just an accumulator
[00:53:23] <jmkasunich> again, you also need a register to hold the value you are adding to the accum, which will eat up some FFs
[00:54:09] <jmkasunich> the register doesn't need to be as long as the accumulator tho
[00:54:10] <jepler> looks like an LE has only one FF
[00:54:27] <jmkasunich> you could probably get good results with 16 bit regsiters and 24 bit accumulators
[00:55:53] <jepler> is it important to latch all the axis values at the same time? Or could you get away with one register for all the counters -- at access of the low byte, latch all the bits and then give the high byte at the next request.
[00:55:58] <jepler> or am I being clever about optimization too early?
[00:57:24] <jmkasunich> optimizing too early
[00:57:56] <jmkasunich> the scheme you are describing needs either an on-chip tristate bus or 4-1 muxes to send data from each counter to the FFs
[00:58:17] <jmkasunich> that may cost more than the FFs themselves, (tri-state busses may or may not be available)
[00:59:06] <jmkasunich> what I'd really like is a FPGA on the PCI bus - EPP sucks for speed, and forces you to do everything 8 bits at a time
[01:03:36] <jmkasunich> anyway, figure 40-50 LEs for a pwmgen, add maybe 5-10 more for steppers
[01:04:09] <jepler> I'd rather buy something that costs less than the mesa if I'm just starting out, and don't really have a use in mind anyway
[01:04:24] <jmkasunich> so, max 60 for the output, say 40 for the input, thats 100 per channel times 4 = 400 leaving 176 for the bus interface
[01:04:29] <jmkasunich> seems reasonable to me
[01:05:06] <jmkasunich> yeah - and we know from elson's stuff that you can transfer the neccessary data for 4 axis over EPP
[01:08:35] <jepler> in fact there seems to be a lot of spare time: "This takes only about 50 uS on a 333 MHz Pentium II, so that reasonable servo update rates of 10 KHz could be made on such a machine."
[01:08:59] <jmkasunich> yeah
[01:09:21] <jmkasunich> unfortunately the data transfer part doesn't scale with CPU speed, but still, seems quite reasonable
[01:09:23] <jmkasunich> figure 1uS per byte
[01:10:21] <jepler> has anyone tried 32-bit epp?
[01:10:29] <jmkasunich> ?
[01:10:40] <jmkasunich> there are only 8 wires ;-)
[01:10:47] <jepler> I think that you're supposed to be able to do a 16- or 32-bit I/O operation to the same address and it does 4 I/O cycles behind your back
[01:10:56] <jmkasunich> never tried it
[01:11:17] <jmkasunich> seems kinda pointless, unless you are sending _only_ 32 bits
[01:11:46] <jmkasunich> or you can do something usefull during the 4uS that it takes to transfer the 4 bytes
[01:12:48] <jmkasunich> did you have to create an "account" at xylinx to download?
[01:12:52] <jepler> yes
[01:13:01] <jepler> I'm sure the unwanted mailings will start soon
[01:13:01] <jmkasunich> grumble
[01:13:16] <jepler> that's the price of free-as-in-not-free software
[01:13:19] <jepler> but what are you going to do?
[01:13:24] <jmkasunich> wonder if they'll accept a yahoo address
[01:13:33] <jmkasunich> I have a throwaway one I use for stuff like that
[01:14:56] <cradek> mailinator.com
[01:15:08] <jmkasunich> they actually ask if they can send stuff, the might even honor your wishes
[01:15:32] <jepler> "These additional cycles are generated by hardware and are transparent to the software. The total time for these four cycles will be less than 4 independent 8 bit cycles"
[01:15:48] <jepler> seems like you might save at least 3uS, for your last write
[01:16:03] <jepler> it'll have to wait for someone with such a board to try it, though
[01:16:46] <jmkasunich> such a board? meaning such a parport? or such an FPGA board?
[01:17:20] <jepler> with a parport device that talks EPP
[01:17:52] <jmkasunich> all you really need to see if it works is a scope
[01:18:12] <jepler> you need something to generate the handshaking signals
[01:18:25] <jmkasunich> can't just loop something around?
[01:18:37] <jmkasunich> (its been a while since I looked closely at epp)
[01:18:39] <jepler> not sure, don't know epp well enough
[01:18:47] <jepler> if not, a simple program on a micro would do
[01:19:05] <jmkasunich> heh, get two parports
[01:19:29] <jmkasunich> and use one to emulate an EPP device
[01:19:59] <jmkasunich> hmm... the registration page is timing out
[01:20:03] <SWPadnos_> hey - this sounds like my kind of discussion :)
[01:20:03] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[01:20:17] <jmkasunich> I wonder if they are validating my made up address and zip code and detecting the mismatch
[01:20:44] <jepler> hi SWPadnos
[01:21:34] <jmkasunich> guess not - this time it worked, just took a long time
[01:22:18] <SWPadnos> hi jepler
[01:22:18] <SWPadnos> and jmkasunich
[01:22:18] <SWPadnos> this has got to be the slowest hotel "high speed" connection I've ever seen
[01:22:51] <cradek> oh hush, be thankful to get any connection at all (I was just dealing with that too)
[01:22:56] <jepler> maybe hooking STROBE/ to WAIT/ would be enough to make EPP writes work
[01:23:20] <SWPadnos> well, I'm not sure I have a usable connection - it seems every DNS lookup takes 6 tries and 2 minutes
[01:24:19] <jmkasunich> looks like you'd need to invert it
[01:24:52] <cradek> 'try connecting to the next hotel over - just make up a room number when it asks' (real advice from the front desk at my hotel)
[01:25:10] <jmkasunich> nice
[01:25:30] <SWPadnos> heh
[01:25:51] <jepler> oops yeah
[01:27:25] <jmkasunich> do you have a spare parport?
[01:27:38] <jmkasunich> hal's "not" block will take care of that in a jiffie
[01:28:04] <jmkasunich> with the added benefit of being able to use halscope as a logic analyzer ;-)
[01:28:17] <jmkasunich> crap, that won
[01:28:17] <SWPadnos> way less than a jiffy, I hope :)
[01:28:22] <jmkasunich> won't work
[01:28:39] <jmkasunich> unless you have the equivalent of a crossover cable for the parport
[01:28:53] <Jymmm> jmkasunich I got one of those =)
[01:29:00] <SWPadnos> ewww - not sure I've seen one of those since the LapLink days
[01:29:07] <jmkasunich> jepler: did you download the single file install, or are you doing the webinstall?
[01:29:16] <Jymmm> That's what I have... a yellow laplike cable =)
[01:29:22] <jepler> I downloaded the small file and it's been steadily downloading as long as we've been talking
[01:29:47] <jmkasunich> installing as it goes along?
[01:30:12] <Jymmm> SWPadnos 115Kbps goodness! lol
[01:30:49] <Jymmm> I'll have this 300Gb hdd ghosted in 3.4 months
[01:31:03] <Jymmm> wait... it just went to 3.7 months
[01:31:06] <jmkasunich> wow, the 1021meg version is a shell script!
[01:33:50] <jepler> jmkasunich: above the progress bar it says "installing"
[01:34:04] <jmkasunich> I'm downloading the single big file
[01:34:11] <jmkasunich> I'm not sure I want to install today
[01:35:02] <SWPadnos> Xilinx tools?
[01:35:10] <Twingy> fpga
[01:35:19] <jmkasunich> SWPadnos: yeah
[01:35:23] <SWPadnos> Xilinx = one of the big 3 FPGA vendors ;)
[01:35:52] <SWPadnos> maybe just big 2 and medium 2, actually
[01:37:54] <SWPadnos> it's funny - I got the Atmel AT91SAM7X (ARM) development kit, and the tools disc is a DVD
[01:38:06] <SWPadnos> and of course, I have no DVD drive in my primary development machine
[01:38:37] <Jymmm> SWPadnos stela one from the wifey's machine
[01:38:41] <Jymmm> steal
[01:39:41] <SWPadnos> if only she had one :)
[01:39:52] <jepler> sheesh you can get a DVD drive for $20 these days
[01:40:26] <Jymmm> SWPadnos Fine... rip apart the dvd player on yout TV
[01:40:33] <jepler> /tmp/selfgz9686/platform/lin/setup: line 67: 9741 Segmentation fault $setuploc/xilsetup $switch $batchfile
[01:40:36] <jepler> ************ setup done! ***************
[01:40:40] <jepler> eek
[01:40:41] <SWPadnos> yeah, but I'm not sure what this Windows 2000 machine will do if I suddenly add a DVD-ROM to the machine
[01:40:47] <SWPadnos> bummer
[01:41:10] <SWPadnos> like I'd pull apart my DV-38A ;)
[01:41:30] <skunkworksem1> heat sink compound is sticky
[01:41:33] <Jymmm> you know you would if you had to =)
[01:41:47] <SWPadnos> that DVD player cost more than a whole computer these days
[01:42:06] <Jymmm> no wonder the wifey is always complaining about her computer! lol
[01:42:19] <SWPadnos> I have a DVD drive in my secondary development machine, so I'm probably set (once I installl Win2k or XP as a guest)
[01:42:24] <SWPadnos> heh
[01:42:32] <Jymmm> just share the drive, easy fix
[01:42:35] <SWPadnos> she just got my previous experimenter machine
[01:45:54] <skunkworksem1> So this is working pretty decent. :) for not being tuned
[01:47:18] <jepler> skunkworksem1: are you driving an axis with it yet?
[01:47:38] <skunkworksem1> yes - on the gantry
[01:47:51] <skunkworksem1> with the 'littler' servo
[01:48:58] <cradek> that crazy chain drive Z?
[01:49:09] <skunkworksem1> you got it.
[01:49:13] <cradek> cool
[01:49:46] <skunkworksem1> probably why I can't get it to oscolate enough to actually move the axis up and down
[01:50:02] <skunkworksem1> I increase the P and it just starts to buzz
[01:50:29] <jepler> when you scope the encoder, is it moving -- just not enough to see?
[01:51:27] <skunkworksem1> I could with it not hooked to anything - but I have not scoped it since I hooked it to z. It is pretty scary - the whole machine vibrates :)
[01:52:28] <skunkworksem1> I got it to oscillate when I accidentally put arount 300 in the I
[01:52:47] <skunkworksem1> it went up and down about .5 inch
[01:52:50] <jepler> I thought bigger I was supposed to fix oscillation
[01:53:20] <skunkworksem1> you are asking the wrong person ;)
[01:53:47] <jmkasunich> not if it gets too big
[01:54:40] <skunkworksem1> I can get it to peak at 20A :)
[01:55:35] <skunkworksem1> by turning it. The thing really whines going 100+ipm Poor thing.
[01:56:56] <jmkasunich> the chain drive? or the motor?
[01:57:39] <jmkasunich> hmm, I'm getting about a megabit over my DSL - not bad for a 384K line ;-)
[01:57:51] <skunkworksem1> the actual axis. It is a 10tpi direct drive
[01:58:40] <SWPadnos> you have 384k download speed?
[01:58:50] <jmkasunich> thats what I'm paying for
[01:59:02] <SWPadnos> weird. is it SDSL?
[01:59:16] <jmkasunich> but right now I have two downloads going, one is getting 50KB/sec, the other 60KB/sec
[01:59:59] <jmkasunich> dunno - I thought it was ADSL
[02:00:07] <SWPadnos> 384k is usually only found on expensive business lines. most consumer ADSL is 1, 1.5, or 2 Mbit (or sometimes higher) for downloads
[02:00:23] <SWPadnos> 384k upstream is pretty normal (they usually range from 256k - 512k)
[02:00:56] <jmkasunich> actually when I got this (several years ago), I chose the cheapest option, which was 384 down 128 up IIRC
[02:01:00] <SWPadnos> if the CO is next door, you can get 7.6Mbit down / 1.5 Mbit up, I think
[02:01:00] <Jymmm> * Jymmm pays $25/mo for 3Mbps down and 512Kbos up
[02:01:12] <SWPadnos> I'd be very surprised if the 384k option still exists now
[02:01:20] <jmkasunich> something tells me they silently upgraded me
[02:01:19] <SWPadnos> you've probably been upgraded :)
[02:01:37] <jepler> xilinx "ise" is running, and I'm trying to make a project with emc2's files for the m5i20
[02:01:40] <Jymmm> jmkasunich just check next months bill
[02:01:46] <SWPadnos> yeah - I've got 2M down/256k up for $30 or so/month
[02:01:47] <SWPadnos> jepler: good luck :)
[02:02:01] <jmkasunich> I really need to shop around
[02:02:10] <jmkasunich> I'm still paying $39.95 a month
[02:02:21] <SWPadnos> there aren't any project files published for it (I asked PeteW)
[02:02:40] <jmkasunich> what about the files in the driver source directory?
[02:02:43] <SWPadnos> you shoudl be able to load host54m (or similar) thouh
[02:02:52] <SWPadnos> hostmot54 maybe>
[02:03:15] <SWPadnos> yeah - those are the VHDL source for the FPGA, but no "project" (aka make / configure etc) files
[02:03:22] <jmkasunich> oh
[02:03:44] <SWPadnos> I loaded hostmot54e (is that it?) into Altium, and it seemed to pull in all the other files
[02:03:59] <SWPadnos> those others are instantiated from the main file (similar to includes)
[02:04:35] <SWPadnos> the important part is the pin file, I think - that's what defines which pins are used for what
[02:09:08] <jepler> I created a new project, added all the vhd files, and pressed "synthesize" .. it came back with warnings but no errors
[02:09:34] <SWPadnos> cool. I think I needed extra info because I wasn't using hte xilinx tools directly
[02:10:04] <SWPadnos> there was a change to the encoder module, I think - fixed a bug (which I don't remember)
[02:10:08] <jmkasunich> * jmkasunich googles for HDL 101 pages
[02:10:09] <jepler> it looks like a file that is not a .vhd file specifies what pin each external signal needs to be on
[02:10:10] <SWPadnos> I'm not sure that was ever checked in
[02:10:13] <SWPadnos> heh
[02:10:20] <SWPadnos> yes
[02:10:38] <SWPadnos> the *.pin file tells that information, but I'm not sure it's in the right format
[02:10:58] <SWPadnos> I think the normal extension is .pin or .ucf
[02:16:37] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[02:21:48] <jmkasunich> * jmkasunich just had a very very twisted thought
[02:22:17] <jmkasunich> VHDL macros bear a strong resemblence to hal components
[02:22:27] <SWPadnos> odd, huh? :)
[02:23:02] <jmkasunich> imagine a hal component that reads a vhdl file and builds a (very slow) implementation of the logic the file describes
[02:23:06] <SWPadnos> they're "objects" that onnect to other objects with pins, which may be any of several types
[02:23:14] <SWPadnos> ewwww
[02:23:17] <SWPadnos> I mean - cool!
[02:23:32] <jmkasunich> probably right the first time
[02:23:41] <SWPadnos> heh
[02:28:46] <jmkasunich> how difficult is it to turn a CD into a .iso file?
[02:30:06] <SWPadnos> pretty easy with the cdrecord tools
[02:30:24] <SWPadnos> possibly doable with dd as well (but you may have to know more)
[02:35:38] <jepler> A data CD?
[02:35:45] <jmkasunich> yeah
[02:35:59] <jepler> I think it's as simple ase: dd if=/dev/cdrom of=image.iso bs=2048
[02:36:07] <jepler> as long as it's a 1-track data CD
[02:40:47] <jmkasunich> looks like readcd dev=ATA:1,0,0 f=whatever.iso is gonna work too
[02:41:26] <SWPadnos> ah - the fine forced SCSI nomenclature of cdrecord et al
[02:41:33] <SWPadnos> at least it looks that way
[02:41:39] <jmkasunich> yeah
[02:41:49] <SWPadnos> deprecated, I think ;)
[02:42:05] <jmkasunich> I can never remember that, but I saved notes about how to use cdrecord on this machine in my ~/isos directory
[02:42:59] <SWPadnos> well, you may not have to remember for long. people finally got fed up enough with Joerg Schilling that there should be a real open-source version soon :)
[02:44:14] <jepler> hooray
[02:44:28] <jepler> speaking of real open-source, how about that sun java
[02:44:41] <SWPadnos> yeah - that's a whopper, huh
[02:45:20] <SWPadnos> wasn't it on Slashdot that they're looking into GPL for open Solaris or something>
[02:45:23] <SWPadnos> ?
[02:48:49] <jepler> not sure what use I'd have for solaris if it was gpl
[02:51:18] <SWPadnos> dunno
[02:51:58] <SWPadnos> though someone here (lawrenceG?) and Mr. Schilling both seem to think that Solaris is much better at some things
[02:52:16] <SWPadnos> like realtime and CD recording, respectively
[02:54:32] <SWPadnos> I suppose I should sign off - I'll probably keep my wife up if I keep typing :)
[02:54:34] <SWPadnos> see you later
[02:56:20] <ejholmgren> can't say that I've ever tried solaris on x86
[02:56:45] <ejholmgren> wonder how it compares performance and stability wise
[02:57:33] <ejholmgren> gpl'ing it might give it a better shot at staying alive outside of the sparc arena tho'
[03:03:28] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/servoz.JPG
[03:05:00] <skunkworks> oops - there kinda big.
[03:05:13] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/sinks.JPG
[03:05:46] <skunkworks> they are
[03:08:00] <jepler> skunkworks: have you fried (m)any of those FETs yet?
[03:08:10] <skunkworks> nope.
[03:08:13] <skunkworks> so far so good
[03:09:18] <jmkasunich> gonna have to figure out a way to support those sinks
[03:10:09] <skunkworks> yes - sort of temporary. I want to use the better sinks - but I didn't feel like figuring out how to cut and mount them
[03:10:48] <skunkworks> these where just laying around. I had used them for a 200w amplifier I made a long time ago.
[03:10:50] <jmkasunich> hmm... if the fets were mounted sticking out the _bottom_ of the board, the sinks could be mounted to the same plate that holds the cap
[03:11:30] <skunkworks> good point. would not be a big deal to change the board
[03:14:53] <jmkasunich> what is the distance between the two rows of FETs, and how does it compare to the diameter of the cap?
[03:15:56] <skunkworks> these are some littler servos we found. no specs on them.
http://www.electronicsam.com/images/KandT/servostart/smallservo.JPG
[03:16:13] <skunkworks> I would have to look - I don't have the board here
[03:16:21] <jmkasunich> ok, not important
[03:16:48] <skunkworks> the circuit is working very well - Thanks agian for all your help.
[03:16:48] <jmkasunich> if the rows are far enough apart, you can simply flip the fets over using the same board
[03:17:02] <skunkworks> I think it will fit between the mosfets.
[03:17:03] <jmkasunich> that means the heatsink side of the FET is facing in towards the cap
[03:17:03] <skunkworks> iirc
[03:17:22] <jmkasunich> so those sinks wouldn't fit
[03:17:23] <skunkworks> ah - no I don't think os
[03:17:28] <skunkworks> so
[03:18:17] <jmkasunich> but fi you could put say a piece of 1/4" aluminum plate between cap and fets, and attach them to that, then extend the plate down to the main mounting plate, you wind up with a U shape
[03:18:31] <jmkasunich> cap in the middle, fets dumping heat into the tops of the legs
[03:19:59] <jmkasunich> shit shit shit
[03:20:05] <skunkworks> sorry?
[03:20:14] <jmkasunich> I paused the big xylinx downloads while I downloaded something else
[03:20:21] <jmkasunich> when I tried to resume them, they ended
[03:20:27] <skunkworks> yeck
[03:24:01] <skunkworks> ready for one more scary circuit?
[03:24:53] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/breakout.JPG
[03:25:38] <jmkasunich> I've built lots of boards like that
[03:25:54] <jmkasunich> where are the bypass caps?
[03:26:07] <skunkworks> I was wondering if you would see that..
[03:26:28] <skunkworks> I don't know. I made one - and my father coppied it. I don't think he put any on his.
[03:26:42] <skunkworks> going to have to yell at him
[03:28:37] <jmkasunich> well..... 520 megs of partly downloaded files down the tubes
[03:30:42] <skunkworks> This is version 8 I think :) I have made way too may different version of it. The first version I had used a pull up resister on oc buffer. then hooked the optical from ground to the ouput of the oc buffer. Stupid.
[03:32:19] <jepler> this m5i20 pinout file doesn't specify the connections between the xilinx and the pci interface chip...
[03:59:31] <skunkworks> time for bed - night
[08:34:44] <jymmmmm> Hey is there an easy way to tell what is taking up a lot of room on the hdd?
[08:35:27] <jymmmmm> Like TreeSize, but for nix?
http://www.jam-software.com/freeware/index.shtml
[08:53:21] <alex_joni> du -s /*
[09:19:02] <jymmmmm> I'll try that when I reboot
[09:19:05] <jymmmmm> thanks
[09:20:45] <anonimasu> hm
[09:40:32] <jymmmmm> anonimasu: du -s /*
[09:44:21] <alex_joni> jymmmmm: or somewhere along the line
[09:44:26] <alex_joni> you can pipe it through sort
[09:44:37] <alex_joni> du -s /* | sort -n 1
[09:44:43] <alex_joni> or something like that
[09:45:10] <jymmmmm> Yeah, just wasn't aware of the du utility is all =)
[09:45:30] <jymmmmm> 724MB in /usr/ alone
[10:09:52] <alex_joni> du = disk usage
[10:10:00] <alex_joni> man is helpfull as usually ;)
[10:10:34] <jymmmmm> alex_joni: It MIGHT be helpful if you *KNOW* that the utility even existed you goober!
[10:11:07] <jymmmmm> It's like man login ad the LOGIN: prompt
[10:11:19] <jymmmmm> totally and completely useless
[10:11:27] <jymmmmm> a/ad/at/
[10:11:30] <jymmmmm> =)
[10:19:19] <alex_joni> ook
[11:49:11] <anonimasu> du -h works also
[11:49:27] <anonimasu> or -sh :)
[12:19:02] <alex_joni> -shhhh
[12:27:51] <anonimasu> * anonimasu yawns
[13:26:24] <skunkworks> jepler: good morning.
[13:31:17] <jepler> hi skunkworks
[13:32:15] <skunkworks> done anything more with the etch-o-sketch?
[13:32:51] <jepler> np[e
[13:32:51] <jepler> nope
[13:33:42] <jepler> time to drive to work...
[13:39:54] <alex_joni> hey samco
[13:39:59] <alex_joni> PID working already?
[13:40:59] <skunkworks> Hi alex.
[13:41:11] <skunkworks> its working - just not tuned yet.
[13:41:24] <skunkworks> can't rush into these things.
[13:41:28] <skunkworks> :)\
[13:42:06] <skunkworks> did you see the pictures from last night
[13:42:17] <alex_joni> seen one about heatsinks
[13:42:38] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/servoz.JPG
[13:44:12] <skunkworks> how is the work trip going?
[13:48:38] <jepler> skunkworks: how powerful is that motor you're using?
[13:48:52] <jepler> in torque inches pre squared day
[13:52:28] <skunkworks> :)
[13:53:23] <skunkworks> it is only like 20 in-lbs continuous
[13:53:45] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/permotor.JPG
[13:53:54] <skunkworks> but it has some unreal peak ratings.
[13:55:23] <skunkworks> These are the ones we are ramping up to
http://www.electronicsam.com/images/KandT/servotag.JPG
[13:55:31] <jepler> 288 oz-in isn't a lot bigger than some minimill steppers, is it?
[13:56:01] <skunkworks> right
[13:57:53] <jepler> I'm surprised it moves that big Z axis. must go pretty slow?
[13:58:30] <skunkworks> no - I was getting 150ipm out of it last night.
[13:58:52] <skunkworks> the servo was pushing 5amps at that speed.
[14:00:43] <jepler> not bad
[14:04:54] <skunkworks> there was a few happy dances - at least in my head.
[14:05:50] <skunkworks> we could get the servo to take 20 amps by trying to move the shaft by hand.
[14:06:36] <skunkworks> (the reason I need to mount the heat sinks :))
[14:07:09] <alex_joni> skunkworks: worktrip was shorter than expected (that means it was very good:)
[14:07:42] <skunkworks> alex_joni: good. btw - on the heat sink picture - did you see the ir2111 chips?
[14:08:02] <alex_joni> no, I blacked them out :D
[14:08:04] <skunkworks> you can plainly read them ;)
[14:08:25] <alex_joni> :P
[14:08:46] <alex_joni> wanna see what I did this weekend?
[14:09:26] <skunkworks> Yes
[14:11:25] <alex_joni> http://www.robcon.ro/301589/sIMG_8759.JPG
[14:11:48] <alex_joni> http://www.robcon.ro/301589/sIMG_8766.JPG
[14:11:55] <skunkworks> jeeze - how many axis is that? 7?
[14:12:29] <alex_joni> 8 :)
[14:12:37] <anonimasu> lol
[14:12:40] <alex_joni> for now, the 9th is on the way
[14:13:05] <alex_joni> see that blue support holding the robot?
[14:13:14] <anonimasu> yes
[14:13:19] <alex_joni> that's gonna be mounted on an additional linear axis (3m)
[14:13:25] <anonimasu> nice
[14:13:27] <skunkworks> up and down?
[14:13:28] <anonimasu> how fast?
[14:13:29] <alex_joni> sideways
[14:13:31] <skunkworks> ah
[14:13:34] <alex_joni> anonimasu: which one?
[14:13:39] <anonimasu> the linear axis
[14:13:44] <alex_joni> 0.66m/sec
[14:13:56] <anonimasu> :D
[14:14:06] <alex_joni> 1600IPM ;)
[14:14:07] <anonimasu> the one on order I mean..
[14:14:07] <alex_joni> roughly
[14:14:19] <anonimasu> that's bloody fast
[14:14:25] <alex_joni> * alex_joni knows ;)
[14:14:28] <alex_joni> but it's 20kN
[14:14:35] <alex_joni> there are smaller ones, which go faster
[14:14:36] <alex_joni> :P
[14:15:04] <alex_joni> I like that table.. 1.5t parts ;)
[14:15:10] <anonimasu> :)
[14:15:25] <skunkworks> what do you mean by 1.5t parts?
[14:18:08] <alex_joni> maximum weight of the parts that the table can move
[14:18:24] <skunkworks> ah - went right over the top
[14:18:26] <alex_joni> 1t = 1000 kg
[14:19:12] <alex_joni> this is another one for parts up to 2500kg
[14:19:13] <alex_joni> http://www.robcon.ro/300730/sIMG_8774.JPG
[14:19:39] <skunkworks> that is freakin cool
[14:20:01] <alex_joni> anonimasu: remember we talked about metal "sheets"?
[14:20:02] <alex_joni> http://www.robcon.ro/300730/sIMG_8789.JPG
[14:20:05] <anonimasu> yeah
[14:20:13] <skunkworks> is the drive at the turn table there - or is it mechanically tru the second acis
[14:20:15] <skunkworks> axis
[14:20:15] <alex_joni> that's 120mm sheet :)
[14:20:19] <anonimasu> lol
[14:20:27] <alex_joni> skunkworks: right there
[14:20:28] <anonimasu> that's not sheet.
[14:20:34] <anonimasu> it's well other stuff :D
[14:20:43] <alex_joni> the top one is 70-75 I think
[14:20:47] <alex_joni> and the thin one is 25
[14:20:57] <anonimasu> 25 isnt that brutal
[14:20:57] <anonimasu> :D
[14:21:01] <anonimasu> though 70 is..
[14:21:04] <alex_joni> and 120 too ;)
[14:21:11] <anonimasu> yeah
[14:21:18] <alex_joni> but I'd say it's sheet if it comes in 3x12m sizes
[14:21:45] <alex_joni> * alex_joni wouldn't wanna know how much one "sheet" weights
[14:22:11] <anonimasu> yeah
[14:23:29] <alex_joni> it was fun though.. a bit of work ;)
[14:23:38] <anonimasu> :)
[14:28:32] <ejholmgren> holy crap
[14:28:42] <ejholmgren> that thing is ginormous
[14:32:16] <alex_joni> ejholmgren: not at all, it's amongst the smaller ones ,)
[14:38:32] <ejholmgren> I suppose it's easier to machine a car out of a solid block of steel instead of stamping all of the component parts and then assembling them ;)
[14:38:53] <anonimasu> lol
[14:38:54] <anonimasu> yeah
[14:38:56] <ejholmgren> is that where you work or someplace you visited?
[14:39:10] <anonimasu> but if you add tooling to the equation
[14:39:12] <anonimasu> and machining time
[14:40:36] <ejholmgren> ha ... good article on Slashdot
[14:40:48] <ejholmgren> "Internet Only 1% Porn"
[14:59:00] <jepler> http://hackedgadgets.com/2006/11/15/high-powered-laser-from-dvd-burner/
[15:02:57] <alex_joni> ejholmgren: that's my dayjob
[15:04:20] <alex_joni> jepler: that's crazy
[15:06:27] <jepler> I didn't know any CD/DVD drives had visible lasers...
[15:10:44] <alex_joni> never looked inside either ;)
[15:53:44] <anonimasu> maybe the writer
[15:54:07] <skunkworks> pretty cool... Hmm might have to take one apart ;)
[16:18:25] <skunkworks> alex_joni: these are the small servers we had found. They are full of carbon and need brushes :) Think they had a hard life although the comutators look fine.
[16:18:27] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/smallservo.JPG
[16:19:42] <SWPadnos> strange - I've never seen a server with brushes before ;)
[16:19:52] <skunkworks> must be nice ;)
[16:20:02] <skunkworks> ah - sorry
[16:20:05] <skunkworks> :)
[16:20:10] <SWPadnos> heh
[16:20:25] <skunkworks> you can tell whats on my mind at the moment
[16:20:31] <SWPadnos> somewhat
[16:27:01] <SWPadnos> ugh - got to check out and find a coffee shop
[16:27:09] <SWPadnos> they're painging and the fumes are about to kill me
[16:27:14] <SWPadnos> painting
[16:27:18] <SWPadnos> see you later
[16:27:19] <anonimasu> laters
[16:52:57] <jepler> SF's web archive of our mailing lists still doesn't work. I've filed a new support request, because they closed the last one without solving the problem.
https://sourceforge.net/tracker/index.php?func=detail&aid=1597114&group_id=1&atid=200001
[16:53:12] <cradek> I thought it worked for a while
[16:54:03] <cradek> thanks for doing that
[16:54:35] <jepler> :-P
[16:54:39] <jepler> for all the good it'll do
[16:54:43] <cradek> yeah
[16:56:03] <jepler> gmane is now archiving these two lists, but with badly chosen names:
http://news.gmane.org/gmane.linux.distributions.emc.devel http://news.gmane.org/gmane.linux.distributions.emc.user
[17:03:07] <Lerneaen_Hydra> 'lo
[17:06:33] <skunkworks> they said it should be fixed within 2 weeks of november 1st.
[17:07:28] <jepler> I looked at the site status page, and as they don't say there's a problem with mailing list archiving I assume that must just be unaware of the problem ;-)
[17:08:22] <cradek> http://article.gmane.org/gmane.linux.distributions.emc.user/17
[17:08:38] <cradek> odd - gmane grabbed the raccoon icon thing from my website
[17:09:18] <jepler> yeah it seems to have taken the unpythonic.net favicon for my icon
[17:09:26] <cradek> gmane's setup with good threading is much better than sf anyway
[17:12:37] <cradek> I wish people would start a new thread when they start a new topic
[17:12:50] <cradek> some just seem to reply to any old message and change the subject
[17:13:38] <jepler> I understand how/why they do that, but it is too bad
[17:14:12] <jepler> I wonder if when that happens, and I reply, I should break the thread in my reply -- is it better to hang fewer articles on the wrong thread, or to have my message thread as a reply to the right thing?
[17:15:06] <jepler> maybe readers should have logic like: "if the subject doesn't match, and the user is in the threading blacklist, start a new thread"
[17:15:08] <cradek> I don't know. Either way is bad.
[17:15:37] <jepler> then you tell your MUA "this thread is wrong" and it will fix everything up and maybe get it right in the future
[17:15:54] <cradek> that's an interesting idea
[17:17:39] <jepler> a fair bit of work to implement
[17:27:16] <cradek> I'll try it if you put it in mutt... :-)
[17:59:20] <skunkworks> jepler: the reply to eric... Wouldn't you have a problem with cordinated motion. - the laser 'axis' would be 'hooked' to other motion. say you wanted the laser on the next move to be 100 (was 50) so you have x1 laser50 > x2 laser100... the laser would only reach 100 at the end of the second move. well as I type this - It dawned on me that you would just have to break the moves into smaller segments. n/m
[18:00:05] <cradek> g1a0, g1x1, g1a100, g1x2
[18:00:18] <cradek> you'd want to move just the laser 'axis'
[18:00:49] <anonimasu> hm, could you do realtime adjustment with some optics/ccd cam?
[18:00:50] <cradek> in my program I think X would just barely stop
[18:01:41] <skunkworks> hm - but if the motion was broke down into very small segments. there might not be a problem.
[18:01:46] <anonimasu> ah well, you could.
[18:01:47] <skunkworks> no pause
[18:04:35] <skunkworks> cradek - but there would be no blending at all between x movements would there. (if the laser was on a separate line)
[19:28:15] <cradek> skunkworks: right
[19:28:31] <jepler> I think that may be true -- X will come to a complete stop if you move x, then move a
[19:29:36] <jepler> if you program x1 s100 / x2 s200 do you want s100 during the move to x=1? I wonder which the spec gives you.
[19:30:09] <cradek> I'm sure it specifies the order (x before or after s)
[19:30:13] <jepler> (aside from the "bug" that you get not only a stop, but a 100ms pause)
[19:31:03] <jepler> set spindle speed before motion
[19:31:26] <skunkworks> you want the s100 during the x1 move. that is what I am used to. say at the beging of the program you would say z-.1s200mo3.
[19:31:35] <skunkworks> you want s200 to be the speed for that move
[19:31:58] <skunkworks> (plus you want the spindle to turn on ;))
[19:32:22] <jepler> "mo3"? is that just a typo?
[19:33:03] <skunkworks> sorry m03 (our old controller needed leading zeros to work - 2 digit numbers needed a 0 in front for 1 digit)
[19:33:25] <skunkworks> so I am used to saying F01 or M00 or M03
[19:35:33] <skunkworks> and yes that was a typo ;)
[19:38:42] <jepler> M02 I would have understood -- I think cradek writes the "two digits always" style sometimes
[19:38:59] <jepler> er, M03
[19:39:14] <skunkworks> my point was - the work around would be to make it as an axis as you explained but shorten the line segments to the point that the laser power changes would take effect over a shorter distance. Don't know if that would work for him - and I don't know if I am getting my point across.
[19:40:45] <jepler> I get the general idea
[19:40:56] <jepler> make the last 1mm of the X move the one where A changes
[19:41:24] <cradek> I wonder what he really wants that he is approximating with these segments
[19:41:24] <jepler> that will still not give great performance; you have the "must be able to decelerate to a stop at the end of any move" constraint
[19:41:37] <cradek> maybe he really wants power based on velocity or something
[19:41:59] <jepler> I hadn't considered that
[19:42:29] <jepler> if you move at a constant XY speed then the S-number would give the "amount of burn per unit distance"
[19:42:48] <Lerneaen_Hydra_> step 1, figure out what the hell the problem actually is. ;)
[19:43:03] <Lerneaen_Hydra_> (it's actaully not all that trivial)
[19:43:15] <anonimasu> cant you hook up velocity to a comparator?
[19:43:34] <anonimasu> and scale the output power ?
[19:43:35] <cradek> sure you can get velocity in hal
[19:43:49] <anonimasu> I'm just talking random stuff though)
[19:43:57] <anonimasu> but, it seems like that would fit
[19:43:57] <anonimasu> '
[19:44:28] <cradek> he asked about a very specific thing and we don't really know the whole problem
[19:44:40] <anonimasu> :)
[19:44:53] <Lerneaen_Hydra_> fun fun :/
[19:45:47] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[19:49:29] <skunkworks> that is how the laser here at work is set up. you can set the duty factor in relation to velocity.
[19:49:55] <skunkworks> so as you slow down to make a corner - the laser power is decreased
[19:50:11] <skunkworks> (a little bit more complicated than that - but not much
[19:51:05] <anonimasu> * anonimasu nods
[19:52:53] <Lerneaen_Hydra> random question:is the laser beam focused, or is it a paralell beam? (so if the head is 5cm away, will it still cut?)
[19:53:45] <skunkworks> it comes out of the resonator tube a paralell beam - then a lens focuses it.
[19:55:17] <Lerneaen_Hydra> oh, ok
[19:55:38] <Lerneaen_Hydra> so that's why the support underneath isn't a one-shot thing ;)
[20:25:53] <skunkworks> our beam is about .5" in diameter
[20:26:30] <skunkworks> the focal length of the lense we use is about 5"
[20:26:50] <Lerneaen_Hydra> oh, that wide?
[20:27:01] <Lerneaen_Hydra> cool
[20:27:27] <Lerneaen_Hydra> so you're quite limited wrt material thickness I assume
[20:29:13] <skunkworks> its main purpose is cutting 3/4 inch plywood die board.
[20:29:23] <skunkworks> but we cut plastics a lot alos
[20:29:24] <skunkworks> also
[20:29:31] <Lerneaen_Hydra> plywood and plastics?
[20:29:49] <Lerneaen_Hydra> doesn't the plywood get burnt and the plastic smell like hell?
[20:31:27] <skunkworks> yes
[20:32:32] <Lerneaen_Hydra> haha, perfect :D
[20:39:29] <Jymmmmmm> Jymmmmmm is now known as Jymmmmmmmmmm
[20:40:29] <Jymmmmmmmmmm> Jymmmmmmmmmm is now known as Jymmm
[20:41:41] <Jymmm> Jymmm is now known as Jymm
[20:41:41] <Jymm> Jymm is now known as Jymmm
[20:56:36] <alex_joni> hello
[20:59:42] <skunkworks> Hi alex
[21:00:11] <Jymmm> hodwy
[21:01:44] <alex_joni> jepler: around?
[21:01:47] <alex_joni> hi guys
[21:01:54] <jepler> alex_joni: yeah
[21:02:03] <alex_joni> jepler: I read your laste response on the list
[21:02:12] <alex_joni> there are actually 2 different M-codes
[21:02:25] <alex_joni> one which waits for stuff to finish, then issue the IO change
[21:02:47] <alex_joni> and the other one, gets sent to the motion controller and happens triggered by TP somewhere
[21:03:02] <alex_joni> but I never really figured out that part (except that it started working :D)
[21:03:29] <cradek> I thought we briefly had motion-synced digital IO (a few gcodes iirc) but I don't think we have it today
[21:03:56] <cradek> I think we had 4 codes: on/off at the beginning/end of a move
[21:04:29] <alex_joni> there are 4 M-codes
[21:04:49] <jepler> they're called M62..M65 and I thought they were implemented (at least in 2.1) so I documented them
[21:05:42] <alex_joni> they were implemented
[21:05:42] <cradek> I'm talking about motion-synced IO with no pausing
[21:05:50] <cradek> are you guys talking about another thing?
[21:05:59] <alex_joni> M62 turns an output on, M63 off (imediately)
[21:06:11] <alex_joni> M64 & M65 are supposed to do the same but synched with motion
[21:06:18] <alex_joni> and I know that worked on the old TP
[21:06:57] <alex_joni> I also left the hooks for SET_AOUT all over the place, so that can very easily added
[21:07:06] <alex_joni> be added
[21:10:59] <jepler> as far as I can tell, it has the same problem as S- -- it will wait for any pending motions to complete, then stop and wait for non-realtime to change the output
[21:11:55] <jepler> am I mistaken?
[21:12:30] <alex_joni> only if the now param is set
[21:12:57] <alex_joni> case EMC_MOTION_SET_DOUT_TYPE:
[21:12:58] <alex_joni> if (((EMC_MOTION_SET_DOUT *) cmd)->now) {
[21:12:58] <alex_joni> return EMC_TASK_EXEC_WAITING_FOR_MOTION;
[21:12:58] <alex_joni> }
[21:12:58] <alex_joni> return EMC_TASK_EXEC_DONE;
[21:13:00] <alex_joni> break;
[21:13:28] <cradek> you either have to break queueing or send the DOUT command to motion/TP
[21:13:29] <alex_joni> but I might be reading that wrong .. been a while :(
[21:13:42] <alex_joni> cradek: it always gets sent to motion/TP
[21:14:00] <alex_joni> but only to motion for M62/63 and to motion/TP for M64/65
[21:14:16] <cradek> ok
[21:14:19] <jepler> m64/m65 do something
[21:14:27] <jepler> m62/m63 don't seem to do anything
[21:16:27] <jepler> m64/m65 act "at the right time" but have the pausing problem like S- does
[21:17:20] <jepler> tpSetDout is a stub
[21:17:44] <cradek> 19:33:47 < paul_c> M62 P8 X1.0
[21:17:44] <cradek> 19:34:05 < paul_c> will turn INDEX 8 on at the start of the move
[21:17:44] <cradek> 19:34:20 < paul_c> M63 P8 Z-5
[21:17:44] <cradek> 19:34:33 < paul_c> turns INDEX 8 off at the end of the move
[21:18:01] <cradek> from a very old conversation about emc1
[21:18:16] <cradek> Nov 2004
[21:18:22] <jepler> ain't that way now
[21:18:49] <cradek> nope I know
[21:19:08] <cradek> I'm not entirely sure it ever worked
[21:19:11] <jepler> It seems crazy to me to have a different rule for "on" and "off"
[21:19:14] <alex_joni> same here
[21:19:16] <jepler> that's not the spec I'd write
[21:19:30] <cradek> those indexes were the arbitrary parport indexes (not pin numbers) from emc1
[21:19:52] <cradek> but I thought emc1's motion wrote all the bits constantly
[21:19:54] <alex_joni> maybe we should move this to #emc-devel ?
[21:20:09] <jepler> if you want
[21:39:13] <Jymmm> WTF?
http://www.wbir.com/news/national/story.aspx?storyid=39017
[21:44:43] <Lerneaen_Hydra> ...
[21:44:44] <Lerneaen_Hydra> great
[21:44:51] <Lerneaen_Hydra> wonderful
[21:45:08] <Lerneaen_Hydra> 'night people
[21:45:17] <Jymmm> g'night Lerneaen_Hydra
[22:46:13] <anonimasu> hm, whoever that pasted the laser.. couldnt that be used for FDM
