Jim Kring

Jean-Pierre, this thread brings back memories John et al., Here are a couple of VIs: 1.) Set Control Value {Coercable Variant}.vi 2.) Launch Generic Process VI.vi #1 uses the "To LabVIEW Data" function to perform coercion (if possible) before setting the control value. It does this by first reading the controls value so that it can get its type. #2 is a generic utility VI that first sets the FP control values and then invokes the run method. Additionally, it will open a new instance for Reentrant VIs and it will pass the VI Reference to the called VI, if it has a FP Control called "Self VI Reference". Cheers Launch Generic Process VI image: Download File:post-17-1089685589.zip Download File:post-17-1089685604.zip

That brings back memories Here is a VI that should do the trick (however, I haven't tested it). Set_Control_Value__Coercable_Variant VI Image: Download File:post-17-1089685393.vi

This is an option for VI's added to a pallet menu. When editing the palette menu, right-click on the VI and make sure that the "Merge VI" option is selected. This will cause the VI's contents to be placed on the BD rather than having the VI placed as a SubVI.

It also prevents NI from patenting your idea

I built a LabVIEW RT App and found that I couldn't connect more than about 15 (TCP-IP) clients to the target machine. This includes MAX (Remote System Explorer), LabVIEW RT, FTP, Web Server, and any other TCP-IP clients. Fortunately there is a fix for this problem. Here is a response from NI Support:

I have created a much more full-featured version that fixes this limitation: LVBLD - Command Line Build Tool

I opened the express VI "Elapsed Time.vi" <LabVIEW 7.0\vi.lib\express\express execution control\ElapsedTimeBlock.llb\Ex_Inst_Elapsed Time.vi> in a text editor. I found the following: _Wizard v 2

When Express VIs are dropped onto the diagram, their configuration panel is automagically launched. It appears that express VIs are tagged with information about thier configuration panel VI location, LabVIEW looks for this information when they are dropped onto a diagram, and if found launches the configuration panel. Perhaps this mechanism can be exploited somehow.

Yes, the TCP Server example both (1) creates the event listener (generator) and (2) provides the ability to register the event callback (handler) VI. Perhaps it would make sense to seperate these two things into some more general utilities. However, in this case the TCP Server only required a single callback VI per event source (one connection handler, per new connection) so I didn't need anything fancy in terms of managing the registration -- I simply stored the call-back RefNum in the TCP Server GOOP data store.

I'll take a quick stab at this... I like to use the callback pattern for asyncronous event handling, especially when you may need to spawn multiple instances of the handler. The beauty of the callback is that the user who creates and registers the callback does not need to have any awareness of the underlying framework that listens for the event and spawns/manages the callbacks. The user can simple pass a callback VI reference into the framework to register it as the event handler. If you want a good example, take a look at the TCP Server example that I have posted on OpenG. This example allows you to register a VI to recieve TCP connection references when a client connects to a TCP server that is listening on a specified port. In this example, the TCP Server framework manages the TCP Listener process(es) and the spawing of connection handlers. It also provides a usefull status info VI to get information on the number of clients that are connected (to multiple instances of the connection handler that are running asyncronously). Sure, callbacks "break the dataflow paradigm" but dataflow isn't the answer to everything in all instances. If you limit yourself to a set of strictly defined wire routes then you cannot possible handle N(any number of) asyncrounous threads. Why limit yourself..?

The FTP package here should work for you: http://www.openg.org/tiki/tiki-index.php?p...ctivity%20Tools click on the attachements link at the top of the page.

I will check to see how symbolic links (unix shortcuts) are handled in linux.

And, here's the VI. Download File:post-29-1081781067.zip

The "Control.Terminal" property is exposed in: ..\National Instruments\MAX\Assistants\LVCGen\LV70\mxwScript_ClusterConnector.vi Use this to get the terminal reference and then wire it to the property node.

Actually, I think that you don't need to run the VI. You should be able to interogate the state/type of the wire to determine if is is (un)broken.

Well, there are only 88 Private Classes so how long could it take? Let's see... 88! = 1.855e+134. But, I bet if we apply a little logic it shouldn't take quite that long :laugh: And, I bet that with the scripting tools that are exposed you can even create an "intelligent brute-force" utility that writes the "to more generic class" conversion and then runs it to test to see if it is valid. For example, start with any object and try to convert its reference type to a more specific class over all object classes. The types that do not result in an error are ancestors. Now perform the same test within (and only within) this set of ancestors to determine the inheritance hierarchy. Once these ancestors are determined, you no longer need to determine them. So, the tree structure can be generated dynamically and efficiently. One caveat... when you do the object typecast test you must be referring to a valid VI Server object, not just a null object that flows out of a Class Specifier Constant.

One, "next step", that I suggest is a VI that outputs the inheritance hierarchy of a specific class. This can be represented as a path or and array of strings. The inheritance hierarchy of all VI Server objects could be stored (inside the VI) in a linked list. From this, one could populate a Tree Control with the structure of the VI Server inheritance hierarchy as well as doing more functional programming tasks. I propose that these utilities and type definitions be organized in an OpenG package so that we can more easily collaborate and use the utilities. For example, I would like to create an OpenG package that puts the "New VI Object" and "Open VI Object Reference" (as well as some other recently discovered tools) into the palettes for easy access.

I am building a state machine with a state enumeration. I often have a Case Structure with frames assigned to multiple enumeration values. It is very frustrating when there are three or more adjacent enum values and LabVIEW automatically converts the frame's "case string" to ".." range notation. It is not clear without looking at the enum which states are applicable for the frame. For example... Assume an enum with the following states: [0] "initializing" [1] "shutting down" [2] "aborting" [3] "running" A Case Structure frame that is assiged the following states: "initializing", "shutting down", "aborting" will get converted to: "initializing".."aborting" So we need an option on the Case Structure to explicitly show all inclusive values instead of using the ".." notation.

I might be oversimplifying the problem, but... A power spectrum of your signal should produce a spectrum with a single large peak. Find the frequency of the peak and you're done.

Has anyone benchmarked the performance difference between instanciating a VIT vs. a reentrant VI?

Alex, I recommend using OpenGOOP. It will probably work (its pure G + no variants), and if it doesn't work you can fix or strip out the parts that don't. -Jim

The "Prepare for reentrant run" option (0x08) of "Open VI Reference" was adding in LV 6.1, as was the "Auto Dispose Ref" argument of the "VI.Run" method. But, templates are still a good solution for cloning GUIs.

Yes, LabVIEW can call shared libraries on Linux. They are called shared object files and usually (if not always) have a .so file extension. A while ago, I looked at the possibility of a GPG toolkit for LabVIEW as a way of signing OpenG Package Files. Maybe this will happen some day...

Hello RT and TCP fans. I am currently working on an RT system and I had to create a custom TCP server. I decided to make it very general and allow registering call-back VIs to handle client connection. This design allows for multiple client connections and is super-clean :thumbup: . The call-back framework handles all the management (spawing and cleanup). Please take a look and feel free to comment and discuss in the forum (see hyperlink, below). :!: My only disclaimer is that I've only spent a couple days on it and it has not been tested for memory leaks, reliability, etc. Please report these back to me, if you would be so kind. Example - TCP Server, An OpenGOOP TCP Server Cheers, -Jim

This is an example of using OpenGOOP to manage TCP client connection handlers which are spawed dynamically. Essentially you register a callback VI that will be run each time a client connects to the port that you have registered for. And, if your callback is reentrant, then you can handle multiple client connections! More info and download: EXAMPLE - TCP Server page at OpenG.org Enjoy, -Jim