NI PCI 6509 not working under Win 7 at the same sample rate like under Win XP

[Todd2493]

Hello together,

before I come to the actual problem I want to tell you whats this about, we got an old testbench at which we test rotary encoders, in the testbench pc (win xp 32bit) we use the NI 6509 which reads the encoder state. In the test procedure we turn the encoder at a specified speed and verify that all gray values are read at the first turn, therefore we use the C API in an inhouse software. In the software we use the change detection to read the encoder values in the callback. That so far works perfectly.

The problem now is:
Since the old testbench is, well, quiet old, we decided to build a new one with a newer pc with Windows 7 64bit and the same NI 6509 card. The NI card works there too and reads the gray values but not at the specified speed of our gray encoder test (which works on the old win xp pc with the same card / specified speed -> all values read). If we make the same encoder test at the same speed on the win 7 pc it misses about 1/16 (about 1000) values. To eliminate our inhouse software as source of the problem I have written a small Qt programm that only access the NI card via the C API and logs the read values. With that test program I get exactly the same result, I get all values on the xp pc and alot misses on the win 7 one. With missing I mean that the gray values just dont get sampled. Its not always the same values that are missing, if we turned the encoder more than one turn for example we would get all values but thats not the goal.

So the question is, why does the same NI 6509 card that works under Win XP with a certain sample rate (encoder rotation speed) not work at the same speed under Win 7?

What I have tried so far without results:

-I have written a test program that only uses the used C API calls:

#define SAMPLES_PER_CALL 10000
#define COUNT_GRAY_POSITIONS 16384

void NidaqInterface::InitGrayConnection()
{
    qDebug() << "InitGrayConnection()";

    if (!DAQmxCreateTask("", &hTask))
    {
        qDebug() << "DAQmxCreateTask()";

        if (!DAQmxCreateDIChan(hTask, "Dev1/line0:13", "", DAQmx_Val_ChanForAllLines))
        {
            qDebug() << "DAQmxCreateDIChan()";

            int iStat1 = DAQmxCfgChangeDetectionTiming(hTask, "Dev1/line0:13", "Dev1/line0:13", DAQmx_Val_ContSamps, SAMPLES_PER_CALL);
            qDebug() << iStat1 << "DAQmxCfgChangeDetectionTiming()";

            int iStat2 = DAQmxRegisterSignalEvent(hTask, DAQmx_Val_ChangeDetectionEvent, 0, NidaqInterface::ChangeDetectionCallback, NULL);
            qDebug() << iStat2 << "DAQmxRegisterSignalEvent()";

            if (!DAQmxStartTask(hTask))
            {
                qDebug() << "DAQmxStartTask()";
            }

        }
    }

}

int32 CVICALLBACK NidaqInterface::ChangeDetectionCallback(TaskHandle hTask, int32 signalID, void *callbackData)
{
    uInt16 data[SAMPLES_PER_CALL];
    int32 read;


    if(!DAQmxReadDigitalU16(hTask, -1, 1.0, DAQmx_Val_GroupByChannel, data, SAMPLES_PER_CALL, &read, NULL))
    {
        for (int j = 0; j < read; j++)
        {
            uInt16 num = data[j] & (COUNT_GRAY_POSITIONS - 1);
            QString hexNum = QString("0x%1").arg(num, 4, 16, QLatin1Char( '0' ));

            testState[num] = 1;

            qDebug() << "Gray data[" << j << "]:" << hexNum << ";" << num;
        }
    }

    return 0;
}

-Installed 4 different driver versions, 17.5, 16.0, 8.6.1, 9.1
-Upgraded Win 7 with all available updates
-Changed the NI 6509 cards of the working Win XP pc with the Win 7 pc
-Tried different encoders

I am really at the end of my knowledge, in my opinion the problem has to be somewhere between the C API calls and the hardware, but I honestly don't know where exactly.

If anyone can give me some helpful ideas or new inspirations I'd be very grateful.

Thank you all,

Regards
Todd

[Kevin_Price]

I've only programmed DAQ in LabVIEW so I don't know my way around the text API's into DAQmx.  Let me describe what I think I'm looking at first.

It appears that you're trying to fire off your callback function on every individual change detection event.  Inside the callback, you read all available samples (the -1 argument?) and process them.  But by design, that will usually just be 1 sample, right?  Anyway, you flag each code you read in testState[] (which isn't declared here so must be a global?) and that must be what you check to see how many entries remained unflagged.

So without a theory for *why*, my first thought is to wonder if you're missing a callback.  And not knowing the inner workings of CVI, I speculate that maybe they don't queue up, so if you spend too long processing a given callback, you could miss the next one?

Looking up specs on the 6509, I see you're limited to interrupts rather than DMA transfer and it isn't clear that buffered capture is supported.  If it were me, I'd never have wanted to rely on a point-by-point unbuffered capture in the first place and I would take this as a perfect opportunity to get a board that supports DMA and buffered operations.  Then the task becomes trivial and the wrangling with Win 7 and interrupts and driver uninstall/reinstalls becomes nil.

Maybe there's a solution to make Win 7 more responsive and let you continue this kinda-risky teetering-on-the-edge method of single point unbuffered interrupt-dependent capture, but there's a pretty good chance that you'll burn a lot of time troubleshooting, experimenting, and validating.  The price of more capable DAQ hardware starts to look trivial in comparison...

-Kevin P

[TobiasG]

One thing worth trying is to have the OS use the High Performance Event Timer (HPET).

You can enable it by running the following command in an Administrator command prompt:

bcdedit /set useplatformclock true

Then reboot.

See Slow Connect/Disconnect Process with National Instruments Switches in Windows 7 for more information.

From that page:

Windows 7 systems by default use the Time Stamp Counter (TSC), rather than the High Precision Event Timer (HPET) as the default timer during program execution.  Depending on the CPU and motherboard, the TSC clock rate may vary and lead to a slower response from NI Switches. To work around this issue, National Instruments recommends that you enable Windows 7 to use the HPET clock.

I can't guarantee that this will help, but it doesn't hurt to try!

[Todd2493]

Thank you for your replies, at first Kevin: The software isn't the best I know however it works (I've also eliminated OS dependencies as possible problem in the old software by writing a test software that works the same way). You are right with your interpretation of the software, however it actually does not matter if a callback is missed or not since the samples are buffered, I have tried that and it happens for example when the execution of the callback takes to long. A simple way to reduce the amount of callbacks would be for example if you used instead of DAQmxRegisterSignalEvent(...) the function DAQmxRegisterEveryNSamplesEvent(...), that would work fine too, but the callbacks aren't the problem. The problem is that it really seems like the missing values just don't get sampled at all, and thats what the DAQmxCfgChangeDetectionTiming(...) actually should do (in that function you can also set the buffer size for your sampled values).

Now to you Tobias, thank you for the idea. I've tried the HPET, the BIOS option was actually already enabled so i just left it like that and tried the OS setting, however it had no real effect at all. In the meantime I've tried some more things and made a little bit progress. Additionally to the previous tests I've installed Win7 32bit with drivers 8.6.1 and 9.1 and tried to change the PCI slot of the card, however without positiv result.

Now it becomes interesting, I've taken the NI 6509 card and built it in another Win7 PC, installed the newest driver (17.5) and it worked, so it can't be the OS in general, and also not the driver alone. In the next test I've taken an image of the working Win xp PC and installed that on the newer Win7 PC (so a complete Software image with OS and everything from the old PC on the new PC which didn't really work with Win7), to my suprise and against everything I've been told, the combination did not work either... So now I'm almost sure its not an OS or driver problem anymore but a some kind of problem with the system hardware that it doesn't work in well in that combination.

Has anyone got any idea with what other hardware, cards like the NI 6509 have problems? Generally the hardware hasn't completly changed it's just newer parts as far as I know.

Regards
Todd

[Kevin_Price]

With the time spent on experiments, re-imaging, etc., the cost of a more capable DAQ board should be looking better and better all the time...

I still don't see confirmation of buffering in the 6509 spec sheet and I *can* tell you that I never see the kind of missed sample behavior you describe when using a board that supports buffered tasks and has DMA access to RAM.   Have you looked at something like a PCIe-6323?  It does DMA based buffering, and has a 32 bit port which supports change detection (and other hardware-timed DIO).

I mean, the things you've described doing don't point clearly to a cause or solution (in that when the difference between working and not working is inexplicable, it isn't yet a *solution*.  It's still just an observation).  Why not look into something with more robust capture capability?   

-Kevin P