John Lokanis

All good points Dave. Thanks for the feedback.

Bringing this thread back from the dead... So, I am still planning to do this, it just got put off a bit. In the meantime I have been collecting more ideas and information. One area I want to address first is coding standards. I want to get my coding guild-lines down on paper, reviewed by the group and used to do future coding. I have lots of ideas of what I want to include but would welcome your thoughts. If you have a coding standard doc you want to share, that would be great! I am always happy to steal borrow ideas I find worthwhile. Things I plan to address: Style (mainly what is included in Peter Bloom's book) Commenting Documentation Unit Testing Use of VI Analyzer Organization of source code on disk and in projects Code reuse Code review process What else should be included? thanks for the input. -John

Try using a Variant to represent a tree. Make the attributes of the variant also be variants. And so on. You can model a tree of any shape/dimension this way.

Thanks. I will post an update once I get the other features added. My long term goal is an automated build system that is script driven and will let you do nightly builds, beta builds, release builds, including pushing them out to network drives for distribution. Now if only I could so silent installs on targets I would really have something!

Ok, so I think I have this working. At least the part of dynamically updating the installer message to reflect the version of the EXE we just built and are packaging. I also am updating the installer target folder to reflect the EXE version. This way you get a new folder every time you build the installer. So, no more clobbering the previous build output. Now I need to rename the EXE target folder based on the version. This will be harder since I will need to point the installer to the new folder each time. For now, this seems to work well. Let me know what you think. Project Version Demo.zip -John

Thanks for the ideas. I like the idea of the EXE verification. But, I am trying really hard to stick with native LV build specs and the installer. I just think we should have this kind of feature. Not sure I will be able to pull it off however. Can you modify the installer portion of the build spec from the post build action VI and have the change take effect before the installer build runs (when doing a build all)?

So, here is the problem: I want to access the build version of my EXE with a post build action VI. My goal is to modify the welcome message in the installer build spec to include the build version. If that fails, I want to at least generate a file that can be included with the installer to label the build version. Ideally, I would like to place the build in a folder that incorporates the version in the name. Not sure yet how to accomplish this in an automated way, but the first thing to tackle is getting the version of the EXE. I have come up with three ways to do this: 1. use project properties to extract this information (so far, a major PITA) 2. extract the information from the project file using XML tools. (also a PITA, just in a different way) 3. after the EXE is generated, use .net calls to read out the version information. My question is, has anyone already solved this? Do you have a stable and elegant solution you can share? If not, do you have any other suggestions on how to do this? For the NI guys, why is this so hard? Shouldn't this info be easy to access? Why should it be hard to make an installer that tells the use what version they are about to install? Does anyone else have their own custom build system that does automated builds to new folders every night/week/etc? How do you do it? thanks for any help or ideas. -John

I will be there! And I use OpenG in almost all of my projects. Have been using it for many years. I would like to learn more about the process of turning some of my reuse code into OpenG packages.

Glad to hear to found the right solution for you. It really comes down to what device does what you want to do and does it well. It really does not matter which one has the most RAM, CPUs, ports, etc. If it does not do it's job well (web browsing, email, apps, whatever) then all the 'spec's in the world do not matter. The best thing you did was to try them side by side. Same thing goes for smartphones. Now, if you have kids, you will need to buy a second iPad. I cannot get mine away from them. At least the apps they love are teaching math, reading and basic physics. I have high hopes for the next generation of engineers who have had much better access to information than we did. Now to just get LabVIEW running on a tablet...

LabVIEW does not 'normally' run as a console application. So, making it write to StdOut and StdErr is not simple. But, it can be done with some hacking (in Windows). Not sure if it is possible in OSX or Linux. But, keep in mind that you get one shot at sending in commands. The app must then process those commands, write to the StdOut and then exit. You cannot send additional commands via the CMD console. (search LAVA for a thread on this from last year) If you need continuous commands to a running application, I would suggest you write a DLL or create a web service interface for your application. The bonus of the web service is you can use something like curl on the CMD line to send and receive data and you can do that from any machine on the network. good luck! -John

Just to add some real world experience from someone who has lived on both sides of the fence: For many years I used Windows PCs professionally and at home (having built many myself over the years). I still use Windows7 at work everyday. However, when our last Dell laptop died, I decided to give the Mac a try. My wife already had an iPhone and I was impressed with the quality and ease of use it offered. Long story short, we now have 2 MacBook Pros, 2 iPhones and an iPad2. The first MBP is used for what I call family activities. Photos, web browsing, kids games, school projects. All the things that pretty much any computer can do, but the Mac makes it easier to get done. No extra SW to buy in many cases and very few bug or compatibility issues. The second MBP is mine. I use it for music production (hobby) and consulting (LabVIEW). I run LabVIEW under MacOSX and in Win7 VMs. Whatever is needed for the job. The iPad is used as a consumption device. The kids have lots of games and learning software (it is amazing how a 5yr old can figure out how to use iOS with basically zero instruction). I use it for Twitter, web browsing, video streaming, news apps, etc. My wife uses it for email (as noted, you only get one 'user' per device in iOS), Facebook, web and TV. It is a great device when you just want to look up something quick or want to sit on the couch and 'consume' content. I would never use it to write long docs or even attempt to do real work on it. It is not intended for that purpose. As for the debate about Apple vs the rest of the companies out there, I will say this: When we were a PC house, I spent a great deal of my time fixing problems with our PCs. Software bugs, HW compatibility issues, random weirdness that seems inherent in all Microsoft software. After switching all that has gone away. I know a great deal about fixing Windows but I know very little about Unix or MacOSX. Fortunately, the few times I have had to figure out how to fix something on the Mac, it has been very simple to diagnose and correct. So, if you like playing an IT support person in your free time, by all means get a netbook, Andriod tablet or whatnot and hack away. But if you want to come home from a long day at the office and just use your devices, then seriously consider an iPad. As for all the comments about Apple being a 'walled garden' I'll add that their garden is 1000x bigger then the rest of the ecosystem out there (as far as apps go) and a wall is not such a bad thing if it keeps out the snakes and bugs and other things that waste your time. In the meantime, I am patiently waiting for my parents old Dell desktop to die so I can get them to move to a Mac. Then I will finally be able to eliminate 'IT Support' from my list of job titles. -John

Glad to hear you passed! Looking forward to the CLA summit too!

You can always write your own. Most of what you want is available via VI Server.

Subtle race conditions can be affected by recompiles. So, sometimes it works (and works every time) and then after a recompile, the code is executed in a different order (like if you edited the block diagram and caused the compiler to rethink the compile order). Suddenly, the code does not work because the intended flow 'loses the race'. That is the joy of LabVIEW, There is no such thing as a syntax error but there are plenty of opportunities for race conditions to bite you in the behind. (BTW: that is why in my opinion EEs make better LabVIEW programmers than CS majors. We just naturally think in terms of races and not syntax.)

Here is a way to make something simular, but with the ability to be set at runtime. http://lavag.org/topic/7174-a-labview-worm/ This has the advantage of letting you globally set a reference that the RTE generates when your app starts.

I am looking for a list of and/or links to all the different architectures that have been proposed/shared in the LAVA community over the last year or so. I want to do an investigation of each and see what features I want to incorporate into a application template I am working on for my company. I have been searching the forums and found many, but I would like to make sure I have not missed any important ones. So, if you have authored one or know of one, can you post a link to the thread on LAVA or the NI forums or wherever else we should go to learn about and download your design? Personally, I am interested in ones based on OOP but please feel free to post links to ones based on QSM, Events, traditional state machines or any combination thereof. I hope this thread becomes a launching point for anyone looking for information on architecture ideas for LabVIEW. thanks! -John

You also get this if you use some .NET assemblies that are missing on the target machine. Took a LONG time to figure that one out!

The International Association for the Advancement of LabVIEW Development LAVA - Where new ideas in LabVIEW flow freely... Most Awesome Graphical Magical Algorithms (MAGMA) Very original LabVIEW concepts about neat objects (VOLCANO) Highly evangelical algorithm topics (HEAT) Topics enhancing concepts to optimize National Instruments code (TECTONIC) ok, some of those are pretty bad...

Thanks guys! I use this 'fire and forget' method in a lot of my code. This new node will certainly help clean my diagrams up!

I have a slightly different question about the CBR node. If I want the VI to run and dispose of it's own reference, how do I tell it to do that (I will not be calling the wait node since my VI returns its data via a queue). thanks, -John

I had no problem. Just had to make sure I en-queued for the bus before everyone else! Hope everyone liked the panoramas!

I can't tell you how happy this makes me. No more will my users be able to 'pause' dynamic VI launching by dropping down a menu and not selecting anything...

Pretty cool. Wondering how to integrate this into the IDE... One issue: for some reason, when I open the project, LabVIEW opens 4 new (untitled) VIs while the project loads. Other projects don't do this. Any ideas?