Odd problem after NI-Scope upgrade

[Fedor]

Matthew,

The installer problem only appears if NI-SCOPE 3.9.7 installed on a machine where no VC2010MSMs_x86.msi was applied before. For example, when I install DAQmx 9.6 before NI-Scope, there is now problem. 

Could you check the size of  VC2010MSMs_x86.msi file that comes in NI-SCOPE397.zip? I just downloaded it once again to a different PC, and the size of the above file is 192kb vs. 770kb in other distros.

Fedor.

[TimmTheEnchanter · Accepted solution]

Hi Fedor,

I was able to confirm the bug you're seeing (reading back 66 samples fewer than you expect) when installing 3.9.6 and 3.9.7 on a fresh machine (Win XP SP2 32-bit), from both a local network and from the download page on ni.com.  Therefore, I don't believe the issue you're seeing is a result of the download page, or due to the MSI.  Also, I since I installed on a fresh machine, I confirmed this doesn't have anything to do with upgrading from a previous version of NI-SCOPE.  I tested with 3.8.7 and confirmed the behavior was not present.

The short summary is that:

- I have filed a new CAR 368402 to address this new behavior you're seeing.

- For the short-term, you may use a work-around as I've identified below (see attached VI)

History:
There was some incorrect behavior prior to NI-SCOPE 3.9.6 when fetching from a 5105 digitizer with numbers of channels that are obtainable by taking 2^x, where x is some integer value.  (In other words, 1, 2, 4, and 8 all are two raised to an integer value, as in 2^0, 2^1, 2^2, 2^3.)  Calling Fetch with any number of channels that does not fit that criterion (e.g. 3, 5, 6, and 7 channels) reported back invalid data.  Note that the ordering of the channels, and which channels are used, does not matter--it is only the number of channels that evoked this issue.

The bug fix that we addressed in 3.9.6 was identified as CAR 327321, and you can find that CAR referenced in the 3.9.6 or 3.9.7 ReadMe.  Note that the CAR 327321 points out that low sampling rates (<20kS/s) evoked the incorrect behavior--that is not quite true, that is simply how it was most obvious, and how it presented in a previous customer issue.  The behavior was noticed at higher sampling rates as well - the only variable that seemed to matter was the number of enabled/fetched channels.

Back to your Issue:

While this incorrect behavior (wrong data) was identified and fixed in NI-SCOPE 3.9.6 and 3.9.7 that fix appears to have also introduced the issue you're seeing, where the number of samples returned is less than expected when fetching from numbers of channels not obtainable by raising two to an integer value (i.e. calling the Fetch function with 3, 5, 6, or 7 channels wired into the "channel" input.)

."..this VI returns fewer points than requested, never finishing acquisition."

To be more specific, the issue we're observing here (66 samples fewer than expected are returned by the Fetch function) only happens when you enable 3, 5, 6, or 7 channels, and request to fetch from them all at once (with the same Fetch function call).

"And it only happens when  its "channels" input is wired! How odd is that?"

When you leave the "channels" input unwired, it will by default only fetch data for the first channel (the default value is "0", meaning channel 0.)  Since this number of channels fits the criterion I mentioned above, you will not see this behavior in that case.

So in other words, it's important to know that if you enable and acquire from more than one channel, and then call the Fetch function with the input unwired, it will only return the data for the first channel!

The attached VI:
This work-around VI works by calling the Fetch function on each channel individually (one at a time) to return data.  TheFetch function therefore runs in a sub-loop, and builds an array of waveforms as the output of the sub-loop, which can be used in the rest of your program.

I do not recommend modifying this code to Fetch 2 or 4 or 8 records at a time to improve throughput--this will result in the same behavior as you initially noticed (this VI never finishes executing.)  As this work-around currently stands, you must call Fetch once for each channel you've enabled.

Please let me know if it helps or if I may be of more assistance.  I apologize for the inconvenience this issue poses, but I hope this work-around is suitable for you.

-Andrew 

[Fedor]

Andrew,

Thanks for confirming the bug. I did not check all the variations, but it does appear with 3 and 5 channels fetched, where the record is short by 66. I don't recall if I tested with 6 or 7  channels, but I would trust your findings.

Fedor.