Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Acquire serial bit message after trigger, in a loop at 2KHz with PCI6534: retrigger too slow??

Hi,
 
I have 3 lines entering my 6534: trigger, data, clock. The trigger is a 200nS pulse, followed by a 112 bit serial message (112 clock pulse of about 100nS, and I read the data at each clock pulse and I get my message).
 
Now this works fine. I set the 6534 for pattern I/O with an external trigger and external clock, I read the 8-bit port one sample at a time, compare it to zero to transform each read into a binary bit, put that into a binary array and after my 112 clock ticks I get my message fine.
 
Here's my problem: I need to do that at 2KHz, the trigger/serial message is coming at me 2000 times a second... and it seems I cannot just loop and retrigger, it seems I need to reconfigure the card and put EVERYTHING in the while loop to make it works... and on my machine (which is a very decent machine) I can get only about 50Hz.
 
I'm using Labview 7.
 
Why can't I just, after the Dig READ, reset the trigger???? I think I tried everything and it does not allow me. Searching the development zone it seems the 6534 is "not retriggerable"... but I'm not sure what it means, I do not want a hardware retrigger, I just want to reset the trigger via software.... and go at least at 2KHz...
 
Now if somebody has a solution with ANOTHER CARD, this could be an option, I need this done!!
 
I included my code (with everything in a loop).
 
Thanks a lot
 
J-F
0 Kudos
Message 1 of 4
(3,204 Views)

Hello J-F,

It seems that you know what rate you need to acquire your serial message at, so I do not understand why you need a trigger at all.  It seems you are getting a bit for each external clock pulse, so why can't you acquire all data and just dispose of any you do not need by parsing your data after it is acquired?  Using this method, you should easily be able to acquire at the rate you want. 

Maybe I do not understand what you are trying to do, so please post back with more information.

Thanks,

Laura

0 Kudos
Message 2 of 4
(3,198 Views)

Hi Laura,

Thanks for the reply.

Well, the trigger ensures me that I will not desynchronize. This test will be run for a couple of months continuously, so the probability of a glitch on the clock is quite high.

Yes I could probably redesign without a trigger, but I do not have a lot of experience with buffer manipulation. I have a CRC on my data, but if I discover an error how do I recover coherently? Clear the buffer until I accidentally recover in-between messages? Maybe I could use the trigger then to resynchronize (well, I think this could work, I tough of it while writing you this reply, you already helped me!!!! thanks!!!)

Another way would be to acquire my 112 bits, then pause the acquisition for the duration of another couple of bits (so that if I had extra clocks they will be ignored and I will recover at the next message). But how do I do that since timeout/timer resolution is 1mS??

Thanks a lot,
 
JF
0 Kudos
Message 3 of 4
(3,193 Views)

Hello JF,

I see now why you want to have the trigger.  I think a retriggerable operation would work best for you.  A retriggerable operation requires counters (since they are retriggerable), which the 6534 does not have.  If you have a second device with counters, there is an example that shows how you could set this up. 

You may also want to consider our M-series DAQ devices because they feature correlated DIO (1 MHz up to 10 MHz depending on the board) on at least one port and they have two counters.  I noticed that your program you posted is written with traditional DAQ, but the M-Series boards require DAQmx just so you are not surprised if you decided to go this route! 
 
I hope one of these solutions will work for you!
 
Laura
0 Kudos
Message 4 of 4
(3,173 Views)