Jon Kokott

class property nodes are broken pre sp1 for LV2010, and I haven't tested if they fixed the issue for sp1 yet, though it is supposed to be. Here is a thread where I pretty much describe the same issue (LV crashing) there was a CAR assigned at some point. http://lavag.org/top...nodes-and-dvrs/ 255982 ReturnChild Class Property Node does not output until deleting and rewiring any part of the VI This issue pertains to Object-Oriented Programming in LabVIEW. Essentially upon creating a Parent class and Child class, we are unable to read the child class properties in the main VI through property nodes unless we have changed the VI recently (i.e. unwire & rewire). Workaround: The workaround for this issue is to use subVIs created from 'VI for Dynamic Dispatch Template.' Within the subVIs you are able to unbundle and bundle the object. Reported Version: 2010 32-bit Resolved Version: 2010 SP1 32-bit Added:12/31/2010

I would be interested in a document describing the flattening format (I didn't think that this information was released). This is the closest thing I could find on a google search: http://mp.ustu.ru/Users/Kalinin/Files/LabView/National%20Instruments6.0/LabVIEW%206/manuals/datastrg.pdf Something on ni.com or in the help files would be preferred.

When you say deserialized objects, are you talking about references to objects? (SEQ/DVR/LCOD or whatever implentation?) in most implementations getting a reference to an object is a private operation anyway, what do you need to validate for?

Is there any labview data friendly standardized (i.e. open source) way to flatten LV data? I would see that as useful as a "future proof" scheme. Something like C style structs (only a struct is a cluster) It wouldn't have to do all LV data (I don't care about non fundamentals like refnums, or picture controls.) Extend that question for a human readable version. It definitely would have to do the flatten/unflatten (to a variant is OK at that point because we'd be in the native LV version.) ~Jon

My preference is to take the risk that flattened data will maintain compatible with future versions of labview.

OK, so it sounds like the only way to be sure of your compatibility for future labview version is to not flatten data to string. NI will just change it at some point and it will affect all past projects. I guess a human readable, proprietary transfer mechanism will the preferred system for us.

All you have to do is call that invoke node again but use the reference to your new vi you are running. Here is a picture of what it would look like

the reason for using variants is that it is a public data structure (i.e. not labview data. some people are concerned that LV will change the way it flattens clusters or something to that effect.) Here is what I consider the core issue: Using human readable (and custom for that matter) means our team will have to program every parser, and every function. The data is turned into a variant/enum at the other end NO MATTER WHAT. Is it really worth the time to convert (CODING TIME) a piece of labview data to a human readable screen, transmit it over tcp, convert it back to labview data, then turn it into a varaint/combo? I don't actually have to maintain this code, I have a bias toward a particular method (it might be more obvious now.) The criteria for selection are: Flexibility. Speed. Maintainability. Time to implement. Ease of debugging. By the way, the xml-rpc is awesome. I'll suggest that as another alternative. ~Jon

thats what the variant model is doing exactly. the data is always the flattened string and it is always prepended by the type string (which itself is prepended by type string length)

you must use the insert vi method on the subpanel you want a front panel loaded in. For the case you describe, the second VI you launch you must also obtain a reference to (static VI reference will be your friend as long as that VI is not reentrant.)

In the context of a large application that will be maintained/added on to for years, what is the best choice for data communication? For the purposes of this discussion, we are talking about using TCP to communicate between two LV applications. Each application will be updated separately. The server side will ALWAYS be up to date with the latest transmission/receiving types, the clients may be out of date at any given time, but newer transmission types will not be used on legacy clients. Would it be better to: Use a messaging system relying on a typedef'ed enum with variant data. (Flattened String to Variant, Variant to flattened string used for message formation/conversion.) each message has an associated typdef for variant conversion. OR Use a messaging system relying on a typedef'ed enum with a human readable string following the bin data of the enum. Each message has its own typedef and a string formation VI as well as a custom string parser to data. Additionally, LVCLASSES cannot be used, so don't go there. Would love to hear some takes including your perceived benefits/drawbacks to each system.

I'm gonna assume you had some help selecting this hardware configuration, and it is known to work. Start by sending whatever examples you have of communication in the white paper and observing the responses. ~Jon

This is a separate serial bus. Are you tring to use RS-232/UART or some other standard to communicate over this bus? it seems like you are trying to hack together something together from the VISA commands to emulate device drivers.

Convolution was really important last time i did Vision stuff. It is a major processing bottleneck every time. (it would be helpful to have a native function in all datatypes to be sure.)

I do not think this VI will work as you have intended. You have a Queue owning the consumer loop at the bottom of the VI, however, you have a state selector which responds to a shift registered enum. This will create a situation where you will display the data you write, but you are junking 1/4 of the data each time. That case structure cannot enter your desired state until the signal is updated by your producer loop. Perhaps you could place your dequeue operation inside your display state to create a lossless display/write cycle. ~Jon

[bug] You cannot use a multipane source VI. Fix: remove the subVI which replicates the frontpanel of the source VI.

Name: Daemon Creation Tool Submitter: Jon Kokott Submitted: 23 Feb 2011 File Updated: 28 Feb 2011 Category: VI Scripting LabVIEW Version: 8.6 License Type: BSD (Most common) This Labview scripting tool takes a standard VI, and creates a wrapper around it to launch it as a daemon. This is useful for creating inline code modules that need a process to run in the background.Accessible through the tools menu option. Features: Daemons will abort when the top level VI is aborted. Daemon can be aborted by closing the "Daemon Owner" VI refnum. Daemons obey source VI properties such as open front panel when called. Host process can be reentrant or standard. Tool places created daemon in idential project location. Tool will not alter the source VI in any way. To install this toolkit unzip and run the setup.vi file. The setup.vi as well as uninstall.vi will run immediately upon opening, so if you wish to inspect the files open the .lvproj file in the /source directory. It will install the toolkit to whatever version of labview runs the setup.vi file. uninstall.vi will uninstall the package. The package has been saved in LabVIEW 8.6, and fully tested in 8.6 & 2010. ________________________ Created By: Jonathan Kokott jmkokott@gmail.com Click here to download this file

DVRs and SEQs do not function identically. DVRs (when used with LV classes) require you to explicitly verify the data type when you write the in place element structure. This is done using the preserve runtime class VI. This means you cannot change the data type of class (from one child to another or child to parent.) You can change the data type of a class in a SEQ, as long as the class is a child of the original data type. ~Jon

Correct me if I'm wrong, I have all scripting features enabled (as far as I can see) the supersecretestuff=true flag hasn't done anyting in a lone time. The origins of that property are likely that it was leaked from the NI alliance member "stuff" (whatever that is) ~Jon

could you send the VI for that. (that property is also a super secret public) I am aware of application instance, however, I was using a significantly more convoluted method involving getting the last active bd to owning application. ~Jon

Thanks, this is not present normally, the only way I was able to get to it was through a copy paste method. ~Jon

When launching a tool from the tools menu option of a given VI (tool residing in the labview 2010/project directory) How do I get the VI that activated the tool? Currently I'm using App.VIOfTopBD, but this does not always return the right VI if the block diagram wasn't the last one open. I'd rather not monitor every activated VI with some sort of a daemon (similar to what is done on the sub VI fixer script engine) (I prefer not to launch any tools at start, trying to run as lean as possible.) ~Jon

Create event structure, event MCL, "Double Click" Using MCL ref: Invoke node convert point to row column, to get cell position Property node write edit position, put in the cell poistion. viola ~Jon

A workaround I have used in order to achieve this functionality is to use a Daemon launcher to enact the static VI call. Do this by creating a launcher with two cases 1. A case where the vi opens a copy of itself and populates all the control values and then runs. (I typically open the daemon process here as well, and pass it to the new instance and out of the current instance so that you have the reference handy) 2. a case where the vi detects that it is the clone and performs the call by reference node. In case 2 the VI doesn't have to be a call by reference node. It could be a standard VI call. A call by reference (with a strictly typed static VI reference somewhere in the call chain) will guarantee that the the process is reserved and your abort button will abort this process.