2010 blocking Ethernet traffic

[JoeQ]

I recently purchased an upgrade for my Labview. I have most of if working not but ran into a snag and am curious if anyone can help.

I use custom hardware for many tests. Many of these systems hang on the Ethernet bus. I use the code interface to make calls to DLLs that talk with the Ethernet devices. When I try to run these applications under 2010 SP1, it seems that Labview blocks the calls.

The new version of Labview has a lot features and I wonder if something like the VISA server, Network Browser, or the like is causing it.

I do have two GPIB-ENET, and noticed the 2010 dropped support for them. I downloaded the last known working drivers and these seem to work just fine.

[JoeQ]

After uninstalling all but the basic features, then halting registrationwizard, systemwebserver, applicationwebserver and any other task I found relating to NI that was loaded prior to starting LV, still no luck.

[JoeQ]

I ended up talking the hardware to try on a system that has other versions of Labview installed on it.

5.x works

6.x works

8.x doesn't work

9.x doesn't work

10.x doesn't work

The code interface does not support error output in version 6. However, enabling this in versions 8-10 cause no errors even with the maximum settings.

I did find this post while searching for a solution:

http://stackoverflow.com/questions/1267804/labview-blocking-qt-signals

Looking at the NI site, lots of chatter about how robust 8-9 are for DLL calls where 10 would crash if the incorrect types were used. No mention of earlier versions of LV.

[Rolf Kalbermatter]

I ended up talking the hardware to try on a system that has other versions of Labview installed on it.

5.x works

6.x works

8.x doesn't work

9.x doesn't work

10.x doesn't work

The code interface does not support error output in version 6. However, enabling this in versions 8-10 cause no errors even with the maximum settings.

I did find this post while searching for a solution:

http://stackoverflow...king-qt-signals

Looking at the NI site, lots of chatter about how robust 8-9 are for DLL calls where 10 would crash if the incorrect types were used. No mention of earlier versions of LV.

Are you sure Windows is not blocking any network access for those applications? When first starting up you should have gotten a dialog asking you if the application is allowed to access the network. This dialog is easy to just click away! And the DLL running in the LabvIEW process will simply be treated as the LabVIEW process by the Windows firewall rules.

[JoeQ]

Thank you for the response. Good idea but I am not using the XP firewall features and have no virus scanners with built-in firewall installed. I have tried running the 8&9 under Windows 2000 Pro (not supported with 10). Have tried 8,9 & 10 on XP Pro. All have the same problem and appear to block it.

It's strange as the DLL returns all the correct info, so it doesn't appear to be a type problem. It acts like the calls are blocked when the DLL is called from Labview.

[Michael Aivaliotis]

What version of LabVIEW did you upgrade your current LabVIEW application from? I assume it was working before (on the previous LV version) and now it's not working?

How are you testing this on older LV versions? Are you down-saving the VIs?

When you say the DLL returns all the correct info. How is that possible if it cannot communicate with the hardware? What is returned?

[JoeQ]

>>What version of LabVIEW did you upgrade your current LabVIEW application from?

5

>>How are you testing this on older LV versions? Are you down-saving the VIs?

I am sure I'm not understanding your question. You run VIs the same way in 5 as any other version...

>>When you say the DLL returns all the correct info. How is that possible if it cannot communicate with the hardware? What is returned?

Just because it can't talk with the hardware does not mean it can't return anything. It returns with codes that show it can't talk with the hardware.

On the plus side, it looks like I have it solved. The problem was the DLL and not Labview as it will now run with all the versions I have access to. With everything now working, it's time to finally try it out.

[Rolf Kalbermatter]

On the plus side, it looks like I have it solved. The problem was the DLL and not Labview as it will now run with all the versions I have access to. With everything now working, it's time to finally try it out.

Now we all are curious, as to what you did, that it suddenly worked!