Failure: "units.c", line 334
LabVIEW version 3.0.1
Please record the preceding information
and contact National Instruments for
Technical Support

I don't plan on contacting NI because I doubt this version is still supported, at least not without a contract.

https://www.ni.com/en/support/documentation/compatibility/18/labview-and-macos-compatibility.html

This surprised me because I know the founders were hard core mac enthusiasts and also because usually large companies will put something like this on their road maps so that people can plan better.

A colleague of mine wanted to run an old app I had released on macOS a few years ago (labVIEW 17 was in the error log), and he reported that the app did not run anymore.

I figured that since he was using macOS Monterey on an Intel MBP, there might be a chance that releasing the app using LV 2021 would work. Since my MBP runs macOS Catalina, I released it on that, sent him the executable and instructed him to download the 2021 RTE.

That still doesn't work. I can't even make sense of the mangled error message he sent me.

I know that Monterey is not even a term on NI's website, but I would assume that some have tried it already and maybe even released LabVIEW apps on it.

Any hint as to what could be a problem in my workflow would be helpful.

PS: the app is native G, there is no .NET, Active X or whatnot. I can actually upload the executable if someone wants to try it out on a Monterey Mac.

https://forums.jki.net/topic/2676-vipm-2017-for-mac-is-here/

I'm experimenting with porting my existing LabVIEW application from Windows to Mac OS X. The code uses several instances of 'Build Path' function in 'File I/O' functions sub-palette. The 'Name or Relative Path' input is being connected with a 'string' data type rather than a 'file path' data type. With some quick code change and checks, I've realized that it's better to use the latter data type, so that the separator character '\' in Windows is automatically interpreted as ':' in Mac OS.

Some parts of the code, however, build up the string. E.g. a 'Format Into String' is used to output based on a format string, e.g. 'Images\%s.jpg'. Doing a 'String to Path' after this function does not automatically interpret the '\' in Mac OS to ':'. (I can imagine that it would be difficult for the compiler to recognize that a specific character is meant to be a separator and not part of a file/folder name.)

I can write more complicated code where the format string is itself concatenated based on the execution platform. Are there any easier or recommended approaches? Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform?

Thank you.

Does anyone with a similar setup have any suggestions on what settings to use?

Thanks guys.

I've finally managed to compile SQLite binaries for the Macintosh and have tested the SQLite API For LabVIEW on OSX Lion (10.7) but need some kind-hearted people to test on other OSX systems to establish a minimum version (in particular 10.4 to 10.6).

If anyone is interested and can spare a few minutes to try it out; please PM me with an email address and I will send the pre-release

If you want to try a preview release, you can download it here:

https://jki.box.com/s/d3ux8pknhu39znpc0re8

It supports Package configurations, building, repositories and The LabVIEW Tools Network. All the same cool stuff that the Windows version has. The power of LabVIEW allowed us to use the same code base for both Windows and Mac versions which was pretty awesome.

Let us know if you have any issues.

I am trying to install the VIPM for Mac and I seem to be gathering an error about not having permission to write to certain areas. My question is how can I go about fixing these permissions? I am the only user and administrator for my mac and running OSX 10.7.

Thanks in advanced for the help

PS... I attached a screenshot of the error screen

Does anyone know how to do this on the Mac?

I've been told in another post that NI has to receive written notice of the transfer to allow me to register a used version.  

Thanks  

I need to create program on Mac to communicate to serial device. This device use extended ascii code (0-255). I know that the first 128 characters are same between Ascii Mac and Windows. But different for next 128 characters.

Do know how convert them to be compatible between Ascii Mac and Windows?

(Mac OSX and Labview 2009SP1)

Regards

Eric

I recently upgraded from LabVIEW 7 that I used on Windows to LabVIEW 2010,which I now use on a Mac. Most of the program I made on the PC/earlier version seems OK on the Mac except I am having some difficulty reading the mouse to determine whether the left or right button was clicked. I was hoping someone might be able to shed some light on this for me?

I forgot to add that it's the MAC OS X version.

Any suggestions will be really helpful! Thank you!

Hello,

I recently upgraded from LabVIEW 7 that I used on Windows to LabVIEW 2010,which I now use on a Mac. Most of the program I made on the PC/earlier version seems OK on the Mac except I am having some difficulty reading the mouse to determine whether the left or right button was clicked. I was hoping someone might be able to shed some light on this for me?

I can't seem to depress the control button and drag to either expand/scoot the diagram, or to make a copy by dragging. Does anyone know the Fusion settings to allow this?

Bonus: in Bootcamp shift-ctrl-a does not align.

(BTW I'm going to try out LV Mac eval)

Thanks

cc

thanks,

-John

I use LabView 8.6 on Windows PC's to run instruments in my lab. The .vi's I've written all use DAQmx (version 9.0 I think) to access the hardware.

What I would like to be able to do is edit these .vi's on my Mac, then upload the edited versions to the Windows computers to execute. Has anyone ever done this or know if its possible?

All I've tried to do so far is open my .vi's on the Mac, and of course I get DAQmx errors and missing files (.dll's mostly). I've installed DAQmx Base on the Mac, but I can't convert all my software to use DAQmx Base on the Windows side because there are some functions that aren't supported by Base (DAQmx Events for instance).

Is there a way to 'trick' my LabView on the Mac to think its in Windows and actually load all of the 'Windows only' .vi's? Or will my software be messed up anyways when going back to Windows to execute?

Thanks for the help!

I just got my USB 9161 and 9211 thermocouple device working with the newly released version of DAQmx Base for OS X. I am able to read temperatures from LabVIEW but the DAQmx Physical Channel control does not automatically populate with the ID of my USB device. (Note that the phyiscal channel control does contain the PCI devices.) If I type in the name, Dev1/ai0 for instance, it works.

But so far, I can't find any way to query for attached devices without just trying to read them and checking for an error. This isn't particularly good because my software is running on several machines that all have slightly different hardware configurations. If I don't get an error reading an analog input on dev1, I only know that the device contains an analog input but I still don't know the device type. Is it a thermocouple device or a generic analog input device?

Anyone else run into this?

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

Not really a "Labview" question....but related.

I've "zero" experience with Macs so apart from a huge learning curve, I'm getting bogged down with multiple tool chains and a severe lack of understanding of MAC (which I think is BSD based).

I've released an API which currently supports windows (x32 and x64) and has been reported to work with Linux x32. These work because I'm able to compile dll and .so for those targets. I'd really like to include Mac in the list of support but am having difficulty compiling a shared library (dynlib?) that Labviewwill accept.

I have set up a Mac OSX Leopard 1.5 virtual machine with labview and Code:Blocks.It all runs (very slowly) but I'm able to compile a shared library in both x32 and x64 (Well. I think I can at least.. The gcc compiler is using -m32 for the 32 bit and won't compile if I have the wrong targets). The trial version of Labview I downloaded I know is 32 bit (got that from conditional disable structure) and I think the Mac is 64 bit.

So I have the tool-chains set up and can produce outputs which I name with a "dynlib" extension. However. No matter what compiler options I try, whenever I try to load a successful build using the labview library function (i.e. select it in the dialogue) it always says it's "Not a valid library".

Does anyone know what the build requirements (compiler options, architecture, switches etc) are for a Mac shared library? There are a plethora of them and I'm really in the dark as to what is required (i386?, Intel?, AMD? all of the above?, -m32?, BUILD_DLL?, shared?)

Any help would be appreciated.

No problem at all, as long as we are talking about Windows - you just have to chose which one of all the DB toolkits you want to use.

But this project is supposed to run on a Mac.

Does anyone know a LabVIEW DB toolkit for MacOS?

In case it matters: The MySQL DB itself will also run on a Mac, but on a different computer.

Thanks in advance for all suggestions!

Cheers

I recently found a nice presentation about the myths of Mac OS X.

Entertaining and interesting:

http://events.ccc.de/congress/2007/Fahrpla...ts/2303.en.html

I need help from someone who happens to be using LabVIEW on a mac. What is the LabVIEW folder structure for OS X i.e. which folders are there under the LabVIEW installation folder. Especially is there a folder named readme like in Windows with readme files, or is this replaced with a folder named unix like on Linux?

Regards,

Tomi

I have an old labview disk from work for 7.1 for Mac OS and at home I'm running Mac OS 10.5.1 on a Dual G5. Everything went well during installation and the 7.1.1 update.

So after installing everything I can open existing vi and the simple one I've tried works but Labview consistently crashes when I try to select "File - New", (not new vi).

Does anyone have any suggestions?

I saw this thread about running LabVIEW on the new Intel-based MacBooks, but I have a different question. Has anyone booted Windows on these machines and tried to run Windows LabVIEW?

There are basically two ways to boot Windows on the MacBooks. One is to dual-boot, and the other is to run a virtualization solution (like something from Parallels).

I'm imagining that LabVIEW itself might run fine in at least one of those scenarios (as long as Windows is happy, which reports indicate it is), but I'd be more concerned about NI-DAQ.

Any experiences? Any hypotheses? Any brave souls want to give me a bag of money to buy a MacBook with so I can carry out this daring expriment... for the good of the community and all?

Justin

I have many computers acquiring datas, and I need to read and write these datas from a single ethernet hard drive (LaCie 500 GB, FAT32).

On a Mac G5 with LV8, once the ethernet drive is mounted in the finder, I try to read a simple config (or text or binary...) file in labview, but I get an open/create/replace file code 10 error.

I've got the same behavior with a file located on a PC hard drive (mounted in the Finder too), but I don't have any problem with a file on a Mac hard drive.

It works when I try the same from a PC with LV8. For me, all this tells it's related to smb/cifs stuffs...

I tried manual path entries like : "file://Volumes/GRESSENSGRP;U676-BACKUP/Datas/file.txt", etc... but nothing works. I didn't find the same problem in the forums...

Any idea ?

thanks

Boris

For the wireworkers on the Mac and those interested in the topic who attend this year's NIWeek I would like to announce the session entitled ''LabVIEW and Mac OS X: State of the Union'' to be presented by my fellow compatriot Chris Salzmann from the Swiss Federal Institute of Technology (EPFL). The session will be in the ''Software Development Techniques'' track with the following abstract:

Attend this session to learn how to access Mac OS X features using LabVIEW, including the command line, pipes, Script, and FrameWorks. Explore data acquisition options and specific LabVIEW for Mac extensions for image acquisition, database access, and math.

Download File:post-1718-1142209434.zip

I suppose some know me as the notorious advocate for LabVIEW to stay on its initial heritage platform. I know I would better spend my energy on other topics but the circumstances force me to keep the issue recognized. Even though the present majority of LabVIEWers use LV on Windows there is still an active group of LabVIEW pioneers and very committed users who were faithful to NI as well as Apple for nearly two decades by now. Note that the success of the LV-environment was made possible by an initially very small community who recognized the potential and the beauty of graphical programming of DAQ solutions at a very early stage!

I personally never really understood the breakthrough of the MS-OSes but it obviously happened this way. If you work with LabVIEW on the Apple platform, if you consider this possibility in the future or if you believe in the fundamental value of keeping LabVIEW independent of computer OSes it would be a valuable service if you take the small survey under ''Measurement and Control Products for MacOSX'' at:

http://www.ni.com/mac

Thank you very much for your support.

Have some peaceful and relaxing days and a good start into 2006.

Urs

Urs Lauterburg

Physics demonstrator

LabVIEW wireworker since LabVIEW 2 on Apple Macintosh

Physikalisches Institut

University of Bern

Switzerland

I found this on ni.com (see atachment), but I'm not able to use the widget. I obtain "unable to locate VI" message with all config I Tried

Does anybody try to use it ?

Ptit bras

Download File:post-853-1125045422.zip