I've been helping develop a large application that has a 4-20mA output component. Communication to an external digital to analog output converter module is done through a serial port, and a USB to RS-485 adapter is being used between the USB port and the output module.
Multiple versions of the application have been tested, and this error keeps on coming up only with the most recent one. Even more strange, the error seems to come up only after the application has been running for a few hours; there is no set interval a which the error pops up after. The only additions to the most recent version are isolated in the initialization frames of the code and an event structure; I can't see how any of these additions would affect the 4-20mA output component of the code.
Only one command is being sent to the output module at a time, and this occurs on average every 30 seconds. The current timeout parameter for the Configure Serial Port.vi is set at 10 seconds.
Also, I personally can't get this error to appear while running the software, as an executable, on the development computer I have access to; It's coming up at a set-up at another location. As far as I know, this set-up's computer is a clone of the development computer, but I do know the output converter module is slightly different than the one I have at my setup. However, I accounted for this different model in my code, and since it runs properly for 12 or so hours with this module, I would think that the commands I'm sending to the module are correct.
Attached is a screen shot of the vi that I have doing the VISA communication. I'm not terribly experienced at instrument control programming, and I basically took most of this code from a LabVIEW example; it's been working up to this point so I haven't paid much attention to it.
If anybody has any idea what might be going on, and how I may fix it, your advice would be greatly appreciated.
try to open the serial port only the first time you need the port and keep it open until your program no longer needs the port and then close it.
I've seen things like this happening at opening and closing a lot.
PS use cleanup to straighten your wires. A png is almost unreadable this way.
Were you ever able to find out what exactly is causing this occur? I am experiencing a similar issue with an oven using VISA GPIB control. Programmatically I can find no errors, but after the routine runs for hours (at least 5 is the minimum I've had the issue), the GPIB bus literally "hangs" up, and requires a hard reset (no programmatical work around available), and I lose hours of cummulative test data.
This may happen when some resources are allocated (such as creating a DAQmx task, or opening a communication channel), and never deallocated. As the systems runs short of memory, it may slow considerably down.
Just trying to guess...
Are you receiving any error messages (such as those in the original post) when this happens? If you are, this behavior could also be happening if the GPIB I/O Timeout setting in Measurement & Automation Explorer (MAX) is set too low. It may currently be set high enough to get by for some time, but a certain GPIB command response may not be responding quickly enough, at some point in the sequence. This setting can be changed by running MAX as an administrator (right click on Measurement & Automation and select "Run as Administrator"). Once MAX is open, on the left hand side, expand the "Devices and Interfaces" section. Select your GPIB device to display the "GPIB Interface Properties". In here, try changing the "I/O Timeout" value to something larger and see if you continue to get the same error.
Some other possible causes are available in this KB:
If you are not receiving errors, what is the exact behavior of the application? Programatically, you can close and re-open a GPIB/VISA session. The reason that it works after restarting is because it forces the connection to close, freeing the resource. If an application hangs, before the resource is released, it can not be accessed again until it is closed. One thing you can try would be to add a VISA close before the VISA open, in order to make sure the resource is available, and not being used in a previously failed connection. This should allow you to re-establish the connection, without having to hard reset.
Yes, but the error message received (Error - 1073807339) happens because the device I am communicating with literally locks up, and a hard reset (power cycle) is the only way of resetting the GPIB interface to this device. Today, I received confirmation from the vendor that the problem can be duplicated at their facility, and it sounds like the issue is with their controller.