Missing data in Change Detection Mode

[Tired and alone]

Hello All

I am having some problems with my application using NIDaq, Visual C++ and a DAQCard 6533. I have attached a word document that tries to explain exactly what I am doing and what the problem is, but here, as concisely as I can I shall try to explain. I have an externally generated trigger of 100uS duration, repeating every 30mS, 3000 times that I use to trigger a pattern generation from port 0 of the DAQ Card. This pattern provides a 10uS pulse, every 100uS, repeating 200 times per external trigger. This is used by external electronics to initiate an A/D. Now the external A/D, via its data valid output, initiates a change detection in ports 2 and 3, with the data valid pulsing once with every 10uS pulse from
the pattern generator, approximately 75uS after one of these triggers. Consequently for each external 100uS trigger there are 200 pulses output from the DAQ Card and change detection is triggered 400 times (rising and falling edge of the data valid line)......

Now this seemed to work fine until I checked some of the code and reset an array.... Now it seems that the change detection doesn't always acquire the full 400 times.... sometimes it will only acquire once...... and over the test this can become significant....

As I said I have attached a word document that shows some of my code and explains the process more clearly. What I want to know is am I doing something wrong in my set up or am I simply expecting too much from the DAQCard 6533.

Any help or guidance would be gratefully appreciated.

[rgharrison]

Hi,

The hardware is definitely able to perform the task you are asking of it. I have a couple questions though. I've read your Application Explanation and it seems like you input (line C) is timed and at equal intervals. You also mention that your A/D converter produces a pulse after each conversion which you are triggering on using change detection. Why not use that pulse as the "clock" signal? You can input that data line into the REQ2 line and have Group 2 of your digital configuration clocked on an external clock (from REQ2). You're change detection method would also do the trick, but this method wouldn't require any triggering.

Now you mentioned that it seemed to work fine until you "checked some code and reset an array". This kind of cha
nge shouldn't cause any kind of failure in the acquisition.

One way to make sure the overall system is functioning is to open one of the shipping examples for VC++ that ships with NI-DAQ (should be in the NI-DAQ folder). You can just perform a continuous pattern input using the external clock to make sure you are getting every sample.

One of the key things to note is that you would have gotten error (-10845, -10846) if you had lost data after collecting it. It could be that the trigger signal for your change detection didn't change.

Anyway, try using your A/D pulse as the external clock for your input group. I hope I understood your application correctly. Have a good day.

Ron

[Tired and alone]

Hi Ron

Thanks for the advice. I have now connected the externally generated triggers to the REQ2 input and reconfigured the card as you suggested, with limited success. Every so often the data acquired will not be as expected. Just to refresh your mind I have 3000 external trigger events in a test and each one of these generates 200 10uS pulses, one every 100uS from a Pattern Generation from Group1. These pulses are used by some external equipment to trigger an A/D which in turn generates a data valid signal. There is hence one data valid signal for each of the 200 10uS pulses. It is this data valid signal that I am now using as the external clock into group2.

I have put in some test signals which would cause the DAQCard to read
all one's on it's input lines, everytime it is clocked, but occasionally during a test run it doesn't read anything, filling the buffer with zeros. I don't understand what is going on. The code I use to output a pattern from group1 and input data from group2 is shown as a word document in the attachment..... any ideas?

Kind Regards

Jamie

[rgharrison]

Hi Jamie,

That seems quite strange. Why don't we try connecting the data lines from group 1 to the data lines of group 2 and connect the REQ1 to REQ2. This way, everytime group 1 outputs, group 2 will input. This will enable us to verify if the card is not working correctly. The pattern we should expect is the exact same as the pattern we generated.

If the card seems to be working correctly with itself, then it could be that the voltage signals coming from your A/D device is not hitting the threshold for a voltage high signal and is occasionally reading the signal as all lows. This is also strange though because you would expect it to be random and on different lines. How are you powering your A/D converter? Can you increase power to
the A/D converter to guaranty that its digital output is read as a logic high?

Anyway, hopefully these tests can help us narrow down the problem.

Ron

[Tired and alone]

Hi Ron (Again)

I have tried your suggestions of connecting the REQ1 and REQ2 pins together and I have also minimised the system by removing the A/D and using an externally triggered function generator for some of the triggers. Basically the setup now is the 'ideal' setup....

However, I still seem to get errors in the data.... I have tried to explain what I have done and what I have found in the attached word document. Basically the REQ pins and the Data lines look to be doing as they should, but the data is not consistently reflected in the data array used to store the information.....

I am running out of ideas of where the problem could lie.... could it be noise? I am not using a shielded cable? or something els
e.....Any additional advice would be gratefully appreciated.... i do have another DAQ Card 6533 but I am holding off using it for the minute just in case the old card is not working and I have caused it......

Kind Regards

Jamie

[Tired and alone]

Hi Ron and All

I am still getting erronous data from my DAQCard 6533 when set to Output a pattern and input using the an external clock. Does anyone have any thoughts or ideas on where I may be going wrong? Please refer to my earlier postings to get an insight into my problems.

Kind Regards

Jamie

[rgharrison]

Hey Jamie,

A couple thoughts, by default, pattern input will export the REQ clock. In contrast, by default, pattern output will import the REQ clock. This should explain your haywire behaviour when you run pattern input before pattern output.

What I would do now is create a bare-bones program. Configure port A for analog input, configure port C for analog output and connect all 8 data lines and the REQ lines. Then start the output operation (which will wait for the external clock) and then start the input which will automatically export the internal clock to the output operation. This will test just the data. Don't include the other ports or the triggers. Keep the rates low for testing purposes. If it pa
sses, continually increase the rate. If it continues to work, slowly add the triggers. Eventually, you will find a piece of code that you add that breaks the program.

If you keep you digital rates low, you shouldn't be affected by noise too much. Once you start increasing your rates, you will notice that noise might start affecting the data. To overcome this noise, twist a grounded wire around your data lines. This will minimize the crosstalk on the signal lines.

This should be the most minimal test of communication between two independently operation ports. Hopefully this works out. If it doesn't, try the other card.

Ron

[Tired and alone]

Hi Ron

Thanks for your continued help. I am in the process of putting together some really basic code to test the speed capability of my DAQCard 6533 (pcmcia) to see if it is really up to the task, as you suggested. I also have a loaned 6534 (pci) card on the way and I will try the same with that. At present I am still missing data, sometimes only a few samples and other times all of them even with a really basic program. I think I need to take a few steps further back as you suggest.

One question I do have though is when I am running the input with an external clock into the REQ pin, when should the input latch? Does it latch on an edge, rising or falling, on both edges, or at a level? At the
minute my app seems to latch data on both the rising and falling edges. Is there a command in NI_DAQ that allows me to configure the point of latching?

Kind Regards

Jamie

[Tired and alone]

Hi Ron and everyone else.... again

The problems with this application using the DAQCard 6533 seem to go on and on. I have now taken your advice and streamlined the system down. I have configured port 'A' for pattern generated output and port 'C' for input and then slowly reduced the rates. I have put the main extract from the code in an attached word document that shows my configuration routine.

Now the card seems to acquire data quite readily at 1mS (1Khz), but if I increase the rate it starts to miss samples and eventually the input buffer is filled with zeros..... Now I am assuming this means it is missing data.....

The rate I am after is about 100uS period.... and I can't g
et realiable results anywhere near this. Only when I increase the rate up towards 1mS can I start to get realiable results.....

So the question are am I expecting too much of the pcmcia card and am I using the card correctly? Are there any alternative ways to set the card up that may give me the timing I need? Failing that would a PCI version of the 6533 or the 6534 provide me with a suitable alternative? Is it something in the interrupt driven nature of the pcmcia card that is limiting the response time?

Any thoughts or comments would be gratefully appreciated. I have also tried my spare card with the same results.

Kind Regards

Jamie

[rgharrison]

Hi Jamie,

It looks like your code is correct. I've included example code I usually work from. Our options at this point are:
1) I'm going to try duplicating it on my DAQCard 6533
2) If it works, I'll send you the exact code.
3) If yours doesn't work it is either
a) Signal Connections are noisy
b) Your board might need repair

Anyway, let's proceed from there. Talk to you soon.

Ron
Applications Engineer
National Instruments