01-05-2012 08:44 AM
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
01-05-2012 10:10 AM
Make sure you program isn't continually opening up instances without closing them when done.
01-06-2012 08:12 AM
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.
01-06-2012 11:22 AM
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.
01-06-2012 12:31 PM
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
01-06-2012 02:35 PM
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
01-06-2012 02:54 PM
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.
01-09-2012 01:34 PM - edited 01-09-2012 01:35 PM
@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.
01-09-2012 01:36 PM
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
01-09-2012 02:38 PM
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?