Leaderboard

You can all send a thank you note to JGCode. He posted a question in the ni.com forums that happened to hit at a moment when nothing was screaming for my attention, and I finally got around to going through the VIs that handle New Accessor and the New Override and removing all the passwords and posting those VIs to the forums. http://decibel.ni.com/content/docs/DOC-13196 http://decibel.ni.com/content/docs/DOC-13195 The first link will get you the files that actually handle creating new VIs within a LV class and scripting the different behaviors for the terminals (including the UI for the New Accessor VI dialog). You'll find a wealth of scripting helper functions in this library. The second link will get you the files that handle updating VI icons when the library icon changes, including the composition of inherited class icons. Open the file "MemberVICreation.lvlib". That's where you should begin your explorations. You'll quickly see the two top level VIs -- one handles new accessors, the other handles new overrides. Remember, with great power comes great responsibility. What do I mean by this? I mean that I'd like someone to finish writing the ElementWrapperRetooler.lvclass for me. :-) It's one of the classes that is now unlocked. That class is the start of a solution to "I have a class X that has another class Y as a private data member. I want to create a new method on X that has the same conpane as a method on Y but with all terminals of type Y replaced with terminals of type X. On the block diagram, I want to unbundle the Y, call Y's method, and if there's an output, put the Y back into my X cluster." This has been requested by many people over the four years since LV was released to accelerate development of the Delegate pattern and similar patterns, but I've never finished writing it. All calls to any of the VIRetooler classes start by calling "MemberVICreation.lvlib:VIRetooler.lvclass:CLSUIP_RetoolVI.vi". Honestly, that should be the only public function in the VIRetooler class and the others should all be protected, but since the classes themselves are private to the MemberVICreation.lvlib, no one on the Language team has worried about setting the access scope correctly on the individual VIs. Have fun. PS: Although the passwords are all removed, the VIs and classes are all private to the MemberVICreation.lvlib. This keeps users from using these VIs on their own diagrams. If you want to use them on your own diagrams, make a copy of this library and make it public. That way when I completely change these VIs in a future version of LV, you're linked against your own copies instead of linked against the ones that ship with LabVIEW. We'll all be happier that way, trust me. :-)

Dear Great LAVAS, I Passed the CLD Exam and I happy to be a LabVIEW Developer. There will be some:beer_mug::beer_mug::beer_mug: lots of them today if anyone want to join me Just PM me for more info.:lol: CLD Ohiofudu.

Hello there, first post here, so perhaps I should start with introducing myself. I've used LabView for about 10 years. For work to hack together some quick automated test routines for instrument control and data acquisition. Outside work I use it like a kind of hobby program language, mainly just messing around with it to see how it works and what it can do. For many reasons (read the NI ads...) it has become one of my favourite program languages, next to Matlab. I never released any code to the public. I never had formal training, and I thinks this shows in my code. What I'm releasing here is something I worked out in the last few weeks as a hobby project, it's now at a point where I think it could actually become useful. I'm looking for comments and criticisms on the code and the general question if this is useful and should be completed. What I tried to achieve is to add a script language to Labview. It should be a simple language, text-based, capable to interact with arbitrary front-panel objects, easy to add to an existing vi and working in the absence of the development environment. In difference to the MathScript or formula nodes it should be able to interact with anything on the front panel and not being limited to controls hardwired to the node. The script should be exchangeable at run-time, even when an executable has been built. Basically, it should be able to do everything a person can do with the front-panel. My approach was to use the GOLD parsing system ( http://www.devincook.com/goldparser/ ) to create a language similar to Matlab, the Intel x86 Assembly Engine by Ege Madra ( http://www.devincook.com/goldparser/engine/assembly-x86/index.htm ) to parse the user created scripts, and the attached Labview code to make it work. Somehow. It's not finished by far. What is working so far: - basic math and logic operations - comparisons - variables (doubles, strings, 1D and 2D arrays) - flow control (for loop, while loop, repeat until, if-elseif-else) - reading and setting values on the front panel. The attached zip file contains all vi's necessary to run what I have so far, inclusive dependencies (OpenG vi's and the Tree Control Toolkit by Norman J. Kirchner). A demo application is TestLoop.vi, there are three scripts in the script-folder that work with this application. Flaws I'm aware of are that it's slow, verging on sluggish (I've used a recursive interpreter design pattern, and recursions are a weakness with Labview, eh?); that I changed it so often to get to this point that I would need to do a serious cleanup of the code; that there is no documentation and of course, IT'S NOT FINISHED. Anyway, please take a look, and as said above, any sort of feedback is welcome. Ciao, Joachim

There's been some discussion over here about finding an appropriate place to distribute templates. Here's a summary: So, jgcode asked the question: what do others do? I wouldn't call that a big, but I'd sure like the ability to have templates in the Tools menu. Maybe make the suggestion on the LabVIEW Idea Excahnge?