Pattern I/O

[David S.]

Hi Rob - I'd like to have you clarify some things before I begin digging into the details here:- How fast are you sampling?  This affects which timing types we can use and whether we need to externally route the clock to account for path delays.
- From the description, I assume you're reading data on a different set of lines than you're writing on?  How many samples are you reading? How many lines?
- Do you have any handshaking lines available on the DUT?  (Like ACK and REQ)
You may want to peruse the timing types available yourself, to see which one fits best with your communication method.&nbsp; You can read about them in the <a href="http://digital.ni.com/manuals.nsf/websearch/E5E1DC8E66F8387886257209006D2399" target="_blank">Help file</a> for your device, under Programming Your Device » Choosing a Sample Timing Type for your Application.&nbsp; I'm thinking that the Sample Clock, Pipelined Sample Clock, and Burst Handshaking are most likely to be useful here.

[brinkrob]

Thank you for pointing me to the card specific documentation.&nbsp; This is
a big help compared to the generic NIDAQmx Documentation&nbsp; I was solely
using before.

How fast I sample is really up to me.&nbsp; The only real requirement I have
is that there is enough bandwidth to support my expected frequency of
messages, which is actually quite low.&nbsp; As a rough guess I would say I
need it to be around 10kHz.&nbsp; Now I'd prefer that to be as fast as
possible, but as long at it could hit 10kHz I'd be happy.

Yes, I'm sampling on different sets of lines but at the same time.&nbsp;
There will be 8 input lines and 10 output lines and some sort of a
clock or strobe that I also output.

There is an "enable" line as one of my output lines that I assert
during a series of samples to tell the DUT that data is incoming, but
no ACK and REQ exactly.

Upon looking at my requirements with the new documentation and a fresh
mind I think Sample Clock mode will do what I want for the output.&nbsp; I
do not expect to saturate the output lines though.&nbsp; By that I mean I
expect to send bursts of data followed by indeterminate periods of
holding output to some "zero" pattern.&nbsp; If I configure the channel as
Continuous, what happens when the write buffer runs out.&nbsp; Does the card
simply hold the last sample, or loop through the buffer again?&nbsp; I would
need it to hold the last sample.

The other half of my problem relates to my input.&nbsp; Technically both
input and output are running off the same internal clock being exported
as above.&nbsp; So technically I don't need to do any routing of the clock.&nbsp;
(Unless there is going to be an issue with the internal clock and what
the DUT sees as the clock being slightly different.)&nbsp; I also only want
to read samples that occur while the "enable" line that I output is
asserted.&nbsp; I assume that I can use both a start and a reference trigger
based on this "enable" signal to accomplish this.&nbsp; Though it seems
weird that I would need to be continually stoping and starting the task
to make this work.&nbsp; Can I use edge triggers on an output line, or do I
have to use a pattern trigger on the single output line, or do I need
the trigger to be on a PFI terminal? (requiring me to output it to the
same place.)

I realize that my questions may seem a little weird, but I'm trying to
nail down the specification for what data is transmitted on what pin to
the DUT, and unfortunatly I need to know this well before I can get
into actually developing the code where I'm sure a lot of these
problems would just sort themselves out.

Thanks for the help.

-Rob

[David S.]

Hi Rob - Your questions are no different than anyone else's, save for the fact that you don't yet speak "NI" with regard to timing, triggering, and data transfer mechanisms. :smileywink:&nbsp; Let's start to get into the details of how your device works:Will this be a truly continuous operation, or do you just need 4 samples (of 8/10 bits each)?&nbsp; If you only need to send/receive the 4 bytes mentioned in your original post, then you should use Finite Sampling instead of Continuous Sampling.&nbsp; The reason is that in Continuous mode, the board reads and writes its data using a circular buffer.&nbsp; In write operations, every tick of the Sample Clock pulls a sample out of the buffer and writes it to the pin.&nbsp; When the end of the buffer is reached, it tries to pull from the beginning again.&nbsp; If new data hasn't been written into the buffer by the program, it'll either return an error or regenerate the original data, depending on an option you can set.&nbsp; Likewise, with an input operation it'll write to the end of the buffer and attempt to overwrite its beginning with the next Sample Clock edge.&nbsp; So you have to read the data from the buffer continuously to avoid an overwrite error.&nbsp; There isn't an option to just repeat the last sample on the next clock edge.&nbsp; If you're only outputting 4 samples, consider using Finite Generation instead to avoid the annoyance of having to work with "dummy" data.By the way, your original post said 8 output lines, and your second post said 10.&nbsp; Which is it?&nbsp; Are we regarding "output" to be from the DAQ to the DUT?Another thing to consider is whether you need to hold the line low in between samples, or just avoid switching it.&nbsp; If the former, then you'll need to send consecutive samples of the same value to the output Task, so it actively drives the line.&nbsp; If the latter, then you don't have to worry about this.The enable line:&nbsp; Is it being driven by the DAQ or the DUT?&nbsp; Which device is using it to gate input operations?&nbsp; If it's gating the DAQ's input, then I have to inform you a little more about the hardware's design.&nbsp; Each "engine" on this board -- 1 input and 1 output -- can be associated with a single trigger and a single clock source.&nbsp; So you can't use both a Start and a Reference trigger on the input task.&nbsp; You can only use either.&nbsp; Given that, we added a Pause trigger to be used with handshaking situations, like your enable line.&nbsp; This trigger is only available with the Pipelined Sample Cock, which by design introduces a delay of a few samples to recognition of a trigger event.&nbsp; So I'm concerned that we may not be able to fully implement the enable line if you need it on a per-sample basis.I didn't quite understand your question here.&nbsp; Can you reword it?Can I use edge triggers on an output line, or do I
have to use a pattern trigger on the single output line, or do I need
the trigger to be on a PFI terminal? (requiring me to output it to the
same place.)I know you said that you're not programming anything yet, but you might also want to check out the LabVIEW Help file for elaboration on DAQmx Key Concepts.&nbsp; Inside that file, you can browse to Taking Measurements » NI-DAQmx Key Concepts.

[Kevin Price]

I expect you should be able to do what you want, though I can't say with 100% certainty. &nbsp; I've done some similar things, but there were some significant differences too.
&nbsp;
Similar
-----------
1. Performed digital Stimulus - Response with 1 hw-timed Dig. output task and 1 hw-timed Dig. input task.&nbsp;
2. Both digital tasks were driven by a common (shared) sample clock.
3. The output was generated on the clock's leading edge, the input was captured on the trailing edge.
4. The total quantity generated and sampled was always known ahead and could be treated as "finite sampling."
&nbsp;
Different
------------
1. Programmed using LabVIEW.&nbsp; Sorry, I'm no help on C++ syntax.
2. Programmed using NI M-series board rather than a dedicated DIO board.&nbsp; I would expect you can have 1 output task and 1 input task running simultaneously with that board, but don't have experience with it to say for sure.
3. I generated my sampling clock with an available counter/timer on the M-series board.&nbsp; This let me make the clock asymmetrical (&gt;90% duty cycle) to provide maximum reaction time between stimulus and response.&nbsp; I'm not sure you can control your internal sampling clock that way.&nbsp; I'd guess you'll get something more like a 50% duty cycle, which may very well be enough.&nbsp; I'd be very surprised if you can't have your input task sensitive to a rising edge while your output task is sensitive to a falling edge.
4. You may need triggering too to guarantee synchronization between tasks.&nbsp; I didn't need to since I could control the start and stop of my own sampling clock.
&nbsp;
Sounds like you're on the right track and I think it's worth pursuring -- I think your chances are quite good for achieving what you need.
&nbsp;
-Kevin P.