Get your questions answered by LabVIEW developers.

[chanlo23]

My question applies to current versions in this way:

•  If I knew a way to edit the bloated LV 7 runtime engine to remove the unnecessary code, then it might be possible for the converted app to perform its routines somewhere near an acceptable speed, without maxed out memory or state-of-the-art systems.  If this were the case, the old version wouldn't be in use.  

My question applies to future directions in this way: 

• If future labview versions include sufficient documentation regarding architecture and functions to empower even moderately-skilled users, like myself, to design/develop applications without having to beg developers, or the experts like yourself, for assistance and
• Il future labview versions include the ability to edit the current runtime engine to remove code that is unnecessary, so that the final applications can run fast and efficiently, even on a wide range of configured systems

THEN,  folks wouldn't HAVE to leave important applications in older versions when upgrades become available in order to maintain performance and reliablity

[Gurdas]

Some more isssues I would like to see taken care of in future versions:

1) Allow for a command line to reach functions and controls. I find it somewhat irritating to click on many layers of menu to reach a function I use frequently. It would be soooo nice to simply type a quick command and have it at my disposal.

2) NI should make available dev areas of the website on CD or DVD pack. I know it would be huge but how huge? I am sure it will fit onto a 25 DVD pack (right?). Not all of us have good internet connections and it is difficult to keep searching for the right info on a slow connection. The pack should allow for updates (customisable) to be downloaded .....

3) NI should publish a comprehensive volume of best practices, code optimisation, memory management etc. It is easier to read from a book than a website and more than that, when compiled in one place it makes more sense. There have been many a occassion when DIY folks like me realised we were doing something so unrecommended it makes you feel embarrassed (not to mention the time and money loss).

More when I think some more !

- Gurdas

[falkpl]

Is there available a nice poster of the vi class hierarchy?  I poster provided (either free or for a nominal fee) of the hierarchy would be great. This would be a good reference to see the classes provided by vi server with the methods and properties opened to each.  Microsoft dose this with the .net and mfc with visual studio and it is an awesome reference and adds to the cubicle (for those like me who cant afford 4 walls) or office some curb-side appeal.  I am very tired of dropping a property or method node and searching for the right members to modify.  I would really like a pretty color poster with a class tree and class diagram for all of the gObjects.  If there is something like this let me know where to get it otherwise you might consider packaging this with the developer suite in the future (I think the price justifies a free poster).

Paul

[EdDickens]

LabVIEW 6.1, 7.0 and 7.1 do include the ability to select/deselect certain components of the runtime engine. The screen shot below shows the RTE configuration dialog from 7.1.   6.1 and 7.0 have a similar screens but not quite as many choices. NI has been working on this because the size of the RTE is something we've all been complaining about. I haven't done enough testing to see how it affects the size of the final engine, and these may not give you enough choices to strip it down enough since you're stuck running on old machines. I assume you're also stuck running old operating systems that will soon no longer be supported. At least you only have to install it once per machine.



I've run LabVIEW 7.0 on a 166MHz CPU running Win98 and not had any problems with running any applications. What types of problems are you having that you attribute to the RTE on newer versions of LabVIEW?

---

@chanlo23 wrote:
Does anyone have the the actual block diagrams of what is in the function for the three  blocks "Replace Array Subset", "Insert into Array", and "Delete from Array" for entire rows in LV6/7?

---

As far as I know, the LabVIEW functions don't actually have block diagrams. They are functions implemented in whatever text based language LabVIEW itself is written in. That's why the LV 5 examples for array manipulation are what they are. For LV 5, that's the best/only way to handle it.

Ed

Message Edited by Ed Dickens on 07-28-2005 08:15 AM

[Dennis_Knutson]

I've observed the same thing as Ed. My converted apps running on old hardware run with no noticeable difference to the old app. Using some of the new features like the event structure has actually improved them. Some of the newer fueatures such as 3D graphs do require more resources but those can be easily avoided.

[falkpl]

Ben,

I am sorry to hear that scripting might never or not for a long time be supported.  I am not convinced that a killer app is necessary before the tool is produced.  If html was not developed because the creator couldn't envision all the possible uses we might not have the internet as the ubiquitous entity it is today.  Useful tools are most useful when we find new and novel uses for them, but I guess business is driven by current demand and I might be the only one curious about scripting and macro-expansion.  I have used such features an c and lisp(I still don't like lisp)  where they solved problems not possible by conventional programming.  I have seen macros used for automatic parser generations where given a grammar definition source code to parse that grammar is produced and compiled.  A possible killer app could include automatic generation of drivers for visa based instruments (similar to express vis).  Another application is in AI I had used lisp's macro expansion to solve genetic algorithms where the code generated new source code to try to solve a problem, then evaluated the new code and repeated the process until a good (good enough solution) algorithm was produced.  One last Idea for scripting is language translation, imagine taking a c source code and converting it to g code: ie for(i=0;i<10;i++){x[i]=i*10} would get replaced with a for loop with the index multiplied by 10 and autoindexed into an array called x[].  We might be able to get a few more converts to LV form the traditional languages if we facilitated the conversion to the dataflow model of programming.  Just some thoughs on the topic, I always appreciate your contribution to the community and enjoy hearing your thoughts,

Paul

[Ben]

Hi Paul,

I was simply attempting be pragmatic.

If you would like, you could send me an e-mail at

bar@dsautomation.com

and I will then contact the product manager from NI that was asking for ideas that would drive the need for scripting. I will then let them contact you directly so you can start the memory dump.

I hope you take me up on this offer and achieve your goal!

Ben

[tst]

 Paul, that's a great idea. If you come up with something, maybe you can post it to the LAVA forums (or sell it).

[falkpl]

I will see what interest I can get on scripting, this might be an advanced add-on but could open new opportunities for labview.  Just a few years back I never thought we would be using labview to control fpgas or even develop code for 32-bit embedded systems but there farfetched ideas already have become realized.  Labview is great because it is evolving and transforming at the rapid pace of technology.  Its a symbiotic relationship, labview is driven by the pace of innovation and labview is driving the pace of innovation in science and engineering. 

Paul

[jreif]

I'd like to see more options in the possible events to be handled by the event structure not unlike what can be done with Measurement Studio controls within VB. Also to be able to trigger events on other than UI events such as value changes created by code and not by the user.

J