LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

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

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
5 Comments
Knight of NI

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?

Trusted Enthusiast

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Knight of NI

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.

Active Participant

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.

 

Example Gatekeeper
Status changed to: Declined

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

DNatt, LV R&D