Pattern I/O

[brinkrob]

I'm writting an application using a NI-6536 with NIDAQmx written in C++.  What I want to do seems simple enough, but I'm having a hard time finding out how in the documentation or on these boards.  And it may simply be that I am not familiar enough with the terminology involved.

I have two different things that I want to do.

I want to output 4 bytes of data, one byte at a time (each bit on its own line).  The hardware I am talking to is designed in such a way that whenever it detects a falling edge on a strobe signal it latches the value of the 8 lines.  So part of my problem is generating that strobe signal when my data is ready.  I also don't want that signal to keep going when I dont have new data to send. (my data will come in bursts.)

Can I use Continuous Digital Output so that I do not have to hand hold the hardware through this procedure?  Specifically, I'm curious how to output the Data Strobe.  Is it as simple as using DAQmxExportSignal to export the SampleClock to PFI4?  What will happen when the hardware is waiting for more data to send, is there a way to hold the outputs at whatever they were last, including the sampleclock?

In theory I could structure my data in such a way that the data strobe was actually part of my signal.  Such that I output each byte of data twice, first with a strobe signal high, and another time with it low.  In that case I wouldnt have to output any clock per se because It would be part of the data.  I'd hate to use this implementation though if there is a simpler way.

My second problem is related to my first.  In addition to outputing data, I also have to act as the reader in the same kind of scenariodescribed above.  The only difference being that the strobe used to latch the data will be the very same strobe that I am outputing above.  So its a strobe that I output rather than receive.  Is there a way of accomplishing this short of having the hardware I talk to, route the strobe sugnal back to me on PFI5 and doing basic continuous digital input?  For example, could I use DAQmxConnectTerms to route PFI4 to PFI5? (Assuming that in the above case my strobe signal is output in PFI4.)

I also find it wierd that there is truely only one PFI line that I can use as an input clock, and one that I can output a clock on.  Is that truely the case?

Thanks for the Help
-Rob

[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.  You can read about them in the Help file for your device, under Programming Your Device » Choosing a Sample Timing Type for your Application.  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.  This is a big help compared to the generic NIDAQmx Documentation  I was solely using before.

How fast I sample is really up to me.  The only real requirement I have is that there is enough bandwidth to support my expected frequency of messages, which is actually quite low.  As a rough guess I would say I need it to be around 10kHz.  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.  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.  I do not expect to saturate the output lines though.  By that I mean I expect to send bursts of data followed by indeterminate periods of holding output to some "zero" pattern.  If I configure the channel as Continuous, what happens when the write buffer runs out.  Does the card simply hold the last sample, or loop through the buffer again?  I would need it to hold the last sample.

The other half of my problem relates to my input.  Technically both input and output are running off the same internal clock being exported as above.  So technically I don't need to do any routing of the clock.  (Unless there is going to be an issue with the internal clock and what the DUT sees as the clock being slightly different.)  I also only want to read samples that occur while the "enable" line that I output is asserted.  I assume that I can use both a start and a reference trigger based on this "enable" signal to accomplish this.  Though it seems weird that I would need to be continually stoping and starting the task to make this work.  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.   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)?  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.  The reason is that in Continuous mode, the board reads and writes its data using a circular buffer.  In write operations, every tick of the Sample Clock pulls a sample out of the buffer and writes it to the pin.  When the end of the buffer is reached, it tries to pull from the beginning again.  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.  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.  So you have to read the data from the buffer continuously to avoid an overwrite error.  There isn't an option to just repeat the last sample on the next clock edge.  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.  Which is it?  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.  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.  If the latter, then you don't have to worry about this.

The enable line:  Is it being driven by the DAQ or the DUT?  Which device is using it to gate input operations?  If it's gating the DAQ's input, then I have to inform you a little more about the hardware's design.  Each "engine" on this board -- 1 input and 1 output -- can be associated with a single trigger and a single clock source.  So you can't use both a Start and a Reference trigger on the input task.  You can only use either.  Given that, we added a Pause trigger to be used with handshaking situations, like your enable line.  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.  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.  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.  Inside that file, you can browse to Taking Measurements » NI-DAQmx Key Concepts.

[brinkrob]

The output and input that I speak of is from the context of the DAQ.  There are 10 output lines, 8 data lines and 2 "control" lines.  One of which is the enable line and the other is an application specific control line that will sometimes be set and sometimes not.  In my original post I just simplified this because I mistakenly did not see them as important.

I will be outputting 4 (10 bit) samples in a single shot.  At that point it cold be an hour before I send an additional 4 samples or it could happen immediately.

I need to hold the enable line low during the entire 4 sample operation.  I am outputting my data on the rising edge of the clock and the DUT reads it on the falling edge.  So technically I want the enable to be low till the 5th rising edge.  Which if I just have to output 5 samples to clear the card, I'm fine with.  I assume at the end of a finite generation, the card holds the last sample?

Maybe I'm thinking about this as too complex of a problem.  I just want to perform a series of 4 output samples and 4 input samples at the same time.  The important thing being I want all 8 samples to occur on the same 4 clock cycles.  Wouldn't it work if I created a task with both an input and output channel, and then tied the whole thing to the internal clock with a finite sample of size 4?  I would just have to start and stop the task each time I wanted to perform one of these sequences.  This is assuming that starting and stopping the task repeatedly is an OK idea.  One hitch here is that I'd want to generate data on the rising edge and aquire data on the falling edge.  I'm not sure thats possible to configure in one task.  And if they are in two seperate tasks, how do I keep them in sync?

As I said in the close of my previous post, I'm most interested right now in what pins all this data needs to be put on.  And assuming what I described above will work, I don't think I have any special requirements on pin locations besides that the clock can only be exported on PFI4.

Thanks!
-Rob

[brinkrob]

So I've been playing around with a little test app I've made and I've found out that I can't put an input and an output channel in the same task.  So now my question is,  how can I synchronize a finite acquisition task and a finite generation task so that they occur on the same clock cycles.  Is this a case where I use a start trigger to start the acquisition task based on the enable line that I output in the generation task.  Am I going to be able to use the output line as a trigger? 

I'll make one other comment.  This whole time I've been saying that I want to read 4 samples at the same time as I generate 4 samples.  In actuallity, I only care about the final 2 samples I read in.  So if there is some sort of a delay as to how fast the input task can start, I can live with it as long as I can reliably get the "final two" samples.

Does that all make sense?

-Rob

[Kevin_Price]

I expect you should be able to do what you want, though I can't say with 100% certainty.   I've done some similar things, but there were some significant differences too.

Similar

-----------

1. Performed digital Stimulus - Response with 1 hw-timed Dig. output task and 1 hw-timed Dig. input task. 

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."

Different

------------

1. Programmed using LabVIEW.  Sorry, I'm no help on C++ syntax.

2. Programmed using NI M-series board rather than a dedicated DIO board.  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.  This let me make the clock asymmetrical (>90% duty cycle) to provide maximum reaction time between stimulus and response.  I'm not sure you can control your internal sampling clock that way.  I'd guess you'll get something more like a 50% duty cycle, which may very well be enough.  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.  I didn't need to since I could control the start and stop of my own sampling clock.

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.

-Kevin P.

[brinkrob]

I've actually just talked to our guy designing the DUT and he is going to use some jumpers such that we can configure the clock location a little from the hardware side  Therefore if this works or not is not really an issue in the near term.  The fun comes in a month or so when I've got a real DUT to talk too.  Till then I sit and think theory. 

If all else fails, I'm pretty sure I can drop to a "On Demand" mode and just hand hold the card through the entire operation, but why do that if there is an easier more efficient way.

Thanks for working me through this.

-Rob

[David S.]

Hi Rob -

Sorry for the delayed response.  I went ahead and whipped together an example that should demonstrate a lot of the capabilities your board has, with respect to this application.  It synchronizes the sample clocks of your DI and DO tasks so that everything is done on the same clock edges.  Using Finite Generation mode, it produces 4 sample edges for input/output, then reconfigures itself to produce the next batch of 4.   This keeps you from having to create "dummy samples" in between real generation/acquisition sets.  I also used the Line State feature to have the board hold the last value of the lines after each batch of 4 samples.

Take a look at it and let me know if you have any questions about it.  I think that working to mold a specific piece of code to your application will be easier than theorizing on paper alone.

[jcarbonell]

Hi Rob,

Can you share the timing diagram for your device?  With it we can probably find a suitable solution w/ the 6536.  Also, are there any overflow / underflow conditions to worry about?

Jeff

---

@brinkrob wrote:
I'm writting an application using a NI-6536 with NIDAQmx written in C++.  What I want to do seems simple enough, but I'm having a hard time finding out how in the documentation or on these boards.  And it may simply be that I am not familiar enough with the terminology involved.

I have two different things that I want to do.

I want to output 4 bytes of data, one byte at a time (each bit on its own line).  The hardware I am talking to is designed in such a way that whenever it detects a falling edge on a strobe signal it latches the value of the 8 lines.  So part of my problem is generating that strobe signal when my data is ready.  I also don't want that signal to keep going when I dont have new data to send. (my data will come in bursts.)

Can I use Continuous Digital Output so that I do not have to hand hold the hardware through this procedure?  Specifically, I'm curious how to output the Data Strobe.  Is it as simple as using DAQmxExportSignal to export the SampleClock to PFI4?  What will happen when the hardware is waiting for more data to send, is there a way to hold the outputs at whatever they were last, including the sampleclock?

In theory I could structure my data in such a way that the data strobe was actually part of my signal.  Such that I output each byte of data twice, first with a strobe signal high, and another time with it low.  In that case I wouldnt have to output any clock per se because It would be part of the data.  I'd hate to use this implementation though if there is a simpler way.

My second problem is related to my first.  In addition to outputing data, I also have to act as the reader in the same kind of scenariodescribed above.  The only difference being that the strobe used to latch the data will be the very same strobe that I am outputing above.  So its a strobe that I output rather than receive.  Is there a way of accomplishing this short of having the hardware I talk to, route the strobe sugnal back to me on PFI5 and doing basic continuous digital input?  For example, could I use DAQmxConnectTerms to route PFI4 to PFI5? (Assuming that in the above case my strobe signal is output in PFI4.)

I also find it wierd that there is truely only one PFI line that I can use as an input clock, and one that I can output a clock on.  Is that truely the case?

Thanks for the Help
-Rob

---