Jump to content

TB_TestDev

Members
  • Posts

    4
  • Joined

  • Last visited

TB_TestDev's Achievements

Newbie

Newbie (1/4)

0

Reputation

  1. I think I have resolved this issue on my own. The root cause ended up being an intermittent network switch. It seems that if the TC-32 is connected to a network that momentarily disconnects, it remains "locked", perhaps waiting on a lost acknowledgement from the network, and is therefore "in use by another process" and cannot be accessed with InstaCal or with the LABVIEW ULx libraries. I do not know how long the TC 32 stays locked out like this, but during testing I observed that it's at least 30-45 seconds from the time the network momentarily goes down to the time that it remains "in use by another process". Interestingly enough, momentarily disconnecting the cable from the TC-32 to the switch does not cause the same error, so the disconnect has to happen at the switch itself. Resolving our intermittent network connection at the switch fixed this issue for us, so if anyone else has this issue, I'd suggest checking your network hardware.
  2. Hmm, the link you sent seems to be more for network drives and their "local device names", but I will try to look around and see if anything else similar pops up! I don't think the problem is the TC-32, we swapped it out for another one and got the same error. I've tried giving the TC-32 a unique connection code, and I also uninstalled Instacal and re-installed a fresh copy, in case that version was somehow corrupted. The issue is very intermittent, so we will see if either of those things fixed it. Do you think a faulty network switch or ethernet cables could cause this issue?
  3. Thank you for your reply! Just to clarify, we are not trying to open InstaCal while our LABVIEW program is running. The error happens while the Labview program is running, and no one is opening InstaCal or using the PC at all. The error also occurred once while configuring the device with InstaCal, while the LABVIEW code was not running. I was unable to access the device, even though nothing else was running on the PC, it still said "Network device already in use by another process." Even though everything else was closed. Could an instance of InstaCal be opening in the background, undetected by Windows Task manager? I'll also look into the unique connection code. Thank you!
  4. Hi All, This may also belong in the Labview forum, but I figured I should start here, since I think the issue is outside of Labview. We have a TC-32 that we are using in an automated test system, being run by a Labview application. Our application keeps crashing intermittently and we get the following error message: Error 1024 occurred at Measurement.lvlibp:ULx Read (Analog 1D DBL NChan 1Samp).vi Possible reason(s): Network device already in use by another process. This happens very intermittently, and no one is opening Instacal or doing anything on the computer when this happens. I was poking around in Instacal to check config settings and test the TC32, when all of a sudden it stopped responding, and Instacal displayed the same error message: "Network device already in use by another process." I closed Instacal, but the "Activity" light on the TC32 remained on, as if it was still talking to something. When I reopened, Instacal, I could no longer talk to the device, and kept getting the same error message: "Network device already in use by another process." Power cycled everything, and it went back to normal, but I can't help but feel that it was the same issue that's causing our application to crash. The TC32 is on a local network with a few other instruments and a PC that runs the application. Everything on the local network has static IP addresses, so shouldn't be any issues with something "stealing" the IP address of the TC32. Does anyone know what other process could be talking to the TC32 and interrupting comms? Can anything other than Instacal and the Labview ULx libraries talk to these instruments? Any ideas on what I could try next to make these comms issues stop? Like I said, the issue is very intermittent, so very hard to debug. Thank You!
×
×
  • Create New...