LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-8451 I2C communicating very slowly on some computers

Hello Everyone!

 

I am having some strange issues with the USB-8451. I wrote a program to communicate with 5 slave devices over I2C, a relatively small amount of data is being transferred and under normal operation it takes about 30-40 ms to communicate with each one. I am trying to collect data at 1Hz so this is easily achievable.

 

I have 3 test computers (2 laptops and 1 PC) that need to run the software and at first they all ran just fine.Then one of the laptops started running slowly, all packets arrived, all data comes through perfectly but it takes ~1600 ms to communicate with each board, pushing me WAY above my 1000 ms threshold. I could not diagnose the problem so I switched to the other laptop and it worked fine, but now it's doing the same thing. Again, they communicate just fine and all the data is correct, it's just very slow.

 

So far the testing PC and my development machine have yet to see the problem.

 

I have replaced the cables, replaced the slave devices, shortened the wires, put the USB-8451 on a powered USB hub, tried all three USB-8451s that I have, re-installed drivers, rebooted the computer, went through troubleshooting in MAX and still the exact same problem.

 

Has anyone else had a similar problem? Any help would be greatly appreciated, Thank you!

 

-Aaron

0 Kudos
Message 1 of 17
(3,144 Views)

Make sure you program isn't continually opening up instances without closing them when done.

0 Kudos
Message 2 of 17
(3,133 Views)

 


thouston@iccnexergy.com wrote:

Make sure you program isn't continually opening up instances without closing them when done.


It's not, that was a problem I had a while back but it has been long since fixed so I'm pretty sure that's not what's causing the slow-up.

 

Again, it worked fine on all the computers when I first installed the program but at some point it just starts working slower. If there were opened instances I would expect it to slow down consistently, and also not right away but after the program has been running for a while.

0 Kudos
Message 3 of 17
(3,122 Views)

Aaron,

 

Can you look at some of the timings in the program you wrote? Perhaps attach the program, and indicate which functions are taking a long time to run?

 

Also, you said that you tried restarting the computers. After the restarts, did the program work fine for some time and then start slowing down? This would be an indication of a memory leak somewhere. It would be useful if you could attach your code (screenshot or VIs), or give a better description of the VIs that you are using. 

Colden
0 Kudos
Message 4 of 17
(3,112 Views)

I have attached a screenshot of the VI that is operating slowly. When it is working normally it takes around 40ms to run, when it is not working it takes about 1600ms to run.

 

Once a computer has "starting being slow" it will always be slow, and to the same degree. Even after a restart. The VIs are not slowing over time. Before the slow down this program has run for days and still achieved the ~40ms run time. Once they have become slow they will always be ~1600ms from the minute they turn on, and every time after that.

 

I have one of the disfunctional computers sitting next to my development PC. I have put the exact same executable on both machines. If I plug the USB cable coming from the USB-8451 into my development PC it works fine. Without changing any hardware, or cycling power if I plug it into the laptop it works slow. And back and forth, fast and slow. It's very strange.

 

Thanks for your help so far, maybe this screenshot will help.

 

-Aaron

0 Kudos
Message 5 of 17
(3,094 Views)

Hi Aaron,

 

Based on that screenshot you posted, it seems to me that you're using code that's very similar to the "General I2C Read Script.vi" example that ships with the LabVIEW 845x driver, which you can find in Help>>Find Examples by searching for I2C. However, you don't have an error handler enabled at the end of your code, unlike in the example. I would make sure that you're monitoring for errors, as there may be some sort of timeout that is occurring that you're missing. 

 

Also, you mention that you've built this into an executable. Do you see the problem when running the VIs that the executable are built from, or just the executable itself?

 

Best,

Dan N

Applications Engineer

National Instruments 

0 Kudos
Message 6 of 17
(3,080 Views)

Just a thought....Where did you get your drivers.  The ones on the DVD are out of date.  The latest drivers are on the website.  Maybe you have some funky old drivers.

0 Kudos
Message 7 of 17
(3,074 Views)

@Dan N wrote:

Hi Aaron,

 

Based on that screenshot you posted, it seems to me that you're using code that's very similar to the "General I2C Read Script.vi" example that ships with the LabVIEW 845x driver, which you can find in Help>>Find Examples by searching for I2C. However, you don't have an error handler enabled at the end of your code, unlike in the example. I would make sure that you're monitoring for errors, as there may be some sort of timeout that is occurring that you're missing. 

 

Also, you mention that you've built this into an executable. Do you see the problem when running the VIs that the executable are built from, or just the executable itself?

 

Best,

Dan N

Applications Engineer

National Instruments 


 

The VI screenshot I posted is a VI that goes into a larger program and there errors are handled there. The VI does not generate any errors when running.

 

Unfortunately I cannot test whether or not the problem occurs ONLY from an executable since I have not seen the slowing on my development PC. The two laptops have seen the problem with the executable but I do not have LabVIEW liscences on those machines so I cannot run the VIs directly. 

 

Out of curiosity I hooked up an oscilloscope to the clock and data lines and compared the results on a working machine and on a slow machine. Both seem to work identically except the lengths of time between the clock signals going out is longer. It's almost like the USB-8451 is doing some "warm up" of some kind before sending out the clock pulses:

 

Just to be clear what I mean, say I want to talk to 5 devices. This is what I see on the oscilloscope:

 

Working PC:  |||||____||||||_____|||||_____|||||____|||||___________________________________________________________

Slow PC:       |||||_________________|||||_________________|||||_________________|||||__________________|||||________

NOTE: the "||||" are bundles of clock pulses

 

So you see that the clock period isnt slowing down at all, but the time between communications is what's slowing down and I'm not sure why.

0 Kudos
Message 8 of 17
(3,047 Views)

thouston@iccnexergy.com wrote:

Just a thought....Where did you get your drivers.  The ones on the DVD are out of date.  The latest drivers are on the website.  Maybe you have some funky old drivers.


First I tried uninstalling and reinstalling all the LabVIEW related drivers that were on the test computers and that didn't help. So I tried updating them to the latest versions I could find online, but still no improvement.

 

-Aaron

0 Kudos
Message 9 of 17
(3,044 Views)

In situations like this I try not to jump to any conclusions about what the problem is.  Can you replace the 8451 calls with dummy VI's and run the program to make sure something else isn't causing the problem?

0 Kudos
Message 10 of 17
(3,037 Views)