Expand VISA "Bytes at port" to apply to all valid VISA connection types

[Mark_Yedinak]

Currently the "Bytes at port" property only applies to serial ports. If you are trying to write a generic driver or communications package that supports multiple connection types you cannot use the "bytes at port" since it will not work for anything but a serial connection. There is a related idea here which proposes the "Bytes at port" can be added to the event structure. It also suggests that this be expanded to other connection types. My idea suggests that at a minimum the VISA property node can be expanded.

[Dennis_Knutson]

Don't see how this would be possible or even necessary. The VISA Bytes at Serial Port is reading a buffer on he pc. Buffers that don't exist for GPIB, VXI-11, USBTMC. And GPIB, VXI-11, USBTMC are well behaved in that they only send data when requested - as the result of a '?' query and are always terminated so you can specify a large, arbitrary number of byres to read. What VISA connections besides serial are you using that don't follow the rules?

[Mark_Yedinak]

Dennis, not everyone is communicating with instruments. The vast majority of my work is with devices that are not instruments and are capable of sending asynchronous messages. I communicate or raw USB, serial, parallel, and TCP. I very rarely use GPIB or traditional instrument interfaces. Since the devices I work with can have any combination of the above interfaces I would like to have a generic communication method that works for all interfaces and works in a similar manner. We had originally wrapped the VISA stuff up in a dqGOOP class to provide a generic interface. We have since abandoned that in are using LVOOP now. We have added BlueTooth communications and have switch to using the native TCP primitives. However, it would be useful if we could know how many bytes are available when reading. It would be even better if we had the events to let us know when data is available as proposed in the other idea. That way we could avoid using polling methods when waiting for asynchronous messages and use an event driven architecture.

[Dennis_Knutson]

But what buffer on the pc do you think you can read that will tell you how many bytes are there? For all protocols other than serial, only the sender would know how many bytes it has sent or is about to send. I agree that the information would be nice to have but I just don't see any way to obtain it.

[Brian_Powell]

One approach would be to write some sort of daemon that services and buffers all of the ports (serial, GPIB, LAN, etc.) that you're interested in.  You then query the daemon instead of VISA for how much data is available to be read.  The OS is essentially doing this for serial ports, since hardware FIFOs are typically only a few bytes on an RS-232 port.

I'd write this as a LV class that spawned new "listeners" for each port when you opened them.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.