Sergey Kolbunov Posted October 10, 2008 Report Share Posted October 10, 2008 I'm trying to figure out would VISA asynchronous mode benefits for my application. I'm sending a large amount of data via VISA Parallel, TCP/IP or USB and these data generate responses (significantly less amount of data). So receiving depends of transmitting the way that without transmit we have nothing to receive. The device under test generates response as it gets enough data for that. I send data in chunks (1000-20000 bytes) while the total amount may be very large (20 Mb and more). Transmit/Receive timeout is set to big enough value because a device under test can be slow in receiving/processing data. What I expected is that in asynchronous mode my transmit and receive processes would be independent, i.e. do not block each other. What I see in fact both in synchronous and asynchronous modes that a receive process may wait for response and block a transmit process from sending the data what will produce that response Looks like Transmit and Receive still work via one door even in asynchronous mode. As I understand from this article http://digital.ni.com/public.nsf/allkb/ECC...6256F0B005EEEF7 locking take place in asynchronous mode anyway and just suppose to take less time, but in my case when I have no actual data to receive the asynchronous receive mode ends up with receive timeout the same way as synchronous mode. So, do I need to synchronize transmit and receive processes anyway (do not run them in parallel carelessly)? Quote Link to comment
jdunham Posted October 10, 2008 Report Share Posted October 10, 2008 QUOTE (skof @ Oct 8 2008, 10:02 PM) What I expected is that in asynchronous mode my transmit and receive processes would be independent, i.e. do not block each other.What I see in fact both in synchronous and asynchronous modes that a receive process may wait for response and block a transmit process from sending the data what will produce that response Looks like Transmit and Receive still work via one door even in asynchronous mode. As I understand from this article http://digital.ni.com/public.nsf/allkb/ECC...6256F0B005EEEF7 locking take place in asynchronous mode anyway Well NI can tell me until they are blue in the face that VISA is awesome, but I will keep my opinions to myself. Yes, it seems like asynchronous should help. No, in fact it doesn't. Putting the calls in separate LabVIEW execution systems (threads) doesn't help either. But, yes, you can get what you want. The trick is (courtesy of NI's Dan Mondrik, who at least tries to atone for NI's sins by helping us)... You have to open separate VISA references to your serial port, one for the write thread and one for the read thread. That's the only non-stupid way to keep them from blocking each other while timing out (the stupid way is to poll each side in a really fast loop with a short timeout). http://lavag.org/old_files/monthly_10_2008/post-1764-1223532516.png' target="_blank"> I did suggest to Dan that this useful nugget be put on the NI Developers' Zone, but a quick search turns up nothing. Let me know if it works for you. Quote Link to comment
TobyD Posted October 10, 2008 Report Share Posted October 10, 2008 QUOTE (jdunham @ Oct 8 2008, 11:13 PM) The trick is (courtesy of NI's Dan Mondrik, who at least tries to atone for NI's sins by helping us)... That's a good thing to know. I don't need it now, but I'll file it away in case the need arises in a future project. Thanks! :thumbup: Quote Link to comment
Mark Yedinak Posted October 10, 2008 Report Share Posted October 10, 2008 QUOTE (jdunham @ Oct 9 2008, 01:13 AM) Well NI can tell me until they are blue in the face that VISA is awesome, but I will keep my opinions to myself.Yes, it seems like asynchronous should help. No, in fact it doesn't. Putting the calls in separate LabVIEW execution systems (threads) doesn't help either. But, yes, you can get what you want. The trick is (courtesy of NI's Dan Mondrik, who at least tries to atone for NI's sins by helping us)... You have to open separate VISA references to your serial port, one for the write thread and one for the read thread. That's the only non-stupid way to keep them from blocking each other while timing out (the stupid way is to poll each side in a really fast loop with a short timeout). http://lavag.org/old_files/monthly_10_2008/post-1764-1223532516.png' target="_blank"> I did suggest to Dan that this useful nugget be put on the NI Developers' Zone, but a quick search turns up nothing. Let me know if it works for you. This approach will not work if you are using TCP connections though. If you use this on a TCP connection you will establish two independent connections to the device. The device should be smart enough that it returns the response on the same connection that it received the data on. It would be nice if VISA allowed true asynchronous communication. In addition, it would be nice if VISA allowed independent control of the various settings on the resource. In particular, it should allow different timeout values for the transmit and receive. Quote Link to comment
jdunham Posted October 11, 2008 Report Share Posted October 11, 2008 QUOTE (Mark Yedinak @ Oct 9 2008, 08:53 AM) This approach will not work if you are using TCP connections though. If you use this on a TCP connection you will establish two independent connections to the device. The device should be smart enough that it returns the response on the same connection that it received the data on. It would be nice if VISA allowed true asynchronous communication. In addition, it would be nice if VISA allowed independent control of the various settings on the resource. In particular, it should allow different timeout values for the transmit and receive. Thanks, I should have stated more clearly that I was talking about serial ports. For TCP, our app uses the native calls which work fine for full duplex communications. I supposed we could have used VISA for that too, but your post makes me glad we didn't. Quote Link to comment
TG Posted October 13, 2008 Report Share Posted October 13, 2008 QUOTE (jdunham @ Oct 9 2008, 07:13 AM) Well NI can tell me until they are blue in the face that VISA is awesome, but I will keep my opinions to myself.Yes, it seems like asynchronous should help. No, in fact it doesn't. Putting the calls in separate LabVIEW execution systems (threads) doesn't help either. But, yes, you can get what you want. The trick is (courtesy of NI's Dan Mondrik, who at least tries to atone for NI's sins by helping us)... You have to open separate VISA references to your serial port, one for the write thread and one for the read thread. That's the only non-stupid way to keep them from blocking each other while timing out (the stupid way is to poll each side in a really fast loop with a short timeout). http://lavag.org/old_files/monthly_10_2008/post-1764-1223532516.png' target="_blank"> I did suggest to Dan that this useful nugget be put on the NI Developers' Zone, but a quick search turns up nothing. Let me know if it works for you. Jdunham I work with Rs232 and I had no idea this would work. Thanks for the important tip and the illustration regarding duplicate session ! :worship: Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.