Re: [Itifg-tech] Camera readout using itifg 8.4

[<M....@go...>]

Hello Tim,

Tim van Werkhoven <T.I...@ph...> wrote on 19.04.2008
20:23:46:

> Hi Matthias,
>
> On Apr 18, 2008, at 16:48 , M....@go... wrote:
>
> > ...
>
> Ah that worked for me, thanks. I noticed you used those flags in
> test_itifg, but it never occurred to me that those flags were that
> important.
>
> Now that O_APPEND seems to influence the drivers behaviour quite a
> bit, are there other flags that are important? I see you also use
> O_SYNC which supposedly explicitly synchronizes the read/write calls
> in memory, blocking until the call is complete. Is this also necessary?

There are:

O_RDONLY; O_WRONLY; O_RDWR: self describing
O_EXCL: only ONE can open the device at a time
O_NONBLOCK: don't block the read call till next frame
O_APPEND: don't use only one buffer; 'append to the current'
O_SYNC: keep the device synchronized to frames (blocks). For the
        dma device it means: start the dma right when the frame
        arises in on-board memory (this is what you usually expect,
        but if YOu want, You can start the dma when You want).
        For the exs device it means: if You write a new shutter time,
        update the shutter AFTER the whole frame is done (if You don't
        do this, Your frame can be broken)
O_DIRECT: no used

> I also noticed by running test_itifg through strace and varying the
> size of the buffer (-n) and the number of frames captured (-t) that
> you do *not* use lseek(fd, +LONG_MAX, SEEK_END), but instead do
> something like lseek(fd, bufsize, SEEK_END). It appears that this
> gives new frames until 'bufsize' bytes are transferred, after which
> you restart the cycle by calling lseek(fd, bufsize, SEEK_END) again.
> How does this approach differ from lseek(fd, +LONG_MAX, SEEK_END), is
> there a lot of overhead in restarting such a cycle and in what
> situations would you recommend one of the two approaches?

The is a fundamental difference:

1. lseek +LONG_MAX: grab mode

You are interested always in the MOST RECENT frame. If You have a longer
processing and there are other frames arrived in the meantime, they are
dropped. The Acquisition is forever.
test_itifg -c (contig) mode

2. lseek n*paged_size: snap mode

You are interested in ALL frames. If You have a longer processing and
there are other frames arrived in the mean time, You get always the
next frame, not cared how 'old' the frame is. You have to count the
number of acquisitions.

NOTICE: If You are on-time with Your processing (display, save,
calculations)
        there is no difference, but if not...

We usually use the grab mode for user live image display (including some
easy on-time calculations) and the snap mode for measuring series.


> Also, when I'm using +LONG_MAX to start capture, I notice that the
> values returned by SEEK_END and SEEK_CUR keep increasing with
> pagedsize every frame. Since the camera I'm using runs at about 1000
> fps, and pagedsize is 68 kb, this means that in about 31k frames,
> LONG_MAX bytes get transferred.
>
> I notice this happens at frame 30839 for me, and the return value
> shifts back:
> frame: 30835, seek_end returns: 2147172352, seek_cur returns: 2147172352
> i: 30836, end: 2147241984, cur: 2147241984
> i: 30837, end: 2147311616, cur: 2147311616
> i: 30838, end: 2147381248, cur: 2147381248
> i: 30839, end: 2147450880, cur: 2147450880
> i: 30840, end: 1073778688, cur: 1073778688
> i: 30841, end: 1073848320, cur: 1073848320
> i: 30842, end: 1073917952, cur: 1073917952
>
> while 2147450880/pagedsize == 32 768, 1073778688/pagedsize == 15
> 420.7647, which is not an integer number. How does this influence the
> general operation of itifg and how should I take care of these events?

Oh dear, You are right!!!

The overflow calcualtion here is (itifgBuf.c:buf_int_overflow()):

  if (buf->present + buf->isize == LOFF_MAX ||
      buf->present + (iti_loff_t)buf->isize < buf->present)
    {
      iti_loff_t offset = (iti_loff_t)1 << (sizeof(iti_loff_t) * 8 -2);

      buf->present -= offset, buf->current -= offset;
      overflow = TRUE;
    }

which isn't aligned to buf->isize (item_size: frame size here). :-(

Please try a offset %= paged_size; for now (this is, what we do).
I have to fix it!

Since we only use 64bit, the overflow isn't as much.

> Also, is it correct that:
> - the return value of lseek(fd, 0, SEEK_END) is the address where the
> next byte read from the grabber will be written, meaning that the
> newest byte in memory is located at the return value - 1?
> - the return value of lseek(fd, 0, SEEK_CUR) is the address where the
> user needs to read next, i.e. the address up to which the user has
> processed data?
> - the difference between the return values is the amount of new data
> waiting in the buffer for processing? In the test program this value
> is always equal to pagedsize, but will this increase to n*pagedsize if
> the program cannot keep up with the camera and the buffer starts
> filling up?

1./2.)
Yes, the idea behind it is a producer/consumer with a read and write
pointer.

3.)
This differs in grab/snap mode (see above)!.

>
> > ...
>
> Ok, so the 80ms is an empirical value, you know the readout time of
> the vossk-ccd1300b camera yourself. I've also found the dalsa camera
> manual now which makes things a bit clearer. I haven't tried
> triggering exposures myself yet, but it's something I'll try when I
> have time.
>

OK.

> Again, thanks :)

You are welcome!

> Tim

                                          Regards

                                          matthias
_________________________________________________
Matthias Stein,
GOM Gesellschaft fuer Optische Messtechnik mbH,
Mittelweg 7-8, 38106 Braunschweig, Germany
E-mail: M....@go..., Internet: http://www.gom.com
Tel.: +49 (0)531 39029-0, Fax: +49 (0)531 39029-15
Amtsgericht Handelsregister Braunschweig, HRB-Nr.: 3131
Geschaeftsfuehrer: Dr.-Ing. K. Galanulis, Dr.-Ing. D. Winter


This e-mail is confidential. If you have received it in error, you are on
notice of its status.
Please notify us immediately by reply e-mail and delete this message from
your system.
Please do not copy it or use it for any purposes, or disclose its contents
to any other person;
to do so could be a breach of confidence.
Thank you for your co-operation.