Leaderboard

Inspired by Fab who showed us a time-saving trick she just learned, here's a trick I stumbled upon today by noticing a tip strip from an inadvertent mouse hover in the "View New Content" section of LAVA. If you click on the bullet rather than the thread, it will jump to the first unread message in the thread, rather than the first post in the thread. My life just got better - been wanting this feature!!

I just discovered by accident that if you copy a primitive VI (like add) then edit the icon of a VI and paste , you get the icon of the primitive? I am sure a lot of you already knew this, but I thought I would share, because it was a nice surprise to me. Now it will be easier to create new icons. Fab

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

If you want to see a Certified LabVIEW Developer sample exam written using LabVIEW classes, I am uploading one here. I built this over the last four hours in response to comments in another LAVA thread which correctly pointed out that a sample CLD written with classes was not available for review. If you wish to comment on improving this class-based sample exam or ask questions about how it works, please post them here. If you wish to debate whether LabVIEW classes are worth using or whether they are overkill for real apps (including for the CLD exam itself), or any other philosophy, please post in the original thread that spawned this. The sample exam that I did was ATM version 2 (I am attaching the PDF to this post for ease of reference). After 4 hours, I have the solution posted below. It is not a fully fleshed out app -- it is exactly what I have finished after 4 hours and would have turned in on the exam. It is very similar to what I turned in for my actual exam, although I will note that for my actual CLD, I specifically brushed up on file handling and had that working. Tonight, I was unable to recall my cramming, so that just got dropped (but documented as a TODO!). Top level VI is ATM UI.lvclass:Main.vi. This VI takes an ATM UI object as input in case configuration options are added to this application in the future -- those options are already part of the UI loop. Issues that I know of: File I/O is not done, as I mentioned above. The display strings are placeholders ... I didn't type out all the proper strings. There's no way for the user's name to be displayed when they put in their card. Although I documented the VIs, I did not fill in documentation into the classes themselves and probably should have. Other than that, I think it all works given the limited testing I was able to do within the 4 hours. I have no idea why I felt the need to make setting the display message go through an event instead of just setting the local variable every time. I think i had it in my head to bottleneck the localization, but that doesn't work, of course, because you have to be able to format information into the strings. That should probably be removed entirely. I did build a message abstraction from ATM UI to ATM, but I didn't build a messaging abstraction from ATM to ATM UI. Why? Because I thought the data needed to respond was always the same. It wasn't until later that I decided that was a mistake, but I figured I should finish out this way. Building a true abstraction layer for completely isolating the ATM from the ATM UI is probably more than can be done in the 4 hour block unless you've got some scripting tools to back you up -- we'll have to see if it's reasonable in LV 2012 (without going into detail, assuming the beta testing goes well, there will be tools to help this exact problem in 2012). 100928-01.pdf AQ_ATM2.zip

WebPanel, an open-source monitoring and control framework based on Javascript, SVG, and WebSocket, is launched at Evexia. The download includes the code originally posted on the LabVIEW, WebSockets, and SVG thread with some minor script improvements and the addition of some new elements (plus removal of some old, sorry). The included LabVIEW server has been brought up to version 2011. Here is a screenshot: As with the original version, this first released version is intended as a demonstration of using Javascript+WebSocket+SVG for remote monitoring and control. Prefabricated graphical objects are imported into an SVG template using Inkscape and arranged by the user in WYSIWYG fashion. The SVG template contains the necessary elements for loading the script and using the prefab elements. As with the original version, the demo server is written in LabVIEW. I am planning an open-source server probably based on jWebSocket and Java. I am also planning on creating a WebSocket subprotocol for binary data streaming. Obviously, the project is in transition right now. If you are interested, check back often both here and at Evexia. I will try to maintain the habit of posting new release information on this thread. if you are interested in contributing, message me. I have a subversion repository set up for the project that will remain at Evexia for the time being. In the future, it will probably move to a public, open-source hosting site. sm

First, as far as I know the main use cases for using traditional "dynamic sub vis" are: 1. The application allows plug-ins that will be created after the main application is compiled. (Dynamic loading.) 2. You want to improve the application start up time. (Dynamic loading.) 3. You want to start an unknown number of identical processes. (Dynamic launching.) If one of those three isn't your goal you might want to rethink using dynamic vis. IMO it will add unhelpful complexity to your project. (There may be other non-oop reasons for using dynamics I haven't mentioned.) "Regular" sub vis on a block diagram are loaded when the parent vi is loaded. I'm going from memory here and haven't tested it all thoroughly, but here's my understanding: It depends on whether you are using dynamic loading or dynamic launching. Here's an example of the difference: The top example has a static reference to the vi that is going to be executed. Since LV "knows" which sub vi is going to be used, you don't need to specifically include it in the build and the sub vi is loaded when the application starts. The middle example does not have a static reference to the vi that will be executed. The reference shown is for a vi that *only* defines the connector pane. (No BD code.) All plugins will need to use the same connector pane pattern. The vi located at that path (if one is there) is loaded when the Open VI Reference function executes. If you have vi's in your project you are loading using this method, you'll need to "always include" then in your build. (It kind of defeats the point of having a plugin though.) The last example is a hybrid of the two. Yep, especially if you're using dynamic loading to load vis already built into your executable. If the sub vi is going to be included in my build anyway I use a Static VI Reference and avoid all the management headaches.

Victory! That output terminal will not be needed as of LV 2012. There was a (bug / unimplemented optimization -- depends upon your view) that made LV add a copy at certain upcast coercion dots. This compiler (fix / upgrade) will have performance benefits for a wide range of LVOOP applications. The change was implemented months ago, so this API doesn't get credit for finding the issue, but the compiler team verified your VIs do benefit from the change. I would therefore recommend not putting it into the API as removing the terminal is a possible mutation issue, and not having the output terminal for a read-only operation is a much better API overall.

You can also drag and drop the icon of one vi to another vi without copy/paste. No keystrokes required... (front panel to front panel)

Hold off on finalizing this until the end of the week, please. I'm asking compiler folks to investigate the performance gain of adding the output terminal to see if there's another way to get that gain OR if it could at least be made unnecessary in LV 2012. Since this affects the conpane of the VIs, and that would be hard to remove in the future, it would be better to publish without it. If you don't hear from me by the end of this week, ping me, please.

It's not garbage collection in the usual technical sense of the word. "Garbage collection" is used in systems where two objects both use a third object. When the first object disappears, all top-level objects objects (like the second object) are traversed and any objects that don't get visited stay in memory. Since the third object gets visited, it stays. When the second object disappears, all objects are again again checked. It's used in systems where there isn't a reference count to determine whether or not to throw the item out of memory because incrementing and decrementing the reference count is too much thread friction. The trick is that the garbage collector isn't actually run after every top-level object gets thrown away... it runs periodically during down time and cleans up large swaths of available memory. LabVIEW just deallocates the queue when the VI that created it goes idle. There's no garbage collector algorithm that goes hunting for all possible queues to see which ones should live and which ones should die. And, yes, what the VI does when it goes idle is identical to calling Release Queue. The same function is invoked under the hood.

I've had a few evenings to work on another XNode, this time to unbundle an array of elements from a Cluster Array (as per this Idea). As much as possible, I've tried to mimic the functionality of Unbundle Cluster by Name. There were a few tricky things to get this to work, and I'd be interested if I missed an easy way to achieve any of them: traversing a cluster hierarchy to build the pop-up menu not permitting the XNode to be shrunk past any connected wires correctly wiring outputs again if the XNode is extended upwards Comments welcome! Requires: LabVIEW >8.6.1 Gavin Burnell's Scripting Tools (thanks again!) OpenG LabVIEW Data and String Libraries Unbundle Cluster Array.zip