Dan DeFriese

I think the change was between 8.2 and 8.5. I don't know if it changed again in 2009. I couldn't get you're original to work with 8.5 the way you had it before so I hacking a simple state machine to parse through file. It still works as of 8.6 (I don't have 2009 yet.) Kind of a hack job, but it works for me and may be enough to get started on repairing you're CR submission. Hope this helps. ~Dan rtm to enum 8.5.zip

May have changed for 2009. But make sure you install the Vision Add-On to the correct LabVIEW directory.

I'm guessing that Cat's comment was tongue 'n' cheek based hoovahh's post. I would consult the VI Engineering website for 'real' employment opportunities.

I definately fall into this catagory ... Keep those ugly cube things away from me. IMO the Init method should simply spit out a fresh object. A method used to put an existing object back to its initial state would be Resetting the object and I'd refer to it as such. ~Dan

If the cluster is type-def'd you can do something like that below. In this case the cluster on the BD is just used for type input to the variant to cluster.

Excellent, thank you for these links!

Maybe a little off topic. Does anybody just use TestStand for there unit testing? If so, do you have any recommendation or caveats.

Your Welcome.

I'm not sure if I consider this a bug. But I usually resolve this in one of two ways: 1) Change the Support Directory's "Destination path" to match the directory of the *.exe. Then, set respective source files to be placed into the Support Directory. OR... 2) Add a new destination called "Application Directory" and set its path to match the directory of the *.exe. Then, set respective source files to be placed into the Application Directory. I'm not sure selecting same as caller works (or should work) with data files since there's no way for the app builder to determine which VI is calling it. (I know that I wouldn't want LV to search the entire VI hierarchy for a path constant!!!) BTW: If your trying to overwrite the default INI file that LabVIEW creates, this is done in the andvanced catagory.

Unfortunately, not everyone feels this way.

To be honest, I'm not sure I read the same article... I don't believe the duct tape metaphor was intended to condone a McGivor menality of thowing whatever you have available as fast as possible to ship the product. I came away with the idea that the praised programmer is generally unimpressed with the faddish super-douper-extra-dynamic techniques he doesn't understand. He sticks with techniques which he considers simple and reliable, like duct tape. Edit: Hew, looks like PaulG read the same article.

My preference is: 1) Each module (group or related VIs and CTLs) to have its own folder on disk. 2) All VIs and CTLs are contained in that folder (no subfolder). 3) Any further organization is done using *Virtual Folders in the .lvproj and .lvlib files (no autopopulating for me). 4) Control file names are ALL_CAPS_WITH_UNDERSCORE. 5) VI file names are Title_Text_With_Underscore. 6) VI and Control filenames have a acronym suffix to identify its owning module. If you don't do it this way go fly a kite!!! Honestly though, I don't think its all important that everybody origanize their code the same way. There are 6 developers on my team and not a single one of us codes the same way, much less organizes files the same way. I think its much more important that you are consistant in what you do. As long as a developer is consistant (does the same things in similar fashion throughout the project) it will work out so I can navigate the project after the few minutes it takes to get my bearings. *I really like Virtual Folders since they allow me order the files any way I want, move stuff around, or remove obsolete code without have to mess with disk or source control content.

That would certainly make me take back every word. I imagine this would be a pretty daunting task. I'm just imagining what the report generation toolkit LVOOP constant would look like if it were full ... best luck. Have a great weekend... ~Dan

Its more dangerous in that it will likely cost more money to maintain the code in the long run. I think your assuming that the maintainer will have the intimate knowledge of the class to determine how the constant got to its current state or the ability to do so. In a future environment that state may no longer have meaning... (The data type change issue). Where I work, I occasionally get pulled to make minor updates to existing code. Some of which are >25 years old. The only reason I can make these updates is that the original author coded it cleanly with nothing hidden. I can make these updates even while having only a novice understanding of the languages (e.g. C\C++, Java, even QBasic). If you need to execute code to get an object in a given state, I think its best to leave that code in the program. In my eyes a preset constant just isn't worth the headache I'm gonna cause myself (or someone else) in the future. I'm not sure I'm getting my point across. I'm not always that good at the whole putting words together and having them come out right. In the end, I don't really have a dog in this fight since I don't LVOOP. It just seems to that this resetting of the constant's value is the least of the class user's worries when I step back and think about what your're doing... and where it would go if some goof like tried it. Anyway, thanks for letting me debate.

Exactly, and when I take over the project 6 months later... The Mr. CutnPaste has moved onto bigger and better things, and now I'm stuck with some magic LVOOP constant on the BD that I can't modify when the requirement changes. In my opinion, its not the resetting of the LVOOP contant's value that's dangerous. It's that by not resetting it you're leaving it in unknown - to anybody other than Mr. CutnPaste - state. Now that's dangerous! I can see how the ability to cut and paste an LVOOP indicator to an LVOOP constant would be useful (e.g. debugging a section of code). However, my vote is for resetting the LVOOP constant value to the class's default value each time the VI is loaded... not just if the class default value changes.

Wow that's wierd. Option 2 works with execution highlighting on. Which I generally associate with a race condition. So forced execution with an error wire and sequence structure and it worked. TabTest.vi

How does the class user determine what the current value of the constant on the BD is without running the VI? (I mean when more than 5 minutes have passed since copy-paste. And No, a free label comment on the BD doesn't count!)

How does someone go about setting the default value of a LVOOP constant? Can the value of the LVOOP constant be determined from the BD without running the VI?

Try coping the LabVIEW.ini file from your ..\National Instruments\LabVIEW 8.5\ directory into the ..\National Instruments\LabVIEW 2009 directory. (Don't know if its LabVIEW 2009 or LabVIEW 9.0). Dan

Thanks .

Good that you brought that up... the LV versionsused in your TestStand Sequence must be the same version as used to build the EXE. Definately something to be aware of and consider before heading down this path. My approach was to build the sequence/TestStand package and VI Server controlled executable during the same process and release them on the same media. In your case, this would also imply 2 installers. One for your TestStand Machine and another for your remote instrumentation computers.

Here are my approaches to bit twidding. Dan

In my project I use localhost since the executable resides on the same machine Open Application Reference with say IP=192.168.1.27 and Port=3364. (The IP is the remote machine and the Port the identified in the INI file.) Open VI Reference is the Top Level VI "EUIOHost.vi" with which I want to interact. I pass both references back to TestStand where they're placed in a Global. Each test uses the VI Ref to obtain Control Ref's and manipulate as needed. I made several wrapper VIs which I keep in the VI Server subfolder. I thought it worked out pretty neat for my first/last TestStand project. Hope this helps.

The trick here is that your not pointing to an executable, You want to connect to the machine/IP Address and port (e.g 3363) on which the executable's VI Server Instance is listening. Also you have to make sure that the executable INI file is setup to start the VI Server. Well, I'm having trouble uploading my attachment, but just look into the Open Application Reference and Open VI Reference primitives. I found this very easy to glue together when I did it. If I get a chance, I'll post an example of how I did it.

Oh, I didn't say I could justify it ! Are you really eliminating the need for Init? Or just just doing it in a super-secret-implicit-sorta way by defining a your own default value for the private data control of the class for which you have no control over. My point is... the user should not depend on things which are not under his control. If you receive and updated version of the class you shouldn't be suprised upon a change to the private data types default value. While I agree that this logic may be a little disconcerning I don't see how it would be advisable to have a rogue class constant with its own default value which the user can't modify after the class is updated... Maybe I just brought myself around there. Perhaps the change in LV should be that a class constant value can be able to be set on BD sorta like a subVI node. Maybe if the constant is setup for a non-default value and the datatype of the class changes the vi should break. Of course, if the datatype has not change the value is retained. Nope. this still seems like playing with matches since your giving the user direct access to private data.