comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Passing file LUN to C routine
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Passing file LUN to C routine [message #35065 is a reply to message #34993] Wed, 07 May 2003 06:54 Go to previous messageGo to previous message
btt is currently offline  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
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: bug(s) in IDL5.6?
Next Topic: RFC 1: Common functions for beginners

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 18:31:49 PDT 2025

Total time taken to generate the page: 0.00245 seconds