DAQ peak as trigger for IMAQdx picture

[Hatef.fouladi]

ok so tell us why you want use trigger to grab and do not use continuous method of images capture and then select appropriate images based on time of captures and frame rate appropriate times could be achieved by signal of your daq
with 30 frp you have 30 point in second and it is enough to get enough picture and then select 6 of best image based on time

[Cedric1993]

Current firewire cameras are max 14fps but at image quality needed for processing afterwards (digital image correlation, cams are AVT stingray) this shrinks even further. 2 firewire cams are sharing the same firewire port so there's another bottleneck for the framerate. USB cameras are faster but not that fast either since it's on a laptop and going trough a hub. I'm working with what I have here since it's for an internship for school.
Need pics at extrema of 3hz signal so that makes 6 pics a sec. There's just no way the pics will be at the right moment. It's for a tensile test bench. I read the force signal with daq box and at max and min force I need to take a pic of the sample being tested. So I calced the times at which the max and min will accure and a bit in front (timed by using test setup) let labview take a pic so the pic is at the actual max and min (It's not an actuel trigger for the cams). That's the plan anyway.

[Hatef.fouladi]

OK test this trick
add one led to your Daq circuit and put your led in one part of your image. use ROI for that part and use algorithm to check if your led is on or off ( there is one color example in labview for test led is on or off )
also if your system is microscopy system you can add your microscope lighting system to your daq signal circuit it this time you can find the pick in image for select

[Cedric1993]

2 further quistions...

What would be the best way to take a picture with IMAQdx?? The configuration is done before the acqsuisition (open camera, buffers etc.) and I use multiple buffers and save the picture afterwards, so its just the part in the loops I'm talking about (see pic with quick setup I've made at bottom). I've timed the loops with difference between tick counts and shift register and the snap option is way slower than the grab- and low level option (+- 460 ms vs +- 245ms for the other 2).

Can I use the timestamp (received from custom keys, see http://digital.ni.com/public.nsf/allkb/D0488009D5AC87CF862579BA007B5F9B ) to ensure my picture is at the right moment? I'd use this in a configuration mode and calculate the difference x between the timestamp I want to take the picture and the timestamp from the actual photo. Then call my take photo command the time x before I want my photo. This instead of the LED option above to make sure the photo is at the right time.

Cedric

[Bob_Schor]

Sorry, I'd love to help, but since you persist in posting JPegs instead of VI, I'll refrain, as I'm not confident I'll be answering the "right question" or contributing to "the solution" to your problem (which I have yet to fully see).  See my earlier post.

Bob Schor

[Cedric1993]

Bob,

Here's the main VI. Since there are shared variables from third party software (labview based) and hardware as well you'll won't be able to run it so I didn't add all the smaller subVI's. (Couldn't find a zip creator on this laptop either for some reason)  But I think the name of the subVI's should be sufficient to get the picture of what they do. It's the fatigue test (case) part I'm working on but if you see something else you would change you're welcome to mention it as well. This is the last version I posted. It does what it needs to do but I'm still figuring out if the pictures are taken at the right moment (that's for tomorrow though).

If something is not clear you can send me a private message or post it here and I'll answer asap.

Cedric

[Bob_Schor]

First thing, banish, remove, and resolve never again to use a Stacked Sequence Structure.  Learn about State Machines and keeping variables in a Shift Register of a While Loop.  Here's an example (very incomplete) --

This has four States (governed by the Enum) -- Initialize, Wait for Trigger, Acquire Image, and Quit.  If you drag this Snippet into a LabVIEW 2015 (blank) Block Diagram, it will become code you can inspect.  I've shown one of your inputs here, "memorized" by the Shift Register so that any other State can use it.  The State is in the top Shift Register.  In the Wait for Trigger State, if you are polling, you ask if it is time to take the image, in which case you put "Acquire Image" as the next State, otherwise you put "Wait for Trigger" and wait again.

Try to make your VIs more compact so that the viewer (and yourself) can take more in without having to scroll around the screen.

See if you can refactor your code to make it more "self-documenting" (as I assert the State Machine model would do).  Once you have, I'll take another look ...

Bob Schor

[Cedric1993]

I'll change it to a finite state machine. Had been thinking about that but wanted to make sure it worked first... I'll post the vi in this message when I'm done converting it.

[Cedric1993]

Bob,

So I changed the stacked sequence structure to a finite state machine. For now I kept the while loop for the pictures instead of doing the wait on next trigger and take picture states you mentioned because it works but I might change it to your way at the end of my internship if I have spare time. Changed some other stuff as well to shrink the code. I'll do those things in the other case as well to simplify it (quasi static). It makes my .vi more fool proof for the users as well so only pros there.

I added the delay measurement vi as well. I build this starting from the example to read the timestamps from IMAQ keys to find the difference between the timestamp I get from the IMAQ keys and a timestamp from just before I call the ''get image'' block from IMAQdx low level. I'd like to call the get image a time x before I need my picture and determine x with the delay measurement vi. You think this is any good? Don't really see how else I could sync these because the led method mentioned above isn't easy as well. It's a basis this vi, I will add extra functionalities for more then 2 cameras and so on but you get the point I guess...

Cedric.

[Bob_Schor]

Cedric,

     I'm not 100% certain I know what you want to do (which is why I'm not giving a lot of specific advice here), but you would definitely benefit from having an available LabVIEW Guru to give you some general pointer and help you clean up your code. Once that is done, it will be a lot easier to "get the algorithm right".

     The following are "Style" comments (ever since I read Peter Blume's "The LabVIEW Style Book", maybe 8 years ago, with frequent cover-to-cover re-reads, I've been, well, "obsessed" might be a tad too strong a word, "a believer in" good Style when programming with LabVIEW).

•  If you put the Navigation window on, you can see that your VI is at least 7000 pixels tall, and appears to be extremely wide, though I can't find anything beyond around 2000 pixels.
• You have a Tab Control that appears to have no real purpose (except, perhaps, to give you more Front Panel space -- if so, there are much better ways to do this).
• You haven't learned to use Error Lines -- NI gives them to us with many functions, and they have an important purpose -- they enforce sequential behavior, and can obviate the need for Frames.
• I see you making an attempt at a State Machine ("Mode"), but instead of using a Shift Register, you are using a Local Variable.  Try your very best to never use a Local Variable -- yes, they are sometimes convenient, rarely necessary, but are fraught with Danger and obfuscate your code.
• Make liberal use of sub-VIs.  Your Main program should ideally fit on a single screen and should have lots and lots of sub-VIs, maybe organized as a State Machine or a Queued Message Handler or some similar structure that lets you deal with "Now What Do I Want To Do" issues.
• The Main routine should be all about what do I want to do, and should have very little to say about how do I want to do it.  The How should be at least one level, possibly two or three, down in a sub-VI.
• I notice that you have a whole slew of Controls "hanging in the breeze" in your Main routine.  Instead of spawning Local Variables from them, run them into Shift Registers on your While Loop an use them that way.  You might want to adopt the practice of not having Controls as Icons on the Block Diagram -- they take up too much space!
• How many Event Loops do you have?  Event Loops belong in their own While Loop.  I happen to like the Queued Message Handler as a fairly simple yet elegant way of getting Event information from the Event Loop into the Main loop -- you can also use the QMH "Messages" as a form of State Machine.
• Simplify, simplify, simplify.  [Often this means "bury the details in a sub-VI"].

Now for another "level" of Style Rules.

• Always develop code inside (or "in the context of") a LabVIEW Project.  [Exception -- a tiny test routine you generate by typing Control-N to bring up "Untitled VI", especially if you never save it.]
• Always create an Icon for every VI that you save in your Project (the Icon Editor is easy to use -- simply a Box with three short lines of text, "Init Camera" or "Snap Image", is sufficient).
• Always write Documentation for every VI that you save in your Project.  It should have a sentence saying what it does, and should list the Controls and Indicators (a.k.a. Inputs and Outputs), particularly if they are "not obvious".

Don't worry that you won't do this -- I have colleagues here who don't, and I yell at (well, scold) them.  My students, of course, don't do this, but they are usually a little easier to persuade, particularly when we "refactor" their code together and they see how much nicer it looks in a Project, split into 4 or 5 VIs, each with an Icon + Description (and they see how easy/fast it is to create Icons and Documentation), and fitting in 10 to 20 percent of the Screen area.

Bob Schor