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

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.


×
×
  • Create New...

Important Information

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