LAVA 1.0 Content

I was even able to debug a compiled executable. The new functions for this feature are great! Ton

John, could you consider uploading this to the LAVA CR? Ton

QUOTE (jaehov @ Feb 17 2009, 10:18 PM) Here are the steps (LabVIEW isn't currently running). Use a string to numeric conversion VI: With a I64 (or U64) as datatype. Now you have two options 1.Use a Number to Hexadecimal string: 2.Display the 'number' and change it's representation to HEX. Ton

QUOTE (crelf @ Feb 16 2009, 10:48 AM) You can add multiple passwords to the cache and store them concurrently. You do have to add the passwords one at a time to the cache. In 8.6 this seems to take 10-11 ms per password. I have a small VI that I use to store all of the passwords that I have and call the VI to add all the passwords to the cache. This VI could be called automatically from the link you use to start the LV environment. EDIT: It looks like this feature is not fully exposed. I must have received this VI from R&D a long time ago as I have been using it for quite a few years.

QUOTE (menghuihantang @ Feb 15 2009, 06:10 PM) The lenght is that the number of characters or the memory size? LabVIEW is not storing a string in Unicode, it only uses single-byte characters, the length in the first 4 bytes is thus equal to the number of characters. For Unicode you will have a factor 2. For a LabVIEW string to Unicode conversion look http://forums.lavag.org/Convert-between-ASCII-and-Unicode-file2.html' target="_blank">here. Ton

QUOTE (Ic3Knight @ Feb 15 2009, 12:14 PM) The data is stored in the on-board buffer, or in the systems ram (I am not sure). However if you wait too lang after a read you will get a buffer over-flow error. What you want can be done with TDMS files, simultaneously write to the file and read from the file. Make sure you open the TDMS file twice and make sure you don't read more than is in the file. Ton

LabVIEW is preparing the data fed to the Call Library Node so that it matches the datatype the Library is expecting. For instance if it is given a U8 and the function needs a Pointer to an U8, LabVIEW will setup some memory space exclusively for that Library Call and sent the memory location (32-bit) to the Library. For strings the same thing happens, only for C-strings they remove the upper four bytes (the size) and terminate the string with a NULL byte. Then the starting memory address (eg. pointer) is sent to the Library. (at least that is what I think is happening, Rolf will be of much more value) Ton

QUOTE (menghuihantang @ Feb 13 2009, 06:43 PM) See the 'http://zone.ni.com/reference/en-XX/help/371361D-01/TOC32.htm' target="_blank">How LabVIEW Stores Data in Memory' knowledge base article. Ton

That fully depends on what kind of advanced stuff you do with DAQ. Simple read/write is quite easy to convert. Ton

The LabVIEW options dialog box has options to exclude vi.lib and instr.lib from Source Code Control add actions. I have been requesting to extend this to user.lib as well for ages. I even filed a bug report once . Do we need this feature? I am in need of this feature because I like the option to include all dependencies when adding a single file to SCC, however it also tries to add all the user.lib (which shouldn't be in SCC IMHO), this can't be added since it is outside the SCC scope and results in error messages. Is it that much work to extent this feature (or even make an option to exclude a whole custom folder). Ton

QUOTE (Aristos Queue @ Feb 10 2009, 04:28 PM) Uhm, I even checked to see if the feature was really available and not made up by me. But yes the feature is available, but I have never used it, maybe just for kicks. Ton

QUOTE (Daklu @ Feb 10 2009, 02:11 AM) OpenG builder post-build files have the info you need (pre-build names and post-build names. QUOTE (Aristos Queue @ Feb 10 2009, 11:35 AM) Every LV 8.x release has included features designed to eliminate the need for prefixing. If you're still needing it, then clearly there is something that the R&D team does not understand about LabVIEW and how our users are using it, because there's general agreement on the team that the tools exist now (8.6) such that you shouldn't have any reason to keep using prefixes. This should probably move to a new thread, rather than hijack Daklu's original question about how to deal with this, but a detailed list of why, between the project application instance isolation and the library namespacing, prefixing for distribution is still necessary. The options in OpenG builder are a little bit more advanced: Prefix or postfix Optional random namespace Next release of OpenG builder allows to namespace the library files only Optional random password Pre and postbuild VIs (to alter description for instance) Version info on source distribution builds Pure G version info Ton

The OpenG application palette have VIs to 'unmangle' or 'mangle' file names. The next release of OpenG builder will optionally only mangle the name of the library not the files inside the libraries (like AQ proposed) Ton

QUOTE (David Wisti @ Feb 9 2009, 10:34 PM) QUOTE (Chris Davis @ Feb 10 2009, 04:12 AM) I've had it working in every version of LabVIEW I've tried since 7 (7, 7.1, 8.0, 8.2, 8.5). I didn't do anything special, just added the keywords as properties within TortiseSVN's panel in a file's properties, then did a commit. Strange, I used LabVIEW 8.6 with exactly the same text on the FP as on the VI description. It only worked on the VI description. Than I looked at the contents of the ctl-file and noticed the text only once in the binary stream. So I removed the tokens from the VI description and the strings were gone from the actual VI file. Maybe an optimization on LabVIEW's part. Ton

QUOTE (CraigGraham @ Feb 9 2009, 11:23 AM) I just tested this and it should work in LV 8.6. I can define a cRIO controller and FPGA, configure it to run the FPGA VI in simulated mode (on the Development Computer) and then create a host VI (targetted to My Computer), which connects to the simulated FPGA VI using the normal FPGA host interface. I attached my example. Ignore the name of the project and some of the additional code as I reused an earlier example. http://lavag.org/old_files/post-3370-1234221191.zip'>Download File:post-3370-1234221191.zip

QUOTE (Donald @ Feb 6 2009, 01:33 PM) For OpenG VIs we use some VIs during the build process. In the post-build VIs we write the SVN properties to a FP decoration. QUOTE (Chris Davis @ Feb 7 2009, 08:45 PM) I'm doing this now and it takes no special code modifications whatsoever. Just put the following free label on your front panel, and What version of LabVIEW are you using? QUOTE (Randy @ Feb 9 2009, 04:46 PM) Any more insight would be appreciated (maybe I'm not finding the correct label). No you are doing it right. LabVIEW doesn't store the FP decoration as ASCII text, however VI descriptions are stored as ASCII text. This can easily be seen with an hex-editor. That is exactly the reason it doesn't work. I assume Chris is using LabVIEW 7, LabVIEW 8 used a new saving technique that reduced file size (I guess zip-compression). Ton

If you edit a page with multiple templates in a row (like the Configuration pages) with the new editor. The layout will be scrambled. The templates will be prepended next to each other with a space in between. The space should be replaced by a new-line. A workaround: after editing with the new editor, switch to wiki view copy the contents to a text editor and do a search and replace on }}/s{{ and replace that with }}/n/n{{ with notepad++ for instance. Using the double /n delimiter will make sure the enter stays in place. Ton

QUOTE (crelf @ Feb 8 2009, 08:17 PM) And the best thing of that feature is that you can add this 'Project task' to an installer! Ton

A task will make sure that the channels will be read using the same clock. I came to the conclusion that MAX is a great tool to manage DAQ configurations, it took me a while to get hooked but I love it. Using global channels with scales and stuff, very easy to change a sensor, the only thing you need to do is adjust the scale! Ton

QUOTE (tilli @ Feb 6 2009, 01:21 PM) If you think you have information that helps us better understand your problem, always append it. Include links to items you refer to (what is tshark's ring buffer?) to help us understand. If you have some code that is a big plus! Ton

QUOTE (Ton @ Feb 6 2009, 01:50 AM) Check ftp://evalftp86:LabV13w86@ftp.ni.com/' target="_blank">here

So the 8.6.1 documents are coming: Bug Fixes Known issues Readme Windows Readme Macintosh Readme Linux Anybody found the actual cds/dvds? Ton

In one of our applications,we are measuring temperature.We configured DAQ mx VI in AI Temperature,thermocouple.We are measuring temperature based on type and units as per the user configuration.For all thermocouple types except B Type,DAQ mx Read VI is giving correct values based on the range user configured.But,for B Type thermocouple,after 200 degrees to 300 degrees only,DAQ mx Read VI is giving correct values.If we source 0 degrees,DAQ mx Read VI is not giving any value.If we give 5 degrees to 90 degrees its showing temperature from 100 to 101 degrees.If we give 100 degrees,its showing 125 degrees.After 200 degrees only,DAQ mx Read VI is giving correct values.But range for a B Type thermocouple is -250 degrees to 1830 degrees.Is there any limitation in the measurement of temperature of a thermocouple of B Type? Regards, Naresh.N

<Shift-right-click> brings up the palette and you can select the paint tool. Ton

QUOTE (george seifert @ Feb 4 2009, 04:03 PM) Try alt+v+t. It's not an extraordinary solution but it's little bit less annoying.