two PCIe-6537 read error and blue screen of death

[pawel]

Hi all

I am reading two PCIe-6537 at 20MHz sample rate acquiring all 32 lines each with externally supplied clock and external trigger.

When operating separately, no problem, but when two are read I get

a) on average of 25% of time error reading the data (time out error but happening before the actually time set by timeout, i.e. immediately after trigger)  and

b) a blue screen of death after 1h or so of constant operation.

I have a feeling a) and b) are related and LV causes the system crash with so many errors. NI support seems to think otherwise. 

I am using Dell Studio XPS 8100 and I have done all the firmware updates for the Chipsets etc. It has not changed anything.

Changing single line to whole port reading does not change anything. 

Any ideas what to try else?

[Jim_S]

Hello Pawel,

I have looked over the service request you mentioned about acquiring 2 PCIe-6537 at 20MHz sampling rate on all 32 lines. In order to narrow down this issue, I think it would be best to try only acquire from both cards without doing any triggerring etc. Also when performing this test, I would only want to acquire from 8 channels on both cards to see if this reproduces it. If this works, we can slowly add more elements to narrow down what the issue is and make us more effective to solve the problem.

I also wanted to ask if you have tried this setup on another machine and if it worked.

Along with this, have you tried to create two Digital Tasks in MAX and try to acquire for the same amount of time to see if the issue reoccurs here? This would tell us if this problem is connected to the driver/computer or LabVIEW.

[pawel]

Hi Jim

I tried with the onboard clock and no triggers (i.e.. Software trigger) and the problem still is exactly the same.

The error (-200361) seems to appear less frequent when less channels is acquired. If I only acquire 8 channels from the second card it does not happen at all. When acquiring 16 it happens perhaps 20% of a time.

Interestingly, what I have noticed that when I use the run arrow it happens more frequently than if I use the "Run continuously" button. Any idea why?

Perhaps some part of the problem is that in the vi I am opening and closing the connection to the card and calling the vi in the loop keep the memory the same or something like that?

I did not try it on other machine as I need two PCIe slots and I do not have other machine like that. However, if it is absolutely necessary to do I could try to find one. But perhaps somebody at NI could help with it?

Thanks for looking into it

Pawel

[Efrain_G]

I have been working with Pawel on a support service request about this issue. Pawel mentioned that he noticed that the problem was resolved by making sure that he does not repeatedly start and stop the output task while the input task is running.

[JÞB]

Pawel, Efrain.

Have you looked at the Max tech report yet? 

What versions of LabVIEW and DAQmx ( autostart bug?)

Pawel can you post some code? (repeated Task creation/destruction can cause hangs)

What does the Task manager say? (is thwere a memory leak? 100% CPU usage?)

Thanks and good luck- these things can be a beast to track down

[pawel]

Hi Jeff

As Efrain mentioned the problem was caused by starting and stopping a DIO task which receiving the DIO on many channels at high speed, i.e. a receipit for trouble :).

I have given the code to NI folks so they can do additional tests if they want.

thanks

Pawel

[JÞB]

Aha- so it is likely the autostart bug

CAR #185781 is fixed in DAQmx 9.1..