Odd problem after NI-Scope upgrade

[Fedor]

I noticed an odd problem with niScope Multi Fetch WTD.vi which broke my code that was working for years until I upgraded to NI-Scope 3.9.6. 

In particular conditions, typically when there're more than 4 channels configured, this VI returns fewer points than requested, never finishing acquisition. And it only happens when  its "channels" input is wired! How odd is that?

I'm attaching a snippet of my code that show this oddity. 

The board was PCI-5105, LV version is 2010 sp1 32 bit.

[Tunde_S]

Hi Fedor,

Thank you for your feedback. I am curious to see if this problem persists if you use the code that I attached. This code compares the actual record length to the number of samples fetched. Also, NI-SCOPE 3.9.7 has been released and you can download the installation files, here.  With this code, does the problem persist when you use NI-SCOPE 3.9.7? 

The attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at:

http://ni.com/samplecodelicense 

[Fedor]

The problem remains in 3.9.7 

I attached 2 screen shots of your program results, one with 4 channels, the other with 5. In the second case the records are shot by 66 points - same shortage I observed myself in my code if there are more than 4 channels selected. It only started happening after the upgrade to 3.9.6/7.

Fedor.

[JoshY]

Hi Fedor,

Do you have any other hardware that also shows this issue? I've run both attached codes with simulated devices and have not run into any issues.

Or, can you replicate this same behavior on another system that does not have SCOPE 3.9.5 or 3.9.7? This is because we don't really recommend back tracking on drivers.

Also, is it still missing the same number of samples regardless of what the record length or sample rate is set to? Meaning, is the only factor here the number of channels that you specify? Again, I've tried running both sample codes with a simulated 5105 but have not been able to reproduce this issue.

[Fedor]

I tried to test this problem on another PC, but I was unable to install NI-Scope 3.9.7 there - in the middle of install it gave the message that it cannot open some "NI VC2010MSMs x86" package. I tried re-downloading it again in diff location, but got the same error. Than I tried repairing it in NI software in the control panel and got   "error 1618 occurred" mid-way.

Frankly I have a feeling that I wasted too much time chasing your driver bugs while my work suffers and my project broke thanks to those bugs.

[MikhailK]

Hi Fedor,

I understand your frustration. I would recommend fully uninstalling the NI Scope driver and reinstalling it again. To get past the "error 1618" please follow the steps outlined in the following article: Installer Hangs at Progress Dialog, Endlessly Retrying to Install

[Fedor]

I uninstalled 3.9.7 and I tried running installer again. I get the same message (Attached).

It's not the download. There's something wrong with NI driver set. What is it?

[Fedor]

I suspect that "NI-SCOPE397.zip" distributed by NI.com includes defective file "VC2010MSMs_x86.msi".

[Fedor]

Alright, I went out of my way again and compared the VC2010MSMs_x86.msi to one included with NI-DAQmx, and there it s 788480 bytes vs. 196608 bytes in ni-scope. Copied one from daqmx on top, and NI-scope instaleld.

What's going on?

[mudson]

Hello Fedor,

We've been working on trying to replicate the issues you have encountered.

Regarding the installer issue:

I have successfully installed NI-SCOPE 3.9.7 on two different machines from the media available on ni.com.  One machine was upgraded from NI-SCOPE 3.9.6, and another from 3.8.  It may have been an issue with something corrupt hanging out in the installer cache, or something odd happening in a temp folder.  I am not sure.  

I'm working on setting up a replication of your hardware setup to see if I can get the 5105 we have on hand to exhibit the same behavior you reported in your first post.