LabVIEW
VISA Ethernet TCPIP (Socket) Termination Character
@BarnaCsenteri wrote:
I had the same issue. But never the less even if I switched it on, the plain TCPIP Visa raw socket does not appends anything (at least it is not visible in IO Trace).
This might be your issue! Raw sockets have absolutely nothing to do with IEEE 488.2. You need a TCP Instr session for this property to have any effect!
Changing behavior for TCP Raw is not really an option. TCP Raw means really raw. It doesn't add anything that is part of things like SCPI or IEEE 488.2 for a very specific reason. Doing so would make many existing software suddenly fail.
Raw means any byte you place on the line is transferred exactly as you specify. No special processing, handling, translation or whatever is performed. So if you absolutely want to use raw, you should not expect existing instrument drivers to simply work but have to possibly modify them. Those instrument drivers are tested with an instrument session and your fear of standard instrument session handling may be somewhat justified in case of some VXI devices and maybe even some obscure TCP devices, but I had generally not many problems with that (but have to admit that I only worked with a few VXI devices way back at the end of last century).
Also, if you use an USB interface and the device supports the USB T&M class (responding to the USB Instr session class in LabVIEW) your device is not a virtual serial device and VISA ASRL does not "kick" in. Instead it is an IEEE 488.2 compatible session and communicates over its own specific USB message protocol (which is mostly derived from the USB Mass Storage protocol class as far as low level communication goes and IEEE 488.2 processing on the higher level).
If your device instead implements a virtual serial port (USB-CDC or COMM class) it will be recognized and treated as a VISA ASRL port.
If it does not implement USB-CDC or USB-T&M you are in the VISA USB Raw world, which while possible to do in VISA, is nowadays in almost all cases a dead end since you not only run into the problem of having to dig up the USB low level protocol specification for your device (which most manufacturers will rather have their arm hacked off than giving that spec out) but also additional issues with driver signing requirements for all but very old OSes.
@rolfk wrote:
Those instrument drivers are tested with an instrument session and your fear of standard instrument session handling may be somewhat justified in case of some VXI devices and maybe even some obscure TCP devices, but I had generally not many problems with that (but have to admit that I only worked with a few VXI devices way back at the end of last century).
I use TCP for instrument communications whenever possible. GPIB is expensive and I don't trust USB (I've had random disconnects and resource names change on reconnection). Of all the devices I have had to communicate with, I think only 1 needed to use the raw TCP class (I'd have to really dig to figure out what the device it was). Granted, I have my own special SCPI library that appends the Carriage Return before sending out the message.
Well VXI, while not completely dead, is factually since many years on extended life support. New development is nearly non existent, and any investment in existing drivers is definitely seen as a case of throwing money out of the window, unless you work in some very specialistic field. The hardware being close to custom made in terms of numbers sold, makes it both extremely expensive and also difficult to justify any further investment beyond trying to maintain the necessary supply chain to still be able to produce them.
USB enumeration and power management issues is something that VISA can't change. It is part of the OS plug and pray technology and something you have to learn to live with and to some extend you can manage it.
Asynchronous I/O may seem like the perfect solution to solve all your large application difficulties but in most situations it is indeed a recipe for failure. I have used it and have been able to make it work in some specific situations but it is much much more tricky than just plopping down a few LabVIEW nodes and hope to be done with. The typical approach of blindly setting everything to asynchronous and massively launch everything in parallel is for sure going to get into nasty blocking situations. But in most cases asynchronous I/O can be avoided by smartly using the synchronous VISA I/O operations to communicate with a device. For instance if you use serial, it is much much more efficient and safe to simply use the Bytes at Serial Port property to check that there is actually some data to read (but never ever use that value to decide how much you need to read unless you want to start doing your own data caching layer in your instrument driver)!
Also your expectations about instrument drivers may be slightly to high. They are in my experience very rarely ready made plug and play solutions but often need some extra functionality or tweaking to be applicable for a specific situation. Some even do not deserve the name instrument driver, but that is usually from more obscure instrument manufacturers, who put some summer vacation intern at a desk with a computer and an instrument and tell him to get going. I have many of such drivers more or less from the ground up rewritten and in quite a few cases not even used the provided "driver" as anything more than trying to gather some particularities about the usually badly documented device protocol.
VISA Asynchronous can work quite well when used from traditional programming languages such as C if you know how asynchronous programming works and that can help to make it work in LabVIEW too, but it is not as simple as changing VISA nodes to asynchronous operation and hope all is well. For most LabVIEW applications it is definitely more simple to not even try to use it.
@BarnaCsenteri wrote:
I might have high expectations but at least I expect to have a "hello world" example working when I get and expensive equipment without needing a tweak. But it seems this is still too high 🙂
A "hello world" application and asynchronous communication are pretty much at the opposite end of the programming learning curve!
