Repetitive image capturing

[willcai1]

This isn't so much a troubleshooting issue as it is me struggling to learn LabView on the fly. I'm using a ThorLabs CS235CU camera, and I finally got the vi ThorLabs included with their software working.

I've been having trouble writing my own vis and editing the ones provided to me. The attached vi is one provided by ThorLabs, and it acquires 1 frame from the camera when the trigger is pushed.

I would like to either write my own version of this vi, or edit this one, so that triggering it will run the vi for a user-specified amount of time and will capture and save 1 frame at an user-specified interval. I would still like to specify exposure and gain, and display the most recently captured image. Also, I'd like to be able to specify the directory the images will save to.

I know this is a lot to ask, but I'm fairly lost and could use a bit of a walk through the steps to achieving this. Any and all assistance would be greatly appreciated!!

[Albert.Geven]

Hi

This probably works, but has several problems.

The idea of finding a camera and using the first one and never look at the others is nonsens in real life.

So if you only have one camera skip it and let the user decide which cameras are used and maybe all of them.

Second, split the init doit and exit part in this vi in three vi's and let the doit part save the resulting images in a queue and let another part of your program read that queue and display and or save the images so that keeping up with a burst of images becomes possible.

Also not just pressing a button but also using events or timing can be used to trigger the image acquisition.

But most important start is to make your program modular by using subvi's and queues to have the time in parallel loops to handle the data.

A simple example of parallellism are the two producer consumer templates that can be found by

File/New in the template section 

Highlighted is the data example that is suitable to somewhere else to save your data, but the other example is also nice to look at to see how the triggerring can be done elsewhere.

[willcai1]

Thank you very much for the advice!

Letting the user decide what camera to use (because there's only one) was something I was planning on doing, so I'm glad you think it's a good idea.

I'm not quite sure what you meant by separating the init, doit and exit into 3 vi's. I'm assuming that the doit part is everything following arming the camera? If so, how would making a seperate vi out of everything prior help, other than making the block diagram less cluttered. Wouldn't making them a separate vi that I reference also remove my ability to edit the gain and exposure values on the front panel?

About the producer/consumer structure: Thank you for introducing me to this template, its been helpful so far. An issue I've run into is that the queue seems to not want to take .NET refnums, even when I've included something at the start of the queue to make that the data type.

Final question for this reply, how does the timer in the loop work? As far as I can tell, without it being attached to anything but a "milliseconds to wait" parameter it wouldn't do anything but count down. Does it prevent the loop from restarting until it's finished or something? Or does it need to be somehow wired to the loop or the queue?

[Albert.Geven]

Hi

Arming the camera would be part of doit. Because arming is needed (proabably) for every image you capture.

In my app (other camera) I always display as much images as possible in a separate window and if needed save the image to a folder with a fixed name and a time and date info in the image name.

That can be done every so many seconds or just for any reason the user may have.

I think that the refnum (for the camera) can be wired to both while loops if needed but probably only one of the loops needs the refnum. Once the picture is catched only memory needs to be accessed.

Gain and exposure controls can be on the UI and on change they can be send to the camera.

You can use an event structure for those changes.

The ms wait just counts down in parallel to other code (if not in a seq frame) and then just is finished.

This is one of the strongest parts of LabVIEW: Code that is not connected to other code runs in parallel with other code and for sure on multi core systems.

If you want to be sure that code does not run before other code, make sure that they are wired in some way. This is called sequencing by wiring.

This is fundamentally different from text based programming where the position in the text file determines the sequence.

[willcai1]

Thanks again for the response, Albert.

I'm still a bit confused with the queuing in the first loop. It still won't let me enter my image data into the queue (see attached images).

A quick clarifying question about the timer: I currently have it inside the producer case loop. If I understand what you said correctly, when I run the vi, the timer will start with the rest of the program, count down, and then do nothing. Is that correct?

[Albert.Geven]

can you send me the vi and the doc of the camera routines?

seems like something is not what I expect.

[willcai1]

I'm not quite sure what you meant by the camera routines, but I've attached 2 documents from thorlabs, the manufacturers of the camera I'm using, on how to use LabView for operating. I've also attached the vi I've been working on that used the consumer-producer loop as a base: however, I think I may instead use a while loop with a time delay inside to loop for the number of images I want with the embedded time delay spacing them out as desired.

[Albert.Geven]

Hi

This will be my last help for the next three weeks, Im going on a real vacation to Austria without laptop....

I would open the camera before the loop and use the TLCamera reference out to feed the upper and lower loop. Afterwards you only need to change the settings when they change, so compare them with the previous value in a shift register or better use internal in the upper loop an event case the acts on value change.

You should get the image in the upper while and put the image data in the queue. No references from .net but real data.

I had problems finding the dlls I found most of the vi's from Thorlabs so I could not save for LV2015

But add a screendump of what it should look like.

I always try to straighten lines to make my program readable and if not readable bugs hide in each corner.

So good luck, maybe somebody else with more experience in Thorlab can help you.

[Albert.Geven]

Finally found the dll's but sure this is my last post today.

So here is a bit cleaned up vi but not yet the data part filled in.

Look at the examples how to get the data of an image and how to save that to file.