JoeQ

I have verified that they now have this fixed. It will be released with version 5.2 of VISA available in August. This version of VISA will support LV 2009 - 2012.

NI continues to work on this bug but as of yet, the above is still the only work around I have found.

It looks like a new feature was added that allows you to select which data sets are to be displayed on a graph. I have manually done this with many of my programs and saw this was going to be a real time saver. If you enable autoscale Y and switch between data sets, the autoscale does not work. You have to add a property to detect the change and then force a refresh. Still it's cleaner than what I was doing, but wish it fully worked. To enable this feature, just right click on the label and make it visible. Also noticed that if I dynamically change the labels on a digital graph using properties, that these do not get updated until I stop the program or drag it off the screen. The only work around I found was to turn off the graph then turn it back on. You can reproduce this problem without coding anything. Beware if you try and play with the digital graph properties that you save your work first. You may get something like this:

The VISA PXI calls worked if I installed only the PXI support from the new VISA and copied these two files over it but it turns out that MAX would crash. If I installed the full VISA, then copied just the two files, the Open again fails. I have narrowed it down to 5 files now that seem to effect it. I can do a full install of 5.1.1 and copy these 5 files from the 2009 SP1 and MAX, trace and PXI communications seem to work. I am also able to get EXE's built with 2011SP1 and 2009SP1 working just fine with the PXI. I am sure it causes some other problems but it does not appear to effect anything I am doing. Next step is to uninstall everything and try it from a clean start, which I am in the process of doing as I post. I have had a case open with NI for a few weeks. They are still playing with serial ports and I understand with great success!! Looks like it works for the most part. So, if you stumble onto this thread because you have this same problem, you may want to try the following: 1) Install your older NI-VISA that worked. I am currently using what was supplied with Labview 2009 SP1. 2) Once you have verified you are able to talk with your hardware, you want to save the following files from your Windows installation directory: SYSTEM32\NIPALU.DLL (mine is dated 1/10/2010 and is 307KB) SYSTEM32\DRIVERS\NIPALK.SYS (mine is dated 1/10/2010 and is 584 KB) SYSTEM32\DRIVERS\NIVIPCIK.SYS (75KB) SYSTEM32\DRIVERS\NIVIPCIKL.SYS (12KB) SYSTEM32\DRIVERS\NIVIPCIKW.SYS (12KB) 3) With the above files saved someplace safe, go ahead and install your 2011 SP1 including your full VISA 5.1.1. Verify you are no longer able to talk with your hardware. 4) Enter Task Manager and shutdown all the NI tasks. You can do this from services or even use Safe mode on boot. You just need to shut things down so you can copy the files in. 5) You may want to backup the above files from your new install. It just may save you time if this causes you some other problems. Keep in mind that after you manually copy the files, Labview thinks it still has the correct files. So uninstalling and reinstalling does not always work. 6) Replace the five newer files with the ones you saved. If Windows gives you an error that the files are in use, you did not shut down all the NI tasks.. 7) Reboot the PC. 8) Take the time to post your results and if this change causes other problems!

After several hours of trial and error, I have traced the problem down to two files that are part of the new NI-VISA. Swapping these with an older version of VISA solves it. I understand that the developers never got in contact with the tech support group, so I am not sure what it will take to get the bug fixed. In the mean time, at least I have a work around.

Using a clean install of 2009, VISA 4.6.2, 5.0.2 & 5.0.3 all seem to work. The bug appears to show up in 5.1.1. Running a trace the error is: > 2. viOpen (0x0282A7B0, "PXI5::13::INSTR", 0, 0, 0x00000000) > Process ID: 0x00000C4C Thread ID: 0x00000D10 > Start Time: 00:16:07.656 Call Duration 00:00:00.000 > Status: 0xBFFF0078 (VI_ERROR_INV_PARAMETER) I have opened a case with NI and am trying to get them to run some tests using a PXI chassis and using the wizard to create a driver rather than using the PXI Platform Services. So far they have told me that opening a serial port works fine and that the older versions of VISA are not compatible with 2011. I have confirmed that opening a serial port on my test PC with 2011 works as well. I assume very few companies are using custom hardware and the wizard with 2011. This is why the bug has not been reported. If they come up with a fix, I will post it here.

It appears even the VISA Open fails with 2011. Again, it is able to find the correct VISA Resource Name. It has an error code of "-107380724". −1073807240 The value of some parameter (which parameter is not known) is invalid. So it finds the resource name but when I make the call it is invalid. This is the only thing passed to the VISA Open fuction. Interesting enough, I am able to use VISA Open and VISA Memory Allocation Functions for the shared memory in 2011. I never installed 2011 without SP1, nor did I try any of the 2010 versions. The last known working version was 9.1.

"....there appears to be a problem with using the VISA calls to talk to the PCI bus....." "The 2011 sees the driver, it just appears it can't talk with it." I may try and see if any of the calls work but in the end, it all needs to work or I can't use it. Funny is the VISA PCI calls did not work in 6.1. So much for regression testing.

We are looking at changing to Labview 2011 SP1. I thought I would spend a little time today trying it out, but noticed that there appears to be a problem with using the VISA calls to talk to the PCI bus. The version I am currently using is 2009 SP1. It uses VISA 4.6.2 The 2011 SP1 uses 5.1.1. it also installed NI-PXI Platform Services 2.6.2. Installing 2011 breaks my 2009 installs. If I roll back VISA, and others, I can get my 2009 to run again, but 2011 will still not run. I have used the wizard to recreated the files. The 2011 sees the driver, it just appears it can't talk with it. Interesting enough, the VISA calls were broke in 6.1 which forced me to upgrade to 8. I don't want to waste too much time on debugging it but would be interested in knowing if anyone else has this same problem. I did a search on NI's site and could not find anything in their knowledge base. Thanks

I just upgraded from 5 to 2010. I am using a P4 3Ghz PC with XP Pro. The intall (complete Full package) took about 6 hours on this machine. Then again, I installed it on my old laptop but just did the minimum and it was done in about a half hour. It is very slow to develop code with it now compared to 5 and 6. Selecting save as, for example, took 50 seconds before I got the file menu. The long times are not constant. Sometimes save can return the menu in 10 seconds or so. Pressing undo, I may as well get a coffee. VI's will run fine, then freeze for a second or so, then run for a while then freeze again. I found if I turned off the NI Webserver that it seemed to solve it. No freezes with a few hours of run time. I have not tried to restart the PC again and see of the problem returns. The new 3D graphs look very nice compared to the old ones but I was hoping to see a lot more modern looking controls in the library.

>>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.

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.

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.

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.

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.