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!
cancel
Showing results for 
Search instead for 
Did you mean: 

Add the option to have a true blocking write for VISA

Status: Declined

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

Currently the synchronous and asynchronous modes of writing data have little to no effect when communication over TCP. The write will return immediately after buffering the data to be written. However, the data it self may take considerable time to actually be written to the network. Absent some type of hand shaking at the application level there is no way for an application to wait until all the data has actually been written. The native LabVIEW TCP Write behaves in the same manner as the VISA write. Given this behavior it is impossible to implement a well behaved write queue for queuing up and transmitting data to a device. For example a normal print queue will open a connection and send the data to the printer. It will not attempt to open a second connection for the next print job until the first one has consumed all of the data. If a large amount of data is being written it can take time for all of it to be transmitted. The way the VISA or TCP write VIs behave the print queue would open a connection and write the data. However the call to the write would return immediately because the lower level network stack has accepted the data and buffered it. The print queue then believes the first job is complete and begins processing the second job. This will mean that a second connection will be opened. Some devices will allow multiple connections and some do not. However without the ability to actually wait for the data to be completely written the queue would have to continually try to open connections. This would be unnecessary network traffic and and unnecessary communication with the printer.

 

I would like to see an open on the write VIs to allow for a true blocking write. The write will not return until the data has truly been transmitted. The current behavior is also valid and can be retained.

 

Note: I have not tested the behavior on other types of interfaces so I am not sure if this is a TCP only issue.



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
1 Comment
Proven Zealot
Status changed to: Declined

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

DNatt, NI