The MacView

Virtual Instrumentation from a Mac perspective

Monday, August 04, 2014

LabVIEW 2014, First 64-bit Version for Mac

It has been a while since I've posted here, but with good reason. We've been really busy working on rewriting large chunks of LabVIEW for Mac 64-bit (see also Christina Roger's mention).

LabVIEW originated on the Mac APIs. Since then, LabVIEW was ported to Windows and Linux, and more modern APIs on those platforms. However, the Mac code largely remained unchanged, except for a minor rewrite for Mac OS X. When Apple switched to the NeXT based Mac OS X, they provided an API set named Carbon, which allowed for much of the pre-existing code to come across without much change. When LabVIEW was ported to Mac OS X, we took advantage of several POSIX APIs that we had battle-tested on Linux, and there were some changes to take specific use of Mac OS X, but much of the old API usages were not changed.

Then Apple decided not to port Carbon APIs to 64-bit. Apple has also deprecated much of the Carbon APIs. So we launched out to rewrite the Mac-specific sections of LabVIEW to be more modern and take advantage of Apple's new and forward looking Cocoa API. We decided the best way to do this and make sure we didn't miss anything that still called into Carbon APIs, was to port LabVIEW to 64-bit on the Mac.

We didn't want to do another minimal-port like we did when we went to Mac OS X. We wanted to fix as much as we could. We put together a terrific team of great developers on the LabVIEW team, and got to work on evaluating what needed be rewritten, what needed to change and what should stay the same. So here are some of the differences between Mac 32-bit and Mac 64-bit and VIs to help with the transition.

Fast

Depending on the operation, 64-bit LabVIEW on Mac is noticeably faster. There are a couple of corner cases where small sub-sections of the code are slightly slower, but everything else we've tested is somewhere between slightly faster to much faster. We went down to the C-Code subroutine level to compare performance between 32-bit and 64-bit to make sure we were not slowing LabVIEW down in porting to 64-bit. We were pleasantly surprised.

POSIX Paths

This was long overdue. Paths in 32-bit are formatted in HFS Classic format. 64-bit uses the more common POSIX paths. It's mostly showing slash (/) instead of colon (:) between path elements (although there is more to it than that). 

There is also a little bit of magic that happens in 64-bit when a path in a string is converted to a path type that allows either format, and then converts it into POSIX style. You can try this by copying the path from the 32-bit path indicator and paste it into the 64-bit indicator. Once focus leaves the indicator, the path will be converted to POSIX format (it's pretty fun to watch).

This magic also happens when using the String to Path primitive. You can have a string of either format and it will convert it to a POSIX path. This makes it easier to transition between 32-bit and 64-bit as you are testing your VIs in 64-bit.
Some other VIs that assist in dealing with paths between 32-bit and 64-bit are Path to Command Line String.vi and Command Line String To Path.vi in Programming -> String -> Path/Array/String Conversion palette. These VIs are helpful in building a path that can be used in System Exec.vi or system shared libraries in a cross-platform manner. They have actually existed in LabVIEW since before 2009, but are added to the palettes now to assist in transitioning between 32-bit and 64-bit on Mac.

Another path related VI that is helpful for Mac users is Executable Path To Command Line String.vi. This VI helps in getting the path to the executable in an app.
This is particularly helpful writing cross platform code that will launch LabVIEW built apps, LabVIEW itself, or other GUI applications. Windows and Linux just take the path to the EXE. On Mac, the .app is really just a folder. This VI will give you a path to the executable you can call from System Exec.vi, in a cross-platform way. This VI did not make the cut for the palettes, but you can find it in vi.lib/AdvancedString.

POSIX Line Ending

Another long overdue change was the "platform line ending." Since Mac OS X, most Mac software uses New Line (\n), however LabVIEW clung to the old Mac Classic Carriage Return (\r). The End of Line Constant (I know the icon shows New Line/Carriage Return) in the String palette returns what LabVIEW thinks is the platforms end-of-line character(s). Windows returns Carriage Return/New Line (\r\n). Linux returns New Line (\n). Mac 32-bit returns Carriage Return (\r) and Mac 64-bit return New Line (\n).
To assist in handling line endings from various environments, we now have Normalize End Of Line.vi in the String palette. This VI has shipped with LabVIEW since before LabVIEW 2009, but is now available in the palettes. This VI takes a string and converts all the line endings in the string to a standard end of line. That way, no matter what the source of the string (Windows, Linux, Mac LabVIEW 32-bit, etc), you can normalize the end-of-lines in the string and then parse the string regardless of the source.

AESend is Dead, Run AppleScript Code Instead

LabVIEW used to communicate with other applications on the Mac using Apple Events via AESend family of VIs. We have removed those from the palettes and added Run AppleScript Code.vi (in Connectivity -> Libraries & Executables next to System Exec.vi). AppleScript is easier for most people to use, and you can test the code in Apple's AppleScript Editor app. The AESend family of VIs still ships with LabVIEW, but is deprecated and we encourage users to move to Run AppleScript Code.vi (NOTE: LabVIEW 2014, both 32-bit and 64-bit, shipped with a crash when running the AESend family of VIs. This is expected to be fixed in a future version). The AESend family of VIs will not work in 64-bit.

Unicode / UTF-8

Mac LabVIEW 64-bit is the first LabVIEW that supports Unicode. When displaying, entering, copying, pasting, etc. strings, 64-bit LabVIEW assumes all the data is UTF-8. This has several ramifications. First, you can put emoticons in text. Pretty cool, but not that helpful. The other implication is that now there is no limit to what languages you can use for file/folder names (this ones for you, Socrates). In LabVIEW 32-bit on Mac, we had users who would name their hard drive something meaningful in their native language, which LabVIEW would then choke on and report it couldn't open the VI. LabVIEW 64-bit, because all strings are UTF-8, can handle any language in the path.

CINs are gone, use Call Library Function Node

On all 64-bit LabVIEW platforms, CIN is no longer supported. All of the functionality is available via the Call Library Function Node (in Connectivity -> Libraries & Executables next to System Exec.vi). Since Apple supports Universal Libraries, LabVIEW on Mac does nothing special to differentiate between 32-bit and 64-bit in library names. If you have a framework or dylib that you want to call into from both 32-bit and 64-bit, make sure it is a universal binary. You can use the lipo command line tool to merge binary code from 32-bit and 64-bit into a universal binary.

Miscellaneous

There are separate installers for LabVIEW 32-bit and 64-bit on the Mac LabVIEW media. We recommend you install both, as not all NI toolkits and addons are available for 64-bit yet.

The Dock icon differs between 32-bit and 64-bit. Think of it as Coal (32-bit) and Solar (64-bit). The icons now also have the LabVIEW version on them. This makes it easier to tell the difference and switch between them when working with both simultaneously.


LabVIEW 32-bit is still in /Applications/National Instruments/LabVIEW 2014 folder. LabVIEW 64-bit is in a sibling folder named LabVIEW 2014 64-bit.

I encourage you to try out LabVIEW 64-bit and leave me a comment below as to what other differences you have found.


Labels: , , , , ,

21 Comments:

Blogger Unknown said...

As a LabVIEW user since LV2, it's great to hear it's getting some love! I still write on a Mac, even if it runs on a PC in the lab; I think it's good discipline to keep the code cross-platform.
Now, any chance of building NI-DAQmx...?!

Monday, August 04, 2014 11:42:00 AM  
Blogger Marc Page said...

It's great to hear from long time LabVIEW users. I know several people who develop on their MacBooks and then deploy to Windows. As far as future product plans, you know the standard tagline, "We are always evaluating product directions based on customer feedback." In other words, I cannot comment on future products.

Monday, August 04, 2014 1:22:00 PM  
Blogger Kirsch said...

This is great! Congratulations on all your team's hard work.

Monday, August 04, 2014 2:24:00 PM  
Blogger John Leeman said...

I second the cry for NI-DAQmx! With that I could finally stay on mac for everything in the lab and would probably use LV for more than I do currently. Great work!

Tuesday, August 05, 2014 5:45:00 AM  
Blogger Marc Page said...

Thank you Kirsch.

John, thank you for the DAQmx request. I'll pass that on to the teams responsible for it.

Tuesday, August 05, 2014 5:55:00 AM  
Blogger John Leeman said...

Thank you Marc. I appreciate all the awesome work you all do!

Tuesday, August 05, 2014 5:56:00 AM  
Blogger Axel Jäger said...

Where can I find an installer for the 64 bit version? All I get offered is the Mac 2014 Evaluation Media that does not contain the 64 bit installer

Friday, August 22, 2014 7:35:00 AM  
Blogger Axel Jäger said...

Where can I find an installer for the 64 bit version? All I get offered is the Mac 2014 Evaluation Media that does not contain the 64 bit installer

Friday, August 22, 2014 7:36:00 AM  
Blogger Marc Page said...

Axel,

Sorry about that. We do not have an evaluation copy of 64-bit Mac LabVIEW at this point.

- Marc

Friday, August 22, 2014 7:37:00 AM  
Blogger Marvin Perry said...

This is really cool, thanks! How does one obtain it? I received our media today and the Mac/Linux media did not contain the 64-bit versions, even though they were addressed in the README file.

Wednesday, September 03, 2014 8:28:00 AM  
Blogger Marc Page said...

Marvin,

I asked around and it looks like the Academic distribution does not ship with 64-bit Linux nor 64-bit Mac. The complete academic suite does not support 64-bit, so a decision was made, to prevent confusion, to not ship LabVIEW 64-bit.

Wednesday, September 03, 2014 8:48:00 AM  
Blogger Axel Jäger said...

Can you do anything about this? I think most of the people who are actually using lab view on a mac are students running it on their laptops.

Wednesday, September 03, 2014 9:13:00 AM  
Blogger Marc Page said...

Axel,

I'll see what I can do. I doubt I can change what is distributed where for LabVIEW 2014.

It appears that, currently, the only way to get Mac LabVIEW 64-bit is to buy a LabVIEW Full or LabVIEW Pro for the Mac (or get someone to buy it for you).

Make sure you talk to your Sales Representative and let him know. I'll see what I can do to influence the next release. The more noise from customers makes it easier to get changes made.

Wednesday, September 03, 2014 9:19:00 AM  
Blogger Ivan said...

Labview multi-platform user since version 3, I really appreciate that Labview 64-bit is released for Mac. It’s been many years now that Mac supports 64-bit, which allows to handle larger datasets, and these years have been frustrating with 32-bit Labview. A big thanks to NI for finally taking the wise decision to provide a true upgrade of the Mac/linux version, and a huge thanks to the developer team who did it!

Now, as an academic I am most surprised that the 64-bit version might not ship within our SSP. Actually I just renewed it for continuity, before its expected end, and with great expectation to switch to the 64-bit version on Mac. There was no indication on the quote that the 64-bit version would not ship. I’ll check that when I finally get the CDs. Actually, I find time to write this note because I am waiting for labview 2013 to complete type propagation, which takes minutes, loading only one of the four CPUs (!). Still a lot of frustration on large projects... and a encouragement for keeping Labview on the right train!

Saturday, September 20, 2014 12:19:00 PM  
Blogger Ivan said...

Received the latest release and used for a few days: it is really cool!!!!

64-bit is not in the box, trying to figure what we can do about it here...

If it's time to make a suggestion: it would be great to add minimal video read/write, just like PNG/JPG is on every platform. Video is everywhere now, doing without it is like not having sound/image five years ago. I insist minimal support is enough (read/write frame by frame with OS codec).

Thanks for all the nice work!

Thursday, October 02, 2014 3:25:00 PM  
Blogger Christian said...

I agree that embedding video is really a big feature need/request.

Friday, January 30, 2015 1:25:00 PM  
Blogger Christian said...

Also basic formatting and printing of reports would be nice. It appears that many of the report vis may be broken in the 64 bit Mac version.

Friday, January 30, 2015 1:26:00 PM  
Blogger Ivan said...

Hi Marc,

the 64-bit version for Mac is really nice.

I started using it and it makes a difference for large datasets, that simply do not fit in memory with the 32-bit version (reconstructing high resolution 3D volumes from projection scans).

However, I coud not shift all my projects to 64-bit, and the reason is one basic feature is still missing on Mac: basic video input.

So far I relied on the library developed by Christophe Salzmann, QTLIB, which is based on QuickTime. QuickTime is 32-bit, and has been replaced by AV Foundation, thus it will not evolve to 64-bit. There is no chance this solution will ever work on 64-bit Labview. On the other hand I guess it is now high time for Labview to offer basic video features in the standard dev package, just as jpeg or png read/write have been added some time ago.

I would like to promote adding functions such as video read/write with standard codecs for a future version of Labview on Mac. QTLib could serve as a template for developing the basic VIs for handling video (open, close, read frame by frame, append one frame, grab from webcam), which constitute a minimal subset of NI vision library. Such feature could be put forward in the next release of Labview, since there are so many applications nowadays with video. I mean video has become as widespread as PNG and JPEG images, it is really time to catch up.

Cheers

Ivan

Wednesday, February 17, 2016 3:09:00 AM  
Blogger Marc Page said...

Ivan,

I agree, Christophe's QTLIB was an amazing project. His library is 32-bit. The 64-bit API for QuickTime is a QTKit. It would be terrific if someone out there were to write a framework that exports a C API for QTKit to be used in LabVIEW. We don't have video on the near-term project list, so it would be up to the community to get this pulled off in the near term.

If I get some time, I may play around with it, but I can't promise anything.

Wednesday, February 17, 2016 6:29:00 AM  
Blogger Ivan said...

Hi Marc,

With the release of labview 2016 the issue of cross-platform support for video becomes critical.

As stated in the "features and changes" page: "NI no longer provides the 32-bit version of LabVIEW for OS X."

Up to now it was possible to use Christophe Salzmann's QTLib to work with video. This was great software because the very same "universal" VIs ran on Windows and OSX systems. However, this tool relied on QuickTime. QuickTime will not evolve (it has been replaced by newer libraries), and so does QTLib that is compatible only with 32-bit.

Thus all the code developed with labview including cross-platform video handling cannot be maintained and developed!

On the other hand, video is becoming an ubiquitous feature in computer technologies, from IT to mobile devices, to big data and deep learning. It is a strategic time to push for video on labview across all platforms. It is time for video handling VIs to appear in the standard dev package, just as jpeg or png read/write VIs were added after photos massively entered the computer world.

I propose the addition in the "Programming/Graphics&Sound" palette of a subset of VIs for handling video (open video file for read or write, read file frame by frame, append one frame to file, grab frames from webcam). There is no doubt that such feature will be valuable in a future labview release!

Friday, August 19, 2016 6:01:00 PM  
Blogger Marc Page said...

Ivan,

You are correct that Christophe Salzmann's video library was a huge benefit for LabVIEW users. While having the capability built-in LabVIEW would be convenient, I am constantly amazed at the incredible solutions that LabVIEW users create.

I would be happy to work with any developers who would like to work on a 64-bit replacement. There are several cross-platform, open-source video libraries out there that show promise as a replacement.

- Marc

Monday, August 22, 2016 7:14:00 AM  

Post a Comment

<< Home

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.