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