How do you cyclicly trigger data acquisition after n pulses counted

Question

Hello all, please forgive my ignorance because I am very new
to lab view and data acquisition. I am working on a system which is going to
scan an object and produce an image. The gimble that I am scanning the object
with is an X-Y type of gimble with stepper motors on each axis. The stepper
motor controller will output pulses real time to indicate the real time
position of the gimble in each axis. What I need to be able to do is count
pulses from the stepper motor controller and then output a trigger pulse to
trigger the data acquisition in a buffered mode when N number of pulses have
passed and then generate another pulse to stop the acquisition after another N
number of pulses have passed. The controller puts out 10,000 pulses per degree
of travel. The velocity that I am traveling at is 20 degrees per second, so
timing here is really important. I need to be able to utilize the speed of the
daq card and not so much the speed of the computer to iterate through a loop. I
have tried using the count down feature in the NIDAQ MX library but it does not
appear to be useful to me. I set it up and it will count down but once it hits
zero it continues to count down. My expectation was that it would either
restart the down count or it would stop. I was expecting some sort of trigger
event to take place once the count reached the zero point but I did not observe
any sort of event taking place. Once again my knowledge and background is
really limited so I could be missing something really fundamental here. I have
tried using some of the legacy functions which would enable me to do exactly
what I want to do but they do not seem to work with my daq card. I have a NI
PCI-6122 and if anyone has any knowledge on how to get this type of card to
talk to some of the non MX functions I would be more than happy to hear how. It
seems to me though, that I am limited to the MX functions which I can not
really translate into what I have learned I can do with the legacy functions. I
thank you all once again for taking the time to read this I and I will
appreciate any and all responses that can be helpful.
~ Randy Brown

Answer 1

I have run a few more tests and obtained some data per the request of a telephone support engineer. I have some scope screen shots that might be able to shed some light on what is going on. I will provide a brief description of what I discovered before I show the resulting data. I discovered that using the number of up ticks and down ticks suggested does not yield the right timing for the clock pulses that I will need for triggering my data acquisition. When I use 55 low ticks and 2 high ticks as my settings I end up getting a pulse every 32 pulses read on the PFI line. I get the same results when I interchange the numbers, for example, when I set the program up for 2 low ticks and 55 high ticks I get the same resulting one clock pulse per 32 pulses on the PFI line. I started playing with the numbers and come to find that I was able to generate a pulse every 57 pulses in this setup. I set the high ticks to 2 and the low ticks to 71 and once I did that it generated a pulse every 57 pulses in. The results are not ideal though, a number of things happen within the first second of operation. One mode of operation the clock output pulse latches after a few pulses generated. Another mode of operation that I noticed was that it would generate n number of pulses and then just stop even though the program was still running. The results I am getting are not reproducible when it comes to the long-term operation of the clock pulse generation but the bottom line is not matter what happens the end result after 1 second is not what is expected. I will show below screen shots of my program and also scope shots for the respective modes of operation.
Front End interface
Block Diagram
55 High ticks and 2 low ticks results
55 low ticks and 2 high ticks results
77 Low ticks and 2 high ticks results
Undesired Latch after 1 second of operation
N number of pulses generated and stopped while program was still running
 It appears the the long term operation (and when I say long term I mean after a second) is intermittent, it either latches high or low after a random number of pulses are generated on the clock output. I am not sure why this is happening. The one setup that I came up with that generates a pulse every 57 pulses is not going to work for the setup that I have I think I would have to reduce the 71 to 69 in order to compensate for the two pulses that happen while the output pulse of the clock is high. To be honest I have no idea what is going on and I am starting to wonder about my daq card. Being that it is not really reproducing the same results I am starting to think maybe something is wrong with it. Another possibility is that it might be the bnc 2110 that I am using. I will try another one tomarrow and see if this problem persisits. I am leaving now so I won't be able to try that as of yet but I wanted to pass this info and data along such that maybe you will notice something and be able to lead me in the right direction. Thank you again for all of your help.
~ Randy Brown