Mark Smith

I wanted to express my thanks to everyone on this board who assisted me with preparing for my CLD exam. It helped me a great deal to have advice from experts like you guys.

Now that I have my CLD certification, my next goal is to find paid employment, preferably in the Raleigh-Durham area. I have ten years of experience as a test engineer, and extensive experience building test solutions for electronics. I am open to contract work. My resume and work history is available on LinkedIn at http://www.linkedin....orne/6/102/301.

Josh

Yet another one joins the ranks! Congrats!

Mark

The solution to that is to make the queue unnamed and put its reference into the class data cluster. An equivalent in 2009 is the references to data feature, which doesn't even allow you to name the reference, partly to avoid this issue.

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

Would a SEQ whose datatype is a private cluster effectively block external code from gaining a reference to the Q?

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

Wouldn't a global restrict the proper operation of a class to single instance? If I wanted two instances of that class, isn't there a possiblity that the two instance could be hitting the same global in differnet ways?

Ben

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

Hi Guys,

How is the best way to see a memory leak (if indeed there is one) when running an Executable created with LabVIEW?

LabVIEW 8.5.1 currently

I m using serial VISA and FieldPoint exclusively.

Nat instruments 16 port serial card.

Is there anything out there that is either freeware (or if it works really good low cost software) to catch the devil?

Thanks in advance

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

I will use the VI BuildTargetBuildSpecification.vi to programmatically build a project but I first need to set some buildspec properties such as the destination folder and version number.

Are there VIs or properties I can use for this? I looked into the Properties and AppBuilder folder and I did not figured anything useful.

The only solution for the moment is to edit the project file (XML).

Any better ideas?

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

Hi all,

My problem with Flattern to XML is rounding, see following example.

DBL 0.123456789

result:

<DBL>

<Name>Value</Name>

<Val>0.12346</Val>

</DBL>

Is there any way to set precision of conversion? BTW conversion back (unflattern) works just fine.

Thanks&Regards,

David

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)

LabVIEW does not work with a "copy-modify-merge" method. That method is for text based code. Binary files such as a LabVIEW vi are source controlled by lock/unlock, single person changing code at one time method.

How this differs is that in C+ for example, multiple functions would be in one file. Perhaps your entire program would be one giant text file. In LabVIEW by contrast, you have many little files that separate each function called a 'subvi'. With the one text file situation it is very reasonable to have multiple coders working on different parts of the code, different functions, etc within one big file. Therefore you implement a merging method. LabVIEW on the other hand, one function is typically one file, thus locking that one file for changes does not interfere with the work of the other coders. They are working on the other functions they locked. Then as each person gets the updates LabVIEW uses the new changes subvis. This is very similar to the SCC merging the changes to two text files and each coder recompiling.

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

QUOTE (Ic3Knight @ Jun 2 2009, 01:41 PM)

Unfortunately, I think the perforce "trial/demo" is 2 users only, and we'd be 3... meaning an instant cost of abour £1500, not huge, but not easily justifiable either...

Anyone point me in the direction of an easy step by step SVN setup? with the repository on a windows server machine?

Cheers!

Paul

Just to see what Subversion's all about, you can set up a simple repository using the "file:\\" access mode rather than a server. While this is not considered best practice except for personal repositories, it's incredibly easy. Just install the TortoisSVN package and open the help file, search on create. It will tell you how to create a repository and then access it using simple file access rather than access thru a server. Later, if you like what you see, you can install a server and access the repository you already created. BTW, I use this with two and three person teams (we seldom if ever work on the same code at the same time) and it has not caused problems yet, although we are in the process of finally getting IT to set up a real SVN server and doing it the right way.

Mark

QUOTE (Aristos Queue @ May 5 2009, 09:40 AM)

That's a flaw in our documentation scheme. All four of the "Available with..." fields in the help apply ONLY to methods and properties of VI refnums, but those four fields get printed for help for all of our properties and methods. Ignore them.

All VIs In Memory correctly returns all the VIs in that application instance including standard VIs, control VIs, poly VIs, global VIs, and custom probe VIs. I don't konw what it does with the pseudo VIs (such as the clipboard VI or the proxy VIs that are created when one app instance makes a remote call to another app instance). Those aren't really VIs as customers know them, but they have attributes that make them look like VIs to many of LV's underlying subroutines, and they do appear in the VI Hierarchy Window, so maybe they're in the list too, but I can easily see them not being there.

[LATER EDIT] I talked with our tech writers. This bug in our documentation process has already been reported and will be fixed in the next version of LabVIEW.

Thanks for the info

Mark

QUOTE (normandinf @ May 5 2009, 08:26 AM)

I don't see this restriction in the 8.6 Context help window. Perhaps it was removed with the introduction of classes in 8.2 and the context help wasn't changed until recently?

Now that's interesting - I'm running 8.6 and I get this window when I select help for "Application:All VIs In Memory Property" from the context window - are we talking about the same help menu?

http://lavag.org/old_files/monthly_05_2009/post-1322-1241534189.jpg' target="_blank">

Thanks,

Mark

I was a little surprised to open a Application:All VIs In Memory Property node and discover that it returns Class .ctl types and any typedefs associated with the class. Is this intended behavior? The help for Application:All VIs In Memory Property says

Available with control VIs:

No

Can anyone edumacate me?

thanks,

Mark

QUOTE (esqueci @ May 4 2009, 09:15 AM)

Hello everyone,

I have a program wich makes dynamic calls to driver VIs that we put on the driver folder. What it does is list the folders of the folder, and create an array of paths, wich we feed to a for loop that opens a VI reference and runs them, one by one, with the Invoke Node Run VI.

We have some drivers that run just once (no loop), and others that must run in parallel (looping), and it all works fine because we can set Wait Until Done to false when calling the looping drivers.

My problem is that now we decided to create DLLs out of the drivers, and when using the function Call Library Function, there`s no way to call a looping dll and continue the execution of my main program as I did before when calling the VI`s. The CLF waits until the dll finishes executing and just after that the main program can continue executing.

Creating a loop for each DLL call is not an option since our program has to be able to adapt itself for different numbers and types of drivers without us needing to code.

One alternative I was thinking was calling a VI that would call the looping dll. That would work, but wouldn`t be pretty.

Does anyone have any suggestion for my problem?

Thank you very much,

Dario Camargo

You are correct as far as I know - you'll need to dynamically call the wrapper VI that calls your DLL in order to launch a new thread for that VI to keep your DLL call from blocking. With that said, it seems like you're building LabVIEW code into a DLL and then calling it from LabVIEW - seems like the hard way to do things. I would also think that you could call the DLL in a loop - if the DLL has enough info to know how many times to loop, it seems like you could make a call to a DLL method and get that info - like how many times to iterate thru a for loop. If the call in the DLL is in a while loop, just return whatever exit condition you use to terminate the while loop from the DLL call and use that to terminate your loop around the DLL call.

Mark

QUOTE (dblk22vball @ May 5 2009, 06:11 AM)

I am looking to pick the brains of the LAVA members on how they deal with config files and/or large initialization files.

I have an application where I need to load in 20+ values to initialize the GUI and set up the programs test parameters. I am sure that with future applications, the number of items will increase, so I am trying to get some ideas ahead of time.

What methods would you recommend for large init files or config files?

I have done the single config file, and then you get the number of keys in that section, use a FOR loop to read all of the values and insert into array or cluster. This seems ok, but I have run into issues "elegantly" putting the data in a cluster (since there are different datatypes). You either have to read each key seperatly and put it into the cluster one at a time (can create a huge block diagram) or you use a FOR loop with a case structure and depending on the loop count, insert the value into the cluster, but this can get tedious for adding or removing data from your cluster.

The other way I have done it is to just save everything as a string (config file or just a text document) and read into an array and then index the array when you need the value. This seems to have a lot of unnessecary string to X conversions, and index array actions.

I have been trying to apply some OOP to this, but not sure if this is the right place, and since I am new to OOP I did not get that far yet.

Is there another method that you have used?

Thanks.

I manage large config files two different ways, but they both start the same way - build a cluster (always typedef this cluster - it makes changes so much easier!) that contains all of your configuration fields and then use one of the tools available to serialize the cluster contents to text and then to file.

Method 1 - use the Flatten to XML then Write to XML File to create an XML tagged text file and use Read from XML File and Unflatten from XML to recover the file contents. Attached is a simple example.

Advantages -

- easy to use - just put whatever you need for config info in the cluster and then flatten to xml and write to file

- All native LabVIEW code

Disadvantage

- harder to read and edit manually than a .ini style file

- you won't be able to read old configuration data if you change the cluster definition

Method 2 - use David Moore's Write Anything and Read Anything files

http://www.mooregoodideas.com/File/index.html

Just wire your configuration cluster to the input of Write Anything and it will automatically create a .ini style text file - use Read Anything to read the file and repopulate the config cluster

Advantages -

- creates easy to read .ini style files

- quick! The performance is more than adequate even on config files with hundreds of entries

- if the cluster definition changes, the Read Anything will still read the old config file - it just provides its default data for any fields not found

Disadvantages

- Mostly open code - there's one password protected VI in the bunch

- not native LabVIEW

I use both but for most simple configuration tasks I use method 2. OpenG also has a set of config file VIs that operate much like David Moore's, but the last time I used them (which has been awhile) I found it easier to use Moore's VIs and the performance to be better on larger config files.

Mark

Download File:post-1322-1241527217.zip

OK - I saw JGCode beat me to the punch but I'll post this any way!