TMC wrote in message news:<506500000008000000FD500000-1023576873000@exchange.ni.com>...
> I'm currently using Matrox Meteor 2 Digital boards to capture images.
> I want to intergrate the ActiveX components provided with ActiveMIL
> into LabView.
>
> However simple it sounds in the documentation for MIL all my attempts
> at using the Grab method in LabView has failed. The general message Im
> getting back from the ActiveX method call (Grab) is that the Image
> buffer has not been allocated, this occurs regardless of me setting up
> the VI so it calls Allocate on the Image ActiveX object before the
> Grab method takes place.
>
> The boards and digitizers are all setup correctly as I can use
> InteliCam to test the cameras and it works fine. Im using MIL version
> 6.1.
>
> Does anyone have any experience with LabView and Matrox Meteor boards.
>
> I know there is a company that sells VI's directly for the Meteor
> boards but we would like to save on the expense of having to purchase
> those VI's and create our own ones that cover only the functionality
> we need.
>
> Thanks,
>
> Thomas M Clarke
Hi, Thomas;
I've also been using the Matrox Meteor Dig II and LabVIEW. My
situation is somewhat different in that the customer I have created
the program for provided some .dll's they created in C to control the
card. I started this project last November and was learning Labview
at the same time. Since I now have a lot more experience, I am
thinking of experimenting with the active X control to eliminate my
dependence on a .dll that I don't understand (don't have much C
experience). I intend to check this out this week, so could provide
some input to you soon.
I have had some struggles with the allocation but have found as long
as i allocate before the image grab and deallocate afterwards
everything is fine. However, I recently added a an IMAQ function to
save the image (meaning I had to "create" the image by allocating and
"dispose" of it when I was done. Before adding this, I was simply
graphing the frame grabber output (no image) as an array of numbers
converted to gray scale so no allocation was needed), and I have found
that this seems to conflict with the initial frame grabber allocation,
causing the program to crash when anything is allocated or deallocated
after this step.
I also looked into a company that created VI's for Meteor cards (I
think it was called Alliance Vision) and they did not make VI's for
the Dig II board which you and I have. I spoke with them last January,
and at that time they said they had no plans to creates them, unless
there proved to be a strong demand.
I'd be happy to correspond with you on this outside of this group, as
well.
-Paul M
