ChS

LV 2013 and DAQmx base 3.7 works like a charm for me. Chris

There are many ways. The Apple event way, the PSN way and the System Exec way. The latest one it probably the simplest and faster: to get all your processes in the format PID TTY TIME CMD ps -xc Get the PID of your process (first number in the line) Then do a kill -9 PID This will terminate your application abruptly! ---- You can also send a quit event to the selected application, do it using "vi.lib:Platform:AppleEvents.llb:AESend Quit Application" You'll need the application ID using "vi.lib:Platform:Targeting.llb:Get Target ID"

Booting the kernel in 32 bits solved the problem! Lets hope for a quick release of a 64 bits version of Visa and of course the rest of NI products line!

After updating from OSX 10.6.4 to 10.6.5, every time I open a VI or try to create a VISA resource name control , LabVIEW crashes. Both LV 2009 and 2010 exhibit the same behavior. By looking at the crash log, it seems that nipal has some problems when loading libSystem.B.dylib. I'll try to reinstall VISA and be back to you about the result. Ch (BTW, look at the funny way the editor interprets the crash log by replacing ": D" with smiley) Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x91362176 __kill + 10 1 libSystem.B.dylib 0x91362168 kill$UNIX2003 + 32 2 libSystem.B.dylib 0x913f489d raise + 26 3 libSystem.B.dylib 0x9140a9bc abort + 93 4 com.ni.framework.nipalu 0x2679d7df _palPrintToLog + 1547 5 com.ni.framework.nipalu 0x267a8fc3 0x2671f000 + 565187 6 dyld 0x8fe0ed6d ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 235 7 dyld 0x8fe0d31e ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 246 8 dyld 0x8fe0d2c2 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 154 9 dyld 0x8fe0d3d1 ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 61 10 dyld 0x8fe0200b dyld::runInitializers(ImageLoader*) + 34 11 dyld 0x8fe0b299 dlopen + 558 12 libSystem.B.dylib 0x913078a8 dlopen + 66 13 com.apple.CoreFoundation 0x96f8413a _CFBundleDlfcnLoadFramework + 218 14 com.apple.CoreFoundation 0x96f49b13 _CFBundleLoadExecutableAndReturnError + 1523 15 com.apple.CoreFoundation 0x96f49511 CFBundleLoadExecutable + 33 16 com.apple.CoreFoundation 0x96f4a189 CFBundleGetFunctionPointerForName + 57 17 com.ni.framework.VISA 0x2409cf9c visaLibSymbol + 68 18 com.ni.framework.VISA 0x2409d4a9 visaLibFree + 1267 19 com.ni.framework.VISA 0x240a1247 viFlush + 2194 20 com.ni.framework.VISA 0x240b484e viOpenDefaultRM + 1262 21 com.ni.framework.VisaCtrl 0x1cff5080 GetIOControlNames + 2570 22 com.ni.framework.VisaCtrl 0x1cff46f8 GetIOControlNames + 130 23 com.ni.labview 0x0086267e TagDriverNameProvider::GetIOControlNames(unsigned long, unsigned char const*, _LStrArray***, LvVariantArray***, LvVariant const*, long, void*) + 98 ch

SQLite converter This might of interest to someone with mySQL, PostgreSQL or Oracle database http://www.sqlabs.co...teconverter.php ChS

I guess it depends on the XCode and OS version you are using. There is an option to tell XCode to build for all format (i386,x64 and PPC) You may also links against various OS version. I usually do build for 10.5 SDK. Bitness? unless you have installed the SDK for 10.4 you should not have a bitness issue. The wrapper was needed since I (ok the OS) dynamically call the built in OSX version of sqlite using the -lsqlite3 in the linker flag. I had to rename calls to avoid conflict. This limit will go away if you compile the source for sqlite3. There are many to play with. I'm far for mastering all of them.... I'm looking forward to see it Chris

You are correct LV CLN only recognized "framework" This is strange, there are plenty of frameworks that you can link to, try carbon framework. Anyway LV VIs are often calling frameworks. To see an example check /vi.lib/Platform/Miscellaneous.llb/TickCount.vi See the attached file. I've made a basic wrapper that call sqlite3 functions. It links against the OSX version of SQlite 3 using the OTHER_LDFLAGS = -lsqlite3 in the linker options for the selected target. I have also modified the low level vis to include the OSX calls. See the provided All_OSX.vi to have a direct link to the modified VIs. I DID NOT DO CHECK SQLite PARAMETERS, you should not use the VIs as is, but carefully check that the c and LV code are in adequacy! In the terminal doing a > nm SQLite3x32_dylib show that you did not export the sqlite3 symbols! Note that LV does not unload a framework, you have to quit LV to reload the framework, this is quite painful if you don't have an SSD. Hope this help ChS LV_SQLite_v001.zip

> I too thought about using the pre-installed SQLite. But I'm not sure that I can guarantee that it will be 32 bit if the Mac starts in 64 bit mode. A wrapper is not a useful way forward as it requires upkeep of other code than Labview and > would require a lot of work re-implementing an interface which is already there. A windows wrapper went this route and its limited because of this. > From my limited reading of the "framework" implementation its a bit like a fat arch. So does that mean I can compile a 32 bit and 64 bit and include both in the framework? Does the pre-installed SQLite have both 32 bit and 64 bit > and switch transparently? Do I really have to type in each and every function rather than select it from the LV combo-box? XCode will generate 32/64bit framework. I did not check it but I'm pretty sure the dylib is 32/64 bit. Anyway LV on the Mac is still 32 bit..... And yes you will have to reselect the correct the lib and function name in you CLN. You could specify the lib name as a parameter of the CLN instead. > (And does that mean I select the ". framework" instead of the dylib?) There seems to be little information on > the net for Mac developers. Yes select "YourSQLite3.framework" in the CLN. Be carefull since LV does not unload it, you have to quit LV to load a new version! > I will have a play with Xcode. I know its installed but not sure where to find it (doesn't show up under applications). Its in /Developer/ or you may need to download the latest version from Apple. > I've only just learnt to use CodeBlocks so naively though it would just be a case of re-compiling for the Mac (its also > available for the Mac) It should work as long as it is able to generate frameworks. ChS

On OSX, LV expects to interface a ".framework" file. It has to be 32 bits as LV on OSX is still 32 bits. The easiest way to produce a framework is to use XCode and select new project / carbon or cocoa framework. XCode will prepare a skeleton ready to be used. As SQLite is built-in OSX, you should use the provided implementation and just write a wrapper around it. It is located in /usr/lib/sqlite3. This wrapper is only a few lines of code I've done similar wrappers for other libs. Let me know if you'd like to have a copy of the XCode project and files. Note that LV does not unload DLL/framework from memory. You have to quit LV. If anyone found an alternative I'm very much interested! Chris