Tracking where I am in between TTL pulses

[Kevin_Price]

I don't *entirely* follow how it is that 1 counter/timer board is thought to be sufficient when you have 4 tubes x 7 probes each = 28 TTL event sources.  It sounds like you plan to software-monitor sparks to each of the 4 tubes, then quickly react to decide which of the 4 configurations to set up to take your measurements of the 7 probes.  Roughly 90 degrees later (about 6.25 msec at 40 Hz full cycles) you'll need to start capturing readings from a different tube.  However, it isn't clear to me how the 28 physical probes cleanly map to your 7 planned counter input pins.

From what I *think* I understand of your system and app, here's some tentative advice:

  You've got some possible money for hardware.  Give serious consideration to the PCIe-6259 (or the regular PCI-6259 if you don't have the PCIe slot).  It's a very nice and versatile board.  A key feature is that it can capture data from all 28 probes simultaneously using a digital change detection task.  You would also use one of its counters to timestamp those change detection events.  Each time a probe fires, you would generate 1 32-bit digital word showing the state of your digital inputs and 1 32-bit timestamp value on your counter.  40 Hz x 28 probes x 8 bytes per measurement gives you a total data rate of only 8960 bytes/sec.  The hardware and DAQmx driver will EASILY handle this.  Other advantages are that you're

  I don't see how you could perform a single test run and collect 28 probes worth of timing data using a single 6602 board.  You'd need 4 of them.  But you *can* get it very easily and more reliably with a single 6259.   More reliable because (1) the hardware FIFO for digital input is much larger than for counter measurements, making less demand on the PCI bus and (2) measuring 7 signals on a 6602 would require that at least 4 tasks run off interrupts rather than DMA.  This demands more CPU and is more prone to producing errors due to system speed bottlenecks.  The 6259 would have 2 total tasks, both running off DMA.  Absolutely NO problem.

  It sounds to me like collecting all 28 channels would be nice, but you didn't think it was readily achievable because you had locked in on doing the measurement solely with individual counter/timers.  If there is any value in getting tubes 1-4 captured simultaneously on the same run, and I suspect there probably IS value, then the PCIe-6259 would be a great choice.

-Kevin P.

<Edit: added link>

Message Edited by Kevin Price on 07-14-2008 02:47 PM

[Kevin_Price]

One other tidbit to note:  if you capture using the change detection feature of a 6259, be aware that there is some software post-processing that'll be needed.  The raw data you collect will be an array of 32-bit values representing the new state of all the digital lines on port 0 right after one of your 28 probes fired.  You will need to compare this against the previous sample to help identify which line changed.  There's nothing inherent in the individual sample to identify which line changed to cause the sample to be taken.  It's a software processing step.  But in fairness, a pretty simple one.

Note too that the digital task gives you *no* timing information directly.  It's just an array of port states.  It doesn't care whether the transitions happend at 40 kHz or 0.03 Hz.  You just get a new sample whenever one of the lines changes.  This is why you need the counter timestamping task to run at the same time.

Final tiny tidbit.  Change detection measurements suffer from not providing a simple way to characterize the initial state of the digital port.  The first sample comes *after* the first change.  But to determine which line changed, you need to know the port state *before* the change.  Here are 3 strategies:

1. Just before configuring the change detection task, create and clear a task that takes a quick software-timed snapshot of your digital port.  Treat this as your initial port state.  Then config and start the change detection task.  This method works if you can be sure there aren't going to be any transitions during that fraction of a second that you are re-configuring.

2. Sometimes you can just "know" the initial state based on the electrical properties of the devices and connections.  You may need to add pull-up or pull-down resistors or similar stuff to be sure that non-firing probes will leave the digital lines in a predictable state.

3. Deal.  Just accept the fact that you won't know which probe caused the first change detect sample.  You can still know all the rest.  And odds are quite high that the cyclical nature of your system could give you high confidence at predicting what the change *probably* was.

-Kevin P.

[Signal_G]

Kevin

Great information man.  I think a lot of this is based on using hardware that we already have.  It is a challenge but, in theory, it may just work the way I have it.

We have a budget but our philosophy here is to be as efficient with what we have as we can.  That said, if I demonstrate to my people that what we have is incapable of giving us quality data they'll make the purchase.

I'll talk to my boss about it.  Either way we must find something that works.

Thanks again

Dave