NI-1744 Smart Cameras go offline using Vision Builder AI and LV2010?

[Brad]

Is there any possibility the network goes offline sporadically, or power saving IT programs may put your machine to sleep at night, which may turn off network activity or something like that? Do you currently have the smart cameras connected to your corporate network or on a local hub?

[Kevin_R]

---

@Brad wrote:

Is there any possibility the network goes offline sporadically, or power saving IT programs may put your machine to sleep at night, which may turn off network activity or something like that? Do you currently have the smart cameras connected to your corporate network or on a local hub?

---

I have wondered myself if the problem could be network related.

The cameras are on a private network set aside for the system automation.

Every workstation involved in the project has two network adapters, one for the corporate network, and one for the 172.16.x.x private network. It's a mixture of Windows 7 and Windows XP machines running LV 2010 and LV 7.11, respectively; I'm in the process of replacing all the older XP machines now. (There is another thread in the forums about the DSC issues I had to solve for the LV 7.11 DSCEngine and the LV2010 SVE to communicate successfully; that took about 9 months to solve and stabilize).

The private network does not have a DNS server; on the XP workstations I have a batch file to set up static addresses for automation, for some reason this does not always work on the Windows 7 workstations, but the network services appear able to find the cameras just fine.

We have observed some general disruption of our DSC data sharing when the corporate firewall software receives new definitions (a separate issue which I have taken up with our IT department), but the other symptoms that indicate that has happened were not present yesterday, nor was there any sign our private network had glitched.

There are currently 3 ethernet switches in place between the cameras and the workstation: one that fans out to the 6 cameras, which is cabled to the main 48 channel switch for the automation network, and a third between the workstation and that large switch (which will eventually go away when the LV2010 upgrade is complete). I haven't observed any other symptoms of problems with the switches, but the fanout switch is the oldest of the set.

It sounds like you're suggesting a network glitch could leave a sort of "zombie" session going in the camera, so the LV 2010 VBAI functions can't reestablish contact? Is there a reliable way to automate resetting such a problem (as opposed to manually having to stop LV, reboot the cameras, and then restart LV)?

[Brad]

When you get in this bad state, can you see if there are any VBAI API Interface.exe processes running on the computer (check Task Manager). There shouldn't be if you have closed the session. Try closing the session if you get into this bad state, killing any VBAI API Interface.exe left running from Task Manager, and then see if you can connect in LV without errors. I'll see if I can reproduce something similar here by temporarily unplugging a target's network cable and see what happens.

Thanks,

Brad

[Kevin_R]

As bad (or good) luck would have it, I found one of the cameras offline right after reading your post.

When I opened Task Manager, I found tens of copies of the VBAI interface running! Apparently I messed up my persistent session code and it was spawning new sessions over and over again. No wonder my monitor VI was crashing occasionally.

When I shut down the VI, eventually all the spawned sessions disappeared from TM without any intervention on my part. I did have to reboot the one camera to get it to connect to LabVIEW again, however. (The VB inspection and configuration interfaces could connect without any difficulty before rebooting).

[Kevin_R]

OK, I am clearly missing some basic concept for closing and re-establishing VBAI sessions.

One camera was offline this morning (sigh), so I tried using my revamped code to re-establish communications. I had the Task Manager open while doing so. The 6 (expected) instances of the VBAI API Interface did not shut down, and another batch started. I stopped my main VI, waited for the sessions to cancel, reinitialized to default and tried again.

The stuck camera was still offline, and by the time I got things stopped, nearly 250 instances of the VBAI API Interface were listed in the Task Manager! CPU was at 100%, LabVIEW crashed, and it took a good 10 minutes to get the excess tasks to clear up.

I used the VB AI 2010 configuration/inspection software to reboot the 1 camera, waited until it loaded, restarted LabVIEW and started my VI. It's now running properly again.