Jim Kring
-
Posts
3,905 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Jim Kring
-
-
Michael, it is possible and much easier than I first thought. Here (attached) is a working, and fairly complete solution -- it supports compound types including nested variants (variants containing variants). It is currently sub-optimal for arrays, which can be improved... but that solution is also non-trivial :laugh:
Jean-Pierre (et al.), I was thinking that we could use this VI as a replacement for "Remove Typedefs from Variant" in the lvdata package. Maybe we could add a "Recursive?" boolean argument that defaults to FALSE so that the original behavior is preserved for existing users (but would they even want the original behavior?).
Any thoughts?
Cheers,
-Jim
-
Take a look at this posting.
-
There are binary files, and only NI has the tools to read and write them. These can be created using the palette editor. There are instructions in the LabVIEW User Manual.
-
-
Sorry Jim (welcome back...) Set Contol Value {Coercable Variant}.vi doesn't work either...
The Variant to Data node you use to perform coercion does nothing since you ask it to convert a variant to a variant...
It is possible to make a VI that will coerce variant to another datatype (even numeric string to number...). You sent me an example once from a guy working on variants. I remember it was huge (~1MB) and then not very convenient.
Well, I'm not really, back. I am stuck in a hotel in Albany, NY :headbang:
I was thinking of testing that VI, but I figured that it would work. I didn't realize that the coercion only occurs when the output is strictly typed... too bad. Yes, this would be a non-trivial problem to solve in G. For now, we'll leave that one for the wishlist, I guess.
Cheers
-
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:
-
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:
-
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.
-
Making your wish public knowledge fascilitates this open discussion on the wish list item.
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:
It turns out that the hidden setting in the ni-rt.ini file that we thought had a default value of 100, actually had a default value closer to 30. Depending on how many ports were being used at a given time (i.e. - MAX, webserver, VI Server), you'll have to subtract roughly 15 from that number to get the number of available ports for your other clients. Add the following line of code to your ni-rt.ini file:[TCP_STACK_CONFIG]
Max_Sockets=50
With a setting of 50, you'll have approximately 35 connections. There may still be an upper bound on the number of ports you can have open.
-
I have created a much more full-featured version that fixes this limitation:
-
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.
VI:SetTag: ..\National Instruments\LabVIEW 7.0\vi.lib\express\express signal manip\ConvertfromDDTConfig.llb\subSetVIProperties.viPosible use: Create Express VI ?
-
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.
-
So, on that note, can anyone suggest any other improvements to the VI's listed in this topic?
I will check to see how symbolic links (unix shortcuts) are handled in linux.
-
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.
And, here's the VI.
-
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.
Incorrect. The datatype must match exactly the control datatype when using Set Control Value(Variant). Unlike Variant to Data function, there is no implicit type conversion with this method.
Toolkit Installation Madness
in LabVIEW Feature Suggestions
Posted
Ed, here (attached) is a spec file that will package NI's PID Control Toolkit, if its installed.
This won't work with the current release of the OpenG Package Builder, since the package builder does not allow pathroots in the Source Directory of a File Group. I will re-release a new version of the OGPI that does support this feature, so that the ni_control.spec file will build correctly.
I can work with you to create spec files for all the toolkits, which will allow you to create your own OpenG Packages, from the installed toolkits. You can, oviously, only distribute the OpenG Packages inside your organization, insofar as you have appropriate software licenses for the toolkits.
Regards,
-Jim
Download File:post-17-1091488235.zip