CNVCreate Reader: Service lookup failed for the server. errno: -6338

[AndyP123]

Hey guys.  I'm trying to talk to a LabVIEW application with my CVI app using shared variables but I'm running into some issues I can't seem to resolve.  The first issue has to do with this error in the subjectl line.  I get this only after calling CNVCreateReader twice.  I'm not sure if there is anything wrong with my formatting of the call but I suspect it has to do with something I'm forgetting to do prior to creating more than one reader.  There are a total of about seven shared variables that are initiated/instantiated by the LabVIEW program.  I am programmatically calling the LabVIEW program prior to running code that talks to the shared variables (LaunchExecutableEx).  My second issue has to do with writing to these same shared variables.  I can read from any single one just fine and the data matches up with the front panel of the LabVIEW application.  However, when I attempt to make a call to CNVWrite, I get an access denied style error (unable to write).  I suspect the LabVIEW programmer needs to do something to the shared variables to allow me to write to them but I just wanted to get you guys' input first.  I am running LabWindows/CVI v.9.0.1 and the LabVIEW executable was built in LabVIEW 2009 so I also have installed the LV 2009 runtime library. 

Thanks.   

[Mohan]

The service lookup failure error is most probably because the 'process' name in the variable path is incorrect and does not exist. The syntax in CVI is:

CNVCreateReader("\\\\my-server\\my-process\\my-variable", ...)

where, my-server is the name of the server (localhost if the variables are on the same machine) and my-process is the name of the process hosting the variable. In LabVIEW, I think the default name for the process is the same as the LabVIEW project name. You can also check the process name by running the Variable Manager or Distributed System Manager utility. You can also use the CNVCreateReader function panel in CVI and press ENTER on the pathname parameter to display a dialog that shows all the currently available variables.

The problem with being able to read but not write might be because the variables are configured as single-writer in LabVIEW, and so, only the first writer connection can write to the variable. If you want to be able to write to these variables from multiple connections, then you must remove the single-writer restriction.

[AndyP123]

Mohan,

     Thanks for your information.  I checked all my path names and made certain nothing was misspelled.  Everything looked good so I decided to test a theory.  I have the two programs communicating now as a result of my testing, but what I had to do was insert an artificial wait in between shared variable accesses (two different variables).  I kept getting either that "service lookup failed" error or another error that said "port connection reset by its peer".  The bottom line is it appears to be working now, I'm just not sure of the reason behind needing to wait.  If you have any further insight I would certainly appreciate your input.  Also, I ran the Variable Manager and a couple of the variables that I know to be 8bit unsigned integers appear as singles in the variable manager (even one that is an array of unsigned 8bit ints).  If there is a reason for this and if it may have something to do with my access errors, please let me know.  Thanks again. 

[Mohan · Accepted solution]

The wait is giving other threads time to execute their required tasks and this suggests that the threads were getting starved. The connection used by CNVReader has more latency and overhead because it is synchronous and requires two-way communication. If you are calling CNVRead in a loop, then definitely you should also sleep/wait in the loop or you will starve other threads. I recommend that you instead use CNVCreateSubscriber or CNVCreateBufferedSubscriber connections - these are asynchronous connections and are much more efficient and you will not need the wait.

The variable manager displays the type that was configured when the variable was created and not the type of the current value. It is possible that the variable was initially configured as single and not unsigned byte - you can still write unsigned byte value to a variable configured as single. I have also seen cases where the variable manager gets the type wrong in some cases. Please also check the type in Distributed System Manager - this is a newer program and replaces Variable Manager. Also, you should check how the LabVIEW program initially configured the variable. This type issue should not be related to the error you get when reading.

Message Edited by Mohan on 11-25-2009 08:40 AM