Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Using I2C or SPI communication with cRIO and NI 9403 Module and Scan Engine

geashby,

 

I doubt it has been tested, actually. Which makes me hesitant to make any reccomendations. I would suggest using the USB-8452 instead.

0 Kudos
Message 11 of 14
(4,848 Views)

Now there are two contradictory statements from NI Staff, it would be nice, if you worked it out, saying if it's is feasible or not.

0 Kudos
Message 12 of 14
(4,831 Views)

Hello Maloya,

 

As Kyle mentioned this has not been tested and therefore isn't the recommended way to go about it. I mentioned using SPI because that would allow you to avoid the problem of bidirectionality, but we can't guarantee success because it was not intended for that purpose. However if you think the data rates of the card are suitable (330 ns for the output to be stable means a maximum of ~3 MHz) it would be worth trying out SPI communication on your system. 

0 Kudos
Message 13 of 14
(4,813 Views)

So, the short version, I did get SPI communication working with the 9074 and 9403 module (though perhaps with the caveat of "I am not sure how fast you could do this at"). The long version is below in case it will help you.

 

Using my 9074, with a 9403 module for hardware.

Using this encoder for a test SPI slave: http://www.cui.com/product/resource/amt20.pdf

 (I also had to put a 10k pull down on the MISO channel, but this is likely hardware specific)

Using this example code: http://www.ni.com/example/9117/en/ (I used the "spi_single_port_example.zip")

 

I modified the "Configure I/O type..." as described in step 8, to correspond to my 9403 DIO pins.

I set the pins appropriately to input/output for each of my MISO, MOSI, Clock, and Slave select lines.

 

I had to change the single cycle timed loop in "FPGA_Top_Level_cRIO_Main.vi" to an untimed while loop, as the 9403 I/O is not supported within SCTLs.

 

I also removed the I/O which sets the "ready" light, as I had nothing connected to that pin.

 

Running the "FPGA_Top_Level_cRIO_Main.vi" instead of the host program (I could not get this working via the host program for some reason...), and leaving the "SPI configuration parameters" default, as they corresponded to my specific devices SPI configurations. (and I think SPI_Clock_Divider" =20 means 50 000 Hz communication).

 

I was able to communicate to my device. For each command I had to do the following: set SPI_Cmd to command, hit SPI_Start, (this should then put SPI_Cmd to idle), enter the DEC equiv of the specific HEX command I wanted to send in SPI_Write_Data, toggle the SPI_Write Flag to ON, switch SPI_Cmd to Read/write SPI, hit SPI_Start, this shold change the value of SPI Read Data, SPI_Read flag should go ON, then hit SPI_Ack Read, SPI cmd should go back to idle, repeat from the configuration step for your next command. This manual cycling through the different frames of the  SPI_cmd is obviously not a solution, but I presume that that is what the higher level host VI handles automatically.

 

Though through this manual operation, after sending the 5 or so read/writes required I was able to read the encoder, and all the speed requirement based steps were running at their speed presumably, but I have not verified that changing the SCTL to the presumably slower while loop. It could certainly effect your max communication speed, so don't hold me on this, but since the master is doing the communication clock output, you will still be able to read no matter what with these modifications, I just don't know what your max speed will be. With the 7us sampling speed (142857Hz) of the 9403, I would not try to exceed a communication speed of 70 kHz, as you need to be able to write high and low every cycle.

 

 

Edit:spelling fixes

Message 14 of 14
(4,798 Views)