I get -10810 error when performing MeasurePeriodInBuffer (ND_BUFFERED_PERIOD_MSR)

[apopa]

I am using the NI PCI-6602 board and I got error code -10810 while performing buffered period measurement.
I was running tests in a loop and when the test perfromed around 58000 loops this error ocurred and I can not get enough info about it from the documentation. A buffered period measurement is done in each loop so it worked 58000 times and then it stoped working.
 
Does somebody know what the reasons can be for this error to occur?
 
Thanks for helping,
Adrian.

[Matt A]

Hello Adrian,What development environment and DAQ driver are you using? I believe GPCTR_Config_Buffer is a C function call for Traditional NI-DAQ (Legacy), so I am assuming you are using the Traditional NI-DAQ (Legacy) driver with some soft of C compiler. Please let me know if this is incorrect.It sounds like this error is caused by an incorrect buffer configuration, but it may take some more information to determine the exact cause. You said that you were running the loop approximately 58,000 times before it fails. However, the GPCTR_Config_Buffer function configures a buffer for a counter operation, as described in the "Traditional NI-DAQ (Legacy)? C Function Reference Help, Version 7.x"GPCTR_Config_Buffer

status = GPCTR_Config_Buffer (deviceNumber, gpctrNum,
reserved, numPoints, buffer)
Purpose

Assigns a buffer that Traditional NI-DAQ (Legacy) uses for a
buffered counter operation.

This function configures the buffer for the counter operation. So, you should only need to run it before the loop to configure the buffer and not in the loop where you read from the buffer. For a C example of buffered counter measurement in Traditional NI-DAQ (Legacy) you can examine the example program called STCsingleBufPeriodMeasure.C. By default, this example is installed to the following path:C:\Program Files\National Instruments\NI-DAQ\Examples\VisualC\CtrAlso, I noticed that you are using the PCI-6602. This device is supported by our latest driver, NI-DAQmx, which is the main focus of our development moving forward. In addition to being the more recent driver, NI-DAQmx also offers multithreading, improved state model, simplified synchronization and easier transitions between operations as compared to Traditional NI-DAQ (Legacy). If you are beginning new development and are not required to use Traditional NI-DAQ (Legacy), I would very much recommend that you use NI-DAQmx for your programming. Like Traditional NI-DAQ (Legacy), NI-DAQmx is also free and contains example programs to help you get started.

[apopa]

Ok, the software we have is more complicated than the example I will give below, but I hope this will clarify how it is working:
 
//buffer alocation would be here somewere. from this point on, I just pass the pointer to the NI driver.
//The NI driver will write data in the buffer and this data will be read when acquired data is checked.
nTestCounter = 1;
while (nTestCounter < 200000)
{
       //configure the other NI boards (we have also NI PCI-6534 and NI PCI-6035E)
      
       //configure the the counter on NI PCI-6602 (including the buffer setting) and arm it
 
      //start everything - data transmission,  data acquisition, the armed counter will start when triggered
 
      //when done stop everithing (in the manner exemplified by you in the las post)
    
     //and the comes this - it should put the counter in it's original state
     nStatus = GPCTR_Control(m_nDeviceNumber, m_nCounterNumber, ND_RESET);     nStatus = Select_Signal(m_nDeviceNumber, GetCounterOutput(m_nCounterNumber), ND_NONE, ND_DONT_CARE);
 
     //check acquired data
 
    nTestCounter++;
}
 
I can not put the real code here as it is split acros many libraries and it is too much to put here, but in principle it does what I just described above. I can not make it not to set the buffer every time, but it should work even if I do this once I reset the counter after I used it. Right?
 
Thanks a lot for your help.
Adrian.

[apopa]

Oh, sorry, I got a little bit caried away. Calling

nStatus = GPCTR_Control(m_nDeviceNumber, m_nCounterNumber, ND_RESET);

will only halt the operation of the counter, it does not make any kind of reset, as the name would sugest.
Adrian.

[David L.]

Apopa,

You are correct that GPCTR_control (m_nDeviceNumber,
m_nCounterNumber, ND_RESET) does not reset the device, but returns to the power
on state. ND_RESET can also be used when you want to halt the operation
the general-purpose counter is performing. Below are two quotes from the
Traiditional NI-dAQ (Legacy) C Function Reference Help. I would also highly suggest and recommend doing this application using DAQmx, as it is a newer and more full featured driver.
<img src="http://forums.ni.com/attachments/ni/40/5151/1/ND_Reset1.JPG"> <img src="http://forums.ni.com/attachments/ni/40/5151/2/ND_Reset2.JPG"> Message Edited by David L. on 07-27-2007 06:25 PM

ND_Reset1.JPG:
http://forums.ni.com/attachments/ni/40/5151/1/ND_Reset1.JPG

ND_Reset2.JPG:
http://forums.ni.com/attachments/ni/40/5151/2/ND_Reset2.JPG

[cristicristea]

&nbsp;
The problem is still unsolved.
&nbsp;
To perform the operation that you described I need to call GPCTR_control (m_nDeviceNumber, m_nCounterNumber, ND_RESET), which is called, in the present at the end of each loop. But for the next loop which are the commands which I need to perform?
&nbsp;
If I call GPCTR_control (m_nDeviceNumber, m_nCounterNumber, ND_ARM)/* or NR_PREPARE or ND_PROGRAM
I receive the error -10600. The meaning of the&nbsp;error is: "No setup operation has been performed for the specified resources. Or, some resources require a specific ordering of calls for proper setup"
&nbsp;In documentation I found:
"You should use the following sequence of calls to start your counter:

- GPCTR_Set_Application
- GPCTR_Change_Parameter
- GPCTR_Config_Buffer
- GPCTR_Control "

My intention is to solve the problem using Traditional NI-DAQ.( It is clear for me the advantage of DAQmx but I can not afford this for the moment).
&nbsp;
So which is the set of commands to be run in next loop, only to program the GPCTR without to configure it?
&nbsp;
Thanks
cristi
&nbsp;
&nbsp;

[RT4CY]

I would suggest taking a look at the STCsingleBufPeriodMeasure.C example.&nbsp; This example is located at the following address.

[RT4CY]

Hello cristi,Excuse my hasty reply, I see that Matt Anderson had already pointed you to this example.&nbsp; This example is still a good reference as to the execution order of the commands to use.&nbsp; As David mentioned in a previous post, in order to reset the counter you need to stop and restart the task.&nbsp; This means that you would need to reconfigure the task every time.&nbsp; The sequence that you referred to:&nbsp;

- GPCTR_Set_Application
- GPCTR_Change_Parameter
- GPCTR_Config_Buffer

- GPCTR_Control This needs to be executed on every iteration of your loop.&nbsp; Let me know if this is unclear.

[cristicristea]

Hello
&nbsp;
Thanks a lot for your quickly response.
&nbsp;
This&nbsp;was my understanding, also but I want to be sure that this is the correct way for acces in a loop.
&nbsp;
The application performed&nbsp;in&nbsp;this way the configuration, but after&nbsp;some itterations(50000-60000 steps) the application&nbsp;crashed due to this error:
"-10810 internalDriverError An unexpected error occurred inside the driver when performing this given operation "
&nbsp;
I run the application in debug mode and the application crahes here with the nStatus = -10810:
&nbsp;
nStatus = GPCTR_Config_Buffer(m_nDeviceNumber, m_nCounterNumber, 0, ulBufferSize, pulBuffer);&nbsp;//check for errors&nbsp;if(nStatus &lt; 0) &nbsp;{&nbsp;&nbsp;m_ErrHnd.ErrorHandler(nStatus,"CCounter::MeasurePeriodInBuffer - GPCTR_Config_Buffer");&nbsp;&nbsp;return (nStatus);&nbsp;}
I don't have the code of the GPCTR_Config_Buffer(because this function is from the driver) and if I do not&nbsp;have&nbsp;more information about this error(-10810) I can not find the problem.
&nbsp;
I am looking forward for your response.
&nbsp;
Regards,
cristi