We are using a NI Smart Camera 1774C with Vision Builder 2011 SP1 on a PC with Windows 7 via Ethernet cable, at this stage only through the "Acquire Image - Sample" and not an inspection template (the software engineer isn't available for that). Every time I try to run the camera in continuous shooting I end up after less than a minute or two with a loss of communication and a "Error -1073774588 / 0xBFFF8004" message ... then Vision can't see the camera anymore and Windows Task Manager shows the network usage as being at 99% even if I unplug or turn off the camera. And when I go into the Windows Logs for applications I find a couple of messages in the likes of "LabView information : Error 404 Not Found for /national instruments/vision/vision builder ai/commserver , file c:/program files/national instruments/shared/ni webserver/www/national instruments/vision/vision builder ai/commserver , can't access URL", the only difference between the logs being whether the very last part is "commserver" or "4.2.0".
That problem also happens if I'm going for a single image or sometimes without even shooting at all. At first the camera was set on a dynamic IP, then I tried several static IP settings which one of our IT guys checked, and it never solved the problem. Sometimes the stability would get a bit better but ultimately it would "crash".
I had a bit of a browse on the forums and can't find a solution though some discussions are more or less related. Someone from NI support team was here recently, he had a quick look at it and we found out that when the camera was plugged to his laptop all was fine. He still couldn't understand why things didn't work with our computer though ... and I have tried all sorts of network settings with or without our internal network connected to the computer.
So I'm now desperate for some ideas. Is there an update for Labview or the camera which I need to do ? The software engineer loaded all the recent updates onto the computer a few days ago though ...
Solved! Go to Solution.
What is the speed of your netwrok card? I'm surprised to hear it's at 99% when the camera is unplugged. If you go to Task Manager, you will see the speed listed under the Networking tab. If your PC has a slow netwrok card (10/100M instead of 1G), upgrading to a better network card will likely solve the problem, although even if it says 1G, you may have 10/100M switches or routers between your PC and the camera that slow down the max transfer rates. Have you tried plugging your camera directly into your PC and using a static IP for both? If you try to acquire from Measurement & Automation Explorer do you get the same problem?
Sorry I've forgotten to mention the network usage jumps to 99% after the loss of coms, otherwise the camera only uses 1 - 2% in continuous shooting.
To answer your question the network card is a Gigabit one and I've checked, the drivers are up to date. I do not know how to see if anything is slowing it down but I'll try to have a look at it or ask IT.
Also I couldn't see any process in the Task Manager which would explain this 99% usage.
About your other questions, the camera is plugged directly to the computer via one of the 2 Ethernet cards (other one used for network) and as I've said I did try all possible IP settings for both computer and camera, with or without the network connected at the same time (our final system will require the network). The only change is the overall stability of the coms, it may take several minutes of continuous shooting before the problem occurs or I might not even have the time to do anything in Vision before it happens. So at this stage I have set the camera back to dynamic IP but will revert to static.
And I haven't try to use the camera through MAX so far, I will do so today if I get a chance.
Out of curiosity once the coms are crashed and both Vision and the 1774C are off, I tried closing all NI processes one by one in the Task Manager -> still 99% usage. So much for my little idea ...
About using MAX to capture images, the camera doesn't appear in the Remote Systems list, Network Devices, etc ... However when I open Vision I can connect to it and capture images (but as usual it does "crash"), and the camera appears in the NI Network Browser with the static IP I gave it. This is all making less and less sense to me ...
One thing a bit fishy is the fact the camera isn't updating its software from the 08/2011 to the 01/2012 version though the zipped folder is selected in the last Remote Target Config Wizard screen ... after a couple of unsuccesful tries that way I decided to also tick the "Format before installing" option, and I ended up with a formatted camera and no software installed ... right, after a couple more reboots of both computer and camera I FINALLY was given the possibility to install the software onto the camera (which was by default back to dynamic IP when the computer was still on static ... grrrrr !), this time I selected the 01/2012 version and I ended up with a lovely "Unable to install software onto target" kind of message ...
So I now have a "blank" camera on which the latest software cannot be installed. Someone with an idea before I go outside for a primal scream ?!?
OK so the final word seems to be that one of the 2 Intel Gigabit Ethernet controllers on the computer's motherboard doesn't like the camera. When using the port running on an Intel 82583V I experience what's described above, but when I use the other port with an Intel 82578DM everything's fine. The camera's software is now updated to the 01/2012 version and I haven't experienced any kind of "crash" when shooting in continuous mode for a good 10 minutes. So far so good.
The main difference between the 2 controllers seems to be on the Jumbo Frames support, whatever that means.
Thanks for updating the forum. It's helpful for others with the same problem to see the solution.
Jumbo Frames are packets that are greater than 1500 bytes in size. Support for Jumbo Frames is generally only provided by high performance ethernet cards since they will be communicating with devices that require a higher throughput.