mike_spacex

Name: XNode Wrapper Submitter: LAVA 1.0 Content Submitted: 03 Jul 2009 Category: XNodes LabVIEW Version: 8.0 Version: 1.0.0 License Type: GNU Public Potentially make this available on the VI Package Network?: Undecided Copyright © 2006, Mike Lacasse All rights reserved. Author: Mike Lacasse --see readme file for contact information Description:: To use this VI: Put it in the same directory as the VI you want to "wrap" and rename this VI to ";Dxxx_targetVI.vi" where 'xxx' can be anything, and 'targetVI' is the name of the VI you want to "wrap". The target VI must have a 'type' input terminal and a 'data' output terminal (these can be wired anywhere on the connector pane). Now you can drop this VI on block diagrams instead of your target VI. The 'data' output terminal will conform to be whatever datatype is wired to the 'type' input. Your target VI will still appear in the VI Hierarchy as a subVI. Double-clicking this node on the block diagram will open the target VI.. This is accomplished within the xnode by altering the terminal specifications and by typecasting the output data from the target VI to the datatype wired to the 'type' input. Much of this implementation was done in LabVIEW 7.1 using VI scripting which is available by adding the following lines to LabVIEW.ini: SuperPrivateScriptingFeatureVisible=True SuperSecretPrivateSpecialStuff=True Here's the disclaimer: DO NOT contact NI for support on VI Scripting. DO NOT use these features for released code or applications to your customers. DO NOT count on the implementation to stay the same for future releases of LV. It will change and your code will not be upgradable. The code is pretty well commented. White text boxes describe how the xnode functions. Yellow text boxes are implementation details. Thanks to Adam Rofer for the XNode documentation available at Known issues/bugs: - In LabVIEW 8, the VI description doesn't update correctly from the target VI. It works in LV7.1 to get the target VI's description to show up in the context help window, but not in 8. Not sure why. - Terminal Labels don't appear in context help window. The icon image of the subVI is succesfully copied, but not the terminal labels. This would be a nice fix. 'Get Conpane Image' gets what I want from the target VI but there is no 'Set Conpane Image'. - Is there any way not to require ';Dxxx_' in the VI name, but still have it work right? - If the target VI is not executable, the errors list only says 'External Node: Code could not be generated correctly for this VI'. Thats not very helpful. - Still working on finding a way to automatically rescript the xnode when changes are made to the target VI. This would be nice so if a control or indicator name is changed on the target, the terminals on the xnode will be renamed accordingly. Version History: 1.0.0: Initial release of the code. Click here to download this file

Greetings. We're looking for a Certified LabVIEW Architect with Object Oriented Programming experience in large-scale projects to perform a software peer review. Despite the fact that we're well into the software lifecycle, we could still benefit from advice on prioritizing or possibly re-directing our efforts to make an easily maintainable and extendable product. For starters, I'd like to see how many applicants I get with the following REQUIRED qualifications: CLA with 5+ years Lead Developer Experience OOP Experience using Endevo GOOP Successfully deployed plug-in style applications Software Peer Review / Auditing experience Available to perform audit sometime in the next 3 months This contract job will require reading (really reading -- not just skimming) 100+ pages software documentation, visiting our facility in Charlottesville VA to sit through some software presentations/demonstrations, ask prying questions about our code development practices and processes, prepare & deliver a formal review document with praises, concerns, suggestions, etc. to help direct our future efforts. Don't post your response here; Send your resume to mlacasse@nrao.edu. ONLY APPLY IF YOU MEET THE ABOVE REQUIREMENTS. I'll announce the relaxed required qualifications on this forum topic if I don't get a good pool of applicants soon.

QUOTE (crelf @ Jan 22 2009, 12:59 PM) I think we interpret NI Labs differently. When I read "aren't quite ready for release" and I see a list of "graduates" along the side of the page, I'm led to believe NI Labs stuff will soon (maybe less than one year) be available. Judging from the discussions on the NI Labs forums, there doesn't appear to be much product evolution taking place. This could mean people aren't using NI Labs, or people are not giving feedback, or the product is fairly mature and people are happy. The question you pose, "Is LabVIEW Scripting mature enough for public consumption?", is for NI to answer. Most of the features I've used have been stable since I started using them in LabVIEW 7.1. I'm thinking that NI hasn't publicly made scripting available either because they are still planning on some major revamping, or (as suggested in some previous posts in this thread) they are keeping some sort of upper-hand over possible competition by keeping it in-house. Or maybe they're just pleasantly amused watching us 'easter egg hunt' with each new release!

I said earlier that I don't think scripting "fits the bill" for NI Labs for the same reason LV_FPGA_SE stated: QUOTE (LV_FPGA_SE @ Jan 21 2009, 10:55 AM) If a LabVIEW version upgrade suddenly breaks all my xNodes or scripting code, my supervisor (who knows very little about LabVIEW) would flip out when he discovers I was using an unsupported technology. I only want stuff on Labs that truely is nearly ready for release so I can confidently use it knowing there's little risk that, down the road, major refactoring of my code will be necessary. If NI is prepared (or nearly prepared) and equipped to support most functionality made available through scripting, including auto-update of deprecated properties and methods, then I think Labs is in fact a good place for it. If not, wise advice would be - keep it in your pants if you're not ready for that sort of commitment. Perhaps I'm being too pessimistic about the maturity of scripting and NI's readiness to support it.

Scripting wouldn't be as much fun if it were "legal", am I right? Even for those of you who don't (yet) inhale, isn't it great just to get a little taste of scripting knowing that "the man" doesn't want you to? If not, well, hang around these forums long enough and the peer pressure is sure to get the best of you. Perhaps it should just be legalized for medicinal purposes -- to help take the edge off those long boring days at work for the rogue programmer. Analogies aside, NI Labs is a place that "showcases the evolving technologies from NI R&D engineers that aren't quite ready for release". First, let's assume "aren't quite ready for release" refers to the technologies, not the R&D engineers. Second, I don't think scripting fits the bill. Besides, NI is probably thinking, "Legalize scripting!? What are they gonna ask for next, opening LabVIEW source code?!" We really would need Obama for that one. I guess what I'm saying is, I don't think it'll happen. BUT, if it does, wouldn't it be great if NI still required us to type in 'SuperSecretPrivateSpecialStuff', that way I can still feel like an evil genius!

QUOTE (jgcode @ Dec 8 2008, 05:16 PM) The test suite we developed doesn't do any fancy linking of tests to requirements, it just dynamically runs a batch of test VIs (listed in an ini file) that all conform to a common type specifier. Each test is designed to "exercise" some aspect of our software architecture then output a boolean pass/fail, string message, and error out. Results are stored in a txt file and also automatically emailed to a list of recipients. It's easy to setup Windows Task Scheduler to run a .bat file that opens and runs the regression test VI from the development environment. Weekly, daily, whenever... it can even be configured to run using admin privileges, providing the username/password, if necessary. zipped attachment contains: regression test VI ini file that lists the tests to run .bat file used to schedule autorun 'bad test.vi' -- use this as a template CPU Usage VI (used in many of our tests) http://lavag.org/old_files/post-4721-1229361212.zip'>Download File:post-4721-1229361212.zip

Here's a little nugget and also a complaint (one of very few) that I have with LabVIEW development. Before I ever even knew about LabVIEW I was part of a group of developers that belived in (and strictly enforced) test-driven development, which is related to the test-first programming concepts of Extreme Programming. We were encouraged to not write any code unless we had developed all conceivable test cases for it first. The tests might not even compile at first because not all of the classes and methods they require may exist. Nevertheless, it functions as a kind of executable specification. You then get it to compile with minimal production code, so that you can run it and watch it fail. (Sometimes you expect it to fail, and it passes, which is useful information.) You then produce exactly as much code as will enable that test to pass. Having this practice engrained in me made it difficult to start working in LabVIEW, where you at least need to develop a con pane (and therefore a crude front panel) before you could even write test code that calls your subVI (unless making dynamic calls using VI Server). When I apply test-first programming (as best I can in LabVIEW) I typically write more robust code and avoid the 'fix 1 bug -- create 5 more' problem. It also helps me nail-down the requirements early in the lifecycle. All the tests get added to a 'regression test suite' which we run weekly to verify that nothing has broken. This approach also leaves less open for interpretation than do written requirements documents when handing off tasks to other developers. That's my 2 cents.

I definitely noticed a productivity increase when I added a monitor about a year ago. It also comes in handy when I have to refactor code from another developer who had no notion of keeping block diagrams compact. I just stretch it out over both screens to help get the 'big picture' then start workin' it down.

Here's an example of the suggestion I made at the end of my last post. I think it's generally a good practice, if you must have multiple event structures, to designate only one for handling UI events. This way, you can keep your booleans latched AND you can easily pass relevent information to the other event structures registered to your user event without the need for functional globals or even local variables. Download File:post-4721-1227636898.vi

Interesting discussion... but I think I'm missing the point. Why not simplify GraemeJ's examples with just one event structure with one cancel button (shown in attachment) Download File:post-4721-1227629692.vi If you have multiple events whose actions depend on multiple conditions, still just use one event structure but hold the conditions in shift registers (or functional globals if you must!). Download File:post-4721-1227635074.vi All the concurrent loops and event structures are dangerous and difficult to understand or document. If this is an exercise in communication between concurrent structures with events, then I suggest creating a user defined event and registering it with each structure. Otherwise, keep it simple.

I'd love to hear some ideas on this one. DAQ is so flexible and customizable it's near impossible to write something generic enough to handle all use cases. It's far from perfect, but I attached an example of the way I did it recently. I create an instance of my DAQ object for each input I want. I configure that instance by passing it a DAQmx Task and a 'Type', which describes the expected return datatype of the task. This design can be expanded by adding other 'task types' to the DAQ read method in my DAQ class, and other cases for handing graphing and display or logging. Obviously, the same pattern could be employed for DAQ output. By the way, has anyone ever written code that "figures out" from the DAQ task properties what datatype to expect to be returned? If so, this example could be made much simpler. Download File:post-4721-1227628289.zip

Not sure if it's against the labview development license so I never developed it, but I did consider making a tool for test engineers to make simple modifications to their UIs or create one from scratch in a way that the scripting was done on a different computer (running the LabVIEW developement envir.) then the created VI would be exported to their machine and loaded dynamically in the run-time environment. It would just be a slight modification from a tool I built to help developers using my software architecture to quickly design and deploy UIs using an easy drag-&-drop interface. I was planning on using the VI property 'FP.Get Image' and transferring the image data through Network Shared Variable to an interactive viewer on the engineer's system. When he's satisfied with the changes, the "server" scripts the necessary block diagram code then saves the VI to a network file server so it's available for the 'client' system to copy locally, load, and run. I planned on limiting functionality to create, destory, and move controls and indicators on the UI and specify their linking to monitor and control parameters in his system. Definately possible, but is it legal? If you're curious what the developer's tool looks like, I attached a screen shot.

Hi. I suspect that the intent of tags is NOT to send information TO VIs, but to store information ABOUT VIs. The sample code you made could be done without tags (and without super secret scripting stuff) simply by using the Set Control [Variant] method (see no_tag_utilization.zip). And why not? The master/slave scenario requires the slave to have knowledge about the master anyway, so why not include a front panel control to make it explicit. I think tags could be handy when you want to store information and associate it "with" a particular VI without the VI having any knowledge that you're doing so. An example of "real life" tagging is when scientists tag animials with a GPS receiver and logger in order to track migration patterns. I attached a silly example that demonstrates just this (fun_tag_utilization.zip): Run the GOD VI to create animals (as many as you can handle). Run the Scientist VI to tag animals and log migration patterns (the scientist can only interact with animals/tags he can "reach"; hint: move stuff) Run the GPS Sattelite VI to cause tags to periodically update their value to include their latest position. Take a look at the private/animal.vi block diagram. It's ignorant to any of the tagging & logging. I think this is the advantage. Here's the mystery: Where in memory is the tag data stored? Memory usage for LabVIEW.exe in the Windows Task Manager shows increasing memory usage BUT the VI profiler doesn't show it piling up in any particular VI memory space. I hope the example is fun and useful!

Hey fellas, check this out --- I added it to the code repository a while ago: XNode Wrapper Not only does the output conform to whatever datatype you wire to the type input, but the code actually DOES SOMETHING! The XNode will script a call to the VI with a similar name and type cast the output to the datatype specified. Email me with questions if you're confused. I'm still trying to refine the documentation. An example of how I use this: I have a program that requires some custom handshaking between server and client using Datasocket communcations. I input the URL and the datatype of the datasocket item I'm requesting. Then, the output conforms to the type I want so I don't have to use the 'Variant to Data' function every time I want to call it. This is handy-- its the same thing the DataSocket Read function, and many other LabVIEW functions do anyway, but now I can do the same thing with any of my own VI's. I'm eager to see the day when NI will release XNodes to us the way they have with XControls. But until then... this'll have to do.

File Name: XNode Wrapper File Submitter: mike_nrao File Submitted: 6 Jul 2006 File Updated: 22 Oct 2006 File Category: LabVIEW Development Environment To use this VI: Put it in the same directory as the VI you want to "wrap" and rename this VI to ";Dxxx_targetVI.vi" where 'xxx' can be anything, and 'targetVI' is the name of the VI you want to "wrap". The target VI must have a 'type' input terminal and a 'data' output terminal (these can be wired anywhere on the connector pane). Now you can drop this VI on block diagrams instead of your target VI. The 'data' output terminal will conform to be whatever datatype is wired to the 'type' input. Your target VI will still appear in the VI Hierarchy as a subVI. Double-clicking this node on the block diagram will open the target VI.. This is accomplished within the xnode by altering the terminal specifications and by typecasting the output data from the target VI to the datatype wired to the 'type' input. Much of this implementation was done in LabVIEW 7.1 using VI scripting which is available by adding the following lines to LabVIEW.ini: SuperPrivateScriptingFeatureVisible=True SuperSecretPrivateSpecialStuff=True Here's the disclaimer: DO NOT contact NI for support on VI Scripting. DO NOT use these features for released code or applications to your customers. DO NOT count on the implementation to stay the same for future releases of LV. It will change and your code will not be upgradable. The code is pretty well commented. White text boxes describe how the xnode functions. Yellow text boxes are implementation details. Thanks to Adam Rofer for the XNode documentation available at http://xnodes.lavag.org/XNode.html Have fun using this VI. Let me know what kind of exciting uses you find for it. Email me at mlacasse@nrao.edu Known issues/bugs: - In LabVIEW 8, the VI description doesn't update correctly from the target VI. It works in LV7.1 to get the target VI's description to show up in the context help window, but not in 8. Not sure why. - Terminal Labels don't appear in context help window. The icon image of the subVI is succesfully copied, but not the terminal labels. This would be a nice fix. 'Get Conpane Image' gets what I want from the target VI but there is no 'Set Conpane Image'. - Is there any way not to require ';Dxxx_' in the VI name, but still have it work right? - If the target VI is not executable, the errors list only says 'External Node: Code could not be generated correctly for this VI'. Thats not very helpful. - Still working on finding a way to automatically rescript the xnode when changes are made to the target VI. This would be nice so if a control or indicator name is changed on the target, the terminals on the xnode will be renamed accordingly. Click here to download this file