Jon Kokott

I forgot one other really nice thing about by ref LV2:

you can insert the front panel into a subpanel while you are running to create an easy spy for what the state of the data is. This can be very helpful for debugging.

~Jon

Jon,

Thanks for your prompt response. Unfortunately, I have been tied up and not able to review the post until now.

I am not clear on your previous response. Could you attach the modified project shown in your response? Also, I would be interested to hear the advantages of a SEQ.

Thanks for sharing your knowledge!

I'll attach the modified project when I get off work.

Here are the reasons I like the SEQ as a data store Vrs by Ref LV2

1. I find it annoying to access methods by locating the editable VI in the project (or static VI reference at initialization) then shopping through a deep case structure (it is not uncommon to have an enum with like 40 cases in it)

2. If you create a lock condition, their is no way to time yourself out and reattempt (this is a bad thing to be doing but if you need a quick fix atleast you can do it with an SEQ)

Best thing about LV2.

Fastest code in the bunch.

Tried and tested since before I ever started using labview.

Reasons why I don't like DVRs

1. It is SUPER annoying and code intensive to make methods. Simple method access is 10+ mouse clicks after dropping the VI you want to run. It ends up looking ugly as hell and you have to make a wrapper to clean up the mess. (manual procedure looks like drop inplace, add dvr in/out, drop method inside, drop preserve run time class at end, wire in/out terms, drop merge errors, merge errors in a specific order edit->create subVI save new subVI.) <- I probably won't ever use DVRs until they integrate Invoke nodes to do all this stuff for you (LV2012 probably)

2. you can't swap the data type in the store. (Also not a great idea unless you know what you are doing)

3. Same lock condition as point 2 above

4. The property node feature (2010) doesn't work (for me, some people don't seem to experience the problems i do.)

Best thing about DVRs:

I really don't like these right now. Its too much coding for next to no benifit. (these are marginally faster than an SEQ. If I need that extra speed, I'll pick the LV2 and more than likely optimize the portion that needs to be fast. this is usually a pointer to a pointer (ie reference to a reference for labview) situation where so that I can chop down the bottleneck part of the code to primitives only with no class functionality anyway.)

Nice to things from SEQ

Preview Queue/lossy enqueue primitive (you can implement this with the other 2.)

Timeouts on data store access (good for when you don't have time to find the place where you screwed up and didn't follow a data access rule.)

Really well developed and understood design pattern.

But don't take my word for it.

Their is a ton of material on all these online.

here are your kewords:

Singelton Design Pattern (these are all singletons)

SEQ (single element Queue)

DVR (Data Value Reference)

LV2 (Functional Global, Action Engine, and LCOD (I forget what the acronym is for but i'm sure google can figure it out))

On a side note. if you look at the Config File VIs from 8.6 or prior they used a pointer array stored in a LV2 (really a terrible bottleneck for larger applications so I didn't bother to discuss it)

In 2009 they updated this architecture to SEQ. You should have access to both in your VI lib. Take a quick peek at them to see some code that thousands of people have used successfully.

I hope this helps.

~Jon

I just released my 2010 build to production so I should soon have an answer for you. So far, so good.

I had a problem with using property nodes and classes, especially in built applications.

see this thread:

http://lavag.org/topic/13300-lvoop-property-nodes-and-dvrs/page__pid__79931#entry79931

Could you describe problems with DVRs? In the examples you sent Lynn, I don't remember seeing any DVRs.

Looks like I'm going to have to eat my words on that one. It turned out to be a property nodes related issue. I have a fix for the issue and I'll try to get it in the next possible release, which may or may not be a bug fix (SP1 or 2011). I can't promise anything. (On a side note, I wish there were an embarrassed smiley that wasn't holding a giant "Oops" sign)

[/size]

You may also see this in the Known Issues List as CAR 246263, since that one is the same issue and was just about to go on the list. Sorry you couldn't use my feature for your project. I hope you'll try it again when the fix comes out.

After further investigation it is likely not a related to the DVR.

It just so happens that in my original finding of the problem I was using DVRs and property nodes where the problem originally manifested itself. As I peeled the onion to find the root cause the DVR was one of the things that was removed.

Really Glad to hear that the problem has been identified. Is this the place where the known issues will appear? http://zone.ni.com/devzone/cda/tut/p/id/11869 I haven't seen it come up yet but I'll be watching for it.

~Jon

Hey Jon,

Thanks for closing the loop on this. Since I'm not doing any up or down casting I'll keep using property nodes for now. But I will be back here if anything odd and repeatable occurs.

I'm not really even sure if that is what the issue is. It could be some kind of corruption that occurs in normal class creation. Also I'm suspicious of whether or not it is system dependent (I'm using windows XP 32 bit service pack 3)

I was able to use the othello example with no problems (and I taxed the hierarchy with new data members, methods, property nodes.) So something is going on, but its not totally reliable.

It would be interesting if the up and down casting had something to do with it (I'm under the impression that they do absolutely nothing other than change the data type of the wire so you can actually wire the correct class type to a method.

~Jon

I was assigned CAR 255982 for what I was seeing.

I'm kinda surprised no one else is seeing this because NI was able to demonstrate the error on their end building up a class hierarchy from scratch (reliably.)

At any rate I won't be using property nodes with classes.

Thanks for the input from everyone.

~Jon

Just a quick note to say that the Preserve Runtime Class primitive was added in 2009.

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.

Here is what an SEQ would look like:

and here is your by ref LV2:

Or DVR:

the wire wont be broken if you are creating it inside a class member VI.

these are the main ways to do an object by reference.

I prefer SEQs over every other data store. You can get some extra capability out of them if you are interested in learning how.

~Jon

Please elaborate!

OK, so what you are doing is creating a single object manually by defining a new class for each object. This is not very extensible. lets say you write a sweet group of VIs, but now you need to have multiple instances of a particular child class. You can't add multiple objects by making the LV2 global reentrant and calling it by reference like a standard LV2. Dynamic dispatch VIs cannot be called by reference (you can't preallocate clones so you wouldn't know what instance you were operating on anyway.) Additionally this pattern means that you will be constantly instantiating the default data type of your child class in order to read its actual data. If your default data type has some huge memory profile, you'll have to load that without gaining any functionality (big memory profile, slow performance, effectively nullifying the biggest advantage for a LV2)

If you want to do by reference with LV2 and LVOOP, don't make the container (your Functional Global/LV2) itself dynamic dispatch. Use the normal by reference LV2 (open VI reference, make sure it is reentrant, preallocate clones.) You can still chuck whatever child data type you want in there, but your output will always be casted to the parent type. you'll be using the to more specific class constantly, and keeping track of who is who might be too big of a pain to make it worth it. If you want the correct data type to come out, you'll have to make a new LV2 for every data type you want to support (you were planning on doing this anyway i suppose.)

Otherwise, as I said before, I'd recommend using an SEQ (Single element Queue.) There is lots of support out there for this design pattern. Its easy to understand what object you are operating on because you are required to wire the object reference (queue reference.)

I'll upload some pictures when I get off work.

~Jon

I'm not sure what all the implications of this design pattern are, but it looks like it should work. You will definitely be duplicating data on every child class (the deeper the structure, the more data you will duplicate.) there are probably better design patterns for your implementation anyway. I

I can't upload a snippet right now, but I'm thinking you can't do what you are trying to do in 2009. 2010 added the preserve runtime class which will allow you to override the functional global VI.

Honestly I would go with an SEQ instead of a functional global. It would make understanding which object is being operated on much easier.

~Jon

you can do it in 2009.

Pull the input input outside of the case structure. (no dynamic dispatches allowed inside a structure.)

The input needs to be "Dynamic Dispatch"

the output terminal needs to be "Static Dispatch" and the parent class type, you should see a coersion dot on any child overrides.

you'll have to put a "To more specific Class" vi on the outside of the subvi call of wherever you actually wanted that dynamic dispatch output behavior, because without the preserve runtime class you can't do this.

~Jon

I'll take back the data duplication comment, so long as you don't use a call parent method on any of your LV2 globals.

I am running into a roadblock with implementing a design within LVOOP. I have a base class from which I would like to create multiple child classes. Each of these children should be singleton objects and I would like to override and implement one public function Command and Response "wireless" aka a LV2 style global. Basically, I am looking to re-use all of the functionality of the base class, but just have a wireless implementation for each "module" of the system.

The structure of the base class is shown below:

Remote Interface.lvclass

Private Methods

Create

Destroy

Interface VIG

Public Methods

Command and Response

The Create method stores the class object in a VIG (LV2 style global). The Command and Response method calls the Interface VIG to get the current object.

My first attempt was to simply create an override for the Interface VIG, but LabVIEW will not allow this with the following error:

However, creating a dynamic dispatch input terminal would not allow for the Command and Response VI to call the Interface of each child. What is the proper architecture for this implementation?

I have attached a sample project in LabVIEW 2009. Any help would be appreciated!

Thanks

I'm not sure what all the implications of this design pattern are, but it looks like it should work. You will definitely be duplicating data on every child class (the deeper the structure, the more data you will duplicate.) there are probably better design patterns for your implementation anyway. I

I can't upload a snippet right now, but I'm thinking you can't do what you are trying to do in 2009. 2010 added the preserve runtime class which will allow you to override the functional global VI.

Honestly I would go with an SEQ instead of a functional global. It would make understanding which object is being operated on much easier.

~Jon

The "Othello" contribution in the "Examples Competition" uses property nodes.

Othello

I didn't experience any problems with this code, in dev environment nor built application.

thanks for the example.

~Jon

Jon Kokott's issue appears to be caused by something not related to property nodes, but the property nodes are just getting caught in the crossfire. I haven't had time to take a good look at Jon's demo (I just heard about the issue before I left last night), so I can't say for sure why it's happening. It might help to force a compile (Ctrl+Click the run arrow) after loading a VI (i.e. opening or restoring). I recognize this isn't a solution for a lot of cases.

I would agree with this assessment that something else is going on beyond the property node itself. I've had them work sometimes, but eventually I do something to the class that creates this corruption condition. I've been cntrl clicking quite a bit, and it does help, unfortunately, I cant do that for a built application .

Remember that this is just an example and the code doesn't really do anything. I'm illustrating some common things I do with classes (which actually are needed in my development application.) If I cant change the data type on that wire in the shift register there is no point for me to even use classes (I realize that I don't do that in this example, but I wanted to show how legal syntax (<- is that even the right word?) can create a crash)

As far as the preserve run time class goes, its a similar situation. I really do need to be able to change the data type in that loop sometimes, and that function will return an error. The preserve run time class (as far as I can see) is for use with in place element structures or other situations where labview is unable to resolve the run time data type (inside a dynamic dispatch vi perhaps?)

Make sure that you can build an application also. I spent like a week with an architecture similar to this before I had a point where I could make an exe that would do something before I realized that using the property nodes was gonna crash every time.

~Jon

I am gonna side step my original statement of that I cannot use the preserve run time class VIs. Any place where I would perform that downcasting I wouldn't be changing the class on the wire (I would be getting downcast errors.) As far as that replacement goes it did eliminate my errors in the development environment (no crashes, no data type losses.) But In a built application it still crashes.

Could you build one of your own applications where you are using property nodes?

I didn't consistently see the error until I built my application for the first time. Furthermore, it was mostly displaying bad data in fixed data types like U32s or some other scalar. It wasn't until I used a datatype like a string or array before the crash became consistent (I think its still a matter of probability, it just gets alot higher the more memory you require for a datatype.)

Hey Jon,

If I get rid of the up and down casting it all works great. I create the JonChildChild class outside the loop and there is no crash. So I wonder about the need for the upcast and 2 subsequent downcasts.

Also, you can replace the downcasts with "Preserve Run-Time Class" and you are golden!

Best,

N

Remember that this is just an example and the code doesn't really do anything. I'm illustrating some common things I do with classes (which actually are needed in my development application.) If I cant change the data type on that wire in the shift register there is no point for me to even use classes (I realize that I don't do that in this example, but I wanted to show how legal syntax (<- is that even the right word?) can create a crash)

As far as the preserve run time class goes, its a similar situation. I really do need to be able to change the data type in that loop sometimes, and that function will return an error. The preserve run time class (as far as I can see) is for use with in place element structures or other situations where labview is unable to resolve the run time data type (inside a dynamic dispatch vi perhaps?)

Make sure that you can build an application also. I spent like a week with an architecture similar to this before I had a point where I could make an exe that would do something before I realized that using the property nodes was gonna crash every time.

~Jon

I'm assuming it's not reproducible.

I don't have a complex hierarchy. One abstract parent and 5-6 child classes. Everything has worked flawlessly (though now that I've stated this, it'll break tonight!). I like the fact that when I realize I need access to another data member, I can add the method and save the class and then it's availability is updated in the property node that is already on the BD.

Here is a snippet from the code that is crashing

This is the case with the property nodes.

The snippet didn't change. It is the same except the last VI is replaced with a property nodes that reads the two data values from the class data.

It won't crash without the dynamic dispatch VI "no Crash" in there. This one is crashing in the development environment as well as the runtime. It is important to stick a datatype like a string or array in the child type.

I attached the whole project in a zip file if you want to mess around with it. Just make sure you don't have something else open that you need...

It is the same file that I gave to NI.

~Jon

NIDemo.zip

Hi Jon,

Sorry to hear LabVIEW Class Properties aren't working for you. I went ahead and got a copy of a project that an Applications Engineer (Lynn) had made that demonstrated the problem. It looks like another bug that I had seen but couldn't reproduce. This sounds to be a lot easier to reproduce, so it should be a lot easier (comparatively ) to debug. When I get a chance to investigate it more thoroughly, I'll post here / communicate with support.

- Mike

Glad to hear it. Lynn has been my contact at NI on this issue and has been very helpful thus far.

I'm experiencing problems with using property nodes on classes to the point where I've been forced to abandon them entirely.

One of the new features of labview is that data members of classes are accessible through property nodes (both by value and by reference.) I found this to be extremely powerful as it allowed me to access not only the private data of the child class, but also the data of all ancestor classes (who have exposed their members to property nodes <- this makes it almost a public data type)

however, the property nodes are somehow losing the data type of the class (casting it to the parent type, I think) This has created LV development environment crashes (sometimes) and built application crashes (almost always)

Has anyone had success using property nodes with classes?

Specifically using them in conjunction with DVRs?

How about DVR/Inplace/Preserve runtime class dynamic dispatch operations in conjunction?

For now I've contacted NI on this issue I'm seeing (and eliminated all property nodes)

NI is seeing the same thing I do, but I'd be interested to know if anyone can get this to work.

~Jon

Can you drop a diagram disable structure around the subvi call you are trying to delete? Can you drop a case structure around it, and then delete the whole case structure.

If you want load a VI without its dependencies, you could try moving it to some other folder on your hard drive, and load it alone. It will give you lots of warnings and searches, but you may be able to get the diagram open and delete the unfound subvis. Then you could move it back and cross your fingers and it might load.

If none of that works, you can probably send your VIs to NI, and ask them to recover the damaged VI.

Jason

The diagram disable looked promising, and it did allow me to remove the VI, but unfortunately labview just delay the crash until I try to save the VI.

As far as moving the depenency to a different location, I've tried that, and it makes no difference. Unfortunately the VI i'm trying to delete isn't being found by labview anyway, so moving a VI that labview doesn't think exists doesn't do anything.

mass compiling doesn't help, and I'm starting to think that the recursion in LVOOP isn't ready for primetime in LV8.6.

~Jon

The diagram disable looked promising, and it did allow me to remove the VI, but unfortunately labview just delay the crash until I try to save the VI.

As far as moving the depenency to a different location, I've tried that, and it makes no difference. Unfortunately the VI i'm trying to delete isn't being found by labview anyway, so moving a VI that labview doesn't think exists doesn't do anything.

mass compiling doesn't help, and I'm starting to think that the recursion in LVOOP isn't ready for primetime in LV8.6.

~Jon

Eventually working with that diagram disable structure allowed me to remove the bad VI in question. I had to throw the diagram disable structure over the bad VI, then delete it using a replace with vi. The VI I replaced it with had to be an express VI (I think the fact that express VI's enforce some kind of special recompile had something to do with it.)

thanks for the diagram disable idea,

~Jon

Labview is endlessly crashing on me.

I have some recursive LVOOP classes which i've identified as the origin of the problem.

Essentially I disconnected one of the recursive classes from the hierarchy and now any VI's which used that recursive property are broken and will not allow me to fix the problems without crashing labview. (I can reconnect the hierarchy, but it seems do nothing for me.)

I cannot remove the recursive call as it thinks its VI name is "" and it simply won't "delete" (click on a VI block on the diagram, press "delete" key, and its still there. Do that enough times and it will tell you it cant find the VI, followed by labview crash.)

Is there any way to load a VI without labview trying to load its subvi dependencies? I think this would allow me to atleast remove the problematic calls.

~Jon

Look in Numeric>>Data Manipulation to find Join Numbers and Split Number. Join Numbers will take two U8s and turn them into a U16. Split Number will do the opposite. If you are dealing with arrays of your 16bit data, you may want to also look at the Decimate 1D Array and Interleave 1D Arrays.

The type cast function is a much cleaner way to do this. I suspect significantly faster as well.

~Jon

I did this VI more as an experiment in vi scripting than to be "good."

I would recommend creating a static hierarchy and simply returning the section of interest as yair suggested above if you need this to be blisteringly fast.

~Jon

Generic_VI_Server_Hierarchy.vi

I have a VI that will give you a generic's hierarchy.

I can upload it after work.

~Jon

I'm really not familiar with the .net framework, but it seems that you are using windows to dispatch the .dll. Have you tried registering your new .dll using regsvr32 (http://ss64.com/nt/regsvr32.html)

otherwise you can check out the attached tutorial on the windows registry.

~Jon

I forgot I cant attach files at work. there are tutorials online for how to use the windows registry, just be careful when manipulating these files.

~Jon

I'm really not familiar with the .net framework, but it seems that you are using windows to dispatch the .dll. Have you tried registering your new .dll using regsvr32 (http://ss64.com/nt/regsvr32.html)

otherwise you can check out the attached tutorial on the windows registry.

~Jon

I would try dispatching the .dll by wiring the path.

If that doesn't work, try searching for diagram disable structures.

Anything in a diagram disable will not be compiled and will not be shown in the callers list, but still will be listed as a dependency even though you are not really using it. I've had this kind of conflict several times when using other people's code.

~Jon

Really appreciate the help guys.

I'll put this to good use.

~Jon