#emc-devel | Logs for 2007-07-31

Back
[00:45:38] <SWPadnos> hi Peter
[00:45:48] <pcw> Hi
[00:46:11] <SWPadnos> What's up on the west coast?
[00:46:13] <pcw> Thought I would give a little more info on the 7I43
[00:46:17] <SWPadnos> cool
[00:46:49] <SWPadnos> like, when it might be available for purchase? :)
[00:47:14] <pcw> Not much, Our network was down this morning - janitor unplugged a Enet HUB
[00:47:19] <SWPadnos> bummer
[00:48:02] <SWPadnos> That must be why Lily didn't get back to me in 10 minutes, like she usually does
[00:48:16] <pcw> OK 7I 43 should be available in about 6 weeks, We have a working proto but need to fix some USB powered startup problems
[00:48:53] <pcw> FPGA is Spartan 3 (Spartan 2 is too expensive)
[00:48:57] <SWPadnos> hmmm - like - hard to start up on USB power when the FPGA is unprogrammed?
[00:49:48] <pcw> No Windows driver cyling the power a few times on enumeration - dont like the I/O bits doing things at that point...
[00:50:02] <SWPadnos> ah
[00:50:06] <pcw> (cycling)
[00:50:37] <SWPadnos> so it's closer to the 5i22 than the 5i20, since it's a Spartan 3
[00:50:37] <pcw> Were just going to put a delay on the FPGA power up from enumeration.
[00:51:34] <pcw> Yes, and it has the same 5V tolerance via a couple of bus switches
[00:52:15] <SWPadnos> in the photo, what's the connector at the top, opposite the USB connector? is that for the parallel port connection?
[00:52:28] <pcw> Yep
[00:53:17] <SWPadnos> great. is the pin configuration basically the same as a motherboard parport pin header?
[00:53:31] <SWPadnos> ie, can you use a 26-pin ribbon cable and avoid the DB-25?
[00:53:46] <pcw> Also helpful for debugging the USB connection (shares the same FPGA pins)
[00:54:23] <SWPadnos> ok - that was the next question - can you run it off USB power (and maybe program it via USB), but use the parport for communication
[00:54:28] <SWPadnos> I guess that answer would be no
[00:54:42] <pcw> Yep, thats what we used to test it, a DB25M --> 26 HDR-F flat cable
[00:54:46] <SWPadnos> great
[00:55:37] <SWPadnos> side question: do you sell 50-pin ribbon cables with twisted pairs and/or shielding?
[00:56:07] <pcw> Yes, possibly, Might take a tweek in the little CPLD on board, so the USB chip is never issued a read
[00:56:46] <SWPadnos> oh, that would be great
[00:57:02] <SWPadnos> getting power for parport devices is always an issue
[00:57:22] <pcw> No, we normally just use flat cables. Havent looked at that stuff for a while, Does Spectra-Strip still exist?
[00:57:51] <SWPadnos> apparently it does (accorfing to google)
[00:57:55] <SWPadnos> according
[00:58:44] <SWPadnos> I found another company that sells relatively inexpensive twisted pair, and they have a standard distance between flats of 8" or 8.5"
[00:58:52] <SWPadnos> ribbon twisted pair, that is
[00:58:57] <pcw> Also if you get the Parallel port only model, the USB chip isnt there so USB power would always work
[00:59:09] <SWPadnos> http://www.connectworld.net
[00:59:31] <SWPadnos> hmmm. doesn't USB only provide 50 or 100 mA unless the device asks for more?
[01:00:36] <pcw> We have the interface chip ask for 450 mA (the max). We have on card switching supply so 1A of 1.2V core power is OK
[01:00:47] <SWPadnos> oops - that doesn't look like the right website. sorry
[01:00:53] <SWPadnos> ah. ok
[01:04:40] <SWPadnos> here's the twisted-pair cable: http://www.connectworld.net/cgi-bin/iec/CAB050-RI-TW
[01:05:31] <pcw> 100 Ohm?
[01:05:41] <SWPadnos> do you have a delivery timeframe for the 7i37T?
[01:05:50] <SWPadnos> hmmm. that does seem high, doesn't it?
[01:06:22] <pcw> Oh I see 115 Ohm
[01:08:59] <pcw> 7I37T's are available but first lot had a problem with 3.5MM headers (for pluggable screw terminals) They are OK but cards warped due to using ThermoPlastic Headers at RoHS soldering temperature
[01:09:54] <SWPadnos> ok. I'll need a couple in 2 weeks or so - I can get by with the breakouts I have for now
[01:11:23] <pcw> We're trying to decide whether to scrap the lot or resolder the connectors or maybe sell them at a reduced price as blems - they work fine just a .1" warp on PCB where terminals are
[01:11:52] <SWPadnos> oh - well I'd take some discounted scratch-n-dent ones :)
[01:12:43] <pcw> :-)
[01:13:26] <SWPadnos> my customer can pay full price though
[01:13:40] <SWPadnos> (for unblemished product ;) )
[01:14:17] <pcw> We are re-doing the lot now so it should be pretty soon for perfect ones
[01:15:41] <SWPadnos> excellent. this customer is getting antsy - we've got ~6 weeks to get an analog board designed and built, write custom FPGA code, write a HAL driver for it, and integrate the result into the machine. at least the digital I/O is easy.
[01:17:09] <pcw> Well with analog desgn you can always make it work just by changing component vaukse, Right :-)
[01:17:18] <SWPadnos> heh
[01:17:23] <pcw> (values)
[01:17:27] <SWPadnos> yeah - that's the ticket
[01:18:11] <pcw> We just did an interesting custom job, an absolute encoder interface using SSI
[01:18:18] <SWPadnos> I haven't really done much analog design (certainly not in the last few years) - it'll be fun making a 16-bit A/D+D/A board
[01:18:24] <SWPadnos> cool - what encoders?
[01:18:31] <jepler> pcw: good evening .. the new parallel/usb board looks neat to me, as you may know I've been writing hal drivers & fpga firmwares for another parallel-port card
[01:18:34] <pcw> Gurley
[01:19:22] <SWPadnos> does it track position while de-powered (or re-acquire on power-up)?
[01:19:52] <pcw> <Jepler> Yes since the parallel port part only costs us about 22 cents extra I thought we'd make it more useful for EMC
[01:20:12] <SWPadnos> 22 cents! the nerve
[01:20:19] <jepler> pcw: when programming over the parport, is it done a byte at a time?
[01:21:35] <pcw> <SWPadnos> Its an optical absolute encoder 8192 counts per rev/ 4096 revs = 25 bits - no memory all mech/opto
[01:22:14] <pcw> I was just afraid to drop it - kilobucks
[01:22:23] <SWPadnos> hmmm - so it inherently "knows" where it is, even if moved with no power applied - even across turns?
[01:22:43] <SWPadnos> yeah - I'm trying to find an alternative to Yaskawa motors/encoders/drives for a robot
[01:22:57] <pcw> <Jepler> yep just write the config file to it
[01:23:08] <SWPadnos> it gets expensive at $3-4k per axis
[01:23:19] <SWPadnos> (dependong on controler options)
[01:23:22] <SWPadnos> depending
[01:23:23] <pcw> <jepler> same as USB just send bytestream
[01:25:05] <SWPadnos> pcw, is the SSI interface available to others, or is it "owned" by your customer?
[01:25:09] <pcw> <SWPadnos> yep not cheap. But no homing!
[01:25:43] <pcw> Public (I charge more for private devel)
[01:25:57] <SWPadnos> yeah - that's the idea. we want to be able to tell exactly what's going on when we recover from ESTOP or power failure, without dropping $meganucks worth of product
[01:26:00] <SWPadnos> great
[01:26:11] <SWPadnos> argh. megaBucks!
[01:26:41] <jepler> * jepler wonders what "meganucks" means
[01:26:44] <jepler> is it 1,000,000 canadians?
[01:26:56] <SWPadnos> err - yeah, that's it!
[01:27:08] <jepler> (that reminds me of my favorite joke, the one about the three brazillian soldiers...)
[01:27:18] <SWPadnos> nyuck nyuck nyuck
[01:27:24] <pcw> SSI is really simple though RS-422 clock out RS422 data back - first clock parallel loads (sample)
[01:28:02] <SWPadnos> cool. the less I have to "reinvent", the less I have to convince my partner to go for it :)
[01:28:44] <SWPadnos> I think we can make an embedded EMC machine with an FPGA card that will significantly ourperform anything Parker, Yaskawa, Delta Tau, or anyone else can sell us at the same price
[01:28:54] <SWPadnos> it's just a matter of getting all the pieces to fit together correctly
[01:29:24] <SWPadnos> but that "just" is a relatively big risk factor, so it's not a trivial decision
[01:30:38] <SWPadnos> of course, we won't do it on 600 mA at 24V, but that's life
[01:30:52] <pcw> Yep
[01:34:28] <pcw> Dont know if its relevent but we have 3 Phase 320V Driver coming out for SoftDMC but it should work with EMC
[01:35:05] <SWPadnos> cool
[01:35:49] <pcw> Well it uses IGBT modules so its kinda hot...
[01:36:12] <SWPadnos> I assume the stepper driver (and this one) needs softDMC or a very fast PCI update rate to work (or slow step rates)?
[01:36:43] <SWPadnos> (I assume this because my understanding is that the PWM is varied to provide microstepping and phase current control, which requires a very fast update rate)
[01:38:40] <pcw> Our little stepper driver needs 30KHz + update rate (Sine and cosine PWM from table) But 3 Phase has brains so can run something like SoftDMC or PVT or just send phase angle and it echos currents
[01:38:56] <SWPadnos> ah - nice
[01:39:11] <skunkworks> all kinds of cool stuff
[01:39:26] <pcw> Tiny brains (2 DSP PICs)
[01:39:42] <SWPadnos> heh
[01:39:47] <SWPadnos> very tiny
[01:41:08] <pcw> Were happy with them...
[01:41:47] <SWPadnos> heh. I know a lot of cool things have been done with PICs (I've done some of them), but given the choice, I'd just about never choose them for a microcontroller these days
[01:43:39] <pcw> Yes the're pretty ugly, but for ~$2 16X16 multiply 40 bit accumulator 3 phase PWM+deadzone 1M sample second A-D, hard to beat
[01:44:01] <pcw> +decent quadrature
[01:44:28] <SWPadnos> yeah - they do have some good motor control-oriented controllers, and I think quadrature is more or less unheard of at that price level (dunno if you've heard of Luminary Micro though)
[01:45:09] <pcw> Heard a little, ARM?
[01:45:28] <SWPadnos> yep - ARM + various motor related peripherals
[01:45:41] <SWPadnos> like quadrature and multiphase PWM
[01:46:21] <SWPadnos> if they last, they'll be pretty good, but as far as I know, the company is pretty new
[01:46:59] <SWPadnos> I like their development kit though - microcontroller and demo board, plus a 2HP 3-phase motor :)
[01:47:12] <SWPadnos> it's basically a VFD development kit
[01:48:18] <SWPadnos> hmmm - maybe it isn't 2 HP - I thought I had seen that somewhere, but I don't see it now
[01:49:51] <SWPadnos> I must say though - I hate it when companies make you register to get their stupid datasheets
[01:49:57] <pcw> Ours is basically for BLDC, which are somewhat simpler (For highest sample rate we do Clark but avoid Mr Park by staying in polar coordinates)
[01:51:13] <pcw> I try to avoid those companies unless there's no choice
[01:51:17] <SWPadnos> yep
[01:51:58] <SWPadnos> they had good demos at ESC, and their dev kits are available from Mouser / DigiKey, but they are annoying
[01:52:53] <pcw> We should be able to drive ~2HP (30A peak module - 11A RMS cont@~300VAC)
[01:54:09] <SWPadnos> nice
[01:54:58] <pcw> Course its still early and it may asplode...
[01:55:26] <SWPadnos> "this IRC chat has forward-looking statements. These are not intended to accurately predict the future" :)
[01:55:43] <pcw> :-)
[02:00:34] <jepler> pcw: you mentioned that the 7i43 has "the same 5V tolerance via a couple of bus switches" -- is the pin direction switchable on a per-pin basis, or is it in blocks of pins?
[02:03:59] <pcw> <jepler> the bus switches are bi-directional (just a NMOS FET series switch) so no switching is needed. They work by turning off as the input gets ~1v from the NMOS FET gate drive, therfore protecting the FPGA
[02:04:19] <jepler> pcw: I see, thanks.
[02:05:32] <pcw> (protected from positive inputs, lower than diode drop below ground is stil fryola time)
[02:23:01] <pcw> what interface Mode an Parallel port do you prefer? Looks like EPP is most reasonable (ECP give me a headache). Our little CPLD can support enough of EPP at startup so theres at least a configuration target address/status port
[02:23:46] <pcw> (Meant for <jepler> )
[02:24:18] <SWPadnos> I'd say that EPP is the best we can use with EMC, due to the low latencies needed. ECP seems more useful for bulk data transfer
[02:24:36] <SWPadnos> (but jepler and JonE may know better)
[02:25:12] <pcw> Just for simplicity I'd prefer EPP
[02:25:57] <SWPadnos> sure - more simple and better (or at least no worse) for latency. we're not trying to move 1 MB/second of data
[02:27:20] <jepler> pcw: I have used EPP exclusively.
[02:27:26] <jepler> I followed Jon E's lead in that
[02:27:31] <jepler> I didn't try ECP, but it certainly looked harder
[02:27:58] <SWPadnos> doesn't it more or less add DMA capability to EPP?
[02:28:10] <pcw> Yeah was the headache part
[02:30:09] <jepler> on the systems I've used, it doesn't seem like you get a whole lot more than 1 byte per uS with epp
[02:30:17] <jepler> I always lose my benchmark numbers right after I note them, though
[02:31:00] <pcw> Maybe just 8 bit ISA bus access (or simulated ISA bus access) times
[02:31:08] <SWPadnos> I wonder if chipset-integrated parallel ports can be set to use NOWS, according to this page: http://www.lvr.com/jansfaq.htm
[02:31:21] <jepler> * jepler looks
[02:31:54] <SWPadnos> that's supposed to get rid of 3 wait states, which should speed things up by 2x, or so they say
[02:32:20] <jepler> sounds like it's not something you enable or disable, but something you might or might not have on a particular motherboard (?
[02:32:25] <jepler> )
[02:32:46] <SWPadnos> or a particular ISA card. that's why I wonder if it's somewhere in a chipset register
[02:33:15] <SWPadnos> not that there would be a BIOS setting for that (Turbo Parallel Port :) )
[02:35:48] <SWPadnos> Interesting:
[02:35:51] <SWPadnos> Q: Which mode (ECP or EPP) would work best with parallel port devices such as the Snappy and the QuickCam Color?
[02:35:51] <SWPadnos> A: As a general rule, because of its FIFOs and DMA support, ECP is good at transferrring big blocks of data quickly (scanners, printers). EPP is good for links that switch directions frequently (drives). Specifically, it depends on the driver for the device, so you might want to experiment if both options are available.
[02:36:30] <jepler> if it takes "a long time" to initiate an ECP transfer (particularly a read transfer) that would be bad for emc
[02:36:41] <jepler> since you always want to read - compute - write
[02:36:41] <SWPadnos> that was my thought
[02:38:05] <SWPadnos> also interesting: he's got a port type detection algorithm on that page
[02:38:10] <jepler> I saw that
[02:38:16] <jepler> my algorithm is "hope for the best" :-P
[02:38:19] <SWPadnos> heh
[02:38:46] <SWPadnos> I wonder if we can use that to automagically implement the parport mode thing (I forgot what it's called)
[02:39:12] <jepler> "X" mode?
[02:39:18] <jepler> or something else?
[02:39:34] <SWPadnos> err - no, the module you have to load if you have certain motherboards that exhibit problems
[02:39:47] <SWPadnos> I think it just disables ECP or something :)
[02:40:24] <SWPadnos> probe_parport
[02:40:33] <jepler> probe_parport has to do with configuring ports that are "ISAPNP"
[02:40:39] <jepler> and not configured by the BIOS or something
[02:40:39] <SWPadnos> ok
[02:41:00] <jepler> in hal_parport, this method might be able to determine that there's no port at the requested address
[02:41:25] <jepler> that reminds me of something...
[02:41:28] <SWPadnos> also in hal_ppmc, or pluto
[02:43:03] <jepler> if nothing's connected or the I/O address is not used, after only about 30000 outb()s the pluto hal driver detects that it can't communicate and the module fails to load
[02:43:18] <jepler> if those I/O addresses were for some other piece of hardware, who knows what's happened by then
[02:43:47] <SWPadnos> yeah - not much can be done about that unless you put identification code into the pluto
[02:44:01] <SWPadnos> before you load the FPGA config ;)
[02:44:22] <SWPadnos> http://www.fapo.com/cenmode.htm
[02:44:48] <SWPadnos> FIFO-based "fast centronics" mode. I wonder if it can do any good here?
[02:45:07] <pcw> We could probably do that with 7I43 = IDcode in Config CPLD
[02:45:07] <jepler> probably no byte-wide input support there
[02:47:57] <pcw> Bye all, time to feed dogustus and bunnies...
[02:48:12] <SWPadnos> heh. see you later. thanks for the info
[02:48:22] <jepler> pcw: nice to talk to you
[02:48:51] <jepler> I'm done for the night too
[02:49:00] <jepler> I wrote one line of code, after all
[02:49:06] <SWPadnos> yep - I'm getting that way too
[02:49:08] <SWPadnos> heh
[02:49:20] <SWPadnos> and 2 lines of commit message :)
[02:49:20] <jepler> (so that I can just unconditionally put 'loadrt probe_parport' in stepconf configurations)
[02:49:40] <SWPadnos> ah- good thinking
[02:49:46] <jepler> 'night
[02:49:50] <SWPadnos> see you
[02:51:07] <cradek> yay, nobody has found a new bug in 2.1 yet
[02:51:12] <cradek> it's a new record
[02:51:14] <skunkworks> :)
[02:51:22] <SWPadnos> has anyone downloaded it? :)
[02:51:35] <cradek> at least one (me)
[02:51:48] <SWPadnos> heh. then I declare EMC2 finished!
[02:51:56] <cradek> it may take a full day for most people's update managers to "find" it
[02:52:10] <cradek> I'm not sure how often those poll
[02:52:15] <SWPadnos> oh, then maybe we can declare it done on Wednesday
[02:52:21] <SWPadnos> daily is the default
[02:52:42] <skunkworks> I set mine to every 5 minutes
[02:52:56] <skunkworks> just in case
[02:53:27] <SWPadnos> so THAT's why the bandwidth usage was so high!
[02:56:19] <SWPadnos> wow - bandwidth usage is up a bit. cycle estimate of 531766 MB this month
[03:05:03] <SWPadnos> hmmm
[03:05:46] <SWPadnos> the two top requesting IP addresses are from Guangzhou and Shanghai
[03:06:17] <SWPadnos> they comprise roughly 2/3 of the total requests, and close to 30% of the total data transfer
[03:06:18] <cradek> that cursed iso!
[03:06:27] <SWPadnos> I don't think so
[03:07:26] <SWPadnos> lots from BDI-related referrers as well
[03:41:49] <tomp> jmkasunich: got the belting, and just got the hektor.pdf. it has the specific math used and good closeups of the mechanisms.http://www.hektor.ch/Book/Hektor.pdf/ maybe alex's trikins can reduce the wobble (instead of hektor bi-kins + gravity )
[03:48:12] <SWPadnos> hmmm: http://www.ubuntu.com/news/launchpad-personal-package-archive
[03:52:07] <tomp> also found i have illustrator 9.0 so will try the scriptographer ( an ancient version is still avaliable ), meanwhile enlarging parts of hektor photos to see the mechanisms. got a working idea of the gondola and found a disused commercial spray paint gun & pot at work.
[03:52:12] <jmkasunich> hi guys
[03:52:19] <jmkasunich> just got in
[03:52:27] <SWPadnos> hi jmk. where ya been?
[03:52:34] <jmkasunich> sailing
[03:52:37] <SWPadnos> cool
[03:54:33] <SWPadnos> it's past my bedtime (strangely enough) - good night
[03:55:56] <jmkasunich> night
[03:56:10] <jmkasunich> digital cameras are cool - you can shoot 62 shots of total crap without feeling bad
[03:56:39] <jmkasunich> shooting dim stuff from the deck of a moving boat doesn't work very well
[03:57:24] <Skullworks-PGAB> * Skullworks-PGAB knows that feeling - I used to burn 100ft of 35mm Plus-X a week on a slow week.
[03:57:47] <jmkasunich> I had a great opportunity, just not enough light
[03:58:23] <jmkasunich> the rising moon (full, low on the horizon, and rather red) with the top of a lighthouse silloutted in front of it
[03:59:06] <Skullworks-PGAB> quick question - which works better under RT - an Nvidia TNT2 M64 or an Ati 9200?
[04:00:32] <jmkasunich> no idea
[04:01:18] <Skullworks-PGAB> OK - I'll just test each
[12:41:20] <skunkworks_> cradeK: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BoardElection
[12:41:57] <skunkworks_> if you wanted to edit the stupid mistakes you see - otherwise don't worry about it.
[12:42:10] <jepler> are attachments not allowed at all on the emc-developers list, or are short attachments OK?
[12:43:17] <skunkworks_> I know people have attached their configs and pictures..
[12:43:52] <jepler> it must be a size limit, then
[12:43:56] <alex_joni> size limit
[12:44:05] <alex_joni> jepler: I can check for exact size if you need it
[12:44:14] <jepler> alex_joni: no that's OK
[12:44:36] <jepler> after I got smart, I found that the biggest message in my folder is over 500kb
[12:44:55] <jepler> though that's from 2005, maybe the limit was changed since then
[12:45:45] <jepler> a 250K one from march
[12:46:43] <alex_joni> emc-users?
[12:46:48] <SWPadnos> you can send attachments, I'm not sure about the size limit
[12:46:54] <jepler> specifically -developers
[12:47:27] <alex_joni> 24kB limit for the body
[12:47:32] <alex_joni> on emc-users
[12:48:14] <alex_joni> same for emc-devel
[12:48:22] <alex_joni> can't find anything about attachements atm
[12:48:49] <jepler> huh OK
[12:49:16] <jepler> thanks for looking
[12:50:37] <alex_joni> can't see anything else, but I remember getting admin emails if a message is too large
[12:50:50] <alex_joni> then one of the admins can decide to let it through, or drop it
[12:53:40] <jepler> yeah I guess I can't tell whether a particular message got special approval
[13:09:58] <SWPadnos> out of curiosity, does anyone here have any data about how little memory you need to run an EMC2 system without any swap?
[13:11:09] <alex_joni> without X?
[13:11:15] <SWPadnos> yes, without X
[13:11:23] <alex_joni> probably 16-32MB
[13:11:41] <SWPadnos> ok, so 512M-1G should be sufficient ;)
[13:12:26] <SWPadnos> I'll probably want to be able to connect a remote display, so the X client apps could be running on the embedded machine
[13:29:37] <alex_joni> cradek: around?
[13:30:24] <cradek> yes
[13:32:22] <alex_joni> I /msg'd you
[14:31:30] <skunkworks_> SWPadnos: http://linux.slashdot.org/linux/07/07/25/1519256.shtml
[14:31:54] <SWPadnos> yep - saw that
[14:32:01] <skunkworks_> I was looking for reviews :)
[14:32:06] <SWPadnos> plus the discussion today about slightly more expensive ones from Asus (I think)
[14:35:28] <skunkworks_> more expensive - less powerfull/smaller screen
[14:35:42] <SWPadnos> real company ...
[14:35:46] <skunkworks_> right
[14:39:40] <skunkworks_> although I had gotten some inspirons from dell for $399 (250 dollar rebate.)
[14:42:05] <skunkworks_> iirc
[14:44:01] <jepler> I added a section "Patch Submission" to the wiki, page http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS
[14:44:07] <jepler> comments? additions? contradictions?
[14:47:47] <cradek> looks fine to me
[14:48:04] <alex_joni> same here
[14:48:18] <alex_joni> jepler: there is support at SF for patches
[14:48:22] <cradek> maybe the "outright rejection" part is a little much
[14:48:43] <alex_joni> just like the bug tracker, we could set up a patch system, but I think it's overkill
[14:48:45] <jepler> alex_joni: oh? I know some projects have a tracker *called* patches but I didn't see one for our project
[14:49:07] <alex_joni> jepler: I can set one up, but I don't think we get that many patches to justify it
[14:50:45] <cradek> I think the best way to submit a patch to a project is together with a careful bug report
[14:51:28] <jepler> cradek: "outright rejection" happens -- remember the patch that modified what "G0" did, to change to the final Z before moving X and Y?
[14:51:29] <cradek> a patch is not a substitute for a careful bug report, but it's very nice to get both together
[14:52:01] <cradek> jepler: sure, but he knew that would happen, and wasn't asking for it to be incorporated anyway
[14:52:09] <SWPadnos> question on commit: will cvs commit all changes in the current dir by default, or do you need to specify a file list?
[14:52:27] <cradek> SWPadnos: all changes in the current dir *and under*
[14:52:32] <SWPadnos> ok
[14:52:50] <cradek> if you cvs commit without a -m, you'll see the list in the editor
[14:53:00] <SWPadnos> just wanted to know if the wiki page should have <filename> in the sample commit command
[14:53:13] <cradek> nope probably not
[14:53:55] <alex_joni> jepler: there are 4 default possible trackers
[14:53:58] <cradek> I'm not sure why we want to maintain our own CVS documentation, aside from what's peculiar/particular to our project
[14:54:04] <cradek> ^^ an aside
[14:54:12] <alex_joni> bugs, support requests, patches, and feature requests
[14:54:14] <jepler> cradek: yeah I'm sure that page could be streamlined
[14:54:37] <alex_joni> jepler: we only have bugs & feature requests active
[14:54:43] <cradek> brb
[14:54:51] <SWPadnos> having this "outside documentation" in the wiki means people can find out everything about EMC2 and developing it in one place (once we have everything in there ;) )
[14:55:28] <SWPadnos> so I think touching on all aspects is a good idea, with links to external in-depth documentation where applicable
[14:57:26] <skunkworks_> I just would say - I used the cvs server before source forge and after.. other than my denseness.. I could not tell the difference other than my anonymous loggin worked on the new server - on sourceforge it was hit or miss.
[14:57:47] <skunkworks_> login
[19:35:41] <cradek> I had no suspicion that supporting inflexible windows cvs clients would be important for the cvs of a project that runs only on linux
[19:35:50] <SWPadnos> heh
[19:36:06] <SWPadnos> it is flexible, but hard to configure (go figure)
[19:36:47] <SWPadnos> in fact, I think I can use the Tortoise CVS client with Altium and keep schematics and PCBs (and FPGAs and source code) in a CVS repository
[19:39:41] <alex_joni> it's really not hard to configure
[19:39:50] <alex_joni> SWPadnos: I just answered what you need to do
[19:39:53] <alex_joni> max 2 minutes
[19:40:17] <SWPadnos> heh - thanks :)
[19:40:30] <alex_joni> get pageant (friend of putty)
[19:40:35] <SWPadnos> maybe I'll update one or two of those dirs instead of deleting them then :)
[19:40:37] <SWPadnos> yep
[19:40:37] <alex_joni> get the private key safely to the doze box
[19:40:46] <alex_joni> (your problem how you do that)
[19:40:52] <alex_joni> convert it to ppk
[19:40:57] <alex_joni> start pageant, load the ppk
[19:41:02] <alex_joni> you're done
[19:41:49] <alex_joni> the only issue is that you don't have many possibilities in doze to protect the ppk
[19:42:11] <SWPadnos> sure
[19:42:57] <SWPadnos> I protect it by leaving this unpatched Windows 2000 machine on the internet 24/7, and leaving my administrator account logged in
[19:42:59] <SWPadnos> do you think that's enough?
[19:43:33] <alex_joni> nope
[19:43:42] <alex_joni> install some OpenVNC server
[19:43:56] <alex_joni> that should cut things down to a couple of minutes before you're hacked
[19:44:22] <SWPadnos> ooooh - and pcanywhere client
[19:44:45] <alex_joni> don't forget sharing C
[19:45:27] <SWPadnos> of course
[19:45:37] <SWPadnos> and make guest an administrative user
[19:45:47] <alex_joni> yes of course
[20:12:27] <alex_joni> "Danke an die Programmierer,wenn nur alle Bugfixes bei anderen Programmen auch so schnell
[20:12:32] <alex_joni> gefixt w├╝rden."
[20:12:56] <alex_joni> "thanks to the programmers, if only all bugs would be fixed so fast for other programs."
[20:13:15] <cradek> :-)
[20:13:31] <alex_joni> that's from a german guy, who is happy about 2.1.7
[20:13:49] <cradek> was one of the bugs, uh, bugging him?
[20:15:05] <alex_joni> probably so