07-15-2011 06:24 AM
I wrote you some time ago about my problem: I am using the The SPI digital waveform library ( The example: SPI Correlated DIO) and a harware-timed( PCI 6321) DAQ device. I expanded this example and I am able now to send any number of bits.I am trying to send instructions to a microcontroller. Now I kneed to make a pause of some millisecond after a certain number of bits. I still was not able to figure out how to do that.( I tried posting in the Multifunction DAQ form but could not get the answer I needed). Is it possible to do that delay in the SubVIEW "Add middle Bit" of the "Send any length" VI?
Sorr that I ask again but I was not able to solve this problem,
I would appreciate your help,
07-15-2011 09:40 AM
Hi Katja -
Sorry you couldn't get help in the other forum. I'll see what I can do. Could you please post a timing diagram of the message you need to construct? I want to make sure my understanding of your requirement is accurate.
07-15-2011 03:50 PM - edited 07-15-2011 03:52 PM
Thank you so much for your reply!
Timing diagram..? The application requires to make a pause of 4.5 ms after every 64 byte. The length of my message is always different. I expanded the Send VI of the SPI digital waveform library and I am able to send any number of bits now per message. Its this pause I can`t figure out how to do......
07-15-2011 03:59 PM
Hi Katja -
Here's an example of a timing diagram: http://img707.imageshack.us/img707/6457/readtr.png
From this image, I can gather the timing of every signal transition on the bus. I can use it to fully understand how long each bit is, how long each packet is, any phase skew or holdoff between signals, etc. A text description of your transmission scheme almost always fails to get the entire point across, so it's common to use timing diagrams instead.
For example: you say that you need to pause 4.5 ms after every 64 bytes.
These are just a few questions that can arise when trying to figure out an approach, and an accurately drawn timing diagram can usually answer all of them.
07-18-2011 04:01 PM
Hi Katja -
That waveform cannot be created using the SDW library as it's written. What you need is a new VI that adds a delay of some length to the waveform while holding all the signals in the necessary states. You'll have to customize the library to add that VI. You can look at the existing low-level VIs for a starting point. Every low-level VI in the library is based primarily on two private functions: Change Bit and Add Delay. In your new low-level VI, you'll want to use these two functions to set the line states to their appropriate values (using Change Bit), then create a 4.5 ms pause (using Add Delay). I've attached another copy of your diagram with some annotations.
07-21-2011 03:50 PM
I'm using an NI USB-6251 to communicate with several SPI slaves, using a modified version of the "DAQmx SPI - Correlated DIO" example vi. This uses the SPI Digital Waveform library in combination with the DAQmx write and read digital waveform with a counter. It seems to be outputting all the correct signals, but is not measuring the correct input. My question is, how does the write digital waveform command know which data lines of the SPI waveform (MOSI, SCLK, CS_0, CS_1) to write to which physical port lines (channels within the output task). I have the output physical channels simply defined as a range of 6251/port0/line0:3. Do I need to specify which physical lines correspond to which task (MOSI, SCLK, CS_0, CS_1) and is there a way to do this? Or is it simply a matter of needing to wire my inputs in a certain order on my DAQ. Any advice would be great!
I've also attached my code in case there's some other problem I'm not seeing.
07-26-2011 10:06 AM
Still looking for advice on my previous problem posted above....
I also realized I don't think my chip select lines are operating correctly. The CS line should be pulled low, remain low while all the data bytes are written with multiple clock pulses and then return high at the end. Instead my signals are showing that the CS line is pulsing along with the clock line. Maybe this is due to how my data is being written...? I need to write multiple bytes at a time, currently formatted in a U8 1D array. The Clock line as well as the CS line seem to be pulsing for each byte. Will this work?
07-28-2011 03:38 PM
Still no response to my previous posts, and looking for help. Things seem to be working better but the data I'm reading back from my device still doesn't make sense. How do I know that the correct data lines within the SPI waveform (CS, MOSI, SCLK) are being output and written to the correct physical channel lines of my USB-6251 (port 0, lines 0:3)?
07-29-2011 01:35 PM
Hi Kso -
How do I know that the correct data lines within the SPI waveform (CS, MOSI, SCLK) are being output and written to the correct physical channel lines of my USB-6251 (port 0, lines 0:3)?
You have to either hook an oscilloscope up to the lines to check the real output, or tie those lines to acquisition lines on your DAQ device and acquire the data in a loopback. I don't know for sure, and I don't have easy access to an M-series board to figure it out, but I think the signals in your waveform are assigned in the order of the pins specified. Your physical channel string is "line0:3", so I would expect the first signal in your waveform (bit 0 of every U8 sample in the data array that's stored in the waveform wire) to be mapped to line 0, the second signal (bit 1) to line 1, etc. This should be simple to test with your hardware: just change the mapping of the signals in the waveform and see if it's reflected on your scope.
I also realized I don't think my chip select lines are operating correctly...The Clock line as well as the CS line seem to be pulsing for each byte.
If you look at the "Coerced SPI Timing" output of the Init VI, you'll see that all of the default timing parameters in the VI you posted (and in the screenshot you shared) are coerced to 0 when mapped onto the oversample clock frequency you specified. This will lead to unexpected behavior from the library. You'll need to either increase your sample clock frequency to gain more timing resolution (max 80 MHz for an M-series counter/timer --> 12.5 ns resolution) or increase the length of the various setup and hold times to meet the resolution of the clock speed you specified (1/100 kHz --> 10 us). Note that timing parameters are given in units of nanoseconds.