01-05-2012 01:52 AM
In principle, this should be an easy thing:
1. I get a digital signal from a camera that tells me, on the falling edge, that it took a picture.
2. I'd like to collect an analog signal associated with the image it took and I'd like to use this falling edge the camera produces as a trigger for that analog signal.
3. I'm programming in LabView 7.1.
In an ideal world DAQmx would be reading the camera port and the signal port looking for the falling edge in the camera port. As soon as it sees the very first negative edge in the camera channel, it would record the signal it saw at the same time in the signal channel. Naively, I thought I'd just plug my camera output into the trigger port (PFI0) of my PCI-6110 (S-series) DAQ card and use that as the trigger source for a DAQmx read task on the signal channel. Were it that simple, though, I'd not be here. There are a couple of complications, some of which I can explain, some I cannot.
-----
1. The digital signals from the camera are gated in time. We tell the camera to start taking images by hardware ANDing a constant voltage "high" output from the DAQ card with the camera's external clock. Typically no more than 100-400 samples are collected in the window. There is a significant and variable delay ranging from 1-10 seconds before the next window of triggers appears. I include this piece of information because in my reading of the DAQmx manuals it should have relevance to pre-triggers.
2. For whatever reason, I am able to collect externally clocked analog samples if I plug the clock we use to drive the camera into port PFI0, but plugging the output TTL of the camera (even when not gated) does not work. Perhaps it doesn't like the quality of the signal? The camera output looks fine on a standard oscilloscope. Are there some electronic characteristics of the signal besides voltage that it needs to have?
3. I can collect the camera's trigger output by plugging it into an analog input port (Dev1/ai1 for instance). I can sample that signal with the onboard clock at, say, 15 kHz and it looks just like does on the Oscilloscope. Furthermore, I can make a DAQmx task to collect both the desired analog signal channel and my camera channel simulaneously. Confusingly, though, if I tell this single (dual channel) task to use camera channel as a trigger and then read out the desired channel (all on the same task), I don't get "triggered" acquisition. I simply get the same as if I were triggering using the 15 kHz onboard clock.
4. I tried to create two separate analog input tasks. One reads the camera and the other reads the desired signal. For reasons I don't understand, I cannot wire the output of the camera task to trigger the other task. I've seen examples where counter tasks are able to do this, but since I can't seem to get this signal recognized as digital, I'm trying to use an analog trigger.
01-06-2012 09:18 AM
Hello Tleilaxu_Ghola,
Is it possible for you to upload your VIs here to take a look at what you are doing?
Thanks,
01-06-2012 03:14 PM
I've attached the current and most functional model. I based this code off of the following examples:
1. https://decibel.ni.com/content/docs/DOC-9280
2. Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock
The second being an example that shipped with LabView 7.1.
I'm still in the process of confirming whether or not this code is actually doing exactly what I want. It appears to be so far, but lets not break open the champagne yet. Until I'm done with my tests, there are still issues that I wish were explained in more detail:
1. What's the difference between Retriggerable triggers and regular triggers? My naive understanding was: when the trigger event occurs, you take a sample. From what I've been working on, though, it seems like a trigger event is only the start of an acquisition that then proceeds with an assumed sampling frequency. This code is supposed to work around that by creating a configurable pulse train which then triggers an analog read. I'm not sure why that middle step is necessary to begin with.
2. The first example I linked made no modifications to the buffer, while the one that shipped with LabView does. What, in more detail, is the buffer modification doing? All I got is "DMA needs more, so we give it more". Can someone explain what even the concept of this buffer is, because I'm really quite confused. Does the analog channel read in continuously and then only output when it receives a trigger? If that's the case I can see why a buffer may need to exist, but then... at what frequency does it read the channel? Why add 1000 to the buffer, why not 100000?
01-09-2012 07:14 PM
Hey Tleilaxu_Ghola,
To answer your questions…
I hope this helps. Please let us know if you have further questions and the results of your testing.
Regards,
Kira T