Sending a byte to a digital output using a VI

[4NT4R35]

Hello,

Since i'm new to LW, i would like some help and advices on something using a USB-6002 NI DAQmx.

I would like to setup a digital potentiometer (MCP41100) and for that i need to send the correct data as a byte, in serial, so it could be configured correctly. My problem is, i don't see how to "transfer" the byte into the component trough a digital I/O of the USB-6002. Which function can i use ?

Thanks for your help

[crossrulz]

---

@4NT4R35 wrote:

Since i'm new to LW, i would like some help and advices on something using a USB-6002 NI DAQmx.

---

Your title mentions a VI, but your description says you are using LabWindows.  That does not match.  Are you using LabVIEW or LabWindows/CVI?  I will assume LabVIEW in the below comments.

I have not tried setting up a USB-6002, but you should be able to do a simple setup of a single 8-bit port as the channel.  Then you just write a single sample when you want with DAQmx Write.vi (digital, single sample, single channel, U8 port).  Look in the example finder (Help->Find Examples).  There should be something in there to get you going.

[bstreiff]

---

@crossrulz wrote:

I have not tried setting up a USB-6002, but you should be able to do a simple setup of a single 8-bit port as the channel. Then you just write a single sample when you want with DAQmx Write.vi (digital, single sample, single channel, U8 port).

---

I don't think that's quite right-- the MCP41100 uses a SPI interface. DAQmx Write on a U8 port would work well for a parallel digital interface, not so much for a timed digital interface. The USB-6002 also only has software-timed (non-buffered) digital.

The solution with a USB-6002 would be to create a Digital Input task with MISO and a Digital Output task for SPICLK/MOSI (could be one task per line, or both in the same task), and then clock in/out each individual bits with DAQmx Read and DAQmx Write.

(It's possible that the USB-8451/USB-8452 may be better-suited for this application.)

[4NT4R35]

Hello,

Sorry, indeed, by LW i meant LV, a labview interface...

Your replies are interesting, indeed the MCP uses a SPI protocol. I need to send data byte on the rising edge of a clock which should be a mutliple of 16.

If i understand, the USB 6002 poses a hardware limitation ?

I tought the USB 6002 would be enough since i'm not working at high frequencies. I was thinking of generating a clock signal, and on the rising edge, send one by one the bit trough a DIO pin...

[crossrulz]

And that is what I get for not looking up the part...

Make you life a lot easier and just use a USB-8451 or USB-8452.  They are USB devices specifically made for SPI and I2C interfaces with a very simple API.

[bstreiff]

---

@4NT4R35 wrote:

Your replies are interesting, indeed the MCP uses a SPI protocol. I need to send data byte on the rising edge of a clock which should be a mutliple of 16.

If i understand, the USB 6002 poses a hardware limitation ?

I tought the USB 6002 would be enough since i'm not working at high frequencies. I was thinking of generating a clock signal, and on the rising edge, send one by one the bit trough a DIO pin...

---

The only "hardware limitation" is that the USB-6002 doesn't have a nice friendly SPI API to do it all for you. 🙂 If you're willing to generate a clock signal and your data signal bit by bit (and performance isn't a concern) then the USB-6002 can solve this problem.

The simplest way to do it is to create one task per line (using three DAQmx Create Channel VIs, one for DI (MISO) and two for DO (MOSI and SPICLK)), and use the "Digital Bool 1Line 1Point" forms of DAQmx Read and DAQmx Write to read/write bits (as booleans) from/to each line. "Number to Boolean Array" and "Boolean Array To Number" will be useful here to convert between bytes and arrays of booleans (which you can then iterate over with a for loop).

[4NT4R35]

Thanks for your help. Indeed, i don't have something much more "user-friendly" than the 6002 at this time... At least, i know how to do a "cheap" version of a SPI 🙂

I've created a "DAQ assistant" to generate the clock, as a square signal. So, for the clock it should be fine.

But, i'm a bit confused when using the DAQmx assistant. I noticed that "generate" is actually meant for a signal to enter the USB-6002 so it can be processed and "Acquire" is actually "output" for a signal, is that correct ?

[bstreiff · Accepted solution]

In the DAQ Assistant, "Acquire Signals" is to read signals that are input into the USB-6002, "Generate Signals" is output signals from the USB-6002.

I wouldn't use the DAQ Assistant here, though; sequencing digital input and output like this isn't really a case where the DAQ Assistant is strong. The way I'd approach it is with a VI structured something like the following:

In other words, for each bit, set the value on the MOSI line, then set clock high, then read MISO, then set clock low. I don't have a USB-6002 or a SPI peripheral handy at the moment, so this is completely untested. (Caveat emptor. Cape does not allow wearer to fly.) You may need to make some adjustments given your particular device. (You might also need to add some code for chip-select if your slave requires it.)

[4NT4R35]

Thanks for your reply. I was expecting using more DAQ assistant "boxes"  in my version... But i guess using entry level DAQ requires to build a "charcoal factory" type of algorithmed-graph 🙂 !

I'll try both, see which one fits my needs...

But, i'm encountering an other problem. Can we use for example 3 "lines" (I/O ports if i understand well) the 6002 at the same time ? I noticed one day, when i was trying to light 2 LEDs with a VI, that when the hardware is "idled" for one task (first LED to turn on), it can not work at the same time with the other line. Or is it the way i draw the algorithm that plays a role ?

[crossrulz]

---

4NT4R35 wrote:  But, i'm encountering an other problem. Can we use for example 3 "lines" (I/O ports if i understand well) the 6002 at the same time ? I noticed one day, when i was trying to light 2 LEDs with a VI, that when the hardware is "idled" for one task (first LED to turn on), it can not work at the same time with the other line. Or is it the way i draw the algorithm that plays a role ?

---

More likely your issue is you ran out of total current draw.  LEDs typically take more current then a simple digital (TTL) line can handle.  Since you are emulating a SPI bus, this should not be an issue.