Jon Kokott

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

I'm sure you are not working with Windows anymore, since Windows changes the way of working and data formats with every new version. Not sure you will find another solution though without at least some of that problem too .

As to flattened dataformat changes, lets see, one incompatible change at version 4.0 since LabVIEW was introduced as multiplatform version in 1992. (Version 4.0 was around 1995.) Sounds at least to me like a VERY stable dataformat.

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

I always expect I'm missing something, but why do you need the variant? If you've defined a header that includes message length and message type, that works to provide enough info to unflatten the message at the receiver if you just flatten whatever. And don't variants limit you to non-RT targets? If you use flattened data I don't think you have that restriction.

Second, if you decide to use a human-readable/cross platform protocol, check out the XML-RPC server in the Code Repository - that's a published standard (although an old one, it still gets used) that defines message packing/unpacking in XML formatted texts and has a protocol for procedure invocation and response. It's pretty lightweight but still applicable for many tasks. And clients can be language/platform independent. But any of these human readable schemes are less efficient than byte streams. For instance, to move an I32, you need something like

<params>      <param> 		<value><i4>41</i4></value> 		</param>      </params>

that's a lot of data for a 4 byte value! But it is easy to understand and debug. And if you need to move arbitrary chunks of data, the protocol supports base64 encoding of binary.

Mark

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

Why not take a leason from the 7-Layer model and look at how packets are transfered specifically, design a generic envelope that you can pack any type of data into adn ID the type of packet. So something like

32 bits message type

32 bits length of the data

The first value will tell you what language is being used, and the length tells you how big the data is.

A quick check of th first value will tell your software if it can handle the protocol. if it can then look at the data.

Just my quick 2 cents,

Ben

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)

Hi

I need your help. I created a sub panel in the front panel and wrote the code to open another Vi inside this sub panel. It works,but the problem is the Vi that I want to open here has several subvi's dependencies which do not open inside the sub panel.

What happens now is that the Vi opens in my sub panel but when I click in a button inside that vi ( which is linked to another sub Vi) ,the linked sub vi Opens in a full page( in a seperate window), not inside the sub panel ! How can I modify it in a way that all subsequent Vis also open inside the sub panel?

Can you help me in this regard?

my code image is attached.

Thanks

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

Yes, I agree. That is what prompted the latter part of my post. Why wouldn't this be the example of a Singleton that ships with LabVIEW (SEQ for 8.6; DVR for 2009+). Currently the example is a class wrapped in a library that uses a checkout/checkin mechanism to provide the locking. The checkout/in is still based on an SEQ, even in 2010. AQ had stated that he had wanted to see how DVR's were accepted before proposing his DVR method become the shipping example for 2009. OK, I'll give benefit of the doubt on that one. But why wasn't the example updated for 2010.

There are diferences between the 8.2 version and current version, but both are based on SEQ+FGV. The current shipping example is the same for 8.6 through 2010.

Actually the 8.2 version is somewhat closer to AQ's DVR implementation and the alternative for 8.6 using an SEQ that I mentioned above. The major difference is that the class is wrapped in a library and the public API is in the library and it wraps the class functions. The class is private to the library. There are still checkout/checkin VI's but they aren't actually used in the example or the other API functions. It's almost like they were an afterthought or that you were expected to use them even though the othe API examples don't. The API examples dont have class inputs or use the checkout/in; they just get the SEQ from the FGV and dequeue/enqueue the class. It's an inconsistent message.

The 8.6 and up version is pushing you towards explicit checkout/in. The class is still wraped in a library and the public API is part of the library and wraps the private class functions. But the public API has class inputs so you have to do a checkout to do any operation and then checkin. The public API does not checkout/dequeue or enqueue/checkin internally like the 8.2 version or the DVR version. The user has to do that and then call the API functions.

That's what is prompting these questions. The fundamental mechanism is the same whether it is SEQ+FGV or DVR+FGV. The fact that the original 8.2 example is a little closer to the DVR+FGV version that AQ posted makes me question what issues were encountered with it. Is it the wrapping library (still used in the "better" 8.6+ versions)? Is it the inconsistency? Is it the fact that the public Get method uses Preview queue vs dequeue? Something else entirely?

I'm attaching the original 8.2 version for those that don't have 8.2 and want to see it. I'm also attaching an 8.6 version that duplicates the DVR implementation but using an SEQ. The DVR version by AQ is linked above and I assume everyone can get the current shipping example in 8.6 or higher.

-Scott

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

Refer to the bottom of this post to see how to enable the private properties/methods.

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

Note that you should also use the application reference to account for the possibility of the VI loading in another instance:

The properties are private (indicated by the brown color and documented in their context help), which is why you can't see them.

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

That would be the Application:MenuLaunch:VI

App_MenuLaunch_VI.vi (LV2009)

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

No. Please go and vote for this idea (and tell others to) so that we will have this feature sometime:

http://forums.ni.com...By/idi-p/917632

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.

There are built in labview functions that perform threshold tests.

Additionally they are much more full featured and probably more useful for most applications.

you might start with the peak detector.

~Jon

To close this thread:

When I made the original posting, I did not think my problem was in any way related to the "blacked out" property node element that mje described above.

It seems that their may be some interaction between this and the run time crashes I experienced in built applications (Mr. Mike's response)

I will not be using property nodes, as it reliably fails on my machine. After trying out the Othello example (and hacking it hard to try to recreate the crash--- and failing to create a crash) tells me that something else is probably in play, and I'll have to wait to see the CAR/ fix whenever it is released.

Thanks again for all the responses.

~Jon

Ok so here is how you make your dynamic dispatch FG.

All childs that override this shall follow this pattern. both the input and output are dynamic dispatch.

here are the problems with this type of architecture:

1. In order to access your data store, you must have a copy of the class you are trying to access. In a normal LV2 this is not the case because you do not need to wire the input of your VI. When you do dynamic dispatch, you must wire the connector pane or it will not know what vi in the inheritance tree to load.

2. You cannot extent this pattern beyond one instance per named VI. Creating a bunch of different VI's for data stores is time consuming and you'll never be able to create enough for some applications.

Doesn't have to be... make the VI reentrant and use Open VI Reference to give you a new reentrant clone each time you want a new LV2-style global instantiated.

Reentrant dynamic dispatch VI called by reference? I do not think that will work.

I believe you are refering to this pattern:

and here is your by ref LV2:

~Jon

So I've run into a use case where I can't think of a way out of my problem without having some sort of DVR-based inheritance mechanism. The problem being of course, that dynamic dispatches don't work with DVRs. Then it dawned on me I already have working code that does exactly what I need to do using a trick like so:

Are you not satisfied with calling dynamic dispatch inside the in-place structure? (you need to use the preserve runtime class vi after the dispatch.)

This seems like a significantly more complicated way to do that, and by your own admission destroys the one guarantee you need from the singleton pattern.

I can't see a reason to do this. Instantiating a default value of a class could be horrendous depending on how bad the datatype is.

~Jon