![]() ![]() LabVIEW comes with a library that already interfaces to some of these routines in vi.lib/Platform/ but this won’t be a quick drop in exercise. There is a small change that you could call some Core Framework shared library functions to turn the URL in a path. It’s absolutely not and especially changing anything with file paths and file handling is a major pitta to change in an existing software! The format you are using is an URL format and only would work when interfacing to high level Cocoa APIs in the NSFileManager namespace, except that Apple likes to introduce and a few versions later depreciate APIs like it is peanuts to rewrite your software every few years. Some command line tools tolerate the Unixified UNC syntax //server/share to mean the same as /server/share but that will only work if you have created a mount point in your local file namespace to the actual server resource. The MacOS X Posix file API that LabVIEW uses nowadays on all Unix like platforms has absolutely no knowledge of UNC. The Windows file functions can directly work with these UNC paths. The special support is mostly present in TextToPath routine since the \server\share\ can not be separated and needs to be treated as a single path component just like C:\ for a local drive path. syntax is called an UNC name and is really only a Windows feature that LabVIEW has extra support added to in order to recognize it but that support only exists on Windows platforms. LabVIEW file paths are just that: file paths. It would have been more useful if LabVIEW had a way to do this like on Windows without having to jump through these extra hoops of opening a local volume but this is at least workable. We are now investigating a call to the " System Exec.vi" function and it looks like, with this command, open 'smb://nfssvc0008/pdx/home0/gl_pdx_prod/' it opens a locally mounted volume gl_pdx_prod that points to the proper server folder, which can then be used with this LabVIEW path: Volumes:/gl_pdx_prod/Data.xls to access the file. Interestingly enough, the path appears to the Mac OS as a clickable link when in a document, and as such, it can be clicked and will cause the file on the server to open so it seems it is more akin to an HTML link than a file path. ![]() How should the path be specified to the remote file from the VI such that local mounting of the volume is not required?Īfter some testing on a Mac we discovered that the string-to-path function strips out the double forward slash delimiters that are used as part of the "smb://" that identifies the device as a network drive and replaces them with a single slash so that it looks to the LabVIEW open-file function like we are trying to open a local device/folder/file that does not exist. ![]() Smb://nfssvc0008\pdx\home0\gl_pdx_prod\Data.xls Smb:/nfssvc0008\pdx\home0\gl_pdx_prod\Data.xls On the Mac, it doesn’t let us enter the full path to mount the drive and load the file - the VI is rejecting the double forward slashes, instead replacing them with a single forward slash. Under Windows, the functional file path used by the program to find/use the networked file is this: We have had some success with it working, but only if the server location containing the datafile is mounted locally on the Mac and then accessed from that local location. I am trying to get that same application built for the Mac OS with the help of a colleague who does use a Mac and is getting started with LabVIEW on it. ![]() I am a long-time Windows guy who has built a LabVIEW application used by many in my organization for searching a networked datafile. ![]()
0 Comments
Leave a Reply. |