Viewing a once per rev signal

[pathare535]

I'm currently trying to catch a once per rev signal in the form of an 5v square wave, using an USB-6341 DAQ. I currently have it configured as an analog voltage and am able to watch the voltage level coming out. My first attempt was to take the voltage output and compare it to a treshold and then trigger an event from that but I could never catch a value over the treshold. How can I trigger on a rising edge for this type of signal? 

[crossrulz]

The simple solution is to just use a counter (assuming the speed is what you are after).

But you can use the DAQmx Trigger VI to configure your task to start on an analog edge.

[pathare535]

Ive got the counter working in max now, but I cant get an event set up to work.  Is there a useable resorce for setting up daq events? I cant really find much on google. 

[pathare535]

I took a couple screen shots of my MAX setup, the one is what I currently have working and the other is what I think I need to get events to fire. I get an error when I try and run it though thats shown in the image.

[cody_a]

You're getting an error on the second one because you have the Acquisition Mode set to "1 Sample (HW Timed)".  This is equivalent to a timing mode called "HW-Timed Single Point", which is not supported on any USB DAQ device.

I'm a bit confused on your end goal.  Are you just trying to count the number of times the once per rev signal comes in?  What event are you referring to?  What do you want to occur each time the pulse comes in?

[pathare535]

My end goal is to take a picture timed from the once per rev. I'm sorry ive been all over the place in my thinking of the problem and I'm sure that adds to your confusion. I got what I wanted to happen last week to work where the once per rev will trigger an event and I could take a picture but its not consistant enough. 

So what I really need to make happen now is to use the once per rev to toggle a digital output that directly tells the camera to wait the specified time and take a picture. Ideally I'd like to be able to turn on and off the digital output so I can get to the part in my software that needs the image and then say on the next once per rev signal give me an image and just wait for the image to come in. on the software side I can wait two to three seconds while the hardware waits for the next once per rev and triggers the camera to take a picture. 

Im not really sure how possible this is, my department usually does this with a galil motor controller to trigger the camera I'm just trying to avoid adding another box to the system when I have access to hardware timers in the daq box. 

[cody_a]

Just to make sure I'm on the same page: When a rising edge of the index (once per rev) signal is received on the 6341, you want to wait for a specified period of time, then output another rising edge, which is then routed to your camera as an acquisition trigger.  Is that correct?

Routing the index pulse to the camera directly may be an easier solution - could you explain what you mean by "its not consistent enough" when doing it this way?  Also, what kind of camera do you have?

If you cannot get the camera to work with the index signal directly routed, you could use a retriggerable finite digital output task to perform this function.  The index signal will act as a start trigger; once received, the digital output line will generate as many lows (falses) as necessary to implement the delay/wait, then output enough highs (trues) to trigger the camera to acquire a new image.  At that point, the task waits for another trigger and the cycle repeats.

[pathare535]

---

@tAkinscareofbusiness wrote:

Just to make sure I'm on the same page: When a rising edge of the index (once per rev) signal is received on the 6341, you want to wait for a specified period of time, then output another rising edge, which is then routed to your camera as an acquisition trigger.  Is that correct?

---

Yes this is correct, I dont need to wait before sending the signal to the camera though. The camera has its own timer that I can change with a property node in Labview. 

---

@tAkinscareofbusiness wrote:

Routing the index pulse to the camera directly may be an easier solution - could you explain what you mean by "its not consistent enough" when doing it this way?  Also, what kind of camera do you have?

---

I could route the once per rev signal to the camera but I only want to aquire an image when something happens. like another daq channel exceeds a threshold value. 

I am grabbing the images in a seperate process so I could always capture images and throw them away when not ready for them.

The test I was running on friday was just to see if I could trigger an event in labview and then use like a snap.vi or grab.vi to capture the image. This worked ok and always aquires the image in the right ballpark but isnt as constant at the same position as I'd like. As a group we always assumed it was due to the computer clock doing other tasks. 

right now the camera I'm using is a Gene Nano.

http://www.teledynedalsa.com/imaging/products/cameras/area-scan/genie-nano/G3-GC10-C2590/

[cody_a · Accepted solution]

Thanks for the details, that helps a lot.  I figured the camera had a configurable delay - most modern machine vision cameras do. 

So essentially you want to trigger the camera to grab an image every time the once per rev signal is seen only if another condition (such as DAQ channel exceeds threshold) is also true at that time?

The inconsistency you're referring to is almost certainly caused by the jitter of software timing the acquisition.  You will get much more deterministic performance by using a periodic hardware trigger for the camera, then throwing away images you don't need.  The only real downside to this is the additional CPU time spent acquiring bogus images, which should be minimal.  If you want a pure HW solution, perhaps use an external boolean AND gate to ensure the once per rev signal only makes it through if another signal (set by the DAQ card when the other condition occurs) is high.

[pathare535]

oh, I didnt think about a hardware AND gate. I think that could work easy enough. Thanks!