From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-11-2014 12:15 PM
Out of curiousity, any reason why you can't just open two separate UDP sockets in this case - one for sending, and one for receiving? Is there some reason you want to reuse the same socket? The additional resources aren't much, and you'd need to do this a huge number of times before you ran out of ports.
03-11-2014 12:54 PM
Hello Nathan,
That's what I ended up doing for some of the products we test, using one port to read and one to write. To me, that was more reliable/efficient than just ignoring error 66.
However, a few of the products we test are designed to transmit messages to devices at a specific port and receive data back from the same port. For those products, using two ports is not an option. (I don't have control over the design of the products).
Thanks for your suggestion. I'm going to reach out to someone at NI support through our Enterprise Agreement to see if I can get someone to dig a little deeper since the forums are not helping.
03-11-2014 01:02 PM
(Logged in under different account in previous thread - If someone could provide a path to migrate Aliases once they have left a company, that would be awesome, but that's probably for a different thread)
Hello Nathan,
That's what I ended up doing for some of the products we test, using one port to read and one to write. To me, that was more reliable/efficient than just ignoring error 66.
However, a few of the products we test are designed to transmit messages to devices at a specific port and receive data back from the same port. For those products, using two ports is not an option. (I don't have control over the design of the products).
Thanks for your suggestion. I'm going to reach out to someone at NI support through our Enterprise Agreement to see if I can get someone to dig a little deeper since the forums are not helping.
03-11-2014 01:50 PM
@gt8860a wrote:
(Logged in under different account in previous thread - If someone could provide a path to migrate Aliases once they have left a company, that would be awesome, but that's probably for a different thread)
Veering off-topic a bit: I've never thought of my NI profile as specific to a company. You can change your email address and company name in your profile. Note, however, that if you move to a new company, install an existing copy of LabVIEW (say from the previous employee who left), and associate it with your NI profile without updating the profile to reflect that you've changed companies, you'll get an automated note asking if you do, in fact, want to transfer the LabVIEW license between companies, even though that's not what you are doing at all.
04-30-2014 08:46 AM
Yup, sure enough, I have the same problem. I didn't hit it with main application that does parallel read/write, but when the hardware had to be worked on and I wrote a simulation VI that does serial read then write on the same port, just like the instrument and just like it's described here and in the VIs posted. For now I'm just ignoring 66 too. We'll see if that works...Just an FYI, not looking for a response (since this topic has been beat to death already).
NI - I would have expected more information. The CAR should not have been closed as "not reproducible". I find that very hard to believe! It's literally 3 VIs and a loop. Open UDP> Into loop > Read w/ timeout (Error 56) > write anything > Loop > Read (immediate error 66). There are examples here. I'm using LabVIEW 2013 on Win7 and see the issue. R&D can contact me directly, I'm happy to help if they need it. I understand it's very low priority and likely won't get worked on for awhile (ever?) and certainly not before I need it, but something strange is going on here, especially since it works fine on other OSs. If the CAR was closed for other reasons that makes more sense, but not reproducible doesn't. You can tell us if that was the case...
Thanks.
j.harv
05-01-2014 08:46 AM
Hi J.Hary
If you have a simplified version that can reproduce the issue with LabVIEW 2013 and Windows 7 could you attach it to this thread so I could try to reproduce the issue on my computer.
Regards
Esteban R.