How do you cyclicly trigger data acquisition after n pulses counted

[fezline]

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

[VuD]

Hi Randy,

Are you using one of our motion controllers with your DAQ card or are you controlling the stepper on the 6122 itself?  If you do have a motion card with NI-Motion, there are several examples you can look at which synchronize/trigger the two devices. 

Synchronizing a National Instruments Motion Controller with a Data Acquisition Device

Motion Breakpoints used as Triggers for Finite Retriggerable Analog DAQ Acquisition
 
There are also some DAQ/Motion examples in LabVIEW and in the Motion manual.  Hopefully these will give you a good start.  If you are controlling the motor with your DAQ card, how do you have it configured?  Is it set to step/dir. or cc/ccw? 

Vu

Message Edited by Vudoo on 05-07-2007 06:17 PM

[fezline]

What I have is a gimble that has it's own controller. I send commands to the controller through RS232 using labview but the DAQ card has nothing to do with controlling the stepper motors. I am monitoring pulses that are coming from the newport controller. The stepper motors are integrated to a gimble. If you would like to see what I am talking about I can provide a link to what the device is that I am using. The link is below.
This is the gimble
http://www.newmarksystems.com/gimbal-gm12.html
This is the controller
http://www.newmarksystems.com/motion-controller-nscm.html

The controller we have has a special breakout 9 pin din connector that enables us to read the ttl pulses being sent to the stepper motors. Being able to count the pulses enables us to determine the location of the gimble in any axis. The controller is set to provide 10,000 pulses per degree. For my application I need to aquire a sample for every 57 pulses in the x axis. My intent was to use the count down counter to count down from 57 and once it reached zero I wanted some way of starting a task of aquiring one sample and storing it in a buffer. This is all happening really fast so I must use a buffered aquisition mode. I need to be able to arm the card such that all control of what is going on is being done by the daq hardware and not the program; otherwise, it will lag out and I will miss huge amounts of data. I was basically looking for either a way of triggering from a down counter or using a frequency divider scheme that would allow me to output a pulse every 57 pulses read. Since the gimble is moving at 20 degrees per second and the controller spits out 10,000 pulses per degree, the speed of the counting and trigger need to be controller by the DAQ card. I know of a way of doing this with the old DAQ functions but I have no idea how to do it with the new functions and my card does not support the old functions. I hope that I have been clear enough with what I hope to do. I thank you for any help you can provide.

~ Randy

[fezline]

I will try the VIs that you linked in the previous message when I get into work tomarrow. It appears that they might actually enable me to do what I need based on the write up associated with them. I will let you know if they work. Thank you once again for your help.

~ Randy

[fezline]

Thank you for the suggested examples but it appears that these vis require many sub vis that I don't already have. I am still struggling to figure out how to use the nidaq-mx functions to do what the older functions were able to do. It is frustrating because it seems that they attempted to make things easier with NIDAQ-MX but I think their efforts were counter productive. Thank you once again.

~ Randy

[stilly32]

Hi Randy,

I think what we have is a bit of a terminology mix up. Let me see if I'm stating your problem correctly: You want to take an AI sample on every 57th pulse from an external source (your stepper motor output). Is this correct? If so, this is relatively simple to do. What you're effectively doing is dividing down your stepper motor output by 57. To do this, you want to set up a pulse train generation that is (for example) high for 2 ticks and low for 55 tick so that you will generate a rising edge every 57th tick. You would use the stepper motor output as your source for the pulse train generation. Check out the  "Gen Dig Pulse Train - Continuous" example, I've attached a screenshot of the modified VI.

You would want to specify the external PFI line that you connect your stepper motor output to as the "source of Ticks" input. This will then generate a rising edge for every 57th pulse it receives, you would now need to use the counter output as the sample clock for your AI task. You could just take the code from the "Cont Acq & Graph Voltage-Ext Clk" example and specify the "Clock Source" input to be the "Counter#InternalOutput" or just the default PFI line for the output. This will acquire an AI sample on every 57th pulse.

If this is not what you are trying to do, or I need to clarify any of my suggestions, please post and and we'll work from there. Hope this helps,

Andrew S

National Instruments

Message Edited by stilly32 on 05-08-2007 02:56 PM

Message Edited by stilly32 on 05-08-2007 02:57 PM

[fezline]

It appears to me that you have captured the essence of what I am trying to do. Once again I am a newbie so I apologize for any miss use of terminology. I will attempt to use the method you indicated. It appears to me that most of what is done as far acquisition is concerned is controlled by hardware and not software which is the biggest issue to me. Pulses are coming at me really fast and I can not let the bottle neck be the time it takes to complete a loop. I will let you know if this works. Thank you very much for your help.

~ Randy

[fezline]

I made the vi exactly as shown and I follow the logic of what is being done but I have some questions since it is not working properly. One thing that I think I didn't include in my description of what is going on is that the pulses that I am getting from the controller of the stepper motors are active low. Or so I think that is what it is called. Basically the state of the output of the controller is always 5 volts except for when a pulse is sent to the stepper. For the instant the stepper motor receives a pulse the output goes low. This does generate a normal pulse string but I am not sure if the number sequence of high and low ticks would be the same considering the fact that the active state of the tick is not high. Also, when you have a string of pulses that has 57 low states, and it is active low, would there not be 57 low ticks and 56 high ticks? I am not all together sure I understand what a tick is to be honest. But since it wasn't working I started to try and understand what was going on. It is my perception that the ticks are states, high or low. If there are 57 pulses and it is active low. There will be 57 low states and 56 high states. I am not sure where the counting begins and ends though. Does this tick counter need a pulse that is active high? I can always get an inverter and put it inline if that will solve my problem. I have a feeling I am missing something fundamental here but I am not sure. When I observe the output of the counter it seems like it actually works for like 2 seconds and then the output latches high. I began to think that it was a buffer issue but I read about the continuous acquisition mode and it appears that it makes the buffer circular. If the buffer is circulating I should never reach the limit of my buffer, or at least that is my not so well informed assumption.

I greatly appreciate your help and I think we are converging upon a working solution. I look forward to any insight you might have as to why the output of the counter latches high after about a few seconds of operation. What I would like to point out is when I remove the while loop and everything contained and after that, and run it in the continuous mode it seems to work. The output doesn't latch and I get a constant stream of pulses of varying period due to the deceleration of the gimble as it reaches its respective limits. But the pulses do appear to be related to the input pulses in a fractional way. I will say that I tried the high ticks and low ticks using both your numbers and a whole sequence of other combinations to see how the results change but I don't get anything consistent when running it with the while loop. The desired mode of operation is with the while loop but I figured this feature of what is going on might give you a better idea as to what is going on with my program. Thank you once again and I look forward to reading your reply.

~ Randy

[fezline]

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

[stilly32]

Hi Randy,

Thanks for the screenshots - those really help in troubleshooting. I'm no sure why you're seeing this behavior, but there are a few things to try to eliminate some of the possible causes:

Specify the 100KHz Internal Timbase as the Source of ticks on your pulse train generation. You may not be able to find the name in the drop down menu, if its not there, right click on the constant and select I/O Name Filtering... enable Include Advance Terminals and select the /6122/100kHzTimebase. If you scope the output, does the counter generate the expected divide down?

Also, if you use a different counter to generate, does that change the behavior?

Is the timing consistant - does it stop after x number of pulses each time?

Are you using any other resources when running this or just that vi?

Let us know the results of these and we'll see if we can find the culprit.

cheers,

Andrew S