Reliable unlimited multi-record acquisition

[Ben Schwartz]

I am attempting a multi-record acquisition in NI-SCOPE following the pattern of MultiRecordFetchMoreThanAvailableMemory.  The system is, in general, working for numRecords up to 10,000 (which in this case corresponds to 600 MB of data in total).  However, if I call niScope_ConfigureHorizontalTiming with numRecords = 100,000, acquisition immediately fails with the error:

Error BFFA669E occurred at niScope_InitiateAcquisition.

Possible Reasons:

niPAL Error -50353 occurred:

One or more memory pages in the specified logical buffer could not be locked into physical memory.  The operation could not be completed as specified.

I would like to acquire an unlimited, "potentially infinite" number of records.  One way to do this would be to set numRecords to 1, but according to my understanding, this would sacrificed the benefits of on-card buffering.  I required on-card buffering for reliability, to ensure that no trigger is missed.  This error causes me to suspect that I cannot achieve this goal simply by setting numRecords to a very large number.

How can I acquire an indefinite number of records reliably in NI-SCOPE?

[CWolf]

Ben, 

Have you enabled the property to allow more records than fit in the memory?  It sounds like that might be the problem.  But, if you could post your code, it may be easier to determine why you are getting that error. 

-Christina

[Ben Schwartz]

My acquisition loop is attached.  It's become rather intricate, but the essential lines are

// Set the attribute to allow more records than memory
handleErr (niScope_SetAttributeViBoolean(vi, VI_NULL, NISCOPE_ATTR_ALLOW_MORE_RECORDS_THAN_MEMORY, NISCOPE_VAL_TRUE));
 
// Configure the vertical parameters
handleErr(niScope_ConfigureVertical(vi, d.channelName, d.verticalRange, d.verticalOffset, d.verticalCoupling, d.probeAttenuation, NISCOPE_VAL_TRUE));
 
// Configure the horizontal parameters
handleErr(niScope_ConfigureHorizontalTiming(vi, d.minSampleRate, d.minRecordLength, d.refPosition, recsPerAcq, d.enforceRealtime));

....
handleErr(niScope_ActualNumWfms(vi, d.channelName, &numWaveform));
handleErr(niScope_ActualRecordLength (vi, &actualRecordLength));
// The real number of waveforms is the result of dividing by the number of records.
numWaveform = numWaveform / recsPerAcq;
....

wfmInfoPtr = malloc(sizeof(struct niScope_wfmInfo) * numWaveform);
binaryWfmPtr.any = malloc (d.binaryDataType * actualRecordLength * numWaveform);
// If it doesn't have enough memory, give an error message
if (binaryWfmPtr.any == NULL || wfmInfoPtr == NULL)
     handleErr (NISCOPE_ERROR_INSUFFICIENT_MEMORY);

// Initiate the acquisition
handleErr(niScope_InitiateAcquisition(vi));

I set ALLOW_MORE_RECORDS_THAN_MEMORY to TRUE, and my mallocs succeed, but niScope_InitiateAcquisition fails with the previously mentioned error when recsPerAcq = 100000.  When recsPerAcq=10000, everything works perfectly.

Thanks for your help,

Ben

[CWolf]

Are you able to run the Example without any modifications and acquire that many points?  Also, which scope card are you using?

-Christina

[Ben Schwartz]

No.  The unmodified example exhibits identical behavior (works at 10,000, fails at 100,000).

The card is a PCI-5124.

One interesting additional note is that once this error code has appeared, any subsequent attempt to access the card will cause the computer to undergo an immediate "hard reset", as if power had been lost momentarily.  This is on Windows XP, using the NI-SCOPE 3.4 drivers (the latest version), although I also observed it with older driver versions.  Other than this issue, both computer and scope card have been stable.

[Jennifer O]

Hi Ben,

During the initiate, the driver needs to allocate some memory on your PC for storing timestamp information.  From the error you are receiving, it appears that the driver may be unable to allocate sufficient space for the timestamps of 100k records.

How much memory do you have in your system? Can you check your virtual memory configuration?  You can check this information by right-clicking My Computer and selecting Properties.  The General tab will show your RAM.  Select the Advanced tab and click settings under the performance category.  The Advanced tab will report your virtual memory.  Alternatively, you can go to your Start Menu and select Run.  Type msinfo32 and click ok.  This will create a System Information report which includes this information.  You can save the report and post it here.

I am also curious to know if you reverse the order of your initiate call and the call to allocate memory for the fetch, does your system still error on initiate? If you call NI-SCOPE Commit before NI-SCOPE Initiate, do you see the same error on the commit call? Can you configure record lengths successfully between 10k and 100k without seeing the error on initiate?  Can you think of anything else you may be running on the system that might be taxing your memory?

-Jennifer O.

[CWolf]

Ben,

It sounds like your computer might be set to automatically restart upon system failure rather than showing a blue screen with error information.  Here is an article that explains how to change that, so you can get a little more info about why it is restarting.  That info may help troubleshoot this issue. 

-Christina

[Ben Schwartz]

The system has 1 GB of memory, and another 2.5 GB of pagefile.  Discounting system caches, all of it seems to be available.  The total virtual memory is listed as 2.00 GB, with 1.96 GB available. I am not aware of any reason why this memory should not be available. The system is not running any major tasks other than the acquisition loop.

Placing the malloc() calls after niScope_InitiateAcquisition has no discernible effect.

I added a call to niScope_Commit before  niScope_InitiateAcquisition, but the error still occurs at niScopeInitiateAcquisition.

Christina's diagnosis regarding blue screens is correct.  With blue screens enabled, I get a blue screen the next time I try to access the card after the InitiateAcquisition error.  It says:

STOP: 0x0000008E (0xC0000005,0xF734CCFD,0xF6CD0644,0x00000000)
nipalk.sys - Address F734CCFD base at F72F1000, DateStamp 469ea59f

I will try to determine the exact upper bound on record length, but this is a slow process due to the need to reboot after each failed attempt.

[Ben Schwartz]

My acquisitions are currently configured to be 30000 samples long.  After a rough binary search, I have found that setting numRecords to 16384 always works, 32767 never works, and 17000 sometimes works.  The problem seems not to be strictly repeatable/deterministic.

[CWolf]

Ben,

I think it would be best for you to create a service request and call in so that we can get some more information from you and talk to you directly about this issue.  You can create a service request online by going to ni.com/ask, or you can call in at 866-275-6964. 

-Christina