Pointers to Pointers, MoveBlock, and Stability

[rolfk]

Does Pl_exp_start_seq() only trigger an acquisition or is it guaranteed the acquisition is finished when that function returns?

Rolf Kalbermatter

[B_Kiddo]

First, thank you for answering.

Acquisition is finished when that function returns. "Each time it is called, it starts one sequence and returns immediately (a sequene may be one or more exposures)".There are more information about the CCD functions here: http://www.roperscientific.com/manuals/pvcam26_57-062-00.pdf

Another functions that I used at the end of my dll fuction AquireStandard() are:

pl_exp_finishe_seq() ; in principlenot needed since I use at the beginning only one frame

pl_exp_unint_seq();

free frame;

[kehander]

---

Acquisition is finished when that function returns. "Each time it is called, it starts one sequence and returns immediately (a sequene may be one or more exposures)".

---

This is a contradiction.  The sequence is started and the function returns immediately.  Therefore, acquisition is ongoing after the function returns.

It's been a long time since I worked with this stuff, so i can't be very helpful anymore - but I'm pretty certain about that much.

As I mentioned in that other thread about PVCAM, it seems to be important to call the relevant functions in a specific way, as suggested in this related Matlab script.

[rolfk]

---

B_Kiddo wrote:

First, thank you for answering.

Acquisition is finished when that function returns. "Each time it is called, it starts one sequence and returns immediately (a sequene may be one or more exposures)".There are more information about the CCD functions here: http://www.roperscientific.com/manuals/pvcam26_57-062-00.pdf

---

Returning "immediately" is anything but waiting until the acquisition is done! It simply starts a task in the low level driver who will at some point (vertical synchronization) start acquiring data and then write it in the buffer. How much the buffer is filled if any after the function returns is completely undefined. That is why you do not see anything after the first acquisition but only in the subsequent ones since you do in fact read the image from the previous acquisition.

Also when you read a small region the transfer more likely has been finished while with a bigger region you will only see the first scan lines being acquired yet. These remarks made it pretty obvious what you had been missing.

Rolf Kalbermatter

[B_Kiddo]

Thank you very much, rolfk, for explanations!

It seems to work fine now! Even Labview does not chrash (at least for now:smileyhappy :). Anyway, It seems that with the function Moveblock in the dll Labview is more stable than with the memcpy.

Best Regards

[B_Kiddo]

Dear kehander,

You managed to use the CCD camera with the Labview, right? You mentioned in the poster above somewhere that moveblock function causes problems when you need to call it repeatedly (what you need to do when you take big amount of frames) and you used 'less-tricky functions'. What functions were those? You as well used dll's and CLN at the beginning, aren't you?  I guess you used at the end Micro-Manager. Has Labview crashed so bad? I did the program now for the image acqisition and it works fine-do all the things that I need. Nevertheless, quite often Labview crashes when I exit VI, or write that there is 'Not enough memory to complete this operation'. What should I pay attention to?  It's a bit annoying. Is it a way to improve the functionality or it is better that I will use another way round through the Mathlab and micromanager, form your experience.

[kehander]

---

Is it a way to improve the functionality or it is better that I will use another way round through the Mathlab and micromanager, form your experience.

---

As I have mentioned, despite my efforts I never got image capture via PVCAM32.DLL to work properly in LabVIEW without causing crashes, so from my experience I cannot recommend trying to do it that way!

I think the "tricky functions" I mentioned above (it was a year and a half ago) were DSNewPtr and DSDisposePtr, which I was trying to use to allocate the memory for capture.  I briefly thought they might have been the cause of the instability, but I was wrong.

[CoraMary]

Dear B_Kiddo,

I'm doing a similar project for a Cascade II camera and I got into the same problem. Right now I'm trying to read the data from the camera using moveblock function. The Labview badly crushed last night and I was looking for a solution when I found out that you did this project back in 2009. If you don't mind, would you please post the frame acquisition code or at least a picture with the memory issue with pointers? Your help would be greatly appreciate.

Thank you,

CoraMary

[Chase.E]

Hi CoraMary,

I don't think B_Kiddo has posted since 2009. If you make a new thread and provide more details and what's not working and what you are trying to do, others on the forum may be able to help.