IP to String - Timing Issue with Windows 10

[ccostello4]

Hi,

I was working on a project and noticed something I wanted to point out for others and see if I could get a reasoning as to why this is happening.

I started this project about four months ago and recently update my computer to Windows 10. I am running Labview 2014 V14.0f1 (32 Bit) and had not seen any issues with labview until I enabled some error logging code which reports data to a syslogger. 

We started to notice that the logger was taking far longer than normal to process errors and in turn was slowing down the entire program.

When we dug into the issue we found the slow down was from the IP to string block used to pull in the host name. It was taking around 4.5 seconds to complete. I run the same code on a windows 7 VM and it run in under a 1 ms...

Any idea why IP to String is taking almost 4,500x time longer in Windows 10 vs Windows 7? We have worked around the issue by making the value a control that can be set from a configuration file but I wanted to let others know and hopefully get an answer to why this is the case.

Thanks,

Chris 

[RavensFan · Accepted solution]

LabVIEW 2014 is technically not compatible with Windows 10.

Windows Version Compatibility with LabVIEW.

Maybe the lookup time is affected by something that changed in Win 10.

[ccostello4]

Thanks for the information. I had not seen that graphic.

I called NI before the switch and asked if it would be an issue and the guy at the time said it should be compatible. Guess not completely at least.

[RavensFan]

I think in general, people have successfully used LV 2014 on Windows 10, at least from the few anecdotes I remember seeing on the forums.  I don't think Win10 is all that common yet for there to be very many people using it and an older version of LabVIEW to discover problems.  I think the only people who are using Win10 are the ones who have recently bought a new PC, or those people who got suckered into that by the nagging messages Microsoft was constantly sending out as a part of an "update".

I'm thinking it is very likely that something where LabVIEW needs to communicate with the network system of the OS is one of the things that could have been changed between Win 8.1 and Win 10.

[Bob_Schor · Accepted solution]

The Good News is that with LabVIEW 2016 on Windows 10, it appears to be "instanteous" (I didn't time it, I just clicked the Run button and saw the String Indicator "instantly" fill with appropriate text).

Bob Schor

[ccostello4]

HI Bob_Schor and RavensFan,

Thanks for your insight and quick responses. 

I came in today and updated to 2015 SP1 and everything is back to the way it is suppose to. IP to string read is back to under a millisecond.

Simple fix to a very frustrating debugging issue. 

Thanks again.

[Dsjr6]

Hi I was having a similar problem running on my windows 10 machine. After digging into the problem for more than three weeks, searching online and talking to NI today I figured out the real issue. I'm not sure why but the  control for dot notation needs to be or the IP address need to be 0.0.0.0 then there is no time lang of 4.5 seconds. I am using Labview 2015 SP1.

I hope this helps others with a similar  problems. I will be sending NI a copy of a vi using the IP to string function that causes this problem.

Best regards to all.

David Slapo, Jr.

[VinayKumarR]

Hi everyone,

i found a solution that might interest you.

Tried with LV 2016 on both Win10 and Win7.

-Vinay

[JLJ]

Sorry to revive an old thread -- but I still see a huge (4+ second) delay when using "IP to String" on LabVIEW 2016/Windows 10 under these specific conditions:

• Dot notation is false
• Using a VPN

If the dot notation input is set to true, I never see any noticeable delay. In my application, I cannot simply switch to using dot notation; as someone who needs to do a lot of remote work over a VPN, the delay when dot notation is false is extremely frustrating. Does anyone else experience this?

[altenbach]

---

@JLJ wrote:

Sorry to revive an old thread -- but I still see a huge (4+ second) delay when using "IP to String" on LabVIEW 2016/Windows 10 under these specific conditions:

• Dot notation is false
• Using a VPN

---

With dot notiation=false, the function requires an external DNS lookup that is not handled by LabVIEW, but by the OS. I doubt LabVIEW can do anything about this. Maybe you should do e.g.a Wireshark trace to see the actual traffic when the function is called. Even some internet security software might intercept the DNS lookup and do their own checking against a database of e.g. malware sited. These things are not necessarily fast. What name servers are you using?