Mark Smith

That's because the reference isn't a constant - the actual value gets assigned at run time so what you're essentially trying to do is get the current pointer value and assign it to a constant. This is probably a bad idea most anytime so LV keeps you from doing it. You can create a constant cluster with control ref constants (the easiest way I can think of would be drop controls from the refnum palette and then create a constant) and then bundle the actual control refs into that, but they can't carry control type information - you'd have to cast them to the correct type when you unbundle. I think what you could do is 1) create control refs from your controls 2) Create controls from the control refs (these will be strictly typed) 3) create a cluster on the FP with all of these control refs 4) save the cluster as a type def 5) use this type def to bundle/unbundle the control refs 6) pass the ref to this cluster between VIs Caveat! It's usually a bad idea to pass control refs instead of data between VI's in LabVIEW because this will always force execution into the UI thread. Only pass refs if you have a good reason - if the data could be on a wire, put it on a wire. Edit: Okay. I'm late to the show - what Ben said is the same only appears easier!

If I understand the question correctly, I think the best solution in this case is just to start the queued state machine that's handling the events in a separate thread. I presume you're calling the queued state machine inside the event case and it's blocking until it completes. If that's true, why not just handle the event case by putting the request on the state machine queue and returning immediately? Then the UI will be ready to handle any button clicks and pass the message on to the state machine thread - of course, I may have completely misunderstood the problem. At any rate, I find having more than one event structure on a UI to be a complete PITA. I think there's only one event queue (the real experts can weigh in here) so I find you have to carefully enable/disable controls because any control not handled by the currently active event loop that gets in the queue can cause the application to block forever - the event structure you hope will handle the event can't execute because the other event structure is waiting. This can be avoided and I know some people make this work, but every time I've tried it I've eventually found a better way. Mark

Not to be too pedantic - OK, so I am being a pain in the ass - but the languages you list above (c, pascal, etc) are actually called "imperative" languages by the CS types. Lisp is the best known "functional" language and ProLog is a "logic" language. Mark

Yet another one joins the ranks! Congrats! Mark

That would work as long as you could create all instances at the same time and load all the data members from the same default (including a "live" queue ref) - I'm talking by-val classes since that is where I use this. Otherwise, you still need some globally available LabVIEW construct (like named queues or globals) so each new instance can access the class static members. Or put the queue ref in a LV2 global - but that gets kind of circular. Mark

I haven't tried that - it would certainly make it much more difficult if the user has to re-create his own datatype that matches the private type to get a valid queue ref. Mark

I think this is the intended behavior of a class static member - all objects instantiated from the class share the same data space for the static member. This is useful in some design patterns like keeping track of the number of instances which might be useful if you're trying to manage a limited number of physical resources. The constructor increments the static counter and the destructor decrements it. Also, I use a single element named queue for this type of behavior. The data is in a cluster and the queue name is the class name. If any member of the class needs to read or write the static member they get a queue ref (using the name) and then read or write as required. The SEQ forces mutex-like behavior since the one must intentionally flush the queue before a write so any VI that gets a ref at this point is blocked until the writer is finished and vice versa - once a read operation pops the element everyone else waits until the queue is repopulated. The only problem with this is that VIs outside the scope of the class can "steal" the data by using the class name and getting a reference so protecting the data as private is problematic but unless a developer really wants to "break the rules" this works. Mark

So the question for me is. How get I the data from some cluster control which is located on some tabcontrol in some SetUp.Vi If I use the vi reference -> frontpanal ref ->controls[] ->tabcontrol -> etc. I will only get back variant data and I must provide additional structur information to use the VariantToData Vi. But if I do so, and I change some parts in the SetupCluster, I have to change the type Information in every single place. That's what I try to avoid. regards Peter Dan's reply has the solution - just make the SetupCluster control a typedef and then use the typedef everywhere you want to write or read the data. If you change the typedef and then execute "Apply Changes", the typedef will update everywhere you use it so all of the places you use the typedef to unpack the variant will update automatically. No work required on your part. Mark

First, I think you have to have some way to strictly identify the control you want to retrieve using the reference. Creating a typedef of the control and then using it exclusively to write and read the control cluster will keep your code in sync - if the typedef changes, all users (controls and VIs) will update automatically. Then, I'll be the first here to say that this is probably a BAD IDEA! The most important reason is that this forces all of your code into the UI thread - here's a link to and quote from an NI page http://zone.ni.com/r...xecution_speed/ Using Controls, Control References, and Property Nodes as Variables Though you can use controls, control references, and Property Nodes to pass data between VIs, they were not designed for use as variables because they work through the user interface. Use local variables and the Value property, only when performing user interface actions or when stopping parallel loops. User interface actions are historically slow on computers. LabVIEW passes a double value through a wire in nanoseconds, and draws a piece of text in hundreds of microseconds to milliseconds. For example, LabVIEW can pass a 100K array through a wire in 0 nanoseconds to a few microseconds. Drawing a graph of this 100K array takes tens of milliseconds. Because controls have a user interface attached, using controls to pass data has the side effect of redrawing controls, which adds memory expense and slows performance. If the controls are hidden, LabVIEW passes the data faster, but because the control can be displayed at anytime, LabVIEW still needs to update the control. So, what's a good solution? One is to pass the cluster by wire (simple and fast). If you use typedefs, this is every bit as simple as wiring control refs together. If you need decouplig from the wire, use a single element queue (one VI puts the data on the queue, another takes it off) and used named queues. If you must pass refs by wire from VI to VI, then you could pass the queue ref and use the queue as the data container. If you want mutilple listeners, use a Notifier. And lastly, I think a Data Value Reference (new in LV 2009) would work well, although I'm not up to LV 2009 yet. Mark

I once used a NI 6541 and if I recall correctly, the digital outputs were configurable - I looked it up and they can be configured at 1.8, 2.5, 3.3, and 5.0. These are not inexpensive units, however. Mark

As Rolf pointed out, you may have a dependency on a runtime library that isn't installed. I have found the Dependency Walker app very useful for troubleshooting his type of problem. It shows all of the dependent modules for a DLL in a tree structure and it's free. http://www.dependencywalker.com/ Mark

Create a property node for the button and use the Value (signaling) property - note that this won't work on booleans with latching behavior Mark

I took a look at your Car Wash and agree with the other posters (Mark and Eric) that overall it looks pretty good. A few thoughts, though. First, I think you'd get dinged for using globals - there's nothing you're doing with the global that can't be done with a wire and I think that's the criteria that would apply. If you really want a global functionality, use a LV2 (functional) global as that's what the exam guidelines state. Second, I think it's best practice to always initialize shift registers unless they are specifically intended to maintain state between calls. I don't know if the exam graders would ding you for this (since there are no functional problems) but I have found that sooner or later uninitialized shift registers (unless they're intentional) will get in some sort of state that will cause you headaches. Third, there's no description for front panel controls Fourth - the intializations for the globals (your constants) are arrays that aren't type def'd - I agree that arrays are useful for allowing the code to adapt to changes, but the assignment of sensors to wash steps should be an array of the CW_States enum.ctl type def (this type def already exists) - then the constant would be self documenting. The wash purchase options is also a little cryptic. I would think an array of type def'd clusters (each cluster contains a labeled boolean for each wash state selected) would be much easier to read on the BD. Fifth - the output of the Out_of_Position.vi is labled Boolean - that's not descriptive enough and you'd definitely get dinged for that. I know this is nit-picky, but I think these are the kinds of nits the graders will pick! Good Luck, Mark

I posted a solution to a CLD example here and got useful advice (and passed my CLD!). So I would say go for it - at the least, I will take a look at it and I'm sure others here will do the same. Just give us some time, since many of us are plenty busy. Mark

There's a set of tools at http://technet.micro...ls/default.aspx that could be useful if you are on windows - they extend the capabilities of the task manager and performance monitor that Mark Y suggested Mark

This won't be too detailed, but it should point you in the right direction - From the Application class properties you can get an array of all open Projects and from there you can get a ref to a specific Project. Then from the Project MyComputer property you can get the TargetItem and from there you can get BuildSpecs. Now you have a reference to the BuildSpecs and you can get a ref to the Children[] of the BuildSpecs and finally from there get a ref to the particular BuildSpec you want. Now, with a ref to the BuildSpec you want to modify, you can modify items inside the XML project file using ProjectItem Set Tag method. So, you do end up editing the project file but you can do it programatically using LabVIEW so the process can be automated. Mark

I just tried this on my system (LV 8.6.1) and passed a double control into the Flatten To XML function and got <DBL> <Name>Value</Name> <Val>0.12345678900000</Val> </DBL> which preserves the precision of the double - In LV 8.5.1 I get the results you describe. I thought I remembered something about Flatten To XML having some bugs fixed lately. So, if you can, upgrade to 8.6 Mark

Name: TCP IPv6 Tools for LabVIEW Submitter: LAVA 1.0 Content Submitted: 04 Jul 2009 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 7.1 Version: 1.1.3 License Type: Creative Commons Attribution 3.0 Potentially make this available on the VI Package Network?: Undecided Mark E. Smith Sandia National Laboratories --see readme text for contact information LabVIEW does not support IPv6 protocol (as of version 8.6) using the TCP/IP functions and there is no promised date for inclusion of IPv6 compatibility in an upcoming version. I have a project that requires IPv6 TCP communication so I requested that NI support my efforts which they graciously agreed to do. Christian Loew of NI created a proof-of-concept project using Microsoft Visual C++ to create a DLL that provided LabVIEW access (through a Call Library node) to Winsock 2.x. I have taken that proof-of-concept project and refined it into, as much as practical, a direct drop-in replacement for the TCP/IP functions in LabVIEW. Features: - Drop in replacement for native LabVIEW TCP/IP functions - Supports IPv4 and IPv6 - Compiled and tested for LV version 8.5, 8.0, and 7.1 Limitations: - Does not support name/service lookups – the user must supply a valid network address in dot-quad (IPv4) or colon-delimited hex (IPv6) – the loop back addresses of 127.0.0.1 and ::1 are acceptable - Only supports the Standard and Immediate modes for the TCP Read function. The Buffered and CRLF modes could be added (I just have no present need) - Windows only – uses the Winsock 2.x DLL. However, the only Winsock-specific functions called are WSAStartup (to initialize the DLL) and WSACleanup (to release resources). Everything else should be portable to a sockets implementation on Linux or MacOS (this is speculation only!) if anyone has a need. License This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. This package includes: Microsoft Visual C++ 2008 Express Edition project (lvipv6comm.sln) to create the Winsock wrapper DLL (lvipv6comm.dll) The Winsock wrapper DLL (lvipv6comm.dll) Example VIs – Data Client.vi and Data Server.vi are adaptations of the example VIs of the same name that ship with LabVIEW that use the IPv6 Tools instead of the native LabVIEW TCP/IP functions For LabVIEW 8.0 and 8.5, a LabVIEW project exists (TCPIPv6.lvproj) and the TCP function VIs are in a LabVIEW library (TCPIPv6 Comm.lvlib). For LabVIEW 7.1, the TCP function VIs are in a single folder. TCP IPv6 Tools for LabVIEW Version 1.1.3 Modified 15 Dec 2008 This version fixes a bug in the previous versions where the Close Connection function, when called on any connection created from a Wait on Listener, would close all connections created by the Wait On Listener. This happens because the Close Connection was executing a WSACleanup command on every call. If one executes a WSACleanup on a connection created from a listener, it closes all connections created in that listener thread. This fix is not an exact drop-in replacement for the LabVIEW native tools. It requires the user to set a flag on the Close Connection VI to prevent calling the cleanup if the connection was created by a listener. An example is included in the Multiple Connections Test VIs folder. This fix is implemented in all versions (7.1 - 8.5) ************************************************ TCP IPv6 Tools for LabVIEW Version 1.1.2 Modified 10 Dec 2008 This version adds GetType, Get Address, and GetPort functions - these functions take a socket handle and return the type (IPv4 or IPv6), the connected address, and the connected port. These may be used as part of this toolkit or can be used to return the same information from the native LabVIEW TCP/IP toolkit (Windows only). One needs to get the socket handle using the "TCP Get Raw Net Object.vi" found in "vi.lib\Utility\tcp.llb". Pass the Raw Net Object (socket handle) into these VIs. Note - these VIs are only compiled for the LV 8.5.1 version - they could be saved for previous and used in any version back to 7.0 ************************************************ TCP IPv6 Tools for LabVIEW Version 1.1.1 Modified 19 Nov 2008 This version fixes read buffering The native LabVIEW TCP/IP functions maintain a read buffer across calls for each unique connection ID. If you use a Read function mode that that can buffer data (such as the CRLF or Buffered modes) and you get an error because not enough data is available to satisfy the bytes requested, that data is still on the buffer for subsequent calls to that specific connection using any read mode. For instance, requesting 100 bytes in buffered mode when there are only 80 available at the port will cause a timeout error and no data is returned. A subsequent call to that connection (if it hasn't been closed or gone out of scope) in Immediate mode will return the 80 bytes that were read by the Buffered mode call but not returned. The original version of this toolkit (1.0.0) did not buffer any data since the Standard and Immediate modes always return any data read from the port. The version 1.1.0 did not always handle the buffering correctly. FWIW, this description of the buffering behavior of the LabVIEW native TCP/IP functions is from observation - I could not find a complete description in any documentation. Also, be aware that the LabVIEW help documentation for the CRLF mode is incorrect - this is from http://zone.ni.com/devzone/cda/tut/p/id/7324 *********************************************** Discrepancy in TCP Read help There is a problem with the documentation about operating a native LabVIEW TCP Read function in CRLF mode. The LabVIEW help says if you request n bytes and there is no CRLF in the n bytes, the function should timeout, return no bytes, and return an error. This is not what happens - if there are at least n bytes available at the port, the function returns the n bytes and no error regardless of whether there is a CRLF in the string. If there is a CRLF in the string, it just returns the string up to and including the CRLF as advertised. If there are less bytes at the port than the bytes requested, it times out and returns an error. ************************************************ I found and reported this problem as I was implementing this toolkit. The TCPIPv6_ReadCRLFMode.vi in this toolkit includes a switch so that one can select the CRLF mode to operate as documented or as actually implemented in native LabVIEW - the default is to operate as implemented to make the read operation compatible with existing code. ____________________________________________________________________________________ TCP IPv6 Tools for LabVIEW Version 1.1.0 This version adds support for the CRLF and Buffered modes in the TCP Read function Modified 18 Nov 2008 _____________________________________________________________________________________ TCP IPv6 Tools for LabVIEW Version 1.0.0 Mark E. Smith Sandia National Laboratories mesmith@sandia.gov LabVIEW does not support IPv6 protocol (as of version 8.6) using the TCP/IP functions and there is no promised date for inclusion of IPv6 compatibility in an upcoming version. I have a project that requires IPv6 TCP communication so I requested that NI support my efforts which they graciously agreed to do. Christian Loew of NI created a proof-of-concept project using Microsoft Visual C++ to create a DLL that provided LabVIEW access (through a Call Library node) to Winsock 2.x. I have taken that proof-of-concept project and refined it into, as much as practical, a direct drop-in replacement for the TCP/IP functions in LabVIEW. Features: - Drop in replacement for native LabVIEW TCP/IP functions - Supports IPv4 and IPv6 - Compiled and tested for LV version 8.5, 8.0, and 7.1 Limitations: - Does not support name/service lookups – the user must supply a valid network address in dot-quad (IPv4) or colon-delimited hex (IPv6) – the loop back addresses of 127.0.0.1 and ::1 are acceptable - Only supports the Standard and Immediate modes for the TCP Read function. The Buffered and CRLF modes could be added (I just have no present need) - Windows only – uses the Winsock 2.x DLL. However, the only Winsock-specific functions called are WSAStartup (to initialize the DLL) and WSACleanup (to release resources). Everything else should be portable to a sockets implementation on Linux or MacOS (this is speculation only!) if anyone has a need. License This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. This package includes: Microsoft Visual C++ 2008 Express Edition project (lvipv6comm.sln) to create the Winsock wrapper DLL (lvipv6comm.dll) The Winsock wrapper DLL (lvipv6comm.dll) Example VIs – Data Client.vi and Data Server.vi are adaptations of the example VIs of the same name that ship with LabVIEW that use the IPv6 Tools instead of the native LabVIEW TCP/IP functions For LabVIEW 8.0 and 8.5, a LabVIEW project exists (TCPIPv6.lvproj) and the TCP function VIs are in a LabVIEW library (TCPIPv6 Comm.lvlib). For LabVIEW 7.1, the TCP function VIs are in a single folder. Click here to download this file

Name: XML-RPC Server for LabVIEW Submitter: mesmith Submitted: 04 Jul 2009 File Updated: 28 Jan 2011 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 8.5 License Type: Creative Commons Attribution 3.0 XML-RPC Server for LabVIEW Version 1.2.0 Mark E. Smith Sandia National Laboratories mesmith@sandia.gov This release fixes error handling when the server does not start and port selection fron the Set Server State.vi. This release is for the LabVIEW 2009 and LabVIEW 8.5 versions. LabVIEW 8.0 and 7.1 versions remain at release 1.1.0 ************************************************************************* Mark E. Smith Sandia National Laboratories --see user file for contact information This release fixes two primary bugs 1) Single quotes, which are allowable on attribute values according to the XML 1.0 Spec, were not correctly handled. Thanks to Richard Graham for identifying this bug and providing a fix (now incorporated into the project). 2) The server unintentionally blocked on some method calls and became unresponsive while the method call executed. This has been corrected and new methods will be launched asynchronously as fast as the server can process them. If one tries to call a method that is busy, an XML-RPC fault will be returned immediately since this server does not support reentrant method calls. If one needs re-entrancy, build a wrapper method that launches the reentrant instances. Or just catch the fault and try again until the method becomes available. ******************************************************* XML-RPC Server for LabVIEW Version 1.0.0 Mark E. Smith Sandia National Laboratories This LabVIEW Project (8.5.1 and 7.1.1) provides 1) a LabVIEW XML-RPC server - accepts TCP/IP connections and calls XML-RPC Enabled LabVIEW functions 2) XML-RPC Message Builder tools - Allows conversion of supported LabVIEW data types to XML-RPC data types 3) XML-RPC Parser tools - converts XML-RPC data to supported LabVIEW data types 4) Method Template,vit - wraps LV VIs to create XML-RPC callable methods This project is useful to allow any language that supports XML-RPC (most any, including Java, .NET, Perl, and Python - see http://www.xmlrpc.com/ for details) to call a LabVIEW built function. One example is for a Java application to control and collect data from a remote LabVIEW server. This server could be a real-time LabVIEW server (cRIO, for example) since this server should run on any LabVIEW target (including Linux and RT) and is compatible with LabVIEW 7.X - I say should be because I have not had the opportunity to test on a RT or Linux target but there are no dependencies in the code that aren't available on LVRT or Linux. Is XML-RPC still useful given LabVIEW 8.6's Web Services capability? I don't know - I do know that XML-RPC is a lightweight implementation supported by many languages so the answer is probably "yes". XML-RPC complements rather than competes with the ReSTful architecture of the new 8.6 Web Services. Getting Started: Use the "Set Server State.vi" to start and stop the server. The "Call Generate Sine Wave.vi" demonstrates calling a LabVIEW function (the Sine Wave Generator) as an XML-RPC method. The actual method called is under XML-RPC Methods - open it to see how the XML-RPC protocol is converted to LabVIEW args and the LabVIEW output is converted to XML-RPC and returned to the server. Potentially any LabVIEW side function or VI that you create could be enclosed in this wrapper and called by anything (Java, Python, .NET, etc) that has XML-RPC support. Click here to download this file

Name: ActiveDirectoryTools Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 7.1 Version: 1.0.0 License Type: Creative Commons Attribution 3.0 Potentially make this available on the VI Package Network?: Undecided Copyright © 2006, Mark E. Smith All rights reserved. Author: Mark Smith --see readme file for contact information. This VI uses a .NET 2.0 DLL (DirectoryTools) to search Microsoft Active Directory. The DirectoryTools DLL uses the System.DirectoryServices namespace. The DLL exposes some simple functionality to LabVIEW in a form more user friendly to LabVIEW than direct calls to the System.Directory classes. Important Note: This implementation will only retrieve the first property of any record that matches the PropertiesToLoad - additional instances of an identically named property in a record are not returned Using this VI - this VI was designed to return all the computers on a given MS Windows network. The default filter (objectClass=computer) along with the default PropertiesToLoad of "cn" (common name) will return the name of all computers registered on the network. Any valid filter string and property may be used. Mark Smith Change Log: 1.0.0: Initial release of the code. Click here to download this file

I have a problem with the installer build in 8.6.1. The short story - I build an executable and then an installer. In the installer I have the 8.6.1 Runtime checked on the Additional Installers page. Every thing is OK (except it prompts me for my disk for something in the 8.6.1 distribution, but that works OK and the build continues). I can modify the application, rebuild the exe, and then rebuild the installer - all OK so far. Now, I exit LabVIEW and install the application on my development machine - I do this to try and see if I have any obvious problems with the application or installer (like missing VIs for dynamic calls or config files) before I take it to the lab. This also works OK. Now, I see something that needs modification. I open LabVIEW, modify the VI that needs it, save, rebuild the application, and then try to rebuild the installer. Only now, the installer opens the Locate Distribution dialog and insists that "LabVIEW needs to copy a component installed or updated by the distribution" and it's pointing to the distribution (my installer) that I am trying to build. This circular dependency can't be resolved and the build fails. Here's some excerpts from the build log ... Getting distribution information for NI LabVIEW Run-Time Engine 8.6.1 This product is cached. Skipping. Getting distribution information for NI MetaUninstaller This product is cached. Skipping. Getting distribution information for MDF Support This product is cached. Skipping. Getting distribution information for NI Service Locator This product is cached. Skipping. Getting distribution information for Math Kernel Libraries This product is cached. Skipping. Getting distribution information for NI_Logos_5.0 Product is in volume 1 of distribution with id '{CB09ABD9-FCCC-43BC-B4E1-9DDA6EB98ADB}' Product is in volume 1 of distribution with id '{FA21606E-6B91-43A2-83DE-199D5045AE5F}' Adding distribution 'LabVIEW 8.6.1' Path: D:\Distributions\LabVIEW\LabVIEW861\ Loading distribution information from path: D:\Distributions\LabVIEW\LabVIEW861\ Product is in volume 1 of distribution with id '{FDAAAF1C-1FFC-4C29-A472-27A929FC8489}' Getting distribution information for NI TDM Streaming 1.2 This product is cached. Skipping. ... Complete list of distributions and products to copy: (0) LabVIEW 8.6.1, Disk 1 Id: {FA21606E-6B91-43A2-83DE-199D5045AE5F} Volume: 1 Path: D:\Distributions\LabVIEW\LabVIEW861\ Products: (0) NI_Logos_5.0 Id: {ADAD3A9A-8E72-405F-BB2E-535AA7C8A936} Flavor: 'Full' Path: Products\NI_Logos\ (1) MA231 Tester Id: {CB09ABD9-FCCC-43BC-B4E1-9DDA6EB98ADB} Volume: 1 Path: C:\MA231 Tester\Software\Builds\MA231 Tester Installer\Volume\ Products: (0) NI_Logos_5.0 Id: {ADAD3A9A-8E72-405F-BB2E-535AA7C8A936} Flavor: 'Full' Path: bin\p9\ (2) MA231 Tester Id: {FDAAAF1C-1FFC-4C29-A472-27A929FC8489} Volume: 1 Path: C:\MA231 Tester\Software\Builds\MA231 Tester Installer\Volume\ Products: (0) NI_Logos_5.0 Id: {ADAD3A9A-8E72-405F-BB2E-535AA7C8A936} Flavor: 'Full' Path: bin\p9\ .... And then, .... > The source directory for "MA231 Tester" is invalid because it is at the same location as the deployment destination directory (source = "C:\MA231 Tester\Software\Builds\MA231 Tester Installer\Volume\", destination = "C:\MA231 Tester\Software\Builds\MA231 Tester Installer\"). <<<MDFDistCopyList_GetItemInfo>>> Returning info for distribution 1 Last known path: C:\MA231 Tester\Software\Builds\MA231 Tester Installer\Volume\ Distribution title: MA231 Tester ... I can only fix this by uninstalling my application AND going into the registry and deleting the first entry with the GUID under the NI_Logos_5.0 (which refer to my application) - these entries are in the registry under "HKEY_LOCAL_MACHINE\SOFTWARE\National Instruments\Common\Installer\Distributions\" - where there are also registry entries for every app I've ever built and installed with LabVIEW - all 300 something. Obviously, the uninstall doesn't do much in cleaning up these things. So, anybody have any good ideas what to do? OR at least an explanation? Thanks, Mark P.S. I know this is just another reason to learn how to use the OpenG Builder This has also been opened as NI Service Request 7249245and cross-posted at http://forums.ni.com...=419757#M419757 I'm just hoping somebody will have an answer!

QUOTE (James Beleau @ Jun 4 2009, 11:35 AM) While I agree that LabVIEW can work well with the exclusive lock model for the reasons given, it is incorrect to say that LabVIEW does not work with the "copy-modify-merge" model. LabVIEW does provide a merge tool http://zone.ni.com/reference/en-XX/help/37...to/merging_vis/ that can integrate with SVN http://zone.ni.com/reference/en-XX/help/37...rge_thirdparty/ Mark