Jump to content
Nishar Federer

Not able to receive data using VISA Serial

Recommended Posts

hi, 

I need to make an application , which has to send a  hexa decimal data from labview to the protocol via RS232.I have sent a single data block(1Byte) and i was able to receive the acknowledgement properly. 

But if i send a 9 bytes of Data through VISA via RS232, I am not getting any output at all , But if I send the same data block through different application, I am able to receive data . Can anyone suggest me way to resolve the issue or Better way to do this?? 

 

I have attached my vI with this  . I am struggling at this point for so long.

 

 

 

POC.vi

Share this post


Link to post
Share on other sites

Data communication via serial port (or any communication for that matter) takes time. The receiver must receive, process and reply to the data send by the sender. I suggest having a look at the examples in the Example Finder, they are well documented. Search for "Simple Serial" or just "Serial".

Your VI sends data and immediately reads however many "Bytes at port" are available. There is no delay between sending and reading:

no serial wait.png

Here I modified your implementation such that it waits up to one second for data to arrive:

serial wait.png

  • Like 1

Share this post


Link to post
Share on other sites

A few things need to be discussed here:

1. Does your message protocol have a Termination Character?  This is common for ASCII messages and is typically a Line Feed.  If you are using a binary message protocol or your message does not have a termination character, then you need to turn it off (boolean input at the top of Configure Serial Port).

2. If you know how many bytes you are to receive in a message, then tell the VISA Read to read that many bytes.  If the termination character is involved, then you tell it to read more than you expect and the termination character will stop the read.  Regardless, because you are using a command-response protocol (the instrument only sends you data when you request it) you should let the timeout tell you there is no data.

Share this post


Link to post
Share on other sites

Delete the "Bytes at Port" and rewire. Right click on the "Serial Read" and select "Synchronous I/O Mode>Synchronous" (the little clock in the corner of the Read icon will disappear). It will then block until the termination character is received and return all the bytes or timeout. This is the simplest way of getting up and running and you can look at asynchronous reading later if required.

  • Like 1

Share this post


Link to post
Share on other sites
7 hours ago, ShaunR said:

Delete the "Bytes at Port" and rewire. Right click on the "Serial Read" and select "Synchronous I/O Mode>Synchronous" (the little clock in the corner of the Read icon will disappear). It will then block until the termination character is received and return all the bytes or timeout. This is the simplest way of getting up and running and you can look at asynchronous reading later if required.

I don't necessarily disbelieve you (based on the posts I've seen of yours you do wayyy more instrument control than I do), but thats not how the help describes that switch: http://zone.ni.com/reference/en-XX/help/371361J-01/lvinstio/visa_read/ which indicates that this just changes how the execution system works rather than the logical behavior of the node.

Quote

Whether the data is read synchronously or asynchronously is platform-dependent. Right-click the node and select Synchronous I/O Mode»Synchronous from the shortcut menu to read data synchronously.

When you transfer data from or to a hardware driver synchronously, the calling thread is locked for the duration of the data transfer. Depending on the speed of the transfer, this can hinder other processes that require the calling thread. However, if an application requires that the data transfer as quickly as possible, performing the operation synchronously dedicates the calling thread exclusively to this operation.

note.gif Note  In most applications, synchronous calls are slightly faster when you are communicating with 4 or fewer instruments. Asynchronous operations result in a significantly faster application when you are communicating with 5 or more instruments. The LabVIEW default is asynchronous I/O.

 

Edited by smithd

Share this post


Link to post
Share on other sites
2 hours ago, smithd said:

I don't necessarily disbelieve you (based on the posts I've seen of yours you do wayyy more instrument control than I do), but thats not how the help describes that switch: http://zone.ni.com/reference/en-XX/help/371361J-01/lvinstio/visa_read/ which indicates that this just changes how the execution system works rather than the logical behavior of the node.

Choosing between Synchronous and Asynchronous

Quote

 

For a write operation the following sequence occurs:

  1. The calling thread is locked.
  2. Data associated with the VISA Write function is transferred from the ADE to VISA memory.
  3. Polling begins to determine when all the data associated with the VISA Write has been transferred out of VISA memory to the underlying driver for the hardware resource.
  4. The transfer completes.
  5. The VISA Write function returns.

The same sequence occurs, but in the reverse order, for read operations.

For synchronous operations, the calling thread is unlocked between steps 4 and 5 above. For asynchronous operations, the calling thread is unlocked between steps 2 and 3.

So synchronous is a blocking operation.

Share this post


Link to post
Share on other sites
14 hours ago, ShaunR said:

So synchronous is a blocking operation.

A thread-blocking operation.  Both options are blocking operations as far as the LabVIEW code is concerned.

Share this post


Link to post
Share on other sites
1 hour ago, drjdpowell said:

A thread-blocking operation.  Both options are blocking operations as far as the LabVIEW code is concerned.

In synchronous mode the function will return once the data has been received (or a timeout) by sitting in the polling state until the data has been received (the function is blocked). In asynchronous mode it will return almost immediately and not wait for the polling state (non-blocking). The threading is just the mechanism to achieve this so I don't know what you are trying to say with that statement.

Edited by ShaunR

Share this post


Link to post
Share on other sites

Sorry to the OP if this is going too far off topic but I wanted to run this test to help (maybe?) resolve the difference between async and sync

Setting async or sync here makes very little difference in how long VISA write takes. It always takes a little more than 1000ms.

 

 

sync vs async visa.png

Share this post


Link to post
Share on other sites

If I remember correctly the default buffer size is 4096, so even in async the function has to wait for the buffer to clear if the provided data is bigger than the buffer size. Does increasing the buffer size change the result?

Edited by LogMAN

Share this post


Link to post
Share on other sites
2 hours ago, infinitenothing said:

Sorry to the OP if this is going too far off topic but I wanted to run this test to help (maybe?) resolve the difference between async and sync

Setting async or sync here makes very little difference in how long VISA write takes. It always takes a little more than 1000ms.

 

 

sync vs async visa.png

It's the read you should be looking at ;)

Edited by ShaunR

Share this post


Link to post
Share on other sites

Here's my experiment with reading, writing, and setting a "right sized" buffer.

Now I'm getting 700 for the write, 300 for the "latency" regardless of if either is in sync or async mode

sync vs async visa read write.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By RMowatt
      I am experiencing numerous VISA Lock Errors (-1073807345) on resources I haven't explicitly locked.  This is happening on TCPIP connections to keysight N6700 power supplies and keysight N5242 PNA fairly regularly.
      I have simultaneous loops in the application communicating to the different instruments, using a sequencer of sorts to pipe commands one at a time to each of my various loops.
      Has anyone seen the locking error pop before while not actually using the Lock and Unlock VIs?  This issue has gotten worse lately and it has come time to find the root cause.  My only thoughts are that it may have something to do with having NI MAX and Keysight Connection Expert both installed and possibly trying to "ping" these devices.  Every once in a while me sending commands and these "pings" may clash and cause the locking error.
      Error reads as follows:
      "Specified type of lock cannot be obtained, or specified operation cannot be performed, because the resource is locked. VISA error code -1073807345 (0xBFFF000F)"
      We are using LabVIEW 2013
      Thanks in advance!
    • By Benoit
      Hey guys,
      Can you take a look at this?
      The only work around I found is to dynamically open the connection with an external VI to make it fail so the second time it works.
      If anyone has an instrument that communicate trough TCP-IP with VI, please try on your side with LabVIEW 2018 and visa 18.
      https://forums.ni.com/t5/LabVIEW/VISA-error-with-TCP-IP-BK-precision-2190E/m-p/3876316
      Thanks
    • By szewczak
      I wanted to cross post metux's discovery here asap, and have a separate discussion.
      Metux's original post:
      The recent Linux driver package introduces a CRITICAL security vulnerability:
       
      http://www.ni.com/download/ni-linux-device-drivers-2018/7664/en/
       
      It adds additional yum/zypper repos, but explicitly disabling package signing and using unencrypted HTTP transport. That way, it's pretty trivial to completely takeover the affected systems, by injecting malicious packages.
       
       
      DO NOT INSTALL THIS BROKEN SOFTWARE - IT IS DANGEROUS !
       
      CERT and BSI are already notified.
       
       
       
       
       
    • By PJM_labview
      Hi
      We have an application where we need to have a custom PCIe board transfer data to the PC using DMA.
      We are able to get this to work using NI-VISA Driver Wizard for PXI/PCI board.
      The recommended approach is to have VISA allocate memory on the host (PC) and have the PCIe board write to it (as seen below).

      While this approach works well, the memory allocated by VISA for this task is quite limited (~ around 1-2MB) and we would like to expand this to tens of MB.
      Note: The documentation (and help available on the web) regarding these advanced VISA function (for instance "VISA Move out 32" and "VISA Move In 32") is parse. If someone has some deep knowledge regarding theses, please feel free to share how we could allocate more memory.
      Since we are not able to allocate more memory using the VISA function at this time, we investigate doing the same operation using the LabVIEW Memory Manager Functions which allow us to allocate much larger memory block.
      Below is the resulting code.

      Unfortunately while we can validate that reading and writing to memory using this work well outside the context of DMA transfer, doing a DMA transfer do NOT work (although the board think it did and the computer is not crashing).
      We are wondering why this is not working and would welcome any feedback.
      Note: the DMA transfer implemented on the board requires contiguous memory for it to be successful. I believe that the LabVIEW Memory Manager Functions do allocate continuous memory, but correct me if I am wrong.
      To troubleshoot this, I did allocate memory using the LabVIEW memory manager function and try to read it back using VISA and I got a "wrong offset" error (Note: This test may not be significant)
      Another data point; while the documentation for DSNewPtr do not talk about DMA transfer, the one for DSNewAlignedHandle does. Experiment using LV memory manager Handles has not got us anywhere either.
      We would welcome any feedback regarding either approach and about the LabVIEW Memory Manager Functions capabilities in that use case.
      Thanks in advance.
      PJM
      Note: We are using LabVIEW 2014 if that matter at all.
       
    • By Benoit
      This VI list all VISA session opened and allow you to close all of them.
       
       
      Some times when the GPIB stuck and the VI wont stop..... This VI is a better solution than reboot.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.