Showing results for 
Search instead for 
Did you mean: 

I2C NI-845x Read VI returning incorrect data

Go to solution

I am using I2C Basic VIs in the VI attached (version 15.0) in LabVIEW 15 to send a command to a TI bq20z75. There are a couple of commands to tell the device to send back particular data for example current or status. Most of them work fine, but if I try to send anything above 0x4F the bytes I read back from the Read vi aren't correct. The read VI returns the same bytes from the last succesful command. It doesn't throw an error.

I tried to put a wait between the write and read but that didn't work. I changed the initialization settings but that hasn't helped. The software that ships with the TI device can query these commands without an issue.

Has anyone seen this before or have an idea what can be causing this problem?

0 Kudos
Message 1 of 7

I am not familiar with the TI bq20z75, but are you trying to send the commands listed here: ?


If that is the case, then is it correct that 0x45, 0x46, 0x4f are all responding correctly, but any of the commands further down the list are not?


How are you communicating to the bq20z75 with LabVIEW?  From the VI, it looks like you have a 845x device.  It looks like the bq20z75 uses SMBus, have you seen this TI paper: ?


The comparison between what commands you can send from your computer via the TI software and what you can send via LabVIEW through the 845x device may not be equal comparisons, because I am guessing the method of connecting to the device is different and communication may be slightly different as well.

Message 2 of 7

Thanks for the information.

You are correct that that is the list of commands.

So you are thinking the issue is that I am trying to communicate with an SMBus Device using I2C?

The document you linked to discussing the differences between SMBus and I2C mentioned that the ACK timeout for SMBus is 35 ms. Is that settable through the NI-845x I2C Configuration "AckPollTimeout" property?

I'll have to make sure I have Packet Error Checking disabled on the device.

The document also said this will work "unless the SMBus master’s software is dedicated only to SMBus protocols." I'm not sure about this particular device.

0 Kudos
Message 3 of 7

I think the issue could be in the SMBus I2C combo, but I am not certain.  You should be able to use the AckPollTimeout property to set that to the correct timeout interval.  This may be something worth checking with TI to see if it is even possible to communicate with this chip over I2C

0 Kudos
Message 4 of 7

Thanks for the help. It does look like there is some detail I'm missing when trying to communicate with this device.

0 Kudos
Message 5 of 7
Accepted by Ian_Rice

We found a solution to the problem. Using I2C Write.Vi followed by I2C Read.VI did not work. However using I2C Write Read.VI did work. Can anyone explain the difference between these two methods or post code so that using the Write followed by the Read acts the same as the Write Read?



Message 6 of 7

glad to hear you were able to get it working.  If you right-click on the VI in the block diagram and click help, you will get more information on the VI.  You can also find it here:


more about the actual protocol:


it sounds like the difference in the combined format is that the master doesn't set the stop condition, but repeats the start condition and sends the slave address again and the rest of a normal transmission

0 Kudos
Message 7 of 7