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.

[apopa]

I forgot to add a detail. The error is generated by "GPCTR_Config_Buffer" driver function.

[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\Ctr

Also, 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]

We are using Traditional NI-DAQ 7.4.1f4 because the NI-DAQmx was not available back in the days when the application was developed. As development environment we are using Microsoft Visual C++ 6.0. Currently we are not prepared to invest in switching to NI-DAQmx.

I can say that the buffer is allocated only once when the application starts and then in every loop the pointer to the beginning of the buffer is passed to the GPCTR_Config_Buffer function.

We have used the GPCTR_Config_Buffer function in this fashion for around 4 years now but we did not encountered this error up to now, and it only seems to happen on one computer. This is why I am trying to find out what can cause this error.

[Matt_A]

Hello Adrian,

I'm afraid I still do not understand why you are calling the GPCTR_Config_Buffer in a while loop. You stated that you allocate the buffer once and then pass a pointer to it to the GPCTR_Config_Buffer function in the while loop. However, you should not need to configure the buffer every time, you should only allocate it once. If you examine the example I referenced you will see that GPCTR_Config_Buffer is only used at the beginning to configure the buffer and then the following code is used to determine the measurement:

/* Loop until 'ulGpctrNum' is no longer armed. */

    do {


        iStatus = GPCTR_Watch(iDevice, ulGpctrNum, ND_ARMED,
         &ulArmed);

        iRetVal = NIDAQYield(iYieldON);

    } while ((ulArmed == ND_YES) && (iStatus == 0));

I'm not sure that this is the cause of this error, but it's always important to maintain the proper programming practice. Do you know what is happening to your memory when this error occurs? I ask because the behavior you described sounds like a memory leak. I would recommend that you examine your memory allocation to determine if you do have a leak.

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

[David L.]

Apopa,

I am a bit unclear from your wording, but when the task is cleared the buffer will be release, and will be reallocated when a new task is created. The only way to reset  a counter is to stop and start the task as well.

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

Message Edited by David L. on 07-27-2007 06:25 PM

[cristicristea]

The problem is still unsolved.

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?

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 error is: "No setup operation has been performed for the specified resources. Or, some resources require a specific ordering of calls for proper setup"

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

So which is the set of commands to be run in next loop, only to program the GPCTR without to configure it?

Thanks

cristi