Not able to receive data using VISA Serial

[Nishar Federer 0]

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

[LogMAN 148]

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:

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

[crossrulz 75]

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.

[ShaunR 838]

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.

[smithd 152]

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  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 September 23, 2017 by smithd

[ShaunR 838]

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.

[drjdpowell 434]

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.

[ShaunR 838]

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 September 24, 2017 by ShaunR

[drjdpowell 434]

That’s not my understanding, but I don’t have a device to hand to check it, so I might be wrong.

[infinitenothing 48]

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.

 

 

[LogMAN 148]

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 September 25, 2017 by LogMAN

[ShaunR 838]

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.

 

 

It's the read you should be looking at

Edited September 25, 2017 by ShaunR

[infinitenothing 48]

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