[Help] LabVIEW Search Paths Questions...

Is the "Tools" \ "Options" \ "Paths" \ "Search Paths" stored on the PC that is running LabVIEW or stored in the currently opened VI?
Also can I specify relative search paths for example: "<topvi>\..\..\..\Library\MyLib\*"
Is the search recursive? i.e. If there are subfolders, with subfolders will it drill down looking for the missing VI's?
The issue I have is that I have a project in a directory structure defined by a configuration control program i.e:
Y:\Test Equp\Project\Modules\Library\MyLib\* (there may be one or more sub folders contain VI's).
Y:\Test Equp\Project\Modules\MyApplication\* (there may be one or more sub folders contain VI's).
On the target the structure might be:
C:\Final\Library\MyLib\*
C:\Final\MyApplication\*
The issue is when I copy the files from Y: on my PC to C: on the PXI rack and open the top level VI in "MyApplication", LabVIEW cannot see the files in the "MyLib" until I tell where one VI is in each sub folder in "MyLib". This is a pain, specially if I make changes and transfer the file back to my PC as I have too go through the process again!
If I can spec a search path for the library files then it should just find them on either my PC or the PXI rack...
Thanks
Christopher Povey
Senior Test Systems Engineer for BAE Systems.
Solved!
Go to Solution.

ChristopherPovey wrote:
Is the "Tools" \ "Options" \ "Paths" \ "Search Paths" stored on the PC that is running LabVIEW or stored in the currently opened VI?
It is specific to that PC. It is stored in the labview.ini file.
Also can I specify relative search paths for example: "<topvi>\..\..\..\Library\MyLib\*"
You can, but that's not really the solution to your problem.
Is the search recursive? i.e. If there are subfolders, with subfolders will it drill down looking for the missing VI's?
That's what the asterisk at the end signifies. From the LabVIEW Help:
After you select the directory, LabVIEW inserts the path in the text box to the right of the Browse button. You can edit the path in this text box. When you select a path, LabVIEW normally searches that directory but not its subdirectories. You can make the search hierarchical by appending an asterisk (*) to the new path item. For example, enter LabVIEW/*, LabVIEW\*, or LabVIEW:* to search LabVIEW and its subdirectories.
The issue I have is that I have a project in a directory structure defined by a configuration control program i.e:
Y:\Test Equp\Project\Modules\Library\MyLib\* (there may be one or more sub folders contain VI's).
Y:\Test Equp\Project\Modules\MyApplication\* (there may be one or more sub folders contain VI's).
On the target the structure might be:
C:\Final\Library\MyLib\*
C:\Final\MyApplication\*
The issue is when I copy the files from Y: on my PC to C: on the PXI rack and open the top level VI in "MyApplication", LabVIEW cannot see the files in the "MyLib" until I tell where one VI is in each sub folder in "MyLib". This is a pain, specially if I make changes and transfer the file back to my PC as I have too go through the process again!
If I can spec a search path for the library files then it should just find them on either my PC or the PXI rack...
Thanks
The location of subVIs is saved with a VI, and it's a relative path. Since you are moving both directories there shouldn't be an issue finding the subVIs when you open the top-level VI, so it's not clear why there's an issue here. Are you loading VIs dynamically?

Similar Messages

Labview doesn not care about "vi search path "?

We've had some problems with labview taking sub vi's from other library files than wanted. To clean up the mess once and for all I wanted to include the path to the active library files, and remove the <foundvi> from vi search path.
The added path is something like "\\acanova5\common\...", also tried the version "\\192.168.0.50\common\..."
So far so good, but when I open a vi that need sub vis (before located in now deleted lib files) LV don't find them. When then manually point to the lib file and point to the vi it is ok, but why doesn't it work as I expect?
I looked in labview.ini, and my path is the first in "vi search path" list.
Ola

We've had some problems with labview taking sub vi's from other library files than wanted. To clean up the mess once and for all I wanted to include the path to the active library files, and remove the <foundvi> from vi search path.
The added path is something like "\\acanova5\common\...", also tried the version "\\192.168.0.50\common\..."
So far so good, but when I open a vi that need sub vis (before located in now deleted lib files) LV don't find them. When then manually point to the lib file and point to the vi it is ok, but why doesn't it work as I expect?
I looked in labview.ini, and my path is the first in "vi search path" list.
Ola

TestStand 4.1.1 vi search path

    This is so low-level I'm almost embarassed to ask. I'm using TestStand 4.1.1 over LabView 8.6, both of which are licensed as full development systems.
In order for our organization to make better use of (non-NI or Labview) source control, we've created a common directory structure for several developers over several large TestStand/LabView projects. This includes areas for "common VIs" that are reused across projects. So I'm in the process of migrating a rather complex project into a new directory structure. The sequences and VIs in question were working perfectly under TestStand 4.0/LabView 8.5 prior to this attempted migration.
   My test sequences (and sub-sequences) can't seem to find needed VIs, even though they exist in directories that are included in the search paths I configured. (An annoying sub-problem is that TestStand appears to "hang" while the LabView interface underneath the TestStand window is prompting for a VI's location. I have to click the LabView item in the Windows menu bar to get LabView "on top" and see what the problem is.)
   I've already added several paths to both the LabView and TestStand VI search paths, and I've even checked the "search subdirectories" box, but the items are not being found. It's going to take weeks to lead TestStand and LabView by the nose to find all this stuff.
   I can't believe this would really be a bug. I tried searching the forums for an answer and had no luck. I can't be the first one with such a problem, so help me out with some search terms so I don't have to clutter the forum with such basic stuff. Thanks.
-M

trosier, Neurotika,
It appears as if LabVIEW is having trouble finding your VIs, not TestStand. When TestStand loads the VI you have designated as a code module into memory, if you have the LabVIEW development environment designated in the LabVIEW adapter settings, we tell LabVIEW to load the VI via its ActiveX interface.
If TestStand is unable to find the top-level VI, you will see a dialog like this:
If LabVIEW is unable to find a sub-VI, you will see a dialog like this:
Notice that the TestStand dialog has an additional checkbox at the bottom that allows you to select an absolute path. Also notice that TestStand specifies what file its looking for in the Files of Type box while LabVIEW allows you to choose All LabVIEW Files. Which dialog are you seeing?
Another way to test this is to try to open one of your VIs from disk (by double-clicking on it). If you get a Searching for SubVIs dialog, then it is LabVIEW that can not find the dependencies.
Or if you open the specify module pane of the sequence editor, if TestStand cannot find the top-level VI, you will see a file not found warning like this:
If TestStand can find the file, but LabVIEW cannot find a sub-VI, then you will not get a warning or error until the VI is loaded.
The reason that this matters is that TestStand and LabVIEW do not share their search directory lists. If you have moved files, you will need to know which application cannot find its files.
Message Edited by Josh W. on 04-23-2009 11:27 AM
Josh W.
Certified TestStand Architect
Formerly blue
Attachments:
subVI not found by LabVIEW.JPG ‏31 KB
TestStand file not found.JPG ‏7 KB
VI not found by TestStand.JPG ‏31 KB

VI Search Path not working in LV2011 for VI Server Plug-ins with exe

I have found what seems to be a problem with the search path when a LabVIEW 2011 built executable calls a Plug-in VI.
When the plug-in VI has subVI’s from vi.lib on its diagram the executable has to know where to find them. Not all VI’s in vi.lib are part of the run time engine or the dll’s that may get generated as part of the build. The things you have to do to make plug-ins work for an executable are explained in several Developer Zone articles. The article titled “How Can I Change or Set the VI Search Path for LabVIEW Executables” describes the ini file setting viSearchPath. When this is set to the vi.lib directory I have not encountered problems with previous versions up to and including LabVIEW 2010.
I have come across an example in LabVIEW 2011 where it doesn’t work. I have attached an example (I am using LV2011 SP1). It demonstrates the basic plug-in architecture. Everything works in the development environment. But it doesn’t work from a built exe. I haven’t included the actual built exe in the zip file in case that causes a problem downloading it. If you run the build spec from the src directory project file the exe should get generated in the bld directory. The problem appears to occur when certain VIs from the analysis library are in the Plug-in. In the example attached, the Plug-in VI is very simple but I have placed the troublesome SubVI on the diagram. The VI in this example where there is a problem finding it is the Butterworth Filter VI. I have placed it on the diagram in a conditional disable structure so it is easy to enable and disable. When enabled and you run the test Plug-in VI the error 1003 is raised, meaning a subVI cannot be found in the dynamically called VI (for example see this post). Note that a way round this may be to incorporate the Plug-in VI into the built exe but this shouldn't be necessary. It’s not a problem with this specific filter VI, as it occurs for other VIs I try on the diagram. However if you place an FFT VI on the diagram there is no problem. I suspect that one is built into the Run-Time Engine.
I also note I am running Win7 64 bit and 32 bit LabVIEW (note the relevant viSearchPath in the ini file – you may need to change if you are on different version of Windows). If the example is converted to LabVIEW 2010 everything works as expected for the built exe. I tried that on a colleague’s computer running XP and 2010 but I am pretty sure in still also works on Win 7.
Things I am suspicious of are that the analysis VI’s are part of a LabVIEW library (lvlib) and perhaps something has changed there? I understand there is a problem with OOP in LabVIEW 2011. Perhaps it is related to that as that seems to be an issue in 2011 (see this Discussion Forum post). Perhaps it is related to OS version?
I also tried generating a Source Distribution to extract out all the vi.lib VI’s and place them directly in the Plug-in directory. That didn’t help.
Interested in whether anyone else reproduces this behaviour. In any case something is different in 2011.
Attachments:
LV 2011 test Plug-in.zip ‏42 KB

I found some more out about this issue working with my local NI rep here in Australia. Apparently something has changed in the compiler between LabVIEW 2010 and 2011. Using the viSearchPath token in the ini file, as described in various Developer Zone articles, now guarantees that the Plug-in will not work. The only way to make it work appears to be to create a Source Distribution. I noted in my original post that I had already tried this and it would not work. It turns out that having the viSearchPath token in the ini file when using a Source Distribution causes the error 1003 to occur. When the token is taken out of the ini file the Plug-in (containing an analysis VI) with a Source Distribution works - in the simple example I posted.
Well I then found its a bit more complicated than this. It all worked for the simple example I posted. Recall we found the error when there was an analysis VI in the Plug-in VI. In our actual application (which is a large one) that calls Plug-ins - we still got the error 1003. By trial and error I found a workaround. There are certain Build Spec settings for the calling exe that I set and found worked. On the Additional Exclusions page I found that I had to make sure that I left unchecked "Modify Project Library File after removing unused members". I've always had trouble understanding the need for this setting. In the Build Spec Help on that page it notes that the build will take longer. In most builds you remove polymorphic VI instances, remove unused members of Project libraries and also Modify the project library file after removing the instances (this is a sub setting of the previous). This makes the exe smaller in size and a quicker build time. Obviously modifying the project library caused a problem. In the big application exe calling Plug-in, I probably have the same analysis VI on the diagram (I haven't actually checked and also whether it is the same polymorphic instance) and in the simple example I posted I definitely did not have VI in the calling exe example - so there may be some clue there. I should try putting the same analysis VI on the calling exe diagram in the simple example to see what happens but I'm running out of energy on this one :-(
So none of this gives me much confidence and I wish I could get a better explanation from NI regarding this behaviour to be sure I am not going to encounter a different problem for different calling exe and Plug-ins. I was advised that a CAR would be issued. Perhaps this is now expected behaviour for 2011 but it would helpful if some definitive explanation could be given about what has changed from LV2010. And an update of Developer Zone articles on the subject would be helpful.

Vi search path

Hello all,
I have a problem with "vi search path" in Labview.
First, here are information about our directories architecture to understand the problem.
We are using the following architecture for our developments:
Each project is located in a specific directory.
ex: Project 1 is located in D:\Data\PRJ1
Project 2 is located in D:\Data\PRJ2
In the project directory, there is a subdirectory called "TestTools".
All Labview developments for a given project are located in this directory
and its subdirectories.
ex: D:\Data\PRJ1\TestTools
In the TestTools directory, there are subdirectories:
--> ...\TestTools\Tests : containing test VIs (top level)
ex: D:\Data\PRJ1\TestTools\Tests\Test1.vi
D:\Data\PRJ2\TestTools\Tests\Test45.vi
--> ...\TestTools\Utils : containing sub-vi for the tests.
ex: D:\Data\PRJ1\TestTools\Utils\HF\HF_cfg.vi
D:\Data\PRJ2\TestTools\Utils\CAN\CAN_start.vi
If I add "[topvi]/*" in the "vi search path" menu, Labview will search
the sub-VIs for my application in the directory of the toplevel VI (and its sub-directories).
ex: if I open "D:\Data\PRJ1\TestTools\Tests\Test1.vi", Labview will search the sub-VIs
in the following directory: "D:\Data\PRJ1\TestTools\Tests".
Labview will not be able to find the sub-VI called "HF_cfg.vi" which is
located in "D:\Data\PRJ1\TestTools\Utils".
I can add "D:\Data\PRJ1\*" in the "vi search path" menu but It will work only for Project 1,
and it will not work for Project 2.
I must replace it by "D:\Data\PRJ2\*" to work with Project 2.
If I don't do that, Labview will not find sub-VIs for the tests of Project 2.
(or it will find wrong sub-VIs located in the directory of Project 1 !!)
This is a problem because we often switch from one project to another.
We close and re-open Labview when we switch from one project to the other to be sure
that Labview is not using VIs already loaded in memory, but we still have problems
with "VI search path".
Is there a way to configure Labview to search sub-VIs from an upper directory
that the topvi directory?
Something like that: "[Topvi]\..\*"
(the parent directory of the topvi directory, and all its sub-directories).
I tried "[Topvi]\..\*" but Labview does not support this type of directory.
Someone suggested me to use "Source code control".
I am using Labview Full Dev (not Labview Professional) so I can't use "Source Code Control".
Is there another solution for my problem?
Thanks for your support.
NLu

Dear NLU,
the behaviour is somehow strange. I have projects with some similar folder layout in which sub-VIs are located under ..\..\DMS\sub.vi relative path from the toplevel VI. The search path is set to default. These VIs are really sub VIs not dynamically loaded. The toplevel VI holds the relative path to its sub VIs if they are on the the same drive and the absolut path if the drive is different. This is a least true from LV 3.0.1 to LV 7.1 under all Windows OS I have used (95 and ME I haven't used).
Unloading LabVIEW when changing the project is absolutly neccessary since LV holds a list of all folders where it have found VIs during a session. If you switch from PROJ1 to PROJ2 LV will load VIs with the same name in PROJ1 and PROJ2 but with different paths from the path used during working with PROJ1. Unfotunatly there is no menu entry for "Empty VI found list".
The solution provided by Evan can be made simplier. Create a shortcut to LabVIEW and use the command line parameter -pref to load the desired preference file. Look in the help under "LabVIEW-Defined Command-Line Arguments" for the exact usage.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

VI search path elaboration

Is there a tool or method that will cause LabVIEW to output the steps it takes when searching for subVIs as it loads a top-level VI? I'm seeing some non-intuitive behavior, and wondering if such output would help clarify what's going on.

By default LabVIEW searches through these locations in that order.
You can edit the order or add paths.
Some toolkits add some items in \resource and may point to additional locations relative to \resource. On the other hand if you are seing "Unintuitive" directory searches the most likly reason is its searching though <Foundvi> and your vis may be in a strange location.
Jeff

Including a LLB into the Teststand search path

Hello everyone,
on a testsystem I am using Teststand 2013 and Labview 2013. There are different measurement instruments in my system and right now I have all the VIs for controling these instrumtens saved as VIs on my system. Now I want to change this into an LLB. But when I do that, Teststand is no longer able to find the VIs inside the LLB, although the LLB is in the serach path of Testand. Since a lot of Sequence files access these VIs, it would be a lot of work to manually edit each VI call. Is it possible to include the LLB into the search path?
Thank you very much for your help!
Felix

Hi,
The search within a LLB is not supported within TestStand.
You need to update your vi path in the step settings like "MyLLB.llb\In An LLB.vi"
i.e. modify the path as llbname\\existingviname.vi.
If you put the llb in a relative path it should be fine.
Regards,
Ravi

Associate different vi search paths according project

HI
i Would like to know if it is possible to associate the option VI search Paths with the project
like this you can have different vi search paths for each project you handle
I have read that it can be possible with labview.ini but I have not seen how to do that
Thanks for your help

I believe this is what you are looking for:
How Can I Change or Set the VI Search Path for LabVIEW Executables?
If not, post back with some additional details on what exactly you want to achieve.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

How to create search path for the file on the desktop..

hello experts..
      I have used gui_upload module to upload the data from flatfile to the internal table, in that how can i create search path for the file selection in the selection screen, also please help me the code to update the ztable.
thanks

HI
If iam not wrong you want to select a file from a location that you don't know so if this is ur problem then use the function module
F4_FILENAME
this FM helps to locate and select the desired file from the system.
Sample code that you can check is
How to get windows filename
PARAMETERS: lv_file LIKE rlgrap-filename.
Method 1
    CALL FUNCTION u2019KD_GET_FILENAME_ON_F4u2019
    EXPORTING
    MASK = u2019,.txt,.*u2019
    STATIC = u2019Xu2019
    CHANGING
    FILE_NAME = LV_FILE.
Method 2
CALL FUNCTION u2019F4_FILENAMEu2019
EXPORTING
         program_name = syst-cprog
         dynpro_number = syst-dynnr
         field_name = u2019 u2019
     IMPORTING
         file_name   = LV_FILE.
Regards
Pavan

Portal Help Article search only works english

Hi!
I know there are similar questions and answers but none helped me so far :(
It's a new SCSM 2012 R2 install and all seems to be working.
BUT when changing display language in SCSM SSP from english to finnish the knowledge article search does not work.
I get this in the Portal server even log:
An exception was thrown while processing GetManagedEntitiesByManagedEntityTypesAndCriteriaWithInstanceQueryOptions for session ID .
Exception message: The creator of this fault did not specify a Reason.
Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnknownDatabaseException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Invalid locale ID was specified. Please verify that the locale
ID is correct and corresponding language resource has been installed.).
Data Access Layer rejected retry on SqlError:
Request: MT_Select_FullTextSearch_ca1410d8-6182-1531-092b-d2232f396bb8 -- (BlobJoin=True), (Status_BC4CF092_4309_1838_5E8F_C138367177060=761b8724-8307-8f26-3dc5-cf017922b603), (ObjectStatus_4AE3E5FE_BC03_1336_0A45_80BF58DEE57B0=47101e64-237f-12c8-e3f5-ec5a665412fb),
(FTLiteral0=%outlook%), (FTLiteral1=%outlook%), (FTLiteral2=%outlook%), (FTLiteral3=%outlook%), (FTLiteral4=%outlook%), (FTLiteral5=%outlook%)
Class: 16
Number: 7696
Message: Invalid locale ID was specified. Please verify that the locale ID is correct and corresponding language resource has been installed.

Hi,
and sorry for late response. I'm trying to user finnish language in the Portal.
In the meantime I've updated the SCSM to UR3 but no help... the same help article problem persists.
Help would be appreciated :)
More info on configuration:
- SCSM Datawarehouse Server (Windows 2012 R2)
- SCSM Management Server (Windows 2012 R2)
- SQL Server 2012 SP1 (Server 2012)
- And a separate server containing SSP and Sharepoint Foundation 2010
Okay, just tried adding swedish language pack to Sharepoint and Help Article search works also in Swedish but not Finnish. Could this be because SQL Server is missing Finnish support on Full Text Search?
Thanks,
Tommi
Answer: added stemmer and word breaker info from swedish to sql server registry for Finnish locale ID 1035 and updated languages in sql management studio.

Open Directory, third party LDAP search path problem on Snow Leopard

Happy new year folks,
I ran into an interesting problem this past week in regards to a third party LDAP directory in the Search path (which used to work on previous versions). The issue brings the server to its knees eventually. I'm still digging through the logs, but here's the general breakdown...
1. Add third-party LDAP to the OD node list. This has always worked on previous versions, and appears to still work at the most basic level. I can navigate the node with DSCL, read records, etc.
1. Add third-party LDAP to the OD search path.
2. Wait a few minutes....
3. The server begins to slow down. Apache, SSH, ServerAdmin service stop responding. I'm able to run "top" briefly, which shows an increase of threads.
4. Restart the server and quickly remove the directory from the OD search path
5. Server goes back to being rock solid with very nice response times for Apache, SSH, ServerAdmin, etc.
If anyone has any debugging suggestions, or has seen this before, let me know.
Jaime
--- Below is some console output leading up to the chaos. Before adding to search path, everything looks good --------------------
bash-3.2# dscl
Entering interactive mode... (type "help" for commands)
read /LDAPv3/ldap.itd.umich.edu/Users/jaimelm cn
dsAttrTypeNative:cn:
Jaime Magiera
Jaime L Magiera 1
Jaime L Magiera
--- Add to Search Path, which hangs ------------------------------------------------------------------------------
bash-3.2# dscl /Search -append / CSPSearchPath /LDAPv3/ldap.itd.umich.edu
--- DSCL in debug mode contains the following ----------------------------------------------
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Client: ipfw, PID: 1097, API: libinfo, Server Used : libinfomig DAR : Procedure = getprotobynumber (13) : Result code = 0
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Client: sso_util, PID: 1103, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16779669 : Requested nodename = /Search
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Plug-in call "dsDoPlugInCustomCall()" failed with error = -14292.
2010-01-01 19:26:25 EST - T[0x00000001037A5000] - Port: 27151 Call: dsDoPlugInCustomCall() == -14292
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16779
707 : Requested nodename = /LDAPv3/ldap.itd.umich.edu
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 2 : Dir Ref = 16779707 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 167797072010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16779707
: Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAC : Dir Ref 16779707 :
Data buffer size = 1282010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16779
707 : Requested nodename = ConfigNode2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsFindDirNodes(), Server Used : DAR : 2 : Dir Ref = 16779
707 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: Requesting dsOpenDirNode with PID = 1114, UID = 0, and EUID = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsOpenDirNode(), Configure Used : DAC : Dir Ref = 16779707 : Node Name = /Configure
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsOpenDirNode(), Configure Used : DAR : Dir Ref = 1677970
7 : Node Ref = 33556926 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16779707
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16779707 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Configure Used : DAC : Node Ref = 33556926 : Requested Attrs = dsAttrTypeStandard:OperatingSystemVersion : Attr Type Only Flag = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Configure Used : DAR : Node Ref = 33556926 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Search Used : DAC : Node Ref = 33556924 : Requested Attrs = dsAttrTypeStandard:LSPSearchPath : Attr Type Only Flag = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsGetDirNodeInfo(), Search Used : DAR : Node Ref = 33556924 : Result code = 0
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Client: dscl, PID: 1114, API: dsDoPlugInCustomCall(), Search Used : DAC : Node Ref = 33556924 : Request Code = 444
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Checking for Search Node XML config file:
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - /Library/Preferences/DirectoryService/SearchNodeConfig.plist
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Have written the Search Node XML config file:
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - /Library/Preferences/DirectoryService/SearchNodeConfigBackup.plist
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - Setting search policy to Custom search
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - CSearchPlugin::SwitchSearchPolicy: switch - reachability of node </LDAPv3/127.0.0.1> retained as <true>
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CSearchPlugin::CheckNodes: checking network node reachability on search policy 0x0000000000002201
2010-01-01 19:26:36 EST - T[0x00000001037A5000] - CCachePlugin::EmptyCacheEntryType - Request to empty all types - Flushing the cache
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Client: Requesting dsOpenDirNode with PID = 0, UID = 0, and EUID = 0
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : DAC : Dir Ref = 16777216 : Node Name = /LDAPv3/127.0.0.1
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : DAR : Dir Ref = 16777216 : Node Ref = 33556929 : Result code = 0
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CSearchPlugin::CheckNodes: calling dsOpenDirNode succeeded on node </LDAPv3/127.0.0.1>
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : DAC : Node Ref = 33556929
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : DAR : Node Ref = 33556929 : Result code = 0
2010-01-01 19:26:36 EST - T[0x0000000103181000] - mbr_mig - dsFlushMembershipCache - force cache flush (internally initiated)
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Client: Requesting dsOpenDirNode with PID = 0, UID = 0, and EUID = 0
2010-01-01 19:26:36 EST - T[0x0000000103181000] - Membership - dsNodeStateChangeOccurred - flagging all entries as expired
2010-01-01 19:26:36 EST - T[0x000000010070A000] - Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : DAC : Dir Ref = 16777216 : Node Name = /LDAPv3/ldap.itd.umich.edu
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CLDAPNodeConfig::InternalEstablishConnection - Node ldap.itd.umich.edu - Connection requested for read
2010-01-01 19:26:36 EST - T[0x000000010070A000] - CLDAPNodeConfig::FindSuitableReplica - Node ldap.itd.umich.edu - Attempting Replica connect to 141.211.93.133 for read
2010-01-01 19:26:36 EST - T[0x0000000102481000] - CCachePlugin::SearchPolicyChange - search policy change notification, looking for NIS
2010-01-01 19:26:36 EST - T[0x0000000102481000] - Internal Dispatch, API: dsGetDirNodeInfo(), Search Used : DAC : Node Ref = 33554436 : Requested Attrs = dsAttrTypeStandard:SearchPath : Attr Type Only Flag = 0
------- From another screen, I do "id jaimelm", which hangs ------------------------------------------------------------------------
: Requested Rec Names = jaimelm : Rec Name Pattern Match:8449 = eDSiExact : Requested Rec Types = dsRecTypeStandard:Users
2010-01-01 19:36:55 EST - T[0x00000001082A2000] - Internal Dispatch, API: dsGetRecordList(), Search Used : DAC : 2 : Node Ref = 33554436 : Requested Attrs = dsAttrTypeStandard:AppleMetaNodeLocation;dsAttrTypeStandard:RecordName;dsAttrTy peStandard:Password;dsAttrTypeStandard:UniqueID;dsAttrTypeStandard:GeneratedUID; dsAttrTypeStandard:PrimaryGroupID;dsAttrTypeStandard:NFSHomeDirectory;dsAttrType Standard:UserShell;dsAttrTypeStandard:RealName;dsAttrTypeStandard:Keywords : Attr Type Only Flag = 0 : Record Count Limit = 1 : Continue Data = 0
2010-01-01 19:37:03 EST - T[0x0000000108325000] - Client: httpd, PID: 157, API: mbr_syscall, Server Used : process kauth result 0x0000000102022B30
2010-01-01 19:37:03 EST - T[0x00000001083A8000] - Client: httpd, PID: 151, API: mbr_syscall, Server Used : process kauth result 0x0000000102022C50
2010-01-01 19:37:05 EST - T[0x000000010842B000] - Client: httpd, PID: 203, API: mbr_syscall, Server Used : process kauth result 0x0000000102022D70
2010-01-01 19:37:15 EST - T[0x00000001084AE000] - Client: httpd, PID: 994, API: mbr_syscall, Server Used : process kauth result 0x0000000102023890
2010-01-01 19:37:26 EST - T[0x0000000108531000] - Client: httpd, PID: 198, API: mbr_syscall, Server Used : process kauth result 0x0000000102023980
2010-01-01 19:37:31 EST - T[0x00000001085B4000] - Client: httpd, PID: 161, API: mbr_syscall, Server Used : process kauth result 0x0000000~

Hi
I'm in agreement with harry here but what I'm struggling to understand is why you are seeing this as a problem? I'm also struggling to see this as being a possibility in a single server environment if I understand your post correctly?
Promotion to OD Master with all that entails absolutely rests on a properly configured and tested internal DNS Service. The Kerberos Realm's foundation (and with that the ability of the server to perform its function as KDC and offer LDAP services) entirely depends on what is configured in the DNS Service. This will include the server name, domain name and tld. The Kerberos Realm automatically configures itself using that information. Likewise the searchbase.
Its more than possible to change the Realm name and with it the LDAP search base (in certain circumstances) and have an OD Master, however Kerberos won't start it won't need to as the KDC will be elsewhere. You generally see this when augmenting Windows AD with MCX. In that situation Realm name and search base will reflect what is set on the Active Directory. Client computers will use what is set there for contact and authentication information before looking at the OD Master for anything else.
Does this help? Tony

Can I programmatically change the VI Search Path?

I'm writing a simple program to periodically mass compile certain directories of my source code. In my directory structure I try to enforce rules about what is allowed to depend on what, so I want to programatically enforce this during the mass compile. To do this, I'd need to modify the VI search path before each directory is compiled. Is there any property or method available for changing the VI Search Path?

There is, but it's a private property, so it's not documented, and its behavior and/or availability can change with subsequent releases of LabVIEW:
Message Edited by smercurio_fc on 10-24-2007 05:24 PM
Attachments:
Example_BD.png ‏2 KB

Still LDAP server not responding when add to authentication search path ...

Howdy All,
I still have an OS X Server 10.5.6 (running Open Directory with its own Master directory) that when configured to connect to a corporate LDAP server indicates the server is responding fine, but when I add the server to the authentication search path, the server is no-longer responding.
I suspect this may mean the LDAP server is choosing to no-longer respond? Is it possible that the LDAP server could have my machine / IP address "black-listed" in some way? I have asked corporate IT but they didn't seem to think so (although I was queried before about repeated connect attempts).
Somewhat strangely I can configure a laptop client (OS X 10.5.6) to connect to the same LDAP server from an Ethernet port on the same LAN and it works fine. However, when I connect this laptop to the LAN through my server (WiFi NAT) I get the same issue as described above.
I don't have the firewall on the server turned on, I have played around with some certificates on the server, but have set "TLS_REQCERT never" in the ldap.conf file on the server (and client) as suggested by corporate IT. I have Kerberos running on the server and all else seems fine on the server.
Can anyone suggest what may be causing this? Or how I can debug the problem?
Thanks in advance.
Cheers,
Ashley.

Hi Jeff,
Thanks for your post. That said, I'm not sure how you got the impression that I wish to go to Maine I'm happy here in Perth, Western Australia.
Jeff Kelleher wrote:
Connecting a Mac to an LDAP server is a far cry from connecting a OS X Server to an existing LDAP server. Not that I could necessarily help, but asking how to connect an OS X Server to an LDAP server is a bit like asking "guess where I am now, how do I get to Maine?"
You need to provide as much info as you can.
Seriously though, I'm not sure of the difference. I am using Directory Utility to allow this OS X Server to get authentication information from an LDAP server just like an OS X Client would.
I have Open Directory in Server Admin just setup to connect to a directory system (i.e. the organisation LDAP server), not a master or replica.
My final goal is to allow access to an OS X TeamsServer Wiki by users who are authenticated against the LDAP server (rather than having to have separate accounts, logins, on the OSXS.)
I am hoping that I can use a group from the LDAP server to define the team, but perhaps I will have to run a standalone OD. I hope then I can add LDAP users to the OD group.
What other information would help?
Thanks,
Ashley.
OS X Server 10.5.6

How to search paths work?

I can not get the search path to find a VI that is saved in an LLB file that is located in the same directory as the LLB file that contains the TOP-VI. My search path include both "topvi" and "topvi"\* but Labview will not search through the other LLB file, it only search the TOP-VI LLB file and through the directory itself.
I don't want to add any specific search paths for special directories. I think that using basic search paths, Labview should at least search all LLB files within the directory that contains the LLB file where the TOP-VI is located.
I know that I can just find the files manual and then save the VI but I am trying to understand how the search path is supposed to work?
What am I doing wrong? Is this a bug? Is there a work around or special search path that I should add to the options to make Labview search through all the LLB files?
Thanks
Roger Bald

Roger,
I see what you mean. This does seem a bit odd. If the subVI is relocated into the same library as the top level, it finds it, but not if it's moved into another library, or even moved to the same directory as the top level and not put in a library.
I tried this with the default VI Search Path setup, then added the <foundvi>\* to the path and got the same thing.
It does seem that there should be a way to have it search through the entire structure of the top levels directory.
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

Search Path Field Height

We have a large LV developer user base and our users are getting confused by the limitations on the search path fields. The lowercase q really looks like a q (see below), any ideas on how to change this to make it more clear?
Thanks!
Using LabVIEW2012 32bit

Ironically, in your message both characters "lowercase g and looks like a q" they both look the same. I understand, looking at the image that you are saying lowercase G and lowercase Q look the same, apparently because the field height clips the image?
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

[Help] LabVIEW Search Paths Questions...

Similar Messages

Maybe you are looking for