LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

change exposure time of camera and take picture

Solved!
Go to solution

Hello everybody,

I am very new to the world of LabView. Please excuse my question if it is very simple.

 

I have a Hamamatsu Orca Flash 4LT. I want to write a program to change the Exposure Time of camera to 4 different values and take a picture of the object in each ET. In other words, I want my program to set the ET to 85 millisecond and take a picture. I also want the program to the the same job to ET of 75,65, and 55. So I have written a program and attached to this question. When I highlight execution (the icon which looks like a lamp in block diagram) and run the code, it does the job perfectly. It takes 4 pictures of the object and those pictures are correct. By correct, I mean that when I do the same job manually (without labview) and compare the 4 pictures from my code to the 4 pictures from camera's own software, the pictures are identical. 

 

However, when I do not highlight the execution (turn off the little lamp) and run my code, the pictures from labview are not same as the pictures from camera's software. I am sure that this problem has something to do with timing. I should put a wait time somewhere but I don't know where.

 

I would be highly apreciated if anyone can take a look and give me a hint. 

 

Thanks in advance,

 

Sina

0 Kudos
Message 1 of 4
(3,003 Views)
Solution
Accepted by topic author Sina90

There is one spot in your code where I can see benefit of a wait statement, and that would be between the function of Get Parameter, and Wait Next Frame.  I'm thinking it takes some time for the camera to execute the command to set the exposure time.  Since the while loop seems to run at a rate of about every 100 msec, and that still seems to be too fast, you'll have to figure out how much time to wait between those functions.  I'm guessing more than 100 msec.

 

I do have some questions about your code and things in there that seem to serve no purpose.

1.  Why do you have a case structure where you act on the iteration number, and do some math on that before multiplying with your exposure time?  In each one of those, the result of the math is multiplying the exposure time by 1.  Actually, instead of using a while loop, I would just create a For Loop and use auto-indexing on an array of your 4 exposure times.  To still have the ability to end early using the stop button, you can enable the conditional stop terminal on the For Loop and wire to that.

2.  You set the exposure time, then you proceed to read the exposure time.  But you don't do anything with the data you read.  So what is the point?

3.  You have 3 shift registers that seem to serve no purpose.  A cluster that enters the loop, but never changes.  And two orange Double floating point that seem to be related to the exposure times and get passed on to the next iteration, but you never do anything with that data in the loop.  And the fact you may add 1 to numbers that seem to be .085, .075, .065 or .055 just doesn't make sense.

4.  You have an IMAQ create in your loop, but you never dispose of that IMAQ reference.

Message 2 of 4
(2,968 Views)

Hi RavensFan and thank you very much for your comment.

 

You're very right, I wait time between get_parameter and wait_next_frame did the job. Obviously it took some time for camera to execute the order, and as you predicted, 150 msec was enough to solve the problem. 

 

I will also answer your questions for the record:

 

1. In my question I said my ETs are 85, 75, 65, and 55. I said this for simplicity of my question. The actual amounts for ET are 85, 75, 60, 52. The increment is not a constant number and those numbers do not have a linear relationship. 

 

2. After I set the ET, that block actually changes the ET of the camera. That is the whole point of it. Excuse my answer if I haven't understood your question correctly.

 

3. Some parts of my code are provided by the company and shift registers were a part of it. I didn't really put them there with a purpose, but I will try to eliminate those and see if the code works or not. Thanks for suggestion.

 

4. Isn't Imaq_write_file disposing the information?

 

Thank you very much for your help again 

Sina

 

 

0 Kudos
Message 3 of 4
(2,914 Views)

I'm glad to hear you were able to get the code working the way you needed.

 


@Sina90 wrote:

 

 

You're very right, I wait time between get_parameter and wait_next_frame did the job. Obviously it took some time for camera to execute the order, and as you predicted, 150 msec was enough to solve the problem. 

 

I will also answer your questions for the record:

 

1. In my question I said my ETs are 85, 75, 65, and 55. I said this for simplicity of my question. The actual amounts for ET are 85, 75, 60, 52. The increment is not a constant number and those numbers do not have a linear relationship. 

I'm not talking about the constant interval.  The fact is you have that number for a particular snapshot predefined in each case depending on the iteration number.  But you are also taking that iteration number, doing different equations on it in each case, but the result of that equation is always 1.  Then you proceed to multiply the constant by 1.  It is a lot of programming for no actual change in the constant you already defined.  I'm going to attach a modified VI that simplifies all of this and shows the method using the For Loop.

 

2. After I set the ET, that block actually changes the ET of the camera. That is the whole point of it. Excuse my answer if I haven't understood your question correctly.  No.  Writing the parameter sets the ET.  Reading it back doesn't change it.  Reading it back would be just so you can verify the change actually did occur.  But you aren't doing anything with that data right now.

 

3. Some parts of my code are provided by the company and shift registers were a part of it. I didn't really put them there with a purpose, but I will try to eliminate those and see if the code works or not. Thanks for suggestion.

That's good.  Any code that really doesn't do anything should be eliminated to prevent programmer confusion.  I can understand how it might be a remnant of some previous code.

 

4. Isn't Imaq_write_file disposing the information?

No.  The reference to the image still exists in memory, and you could proceed to use that reference if you needed to do something else with that image.  Look at the IMAQ palettes and you should see a VI called something like "Dispose Image".  That is what will get rid of the reference.  Each time you open a reference, you should have a corresponding close.  You could open, use (acquire, write to file), close each iteration of the loop.  Or you could open once before the loop, reuse that reference 4 times in the loop (acquire, write to file), then once the loop ends close the reference.

 

Thank you very much for your help again 

Sina

 

 


 

0 Kudos
Message 4 of 4
(2,907 Views)