I have a few questions that may help us get to the bottom of this:
So what all changes from when your code works to when it doesn't? Does it work the first time and then not subsequent times? What is your code accomplishing, it is possible that it is not in the proper state to receive and acknowledge the address bits. What do you do to make it start working again?
Thank you for your reply.
Basically the code is to read information from smart battery. I need to get battery charging status, battery chemistry etc. LabVIEW code is standalone and I revise it from I2C read script example. I press "Run" button to run the code. Running may be OK at first time. When I press "Run" button second time, it is most likely that I get the error, I press "Run" button one more time, it may or may not be OK. Continue pressing "Run" button sometimes it is OK, sometimes it not. But if I press "Run" button too fast between the two running, chance to get error is much high. I did not change anything in the hardware and even I did not unplug and replug the USB-8451 from computer. Sympotom to me is that I2C reading is unpredicable.
What do you mean by "it is not in the proper state to receive and acknowledge the address bits". Do you mean the smart battery (SMBus device) is not ready? How could I make it ready or how could I detect it in which mode master or slave?
I am having a similar problem while trying to communicate with SMBus devices using the NI USB-8451. It works fine when communicating with I2C devices, but when I try to communicate with an SMBus device, I get the same error that Jason described. However, I have never been successful in communicating with the device using the NI hardware - the connection is not even intermittent. There is a set of hardware and software that came with the SMBus device, which seems to work fine, so the SMBus device is not damaged. Has a solution to this problem been proposed?
There are still issues with using the USB-8451 with SMBus devices at 100KHz. Currently the only work around is to use the device at a slower baudrate. Like Dirk mentioned, this is due to the low time spec being violated when running at 100KHz.