| Passing file LUN to C routine [message #34993] |
Tue, 06 May 2003 11:22  |
btt
Messages: 345
Registered: December 2000
|
Senior Member |
|
|
Hello,
I have IDL interfaced (via DLM in C) with a frame grabber for collecting
video. I want to pass a file's LUN to C (repeatedly) so that the C
routine can write the most recent frame to to the file. My idea is to
place IDL in an interruptable loop (widget timer); in each iteration the
C routine is passed the LUN, writes the image and then returns a flag
such as the number of bytes written to IDL. Later I'll poke around with
the images by using an ASSOCiated variable within IDL.
It's a reasonable plan that is rapidly going amuck; what I have tried so
far causes IDL to crash. I have been using the IDL_FileStat() function
to get the required FILE pointer for C. The compiler doesn't C complain
about the setup; but it kills IDL when I run it. Methinks
IDL_FileStat isn't my friend anymore.
So ...
(1) How do I properly convert the LUN in IDL into a FILE pointer? (I
guess the question maybe better phrased as how do I get IDL to give me
the FILE pointer associated with the LUN I pass?) I think I need this
because the C routine fwrite requires it.
(2) Is this creating an unstable situation by leaving the file open all
the time until some condition is met in IDL?
(3) Would I be better off passing the filename to C and having C
open-write-close for each iteration?
Thanks,
Ben
|
|
|
|
| Re: Passing file LUN to C routine [message #35065 is a reply to message #34993] |
Wed, 07 May 2003 06:54  |
btt
Messages: 345
Registered: December 2000
|
Senior Member |
|
|
Nigel Wade wrote:
> Ben Tupper wrote:
>
>
>> Hello,
>>
>> I have IDL interfaced (via DLM in C) with a frame grabber for collecting
>> video. I want to pass a file's LUN to C (repeatedly) so that the C
>> routine can write the most recent frame to to the file. My idea is to
>> place IDL in an interruptable loop (widget timer); in each iteration the
>> C routine is passed the LUN, writes the image and then returns a flag
>> such as the number of bytes written to IDL. Later I'll poke around with
>> the images by using an ASSOCiated variable within IDL.
>>
>> It's a reasonable plan that is rapidly going amuck; what I have tried so
>> far causes IDL to crash. I have been using the IDL_FileStat() function
>> to get the required FILE pointer for C. The compiler doesn't C complain
>> about the setup; but it kills IDL when I run it. Methinks
>> IDL_FileStat isn't my friend anymore.
>>
>> So ...
>>
>> (1) How do I properly convert the LUN in IDL into a FILE pointer? (I
>> guess the question maybe better phrased as how do I get IDL to give me
>> the FILE pointer associated with the LUN I pass?) I think I need this
>> because the C routine fwrite requires it.
>
>
> I've never used IDL_FileStat, but I note in the docs it says you have to set
> the IDL_F_STDIO flag or it returns a NULL pointer. This would certainly
> crash your DLM.
>
>
>> (2) Is this creating an unstable situation by leaving the file open all
>> the time until some condition is met in IDL?
>>
>> (3) Would I be better off passing the filename to C and having C
>> open-write-close for each iteration?
>>
>
>
> You could do that, but why not get your DLM open the file and pass back the
> FILE pointer to IDL and then pass that on subsequent calls?
>
>
Thanks JD and Nigel,
The shared memory mapping idea is over my head. It sounds interesting
and quite similar to the DMA routines that come with the frame grabber
library. DMA, too, is over me.
A third little (expert) bird privately alerted me to the STDIO keyword
which I had not set. Just as Nigel points out, I was getting a NULL
pointer. Ouch. It was also recommended that I needed to prevent
buffering by setting BUFSIZE = 0. It works now. I'll try the passing
the FILE pointer generated in C to IDL to see how it works.
So now I have tried it two ways (a lot more actually, but we need not
mention those in public!)
(1) pass C the LUN and have the C write each frame: best rate about 15
frames per second (fps)
(2) pass C a predefined array into which it stores the latest frame and
return to IDL, then have IDL store the frame: best rate about 15 fps
No difference!
Each of these are performed in a event driven loop where the events are
simple timer events with TIMER = verySmallValue. I think I'll try it in
just a simple loop for fun.
Ultimately, I would like to access the video at full frame rate (30 fps)
- not that I need all the frames, but rather I can be sure I am
getting the every Nth frame. I seem to have other problems right now;
if I have C grab N frames as fast as it can without sending each frame
back to IDL
then I see frame rates as high as 22.5 fps. Hmmm. The promotional stuff
that came with the frame grabber says I can get full frame rate. Dang.
Thanks,
Ben
|
|
|
|
| Re: Passing file LUN to C routine [message #35068 is a reply to message #34993] |
Wed, 07 May 2003 02:56 |
Nigel Wade
Messages: 286
Registered: March 1998
|
Senior Member |
|
|
Ben Tupper wrote:
> Hello,
>
> I have IDL interfaced (via DLM in C) with a frame grabber for collecting
> video. I want to pass a file's LUN to C (repeatedly) so that the C
> routine can write the most recent frame to to the file. My idea is to
> place IDL in an interruptable loop (widget timer); in each iteration the
> C routine is passed the LUN, writes the image and then returns a flag
> such as the number of bytes written to IDL. Later I'll poke around with
> the images by using an ASSOCiated variable within IDL.
>
> It's a reasonable plan that is rapidly going amuck; what I have tried so
> far causes IDL to crash. I have been using the IDL_FileStat() function
> to get the required FILE pointer for C. The compiler doesn't C complain
> about the setup; but it kills IDL when I run it. Methinks
> IDL_FileStat isn't my friend anymore.
>
> So ...
>
> (1) How do I properly convert the LUN in IDL into a FILE pointer? (I
> guess the question maybe better phrased as how do I get IDL to give me
> the FILE pointer associated with the LUN I pass?) I think I need this
> because the C routine fwrite requires it.
I've never used IDL_FileStat, but I note in the docs it says you have to set
the IDL_F_STDIO flag or it returns a NULL pointer. This would certainly
crash your DLM.
>
> (2) Is this creating an unstable situation by leaving the file open all
> the time until some condition is met in IDL?
>
> (3) Would I be better off passing the filename to C and having C
> open-write-close for each iteration?
>
You could do that, but why not get your DLM open the file and pass back the
FILE pointer to IDL and then pass that on subsequent calls?
> Thanks,
> Ben
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
|
|
|
|
| Re: Passing file LUN to C routine [message #35117 is a reply to message #34993] |
Mon, 12 May 2003 09:33 |
btt
Messages: 345
Registered: December 2000
|
Senior Member |
|
|
Stein Vidar Hagfors Haugan wrote:
> Ben Tupper <btupper@bigelow.org> writes:
>
> [..]
>
>> (1) pass C the LUN and have the C write each frame: best rate about 15
>> frames per second (fps)
>>
>> (2) pass C a predefined array into which it stores the latest frame
>> and return to IDL, then have IDL store the frame: best rate about 15
>> fps
>>
>> No difference!
>>
>> Each of these are performed in a event driven loop where the events
>> are simple timer events with TIMER = verySmallValue. I think I'll try
>> it in just a simple loop for fun.
>>
>>
>> Ultimately, I would like to access the video at full frame rate (30
>> fps) - not that I need all the frames, but rather I can be sure I am
>> getting the every Nth frame. I seem to have other problems right now;
>> if I have C grab N frames as fast as it can without sending each frame
>> back to IDL
>> then I see frame rates as high as 22.5 fps. Hmmm. The promotional
>> stuff that came with the frame grabber says I can get full frame rate.
>> Dang.
>
>
> With your problem above (22.5 fps max), are you still writing to disk?
> Uncompressed, full-framerate video to disk is quite a challenge for a
> number of hardware configurations...
>
Hello,
I can get up to 22.5 fps (not consistently) when *not* writing to disk.
It is this fast when I get a stack of N images within C and return the
stack to IDL - the timing is done in C, as per the following C pseudocode:
//start
stack is a bytearr(width, height, n)
t0 = mytimer()
for i = 0 to N -1 Do
stack[i] = getTheData()
endfor
elapsedtime = mytimer() - t0
//end
frames per second (fps) is simply elapsedTime/N
Cleearly, the bottle neck is in the getTheData part, which I have
written myself. It is a series of "Start Frame" - "Make Sure It's Done"
- "Copy The Frame Data to Stack" steps. Mea culpa!
Cheers,
Ben
|
|
|
|
| Re: Passing file LUN to C routine [message #35118 is a reply to message #35065] |
Mon, 12 May 2003 08:25 |
Stein Vidar Hagfors H[2]
Messages: 28
Registered: October 2002
|
Junior Member |
|
|
Ben Tupper <btupper@bigelow.org> writes:
[..]
> (1) pass C the LUN and have the C write each frame: best rate about 15
> frames per second (fps)
>
> (2) pass C a predefined array into which it stores the latest frame
> and return to IDL, then have IDL store the frame: best rate about 15
> fps
>
> No difference!
>
> Each of these are performed in a event driven loop where the events
> are simple timer events with TIMER = verySmallValue. I think I'll try
> it in just a simple loop for fun.
>
>
> Ultimately, I would like to access the video at full frame rate (30
> fps) - not that I need all the frames, but rather I can be sure I am
> getting the every Nth frame. I seem to have other problems right now;
> if I have C grab N frames as fast as it can without sending each frame
> back to IDL
> then I see frame rates as high as 22.5 fps. Hmmm. The promotional
> stuff that came with the frame grabber says I can get full frame rate.
> Dang.
With your problem above (22.5 fps max), are you still writing to disk?
Uncompressed, full-framerate video to disk is quite a challenge for a
number of hardware configurations...
--
------------------------------------------------------------ --------------
Stein Vidar Hagfors Haugan
ESA SOHO SOC/European Space Agency Science Operations Coordinator for SOHO
NASA Goddard Space Flight Center, Tel.: 1-301-286-9028
Mail Code 682.3, Bld. 26, Room G-1, Cell: 1-240-354-6066
Greenbelt, Maryland 20771, USA. Fax: 1-301-286-0264
------------------------------------------------------------ --------------
|
|
|
|
| Re: Passing file LUN to C routine [message #35154 is a reply to message #34993] |
Mon, 19 May 2003 05:33 |
btt
Messages: 345
Registered: December 2000
|
Senior Member |
|
|
Stein Vidar Hagfors Haugan wrote:
> Ben Tupper <btupper@bigelow.org> writes:
>
> [...]
>
>> Cleearly, the bottle neck is in the getTheData part, which I have
>> written myself. It is a series of "Start Frame" - "Make Sure It's
>> Done" - "Copy The Frame Data to Stack" steps. Mea culpa!
>
>
> Ben, if you want to get full 30fps rate, you may want to reorganize this part
> to do the "Start Frame" action *last* (i.e. to let the hardware acquire the
> frame while you're doing other stuff). Often, hardware like that are driven
> with "callback" routines (for when a frame is ready).
>
>
Hi,
That sounds like an interesting idea. I'll try it.
Thanks,
Ben
|
|
|
|
| Re: Passing file LUN to C routine [message #35187 is a reply to message #35117] |
Fri, 16 May 2003 10:45 |
Stein Vidar Hagfors H[2]
Messages: 28
Registered: October 2002
|
Junior Member |
|
|
Ben Tupper <btupper@bigelow.org> writes:
[...]
> Cleearly, the bottle neck is in the getTheData part, which I have
> written myself. It is a series of "Start Frame" - "Make Sure It's
> Done" - "Copy The Frame Data to Stack" steps. Mea culpa!
Ben, if you want to get full 30fps rate, you may want to reorganize this part
to do the "Start Frame" action *last* (i.e. to let the hardware acquire the
frame while you're doing other stuff). Often, hardware like that are driven
with "callback" routines (for when a frame is ready).
--
------------------------------------------------------------ --------------
Stein Vidar Hagfors Haugan
ESA SOHO SOC/European Space Agency Science Operations Coordinator for SOHO
NASA Goddard Space Flight Center, Tel.: 1-301-286-9028
Mail Code 682.3, Bld. 26, Room G-1, Cell: 1-240-354-6066
Greenbelt, Maryland 20771, USA. Fax: 1-301-286-0264
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
