Jon Kokott

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

Reentrant dynamic dispatch VI called by reference? I do not think that will work. I believe you are refering to this pattern:

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

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

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 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

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

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

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

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

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'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

I didn't experience any problems with this code, in dev environment nor built application. thanks for the example. ~Jon 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 .

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.)

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

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

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

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

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