LAVA 1.0 Content

QUOTE (Dave Graybeal @ Jan 27 2009, 01:56 PM) Be aware this only works on single pane VIs! Ton

I want to get a reference to a library that already is in memory. For a VI I would use 'Open Vi' with a string with the VI name. Now I would like to do the same for a library. Unfortunately the App.Open Library method only accepts strings. Does anyone know how to do that? Thanks, Ton

QUOTE (john@aleconsultants.com @ Jan 23 2009, 12:31 PM) Yes, the Virtex-5 based boards are able to run code at significantly higher loop rates then the older R series cards using the Virtex-2. I tested one example to get some numbers. The example is a SPI generator based on a state machine in a SCTL. For the Virtex-2 board (7833R) the maximum rate (according to the simulation in the compiler) is 116 MHz, while for the Virtex-5 board (7842R) The maximum rate is 159 MHz.

QUOTE (LV_FPGA_SE @ Jan 23 2009, 01:15 PM) Very nice response, nevertheless, I have been very impressed with what speed improvements I have gotten using LabVIEW and FPGA's versus my dual-core 3.0GHz Intel machine. Do you know if the latest PXI FPGA solutions that use Xilinx Virtex-5 chips make any improvements on this?

QUOTE (john@aleconsultants.com @ Jan 23 2009, 11:50 AM) A little more detail: The derived clock (e.g. 200 MHz) can only be used to drive a single cycle timed loop (SCTL) in the LV FPGA diagram. Anything that you put inside the SCTL needs to be able to run within the derived clock period of the loop, e.g. 5 ns for a 200 MHz clock rate. Therefore if you put more code into a SCTL, the maximum rate at which that SCTL can run will be lower. A 200 MHz SCTL will in fact be able to run very little code, which will most likely be limited to Boolean logic. Doing any kind of numeric data processing will be limited to significantly lower rates with a maximum loop rate in the range of 40 -100 MHz depending on the complexity of the code. In fact, if your longest code path in the SCTL increases, the maxium loop rate may be less than 40 MHz. Note that there are certain functions that are not supported in the SCTL at all as they take more than one clock cycle to execute.

QUOTE (njg @ Nov 13 2007, 10:21 AM) Yeah, but I don't think you can run complicated algorithms on anything higher than 40MHz

QUOTE (mike_nrao @ Jan 22 2009, 02:02 PM) To clarify, NI Labs contains both new features that will be available soon in the product and are prereleased on NI Labs, but it also contains projects and ideas that are being evaluated and may never make it into the product, or will look very differently when released in the future. So NI Labs does serve several different purposes in that regard, but most content that is chosen for NI Labs falls into one of these two categories. Prerelease of an upcoming feature with little change in API Evaluation and feedback of a new idea, concept, or feature that may or may not make it into a released product. We just don't always say which of these two you are looking at. In general I do not recommend building any kind of products based on NI Labs content, unless you have verified with NI the future availablity and interface of the content you are considering using.

Hi Sabine, there are several options (hard to easy): Use dynamic event registration Set the event not to loc the FP (in the options of the event case Ton

I only remember TDMS incompatibilities between the RTE's of 8.20 and 8.2.1. Ton

Stephen, where is that kudos button :thumbup: QUOTE (Aristos Queue @ Jan 22 2009, 07:51 PM) Yes we can! However we can't really control them well. If you open up a private context there should be a way of closing that context well. However I have succeeded in removing the context from memory by first calling the Context.RefCount.Dec method http://lavag.org/old_files/monthly_01_2009/post-2399-1232651093.png' target="_blank"> However when you open up LabVIEW the next time you will get an error: QUOTE The last time you ran LabVIEW, an internal error or crash occured at LVContext.cpp, line 1887. QUOTE and others may be able to fill in more details I assume you know better who these so called others are, please bring them. Ton

Yes, but it doesn't work: Tag is from here. Ton PS, this is not scripting IMHO

There was once a discussion on the NI forums about scripting and what kind of impact it would have on the forums. QUOTE Besides we should make a distinction between scripting and private items. In my opinion scripting is the possibility to edit LabVIEW source files (VIs) without human interaction. Partially this is allready released, the methods exist to build lvlibraries/classes/xcontrols from scratch. The power to make VIs however is not in our hands. Private items are properties/methods/events that are not fully debugged by NI and most likely will be released in a future version of LabVIEW. Ton

Hi Antoine, there is a special method for retrieving the application instance of the VI that invoked the utility VI: Ton

Hi Jed, Could in future posts upload your images to LAVA? Instead of externally linking. This will prevent some annoying portal issues. And if you want to post code I suggest the Code Capture Tool Ton

I think storing an IMAQ handle inside an ini file is a nono. I always thought they were pointers. But I agree with Crelf, what is the output of the INI file? Ton

QUOTE (ned @ Jan 21 2009, 09:32 AM) The pipe control is indeed part of LabVIEW DSC. http://zone.ni.com/reference/en-XX/help/37..._multisegpipes/

QUOTE (Matias Ribeiro @ Jan 21 2009, 04:46 PM) Here's a link to try. http://tinyurl.com/aahkr4

QUOTE (crelf @ Jan 21 2009, 09:26 AM) Here's a couple of my personal thoughts on this topic. This is not an official statement from NI, I don't work in R&D or on the LV team, and I don't know what the reasons are for not releasing this feature. Once a feature is released as part of a product, NI attempts to ensure long term support and forward compatibility for that feature so that upgrading applications from one version to the next is as seemless as possible. This means it becomes very difficult to make significant changes in any existing features, especially ones that include an API of any sort. Therefore NI may not release an API for public consumption in order to reserve the ability to make changes to said API without breaking a lot of existing external source code. My personal guess is that the R&D team does not feel comportable with the current state of the scripting API and long term forward compatible support. Product support is always a big issue and decision influencer in the release of any product or feature. Scripting is a very advanced feature and can be very difficult to support using the existing support channels. This fact may also hold back the release of this feature, weighing the cost versus the benefits. Regarding NI Labs: NI Labs is not an official release of a product and NI does not offer support or guarantee future existence and compatibility of anything made available through NI Labs. Therefore it is not advisable to build any add-on product, toolkits, development tools, etc. based on NI Labs content, as it may not be supported at all in a future version of the product. However, making something available on NI Labs can and does create certain expectations among users and developers and it is important to manage such expectations properly in order to maintain long term viability and success of a product.

What I heard about scripting is that especially event-structure is very hard to do. The events are nowhere proper enumerated, so that maybe quite hard. Ton

Impressive and advanced solution with reentrant VIs. (points for that). Easy comment: No documentation on the BD of the GUI VI. (esp. in the event structure) No on-line help on the led-status of the GUI VI. Intermediate comment: Mix-up of system and labview GUI elements (BD color is dialog the rest is native LabVIEW) Advanced critique: I would use a VI-reference to load the reentrant VIs: (As you can see the BD of this VI has no documentation.) Use the auto-clean up tool for simple VIs, your reentrant loader had a lot of white space, auto-cleanup eases things out. Good-luck, with such a solution you have to pass. Ton

QUOTE (James N @ Jan 19 2009, 06:36 PM) X-Control X-Node Ton

Does anyone know how to set the Menu and selector information on a new or existing polymorphic VI? Ton

I couldn't download the first two examples of VI scripting... http://forums.lavag.org/VI-Scripting-downloads-cat7.html Ton

Your code uses motion which is a seperate toolkit (allthough I think you can install the 8.2 version on 8.6). You have that toolkit installed on LabVIEW 8.2. Now you need to install the toolkit on LabVIEW 8.6, look through your 8.2 CD and try to find the toolkit. It might happen that installing the toolkit on 8.6 deinstalls the toolkit on 8.6. Ton

QUOTE (rolfk @ Jan 18 2009, 09:10 PM) Does anyone how to select an Xcontrol on the owning panel without drawing a rectangle around it but just by clicking it's border? Ton