LabVIEW
Visa Resource Name in cluster passed to Network Stream writer causes error 42.
Solved!
If I try and pass this "motor data" cluster with an embedded VISA resource name:
to a Network Stream Writer in this manner:
Then I get this error from the "Write Single Element to Stream" VI
If I change the motor data cluster TypDef so that a string control is used instead of the VISA reference, the error disappears and the data passes over the Network Stream without problem.
Is this expected behavior?
I thought that the "data in" (type = "POLY"?) like the one found on the "Write Single Element to Stream" VI was supposed to accept pretty much anything...
@Doug-W wrote:
Hi WNM,
This is Doug from Applications Engineering. Are you trying to send the text portion of the VISA resource name or are you trying to send the memory location of the VISA resource name? When you pass the embedded VISA resource name you are passing a memory address and not simply the string VISA resource name (e.g. ASRL::INSR).
Regards
Doug W
All I'm trying to pass is the text information, and only passing the text information as a string is how I delt with the problem.
My point is that this is the first instance that I have experienced, where the use of the real VISA reference control , has produced an error that did not occur when a similar string control
was used instead. I cannot imagine why anyone would want or even try to pass the memory address portion of a reference over a network stream so perhaps the network stream writer should, at some future time, be made smarter in how it handles this type of object and rather than returning an error, just go ahead and pass the text information and ignore the memory reference data. Other VIs in the library already have this intelligence and so should this VI.
Doug
I would consider this a bug, as the memory location (more precisely the VISA refnum or session) of a VISA resource means nothing on a potentially remote system. Also I was under the impression that most streaming methods like binary file IO, but also the network streams would use the LabVIEW flattened format for data clusters and for that the VISA resource name would be the only logical choice instead of the underlaying VISA refnum, but I might be wrong in this specific case and the default behaviour for flattening VISA resources might always have been to the VISA refnum.
Considering that the VISA control can resurect the VISA session from a VISA resource name if it is already opened, flattening to the VISA resource name instead would be more logical, but using a string control in the cluster type definition is a reasonable work around of course.
