LAVA 1.0 Content

QUOTE(Giseli Ramos @ Oct 16 2007, 12:01 PM) Welcome to LAVA Giseli! We have a lot of physics types around here. What is the nature of your "Astonomic project"? How are you planning to use LabVIEW? Ben

QUOTE(Jim Kring @ Oct 15 2007, 04:48 PM) Now I need to create a vi with a blank icon and use a system exec call to that bat file and drive my co-workers crazy! :laugh:

QUOTE(hskupin @ Oct 15 2007, 06:12 AM) Oh Oh another bug hunter. We always need more bug hunters. Thanks for joining the team! Ben

QUOTE(LV Punk @ Oct 15 2007, 11:46 AM) As a Premium Member you have that option. Ben

I noticed today that Ben is now neB. Should I change my name to "knuP_VL"?

It's not complete unless you've made some mods to the hardware too! http://www.inventgeek.com/Projects/usbairs...t/Overview.aspx

QUOTE(Matheus @ Oct 15 2007, 11:17 AM) I can't say I have ever seen a cFP run that fast. I remeber reading a post by an NI AE that spoke of a setting in MAX affecting the acq rate. And yes TC = Thermocouples Ben

QUOTE(Matheus @ Oct 15 2007, 09:56 AM) How is the performance without the SV read? Then how does it perform without the TC reads? Ben

QUOTE(gottfried @ Oct 11 2007, 08:01 AM) There are several ways to do this, I have attached an example of one way. Import the .nce file into max then run the example. The important thing to remember is that there is only one A/D in a multifunction DAQ card, when you read in the documentation that there are X#Channels, they are really just talking about multiplexing capabilities. This means that there is really no such thing as simultaneous sampling with a single multi function DAQ card, so if you really need simultaneous sampling you need: more than one Multifunction daq card, a multiple channel digitizer card or a sample and hold card. If you protect your resource (A/D) with a semaphore and configure your task in MAX you can have multiple sample rates with one A/D, they are however not simultaneous, but that is not possible with a multifunction daq anyway.

After installing LabVIEW I immediately set the grid size to 8x8 for both diagram types. It's much better to align objects. This works fine for creating a new VI which is not inherited from a template. But with the new OOP features of LabVIEW an annoying issue was born. If you create a new VI from a static or dynamic dispatch template the grid size is not set to the given environmental value. Instead the default sizes are used and you have to manually change the VI grid settings. Creating new VIs from templates should also take care of the environment grid settings. This is CAR #49MA4FU1. Henrik

QUOTE(Gavrilo @ Oct 15 2007, 08:14 AM) If the buffers used for all of the wires in the sub-Vi are large enough, the same buffers should be re-used. The last time I poked around with the de-allocate, it only cam e into play when the VI in question was marked for removal from memory. If the sub-VI is part of the app (not dynamic) it will not be marked for removal while the top-level VI is running. On the other hand, if the VI ws loaded dynamically, then when all of its references are closed, the de-allocation is possible. Stepping back: I think of that switch as being useful if you have a set of functions that are called as a response to a user action, are used, and then are unloaded. All of the above is just my opinion based on personal observations. If anyone actually KNOWS what is happening, please step up and correct me, PLEASE! Re: more memory If your VI is using more virtual memory than you have physical memory, then adding physical meemory will help. If you are using less virtual than physical, then use the profile tool to find who using the pig, then review that/those critters for excessive buffer copies. Trying to help, Ben

These are two related issues filed under different CAR numbers: 1. With LV8.5 the project explorer now also shows the hierarchy of files in the new 'Files' tab. If you try to drag&drop an existing VI from the list into the front panel or block diagram of another opened VI than you are not allowed to insert it there. The behavior should be the same like within the 'Items' tab. Listed VIs should be draggable into a target VI. This is Car #4DJFJ7G3. 2. If you drag&drop a VI from the 'Items' tab into an opened VI the focus is still set to the project explorer. To offer a better workflow (necessary for us keyboard users) the focus should be set to the front panel or block diagram of the target VI. Than you can immediately use keyboard shortcuts without having to use the mouse to set the focus to the target VI. This is Car #4E89HJAR. Henrik

QUOTE(NormKirchner @ Oct 13 2007, 03:53 PM) Oh! All of you LVOOPish types are way ahead of me. I have scheduled some time to study in December just so I can understand what y'all are talking about. Give me time, I'll catch up. Ben

Hi everyone. I'm still reading the forum and posts for a while but never created an account. But now this remaining issue is also done. I'm a LabVIEW developer since around the year 2000. Mainly I'm focused at creation of applications with measurement background for laboratory use. I'm working at a research centre where I also do local related technical support for NI problems. We also host a LabVIEW usergroup and have monthly meetings where we present ongoing work or new features. Due to my work I regulary find bugs which I already reported to NI. I'll try to file some of them - which are related to LV8.5 - within the bug section. That's also the main reason why I created the account. Thanks for the great platform. Regards, Henrik

Hi, I studied Electronic and Electrical Engineering at university, and have been in the test and measurement field ever since (1985). Currently sitting within throwing distance of Danny, and appreciating his help. Kevin

QUOTE(sahara agrasen @ Oct 13 2007, 01:17 PM) Be careful. That is proprietary material, and you might as well post a registered key to a LV toolkit or the code on here. From NI's standpoint, it's just as illegal. If you want some more specifics or specific examples or table of contents, I think we can manage.

If that's your interest, keep an eye out for an incoming post from me in the code repository. It's a concept called LVx (x is for export). It's a design pattern that allows you to add exported method functionality to a LV program both in dev mode and exe form. I'll keep an eye out for your comments and own additions to LAVA. Welcome. ~,~

QUOTE(Justin Goeres @ Oct 12 2007, 01:38 PM) I have a workarround... You can just drag and drop a picture "into" the Icon of the Frontpannel Winndow- that takes only a few seconds... => Create your own Templates (pictures) as much as you like Or you can use an customized ICON-Editor: LAVA Code Repository... Vi, Vit, Ctl Icon and Description Editor /Browser Mark Balla's Icon Editor Ver 2.2

I've posted the VI I mentioned on the NI forums here as it uses undocumented features. I put very little time into this; if someone has the time to deal with the recursion and sees value in calculating the VI Modularity Index; go for it! Download File:post-949-1192187068.vi(LabVIEW 8.5)Download File:post-949-1192189545.vi (Uses OpenG toolkit)

That begs the question "Should image links be included in RSS feeds?" I like the fact that they can be included, or I wouldn't be able to read xkcd.com comics at work via Google Reader. I'm going to listen to the new "The 5th dimension" post now PS. A big thanks to Michael for continuing to experiment and add new features like this to LAVA. :thumbup:

There are a couple of NI forum topics that discuss setting up LabVIEW to work with multicore/multiprocessor systems. They commonly refer to the LabVIEW VI vi.lib\Utility\sysinfo.llb\threadconfig.vi Fully utilizing all CPU's for a LabVIEW application Core 2 Duo, Core 2 Duo Quad, and Labview 8.2 From the second link, it seems that threadconfig.vi queries the OS capabilities. I recall that there are versions of Windows that only support a single CPU socket, a quick Google returned this. LabVIEW may be limiting your CPU load distribution as a result of what your OS reports. I just read on another link in the same Google search that Vista includes something called the Next Generation TCP/IP stack. I was interested in this: The architecture of NDIS 5.1 and earlier versions limits receive protocol processing to a single processor. This limitation can inhibit scaling to large volumes of network traffic on a multi-processor computer. Receive-side Scaling resolves this issue by allowing the network load from a network adapter to be balanced across multiple processors. For more information, see Scalable Networking with RSS. It sounds like this might be a useful option for me. Can you tell me a bit about the computer and OS you are using?

Maybe some of the more active LabVIEW related blogs like Thinking in G, ExpressionFlow and crelf's Technology Articles? could use this tool to make audio versions of their blogs available. Maybe even the RSS feeds from LAVA could be "podcasted". Imagine listening to "the 5th dimension" on the way to work (long commutes only, and no carpooling; you don't know who might be offended :laugh: ) http://www.odiogo.com/bloggers.php

QUOTE(Michael_Aivaliotis @ Oct 4 2007, 10:03 AM) Michael, I encountered this problem back in 8.0 it's a mess. One thing I might point out is in 8.2 and up there is a check box in the dialog that ask for the source CD. I can't remember exactly what it says but if you select it the source from the cd will be copied to your hard drive, and the next time you do a build it will get the source from this location without a prompt. If you check this at least you won't have to dig for the CD's the next time you do the build. The downside is the hard drive space you consume over time.

QUOTE(Popatlal @ Oct 7 2007, 05:55 AM) I don't know about all those sites, but I have about 1 hour a day while I drive home. Give me your number and I'll talk you through it. hehehe j/k..... well... maybe not.

QUOTE(yen @ Oct 8 2007, 03:26 PM) We need another dose of the " Kitty Cat " video in this thread.