control MCP41XXX digital poti over SPI with DAQ PCI 6220

[JimPanse]

hello,

I try with the DAQ card PCI 6220 via the digital outputs LINE0: 2 (CS, SCK, SI), the digital potentiometer MCP 41XXX over the SPI interface to control. Unfortunately this does not work. I have a Vi to created the digital signals (picture) and another Vi to output (picture) them on the DAQ card. Phase and polarity of the SCK clock can I change. Unfortunately, the potentiometer can not be controlled with this program. Has anyone a Idea where the problem might be?
 

Thanks

 

JimPanse

[hooovahh]

Wow I always wondered if I could use a series of DIO lines to make a SPI device.  You haven't confirmed the fact that you can or can't yet but it is interesting.

 

What is wrong with using a cheap USB to SPI device?  NI does sell their USB-8451 which is a SPI device and works quite well.  Of course a much cheaper option would be an Arduino Uno and the LIFA Toolkit which has a palette for doing SPI or I2C.  I've used both of these for SPI communication and never had a problem.

[JimPanse]

Hello hooovahh,

Thanks for your reply. I use the DAQ card because it is there. I have found no reason why it should not go with the DAQ card.

If it does not work I'm going to implement the Arduino.

Unfortunately, the question remains as to why the current approach is not working.

[ned]

I don't know what's wrong with your code, but for comparison purposes, others have implemented SPI using a DAQ card:

http://www.ni.com/example/31163/en/

http://forums.ni.com/t5/Digital-I-O/Implementing-I2C-or-SPI-with-Pxi6508-in-Labview/td-p/554383 (scroll through the thread a bit)

[mje]

What is wrong with using a cheap USB to SPI device? NI does sell their USB-8451 which is a SPI device and works quite well.

We have about a dozen of those devices. While neat and good for simple SPI stuff, we have found them rather limiting. For most applications we end up with some horrible hacks and software timing to overcome limitations in the NI SPI API, or at least the parts of the API that that device allows you to use.

[hooovahh]

What limitations are you referring to?  And how did you get around them?  I have only used these devices (and the Arduino SPI) on very simple slow devices for getting voltage readings, so maybe my application didn't see the limit you did.

[mje]

I'm running off memory here on a project I last touched about a year and a half ago, so things are a little bit rusty. There is a thread though regarding the issues I came up against.

 

The limitation that word lengths are limited to 8 bits and every word is a discreet set of clock pulses is a potential deal breaker, though it didn't affect me in the end. If you're pushing/pulling registers larger than 8-bits you need to combine discreet transfers which may introduce issues depending on the timing strictness of the device is on the other end.

 

My biggest beef with the devices is they locked out the lowest level palette which in theory could do most of I wanted. Since I had a dozen of these things, I instead had to so some really ugly software triggering which I would never want to push into a production environment. Even if the low-level palette was unlocked it still has limitations on frame length which seem rather arbitrary to me and I question if I could have been successful with their other 8452 option.

 

What I learned from working with those devices is they are really only useful for very simple operations. SPI is a low level protocol, so I expect to be able to configure the hell out of it. The NI API just isn't flexible enough, or if it is isn't documented well enough. The next time I need SPI, I'll be going down to the FPGA level (or perhaps another vendor).

 

PS: Sorry for the highjack. I have no recommendations for your issue, Jim.