PCI 6509 Change Detection Missing First Data Entry

[jonnnnnnn]

Hello,

I have a two 6509 cards, in separate machines, connected to each other. I'm using six lines, with a channel for each line, to send signals between the two boxes.

I've used the NI-DAQmx 8.0.2 on SUSE Linux, coded in C.

Starting with the Digital IO examples I've made one card transmit on four of the lines and the other card received the signal, using change detection on the falling edge only, with the lines inverted.

To send a signal I set the value to 1 on that line, using write digital lines, and then set it to 0 using the same function.

If I send 4 signals, 100ms appart, 1 on each line. The recipient will detect all four falling edges but the read digital lines function (In the callback of registed signal events) returns zero for the first detection. I'm only reading a single sample from each line.Once it gets going all seems fine.

Do I have to read more than one sample for the first read digital lines function call?

Do I have to make my signal longer, at the moment it's about 150us? I can do this with a wait in the code. I can afford to streatch it to about 1ms, but that's forever with these sorts of processing.

Is there some initialization call to get the driver to initialize some memory internally or something? (It may be my code being slow wrt this, but I can't see how, it does almost nothing.)

Thanks

[jonnnnnnn]

Attached is the source code.

The signal goes...

WRITEDIGCHAN (Box B)  -> ReadDigChan-ChangeDetection-DigFilt (Box A) -> WRITEDIGCHAN (Box B)

Any suggests welcome

[jonnnnnnn]

If I make the code wait for 60us before calleding the second write digital lines, in WriteDigChan, then the data seems to be consistently present.

The card is specd at being able to detect a change with a pulse width of 100ns. Can it actually get the data back, via the callback function, at anything like that speed?

[jonnnnnnn]

Forgot to mention.... although I previously said that I could increase the pulse width of the input, I can't actually do that because the WriteDigChan file is only a test harness. Our live system will be sending the interrupt at 500ns.

[DanVickers]

Hello Jonnnnnnn,

I am Dan Vickers from National Instruments, I am an Applications Engineer based in the UK.

Did you have any luck finding some answers on this post? please let me know if you are still in need of assistance. I will be looking for an answer for you and will post it here once I have some more information.

Kind Regards

[jonnnnnnn · Accepted solution]

I think we came to the conclusion that this card can not detect interrupts as narrow as 450ns. The API does not seem fast enough between the interrupt detect and the call to read data lines.

It looks like we should have brought a counting card rather than an interrupt card.