03-17-2016 10:06 AM
Hi all,
I'm buidling a DAQ vi and when an analog input signal (force) reaches a maximum or minimum I need to grab a picture with the IMAQdx extension. The input signal has a fixed frequency of about 3hz and i need to acquire a few periods of data and take pictures of the sample. I was thinking about using some kind of peak detection on the input signal, and then by doing some math magic (keeping in mind the time to open the camera and take the picture and stuff) take pictures at the maximum and minimum values that follow. I've checked the peak detection examples and read some forum posts as well but didn't really find what I'm looking for.
I will probably put the code for taking pics in a timed loop and use the maximum or minimum to fire a software trigger since the few periods of measurement and photos will need to be repeated. The DAQ can be continuous that doesn't really mather.. When grabbing pics I'll save the data of a few periods to a TDMS file. Anyone with tips on the peak detection or other alternatives on how to to get the pics at the extrema? Picture below should make my problem more clear.
Thanks
Cedric
03-24-2016 02:33 AM
Anyone??
03-24-2016 02:56 AM
I am not familiar with image processing in labview, however recording for the whole time and then susbsetting this video/image stack for wanted frames seems to be viable, since peak detection has a slight delay and you need time for taking the images as well. Of course with long recording this video can grow quite large, so you should prepare with some storage.
Or if it is a fixed signal, you should calculate the timings for your recording in advance
03-24-2016 03:18 AM
Since the signal frequency is max 3 Hz and the max camera framerate for the current cameras is 14fps I guess the chance I have a picture at extremum values is very small. Calculating the time between calling the 'take picture command' and the actual photo seems to be the first step. It's a constant signal so I can calculate the max/min times as well. Using these values to call the 'take picture command' a little in front of the actual extremum seems to be the only option. Still figuring out how to do this though...
03-24-2016 08:19 AM
There are several issues/questions here. The Good News is you can probably "come close", but need to be a bit more specific about what you want and what you can tolerate.
You say your sinusoid is "about 3 Hz", which means that to get camera images at the peak and trough, you'd need to take 6 images per second. Yet your camera has a maximum speed of 14 fps. I'm assuming that you want a single image at the peak and trough, so you want an image (approximately) every 167 milliseconds. Assuming that the camera can do this, and that you can reliably "detect the peak", you still need to determine the (unknown, to me, at least) delay between the time you say "Snap" and the camera takes the image.
For the moment, assume you have already solved the problem of "detecting the peak", so you know when you'd like the image to be acquired. You can experimentally determine the delay by, say, feeding your 3 Hz waveform into an oscilloscope, synch the scope to the waveform (so you know, and can put a "dot on the screen" where the peak really is, and set the camera up to take an image at the Peak, at the Peak + 10 msec, at the Peak + 20 msec, etc. Now examine the images and see which is really closest to the Peak. [Yes, I know I said take the image after the Peak, but since your waveform is cyclic, a "delay" of 10 msec is equivalent to a "lead" of 167-10 msec ...]
So what's the easiest and potentially most accurate way to detect the peak? Again, if the signal is a sinusoid, don't detect the peak, instead detect the "zero-crossing" (which occurs before the peak, and hence if you need to take a picture before the peak, you have a little time). Look at a few cycles and determine the Max and Min (you might be lucky, or have designed things such that the mean is 0). Determine the Mean. Now you want to determine when you cross the mean. Note that the sinusoid will be changing at its fastest rate going through the midpoint, so you will get the most accurate time reading here.
You should now have all you need to accomplish your task (assuming that your Camera can "Snap" at a rate of at least 6 Hz). Note that if you didn't have such a narrow range between the max Camera rate (14 Hz) and the required acquisition rate (6 Hz), there's an even easier method to save the optimum image.
Suppose you needed pictures at the peak and trough of, say, an 0.1 Hz sinusoid, which has peaks and troughs occurring every 5 seconds. Set up your camera in video mode, give it a buffer of, say, 200 frames (probably overkill, but so what?) and start recording. Use your Peak Detector to tell you when the Peak occurs, determine the Buffer that corresponds to that Peak (or maybe the Buffer or two before that -- experiment with Delays), and save those Images.
Bob Schor
03-24-2016 10:14 AM
I grabbed 1 (sine wave) period of data before the actual measurement and calculated the max there. I got the timestamp and then calculated some timestamps in the future (adding 60secs in the pic) at which pics should be taken by adding n half periods of the sine wave. So I get an array of timestamps at which the pictures should be taken (see pic for code). I would work from that and try the grab and snap options both to see which is best. Would the trough 0 method be that much better? Since I'll have to figure out a time to subtract from those timestamps by trial and error anyway (depending on the speed of the cameras) to get a result at +- the max and minima I don't really see the benefits... If the cameras are to slow I can also skip a period (take a pic at the max then wait 1.5 periods and then take a pic at the next minimum and so on...) I've asked this to the researchers who'll work with the software to make sure.
03-24-2016 08:11 PM
Please submit VIs. I won't even bother looking at JPegs of parts of a block diagram for the following reasons:
I don't think you understood what I was trying to say. Let me try again, breaking this down into two separate (but related) problems. I'm going to assume that you have a periodic signal (such as a sinusoid), with or without some noise component, but with a fairly stable frequency. Here are the problems:
I want to tackle the second problem first. Just to simplify, let's assume that I have a strobe that flashes at exactly 1 Hz, and I know the time it flashes. When do I issue the LabVIEW Snap function? Do I do it precisely when the strobe flashes? Probably not, because there may be a slight delay between the time the Snap function runs and the Camera takes the picture, depending on USB delays, camera delays, etc. You need to figure this out and take it into consideration.
Now to how to estimate the time of extrema. Suppose the sinusoid goes from -1 to +1, and we're sampling it at 1KHz to get the value of the peak to the nearest millisecond. We know the peaks will be at sample 250 and 750, but how different will they be from the values at 249-251 and 749-751? Because the peak has slope of 0, the difference near the peak is small, namely 0.00002. How about the difference near the zero-crossings (0 and 500)? Here the slope is at a maximum, and the changes are on the order of 0.006, 300 times larger (or more sensitive). If there's the possibility of some noise in the signal whose peak you are trying to find, the problem gets harder. Estimating where the midpoint occurs and using that to compute where the peak should occur makes the strong assumption that your signal looks the same backward and forward (true for a sinusoid and similarly "well-behaved" periodic functions). Of course, there are "canned" Peak Detection algorithms ...
Bob Schor
03-25-2016 02:57 AM
Bob,
The jpg is every step of the stacked sequence I used to get one max and calc coming peaks. I pasted every step beneath each other in paint... I can send you the vi but it's part of a huge vi with multiple functionalities so I doubt you'd get the point. I can copy the code to an empty vi and post that if you want.
The signal is a force/displacement signal measured with DAQ box (case statement in pic sets the channel for daq) and it's coming from a tensile tester so it's a sine wave. I get what you were trying to say about the sine wave that the derivative is different near the zero crossing so the x value is more precise. Since this doesn't equal the time you have to call the camera though (time between calling snap and photo) I wondered if it's a plus to calc the zero crossing and change my program. After all I will have to calculate a time difference by trial and error anyway to subtract from my timestamp to get the camera to take a pic at the right moment so I thought the small difference between the time calculated with the max and the time calculated with the zero crossing could be worked away there.
Cedric
03-25-2016 04:27 AM
03-25-2016 04:50 AM - edited 03-25-2016 05:01 AM
It's not that simple. There are 4 camera's available. 2 USB camera's and 2 FireWire camera's. There are different possibilities for the camera setup so I'll have to figure out the delay between the grab signal and the actual photo for al setups by measuring the time difference with a test setup.... In the future there will be new USB 3.0 high speed cameras as well but that's easier just run video acq in a buffer ring and detect the correct frame for the timestamp you need. With cameras at 70+ fps (minimum) there will be a picture close enough to the extrema which occure 6 times a second.