I2C pressure sensor with Labview and U6

I am not able to open your VI, but I do see a couple potential issues in the block diagram screenshots. The first is that the IO lines are set to 0 and 1. We recommend using EIO for serial communication because it has less impedance. The second issue is that the speed is set to zero, it is usually a good idea to start with the clock speed set low and the raise it after everything is working. 10 kHz is a good starting place. The lower clock speed may also help when using FIO lines.

Also, have a look at our I2C app-note. It contains a lot of good advise that will help you avoid common I2C pitfalls. The acknowledgement reporting may be useful.

If that doesn't help we may need an oscilloscope or logic analyzer. 

Did you check the acknowledgements (LJ_chI2C_GET_ACKS)?

That will tell you if the slave device is respond at all. If not problems are likely hardware or the address value. If it is responding to its address then our problem is in the usage of the slave device.

The Acks is good news. That means that both the address and the command byte were acknowledged.

Looking at the VI diagram, I think we need to move GET_ACKS to a separate call after the the add-go-get that runs LJ_chI2C_WRITE and LJ_chI2C_READ. The driver might be correcting that for us, but I am not sure.

If that doesn't help we can try the compatibility options. Try changing the options byte to:

1. LJ_chI2C_OPTIONS = 4 - Changes the way the bus is switched from write to read
2. LJ_chI2C_OPTIONS = 8 - Enables clock stretching, which allow a slave device to delay the clock signal if it needs more processing time.
3. LJ_chI2C_OPTIONS = 12 - Uses both of the above options.

1) Every transmitted byte is represented by a bit in the ACK array. A 3 in binary is 0b00000011, which would mean that two bytes were acknowledged.

"If Get_Acks is not a seperate call..." The Get_Acks was between the transmit and receive operations. So, I think the request to read ACKs was terminating the I2C operation before the reads could run. Separating out the read and write operations would would because that would run two separate I2C operations one to write and one to read. 

2) The U6 can run multiple I2C buses. The only limitation is that only one can be actively clocking at any give time.

Hi , 

I know this post is very old but I have a quick question about sending commands to I2C Slave using LabJack U6.

I want to control an STM32F10X MicroController using I2C through LabJack. Im able to connect to this chip using arduino Wire.h.

In arduino, we have the option of sending strings as commands to the I2C slave. How do I send string commands like *IDN? to I2C slave through LabJack.  Do I have to treat each character as a byte, convert to dec and send it?

Also, Is there a way to scan for list of all connected I2C devices without mentioning the address?

Any help woul be greatly appreciated.

Thank you

Hello,

I believe we talked over chat, but I wanted to follow up here in case it is useful for anyone else.

You will need to send the string as an array of bytes. I would recommend explicitly converting your characters to decimal or hex representations of the associated ASCII values before sending out your command.

I do not think we have anything explicitly implemented for the U6 that will scan for valid I2C devices, but one thing you could do is iterate through a range of potential addresses and try a dummy read/write and check for ACKS for each address. You could probably set that up pretty easily with Read_GetAcks_and_Write.vi