Back
[00:00:08] <seb_kuzminsky> see ya's
[01:53:30] <steves_logging> steves_logging is now known as steve_stallings
[03:20:49] <CIA-1> EMC: 03cradek 07concave_comp2 * 10emc2/src/emc/rs274ngc/rs274ngc.hh: oops, missed this on the last checkin
[03:21:37] <cradek> t's nicer if it compiles
[03:21:38] <cradek> i
[03:27:28] <jmkasunich> did you commit something that wouldn't compile?
[03:28:18] <cradek> ummmmm
[03:28:26] <cradek> I'd never do that
[03:28:35] <jmkasunich> I'm wondering why the farm didn't complain
[03:28:45] <jmkasunich> and why it isn't busily compiling right now
[03:28:49] <cradek> branch
[03:29:00] <jmkasunich> oh, ok
[03:29:03] <jmkasunich> I thought something was busted
[03:29:08] <jmkasunich> goodnight
[03:29:13] <cradek> branches are where all the cool stuff happens
[03:29:16] <cradek> goodnight
[03:29:28] <jmkasunich> do you want any branch(es) on the farm?
[03:30:30] <cradek> not necessary - I'm the only one working on it
[03:30:35] <jmkasunich> ok
[04:22:53] <steve_stallings> steve_stallings is now known as steves_logging
[04:46:19] <CIA-1> EMC: 03cradek 07concave_comp2 * 10emc2/src/emc/rs274ngc/interp_convert.cc:
[04:46:19] <CIA-1> EMC: allow other canon calls to be queued after the deferred indeterminate move.
[04:46:19] <CIA-1> EMC: when the move's endpoint is later determined, flush these calls in order
[04:46:19] <CIA-1> EMC: starting with the move. the number of queued calls is unbounded but will
[04:46:19] <CIA-1> EMC: generally be very small. so far, only feed rate is done.
[04:53:14] <cradek> holy crap, the regression tests pass, except for what I expect
[04:53:23] <cradek> this may actually work.
[05:00:02] <SWPadnos> run away!
[13:35:44] <Lerman_______> Lerman_______ is now known as Lerman
[15:00:05] <BigJohnT> what magic creates the man pages?
[15:02:37] <cradek> some are handwritten, some (those for comps) are generated by comp --document
[15:03:23] <BigJohnT> so for a user component done in c the man pages are done by hand?
[15:03:32] <cradek> BigJohnT: yes
[15:03:43] <BigJohnT> thanks cradek
[15:03:48] <cradek> sure
[19:50:24] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[21:46:14] <SWPadnos> hey seb - do you reacall offhand how long gpio_read and gpio_write take on a 5i22?
[21:46:37] <SWPadnos> or maybe hm2_read_gpio and hm2_write_gpio :)
[21:51:39] <jepler> SWPadnos: what shadowy work are you up to now?
[22:03:25] <SWPadnos> camera controls
[22:04:11] <seb_kuzminsky> SWPadnos:
http://thread.gmane.org/gmane.linux.distributions.emc.user/8465/focus=8467
[22:04:51] <seb_kuzminsky> read_gpio, with 72 pins, on the 5i20, takes about 13 cycles on my 2.6 GHz (not 13 ns like that email says)
[22:05:05] <seb_kuzminsky> write_gpio with 72 pins takes 5 cycles
[22:05:15] <seb_kuzminsky> the 5i22 should be about the same speed
[22:05:21] <SWPadnos> ok, thanks
[22:05:44] <SWPadnos> are those done as contiguous bits or is it 1 register per connector (with 8 bits ignored/unused)?
[22:06:05] <seb_kuzminsky> each connector has 24 pins, and is accessed via one 32-bit register, with 8 bits unused
[22:06:11] <SWPadnos> ok
[22:06:29] <SWPadnos> 13 cycles seems awfully fast
[22:06:45] <SWPadnos> I didn't know a function call/return could be that quick
[22:07:04] <seb_kuzminsky> maybe i messed up my measurement somehow
[22:07:13] <seb_kuzminsky> that's what the .time pin said
[22:07:14] <seb_kuzminsky> brb
[22:07:24] <SWPadnos> ok, thanks for the info
[22:07:36] <alex_joni> the link isn't right
[22:07:53] <alex_joni> it's actually 8594
[22:07:54] <alex_joni> http://article.gmane.org/gmane.linux.distributions.emc.user/8594
[22:08:36] <seb_kuzminsky> alex is right
[22:09:15] <SWPadnos> ok, petting the dog seems more plausible at 13 cycles :)
[22:09:35] <SWPadnos> hmmm
[22:09:47] <SWPadnos> 5 cycles seems impossibly short for write_gpio
[22:10:34] <SWPadnos> whichever. it's short enough that a 20-50 us thread probably won't crash the machine
[22:27:20] <jepler> seems unlikely -- it's only about twice the number of IOs for a parport, after all.
[22:29:24] <SWPadnos> oh right, it was the 7i43 that had a problem with read/write in a fast thread
[22:54:11] <seb_kuzminsky> SWPadnos: the 7i43 is on EPP, which is not threadsafe
[22:54:25] <seb_kuzminsky> so read_gpio and write_gpio are not available when talking to a 7i43
[22:54:45] <SWPadnos> I think the original discussion (or one of them anyway) was that someone had a problem with a very fast thread and some mesa device
[22:54:48] <SWPadnos> right
[22:55:29] <seb_kuzminsky> istr a user who ran the normal hm2_7i43.read() and .write() too fast, and the machine locked up because it never left realtime context
[22:55:48] <SWPadnos> yep
[22:55:54] <SWPadnos> that's what I was asking about :)
[22:56:14] <SWPadnos> I figured that the 5i2x would be a hell of a lot better, but couldn't remember the exact circumstances
[22:56:36] <seb_kuzminsky> it's just much faster, but not really "better" in any other way :-)
[22:56:40] <SWPadnos> and happened to notice you join IRC, so I asked instead of searching :)
[22:56:50] <seb_kuzminsky> * seb_kuzminsky is the new google
[22:56:52] <SWPadnos> except that it has 96 I/Os, yeah
[22:57:10] <SWPadnos> I just wish there were a 24 out or 16 out/8 in daughtercard
[22:57:23] <SWPadnos> I don;t know that I can design and build one (or 8) this week
[22:57:54] <seb_kuzminsky> "The 7I37 is an 8 output, 16 input isolated I/O card."
[22:58:04] <seb_kuzminsky> so two of those ;-)
[22:58:17] <SWPadnos> 8O 16I, I need 8I 16O (*4)
[22:58:43] <SWPadnos> I need to control 75 outputs, ideally each one actually having two outs and one in
[22:59:03] <SWPadnos> which is unfortunately a little bit too much for even two cards
[22:59:09] <seb_kuzminsky> the 7i64 might do it, but you'd have to add SPI support to the hostmot2 driver (the firmware already supports it)
[22:59:18] <seb_kuzminsky> 24in, 24out
[22:59:20] <SWPadnos> with microsecond timing per output, so that serial card is out ;)
[22:59:44] <SWPadnos> plus Pete said he has the first batch in testing now, not ready for sale
[23:00:57] <jepler> you mean you need 75*3 IO points?
[23:01:15] <jepler> that's quite a few!
[23:01:20] <SWPadnos> yep
[23:01:26] <SWPadnos> actually, more would be better
[23:01:32] <SWPadnos> 75 is just the start
[23:01:48] <seb_kuzminsky> 3x5i22
[23:02:03] <SWPadnos> I may be better off getting a half dozen GOAL3 units and just use 1 5i22 per
[23:02:24] <jepler> isolated I/O? otherwise, there are always those terrible rows-of-screw-terminal boards
[23:02:40] <jepler> I thought you even had a stock of them, though probably not dozens
[23:02:46] <SWPadnos> I wish I had a camera so I could see if the FPGA can trigger it directly
[23:02:53] <SWPadnos> I have about 6 or 7 actually
[23:03:15] <SWPadnos> I probably have enough opto-22 racks sitting around actually. heh
[23:03:19] <SWPadnos> that would be funny
[23:03:46] <SWPadnos> I wonder how long a ribbon cable I can use between the Mesa and an opto22 board
[23:05:42] <seb_kuzminsky> peter said 6' is no problem for 100 KHz PWM (between an AnyIO and a 7i30)
[23:07:52] <SWPadnos> I need 1 transition per few seconds, but at microsecond resolution
[23:08:17] <SWPadnos> eventually - at first it will be GPIO and software (20-50 us) resolution
[23:37:29] <SWPadnos> seb_kuzminsky, is the fix for zero encoders (or was that stepgens) in 2.2.8, or do I need TRUNK?
[23:45:23] <jmkasunich> SWPadnos: uSec resolution, but how far apart are the nearest transitions?
[23:45:32] <SWPadnos> possibly simultaneous
[23:45:37] <jmkasunich> oh
[23:46:10] <SWPadnos> it's unlikely to have two different times be closer than ~100 us, but they can also be simultaneous
[23:46:18] <jmkasunich> I was thinking you might be able to treat it as a 75 bit (or 200, or whatever) bit vector that you clock out at your leisure, then strobe at the desired time
[23:46:26] <SWPadnos> ah
[23:46:27] <jmkasunich> oh, then that would work
[23:46:37] <SWPadnos> yes, it could
[23:46:46] <SWPadnos> the input side could be a little harder though
[23:46:55] <SWPadnos> those could have any timing
[23:47:11] <jmkasunich> strobe capture, clock in at leisure, or do you need uS "timestamps" on edges?
[23:47:36] <SWPadnos> timestamps on the first edge for each channel independently
[23:48:22] <SWPadnos> and they're clocked from separate sources - the input goes active once the output has been hit on that channel
[23:49:33] <SWPadnos> so each channel should be a state machine: wait for start / count until timer expires / activate output / clear input capture timer / start input capture timer / capture on first edge / wait for reset
[23:51:44] <jmkasunich> phone
[23:52:54] <jmkasunich> back
[23:53:17] <jmkasunich> so basicly you are hitting something at a specified time, and carefully measuring how long it takes to react
[23:53:31] <jmkasunich> x many somethings
[23:54:37] <SWPadnos> yes
[23:55:14] <jmkasunich> but there are actually two outputs for every input?
[23:55:15] <SWPadnos> somebody yells "go", each something waits a specified amount of time, goes, then times how long it takes to come back
[23:55:24] <SWPadnos> should be, but one of them is just "ready"
[23:55:33] <SWPadnos> pre-release and release for cameras :)
[23:56:27] <jmkasunich> so the many ready outputs don't have critical timing and could be multiplexed/serialized/whatever
[23:56:33] <jmkasunich> (at the expense of modularity)
[23:56:40] <SWPadnos> maybe even one output, yes
[23:56:47] <SWPadnos> (dpends on wiring)
[23:56:49] <SWPadnos> +e
[23:57:24] <jmkasunich> the many release outputs can be a vector, since they either change simultaneously, or far enough apart to load a new vector between changes
[23:57:44] <SWPadnos> if the hardware and software are already done, that should work great
[23:58:03] <SWPadnos> since I need to head for San Diego this Saturday though, I may stick with simple I/O :)
[23:58:12] <SWPadnos> (unless the job falls through, as so many do)
[23:58:20] <jmkasunich> I was about to ask, what is more important, good, fast, cheap
[23:58:24] <jmkasunich> sounds like fast
[23:58:29] <SWPadnos> fast, cheap, good ;)
[23:58:47] <SWPadnos> well, fast, barely good enough, cheap, good
[23:59:08] <jmkasunich> cheap would involve some form of probably custom but simple hw to reduce pin (and thus expensive board) count
[23:59:19] <jmkasunich> I don't think that is fast enough tho, so I should forget it
[23:59:26] <SWPadnos> heh
[23:59:28] <SWPadnos> right
[23:59:46] <jmkasunich> what board is cheapest on a per-pin basis?
[23:59:46] <SWPadnos> $1000 for boards and another $1000 for assembly makes off-the-shelf 5i22s look inexpensive
[23:59:58] <SWPadnos> 5i20 or 5i23