Leaderboard

Well the business case is seeing the forest for the trees. Turf wars over libraries will never help LabVIEW become a mainstream programming language. CLAs should be banding together and working with NI to compete with C# and Java. Part of that work is sharing the libraries that make a bare-bones LabVIEW installation actually productive for large-scale app development. Kudos to all OpenG and LAVA contributors for getting us that far. I know everyone has proprietary libraries and has a right to keep them, I'm just saying that this is an issue that is holding the whole ecosystem back.

durnek60: I think the first thing that would come to my mind would be the second approach you have taken, gathering the data from the registry. I have not spent any time with the dll files and cannot help much with those. I'll think about it and see if another approach comes to mind.

On an unrelated note, what is your end application? It appears to me that you are having trouble getting the ueye drivers to work in LabVIEW. I have done this for use with an Edmund Optics camera and there were a few subtleties I discovered. If this information would be relevant to you, just let me know and I'll explain here in the forum.

As you already discovered, you will not get the results you expect by embedding a LabVIEW array in a cluster and passing that to the DLL, because LabVIEW does not handle arrays the way that a DLL does. You will need to use the LabVIEW memory manager functions to allocate space for the array of UEYE_CAMERA_INFO, bundle the pointer into a cluster, pass that cluster to the DLL, copy the data from the pointer location into a LabVIEW array, and dispose of the pointer. Modify the attached code so that it calls your DLL correctly (I do not have your DLL so I could not fill in the name and path to it), then try it. I don't know if it will work, but if not it should be very close. is_GetCameraList.vi

Neither have I. *pointed look at all of you*:-)

OK, according to the dll manual (as I read it) you have to change your cluster to an array of cluster which has the same number of elements, as the number of cameras at your system (1 element in your case). you can receive the number of cameras using the function "is_GetNumberOfCameras ()" of the dll (but for now the constant is much easier). If that does not solve the problem, try the following: Change the "number of cameras" value from U32 to I32 --> depends on how LONG values are represented in the dll. You might also try changing the data handle from "handle by value" to "pointer of handle" In the dll configuration dialog there is a tab named "Error checking", just set it's property to maximum to receive error messages from LabVIEW. LabVIEW might show an interesting message pointing to the particular problem. Note: It's recommend to change the error checking back to normal before finishing the project, maximum error checking might cause problems later.

Hello, durnek60 First of all, change the string constants (SerNo / Model) of your cluster to arrays of bytes (numeric U8 in LabVIEW), since chars are arrays of bytes. The arrays must be initialized (at least 16 elements for each) or the dll will write data in places which are already in use by LabVIEW -> might cause LabVIEW to crash!!! The DWORD values should be at least U32 values. The last DWORD value (dwResrved) should be at least U32 and must be initialized like the char values. I recommend initializing the arrays using the "initialize array" VI of the array palette in LabVIEW (just to be absolutely sure). Hope that will help you. Sorry, can't help you with the configuration dialog, since I don't have an LabVIEW installation on my current system. If the problem does occur anymore you should also share the error messages and the configuration dialog of the your dll call. Greetings, LogMAN

Hi. Version 1.1 of VIRegister is now ready for download: Version changes from v1.0: - Removed the write- and read-functions without error terminals. - Removed type-dependency from VIRegisters, so it's no longer possible to have two different VIRegister types with the same name. - Added support for using the same VIRegister function with varying names and/or scope VI refnums (in a loop for instance). - Improved read performance when no write has yet been performed. - Added array of path to supported data types. - Updated the polymorphic 'VIRegister - Write.vi' to adapt to input. - Added 'VIRegister - Release.vi'. Cheers, Steen

Dear OpenG and LAVA Communities, I’m happy to announce that the OpenG 4.0 release is now available for download. OpenG 4.0 is a synchronised release of all packages that form the OpenG Library: The release includes the following features: Fix to all outstanding bugs (at design time). Package sources upgraded to, and tested in, LabVIEW 2009. Packages now built using VIPM 2010. I will be posting more about this release in the near future. On behalf of Jim Kring and OpenG.org, thank you. Jonathon Green OpenG Developer Installation Open up VIPM 2010 and if not configured to do so press Check All Package Repositories for Available Packages, then choose one of the two options below: Install the OpenG Toolkit package - this package will configure your system to install all the latest packages as well as remove any non-Library packages no longer required (don’t worry it won’t remove any VIs you are using). This is recommended for new or basic users. Manual installation - upgrade required packages on a package-per-package basis. Note: OpenG Builder is not part of the OpenG Toolkit and therefore will need to be manually upgraded (if required).