LAVA 1.0 Content

Thanks! I found that and was excited...but then shortly afterward was shot down when I found that there wasn't an /images directory on my HDD.

Maybe I'm missing something here, but can you connect to the LV RT controller from MAX on your development system to format the drive and reload the SW? If necessary in MAX you can generate a boot disk for your RT controller to boot it into safe mode and connect from MAX.

Configure RT Series PXI controllers with the RT Engine pre-installed. In MAX, select Help

Thanks,

I have an issue where the builder is looking for the february device drivers disc for some reason, reinstalling the may discs didn't help.

This is very helpfull, but could you give a pointer to where this registry entry is?

Ton [/quote

Use the find function of your regestry and put the path from which your device drivers were installed and substitute May 2006 with Feb2006 in the path. For examble may path was Z:\Public\NILabview\Ver 8\May2006\Device Drivers for Data Acq Instrment Cont and Vision\Disk1\products\gpib\driver\ So if I want to find were Feb is being used I would search for Z:\Public\NILabview\Ver 8\Feb2006. The word is Installersource. Be carefull it is possible if you did not install all the same packages in your May updates as in Febuary the source for the package you are trying to include could truely have been installed from Feb. Look at the name of the packages you find in your registry that have come from Feb and determine if you truly did install it from May if so try chaning the path, if not reinstall that package from May. Good luck, be careful.

I'm going to be stuck in Owego, NY for NIWeek and today we sort of had to go home early.

I'm originally from Jamestown, NY and I still drive back and forth on Rt 17 a couple of times a year for the holidays. It could be worse; you could be driving there in January!

Sorry you won't be there. My flight arrangements have me getting into Austin at ~ 9:00 pm and it's a half hour drive to the LAVA B-B-Q (according to the map), so I'll probably miss it

I recently discovered a bug or perhaps an "added feature" not sure which so I posted it here. Here is my sad story, I am telling this sad tale in the hopes it will save someone from all the grief I suffered.

First I will explain what I did, then what happened, why it happened and lastly how to recover.

What I did, I built an installer for an application, "My Application" that included several additional NI installers (MAX, NI 488.2, VISA ....) after the build was complete a file, lets call it "setup.exe" was created to install the application. I copied the installer onto a network drive, and then went to a different LabView development machine ( Dev 2), and ran "setup.exe", from the network drive, to install "MY Application" on that machine. The install went fine and the application worked as expected.

What happened, several days later I was building an Installer for a different application (Setup2.exe) on Dev 2, this Installer also included some NI installers. Here is where it gets fun , during the build a dialog box popped up stating "Unable to locate the installer source for 'Setup' distrubution. Locate the distribution and try again." with a path control pointing to the "Setup.exe" located on my network drive. I had deleted "Setup.exe"from network drive so it failed the build. At this point I was confused as to why the build for "Setup2.exe" was referencing "Setup.exe", but I thougt ok , I will put "Setup.exe" back on the network drive , and try to build "Setup2.exe" again. Second try for "Setup2.exe" still popped up the same dialog, and failed. Looking at the details of the dialog that is displayed after a failed build I discovered a line staing it could not find Setup, but found somthing close. Two other development machines that had "My Application" Installed on them exhibited the same failure mode when trying to build a new installer with additional NI installers included.

Why it happened, whenever you include an additional NI installer in a build it needs the installation source for the NI 'package' you are trying to include with your installer. By default it looks in the location that the 'package' was installed onto your development machine from, but you can point to another location for the 'package' source if it is not located in the same place, but it must be the same version as the package that is installed on your machine. I guess I did not realize this prior to this experince because I have a VLA, and I always have the drive that I installed from mapped on my development machines. In retrospect it makes sense. So, what was happening was the Installation of "My Application" on Dev2 was installing newer versions of some of the NI 'packages', so from Dev2's perspective the source for those packages was installed from "Setup.exe". What this ment is whenever I tried to build a new installer on Dev2 that included NI packages that were installed from 'Setup.exe' it needed to find the source for those packages in "setup.exe". I guess that makes sense to me now, but what doesn't make sense is it appears it needs not only find the same version of the source, but it needs to reside in a file called "setup.exe" and the version of setup.exe needs to be the same version it was when the source for the package was installed from it.

How to recover, the first thing I tried sense I nolonger had a copy of the build for "setup.exe" that was used to install "My Application", was to uninstall Labview and re-install LabView. My thought was that this would change the location of the source for NI packages back to the VLA server, however it still wanted "Setup.exe". I had had enough at this point so I removed everthing NI first through ADD/Remove programs, than MSIBlast.exe. I reinstalled Labview, tried to create a Installer with NI packages, and still it wanted "setup.exe" At this point I was ready to cancel my trip to Austin next week, and swear off LabView for ever :laugh: . Then my collegue decided to search the registry for "<path to setup.exe>" we found an entry that referenced NI 488.2 to "<path to setup.exe>" we deleted the entry and all our problems were solved. We went to the other 2 development machines sereched the regestry for "<path to setup.exe>" and found 30 or so refernces of NI packages pointing to "My Application" we deleted all entries, and like magic problem solved. :thumbup:

In conclusion be very careful when you install a Labview built application on a development machine, and if you should find yourself in a similar situation search the regestry for "<path to setup.exe>", and delete all references.

It's August 4, and Amazon is indicating that the book has not shipped yet, but has an expected delivery date of August 3

I'm wondering if I'm gonna get it before I fly out on Monday (I'd hate to have to read Alfa's book , but it's downloadable... )

Shouldn't a pro wrestler at least preside over the fight? Who is more qualified than a straight edge guy like me?

Extra points for the first to execute a Texas cloverleaf.

I'm not sure I can be COMPLETELY impartial... I scheduled for Norm's presentation; but BEFORE the fight was announced.

You might try automating the startup of 7.1 and 7.1.1 using a batch file to script the folder name changes you need to make your solution work.

I can't remember if windows uses a path or a registry entry to find the associated program when double clicking a LabVIEW file type, but if you're creating a batch file to rename the directories, then you may want to make sure that the file associations (.vi, .ctl, etc) point to the correct place.

You can add these DOS command lines to your batch file:

FTYPE LabVIEWControl="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWControlTemplate="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWInstrument="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWInstrumentTemplate="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWLibrary="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"ASSOC .CTL=LabVIEWControlASSOC .CTT=LabVIEWControlTemplateASSOC .llb=LabVIEWLibraryASSOC .vi=LabVIEWInstrumentASSOC .VIT=LabVIEWInstrumentTemplate

To see the current associations for an entry, use the same command without an assignment:

FTYPE LabVIEWControlFTYPE LabVIEWControlTemplateFTYPE LabVIEWInstrumentFTYPE LabVIEWInstrumentTemplateFTYPE LabVIEWLibraryASSOC .CTLASSOC .CTTASSOC .llbASSOC .viASSOC .VIT

Or if you're curious about other associations, just type FTYPE or ASSOC and be prepared to read fast

You can create a poll that will allow you to ask multiple choice questions and track the stats, if you are interested. I believe you can even create a poll for this post...

1) Do (I) use Express VIs? No.

5) If you don't use them at all, what is the reason? I am a LAVA member, and our (old) motto is No Express VIs Required (follow this link)

looking up Aussie terms on the internet?!?

My cell phone is bog standard, so I can't make backgrounds for it. Have to find a way to spend my lunch break, and learning the Thai alphabet is no piece of piss...

I'm not going to be able to make it to NI-Week.

Deadset, mate? Are ya gonna make us Seppos drink with the flies?

You beat me to it

I've got toget to 667 posts some how

please help me

Two suggestions:

1. Google is your friend...

"VISA Error -1073807342". The first entry is a link to the NI web site that suggests that NI-VISA is not installed or is broken, and should be re-installed. The question to NI was about GPIB, but the error still means the same thing, a problem with NI-VISA. Try installing/reinstalling NI-VISA.

2. "How to ask questions the smart way". Read "Before you ask", then see first suggestion; took all of 1 minute to type "VISA Error -1073807342" into Google and wait for a response.

Good coffee today, plus i'm looking forward to NIWeek / and the new edition of LabVIEW for Everyone, Third Edition

I think I'm gonna keep Sessions I80 and I43 on my NIWeek schedule

unless the data has to go to more than one place

Well, I'm back... The data does indeed need to go "more than one place"

I've learned that there is data that must be evaluated AND shown to an operator before and during actual logging to file. I've created a new vi that reads the original raw data queue (tcp strings) and performs a least squares fit on a subset of that data. I create a second data queue within this new vi that I "forward" the raw rate data (tcp strings) to.

When I need to start the actual logging, I manually start the original logger vi, perform a lookup in a LV2 global to retrieve the reference to the secondary data queue, then log to disk. I've got enough memory to support the dual queues for now, I can decrease my queue sizes some if I run into problems.

Currently, my vis are started Reentrant (option 8) and Autodispose references set to true.

When testing ends, I send a notification to the top level TCP reciever VI to close. The receiver closes the TCP session, then moves to a pause state where it waits for the first data Queue Status to return empty, destroys the first data queue and exits. The least squares fit vi errors out reading the destroyed first data queue, then moves to a pause state where it waits for the secondary queue to empty, then destroys the secondary data queue and exits. The independantly started logger vi errors out reading the secondary queue and closes it's file handles.

This seems to work, but I fear that I won't close all the threads and references properly.

Should I add all of my references to my LV2 global and add an action to check/close all these references?

Is this design reliable and scalable to three "channels" of tcp receivers?

Thank you, Jimi! :thumbup:

And I want to know is there any other disadvantages of Storage VIs except the performance? When I using them, especially "Write Data", they always cause LV hang, I have to kill the process of LV at last. Did you also meet such a situation? Thanks again!

I just encounter occaisional delays every now and then when writing data. This is a problem because my data acquisition buffer gets full during the delay and I loose data. Well, I made an enormous data acquisition buffer to overcome this problem. I also get LV to hang when I acquire data after about 30 mins, but I think the problem is no in storage VIs but rather on front panel buffer.

I use the HDF5 because it allows me to

• Write multidimensional arrays, storage VIs support only 1d arrays (maybe 2d)
  
• Create hierarchies of unlimited depth, storage VIs allow only two levels namely channel groups and channels
  
• Add any number of attributes and any type of attributes, storage VIs support only predefined attributes
  
• Write complex number arrays
  
• Read selections of the data instead of the whole data
  
• Write parts of the data instead of the whole data
  

:arrow: The article you're looking for was written by Jeff Kodosky, and is archived here.

Thanks for the link crelf! A nice article. I think Kodosky made some good points. However, from our point of view and from this discussion point of view he asks the wrong question. The question is not if LabVIEW can be used to solve general purpose programming problems. It certainly can. The more important question is if LabVIEW is by desing the best possible graphical programming environment to solve general purpose programming problems. I think the answer to this question is no, it is not. LabVIEW is very good indeed. However it's not that good in many tasks and I have been forced to use other programming languages to solve some of my task just because it would be much too complicated to solve these issues using LabVIEW. I think there is still room for a graphical programming language better than LabVIEW.

What I'll do today, I'll read more about functional programming to see if functional programming could be implemented in a graphical dataflow kind of way.

Thanks!

You mentioned HDF5, what is it? and what's the relationship between Storage VIs and it? Is it implemented using Storage VIs? If so, I'd like to be your beta user:)

No, it is not implemented using storage VIs and storage VIs are not implemented using HDF5 (at least to my knowledge). The quotation below from HDF5 homepage tells propably more. See HDF5 homepage for more details.

HDF5 is a general purpose library and file format for storing scientific data.

HDF5 can store two primary objects: datasets and groups. A dataset is essentially a multidimensional array of data elements, and a group is a structure for organizing objects in an HDF5 file. Using these two basic objects, one can create and store almost any kind of scientific data structure, such as images, arrays of vectors, and structured and unstructured grids. You can also mix and match them in HDF5 files according to your needs

The LabVIEW library I have written implements central parts of the HDF5 C library. It currently ony works on Windows.

How is it you see that LabVIEW has(or had) the potential to change the world in a way that JAVA doesn't? I think this is a core element of your position that I do not understand.

Should we open another topic for possible alternative pasts and futures of National Instruments and LabVIEW in the case some other decissions were made. I suggest that we try to discuss if there is need and space for a new general purpose graphical programming language, and if there is what should it be like.

I would like to create a control that has Enum data type, but looks like this (menu ring):

The Enum does not have a drop-down arrow for the user to realize more options are available, and I find the Menu Ring control more clear.

Is this possible?

Thanks!

Use enum under Controls->System->Enum. You can also select the enum control on a block diagram and then select customize control from the Edit menu and then press the wrench icon to be able to edit the look and feel of the control.

I think functional programming languages have similar approach.

Good idea Zen! I would very much like to see a graphical functional programming language. There are a few things that make LabVIEW a bit like functional languages. First is that the value of wires is not changed (in most of the cases). Second is that the language is automatically concurrent.

I think there are however much more differences in LabVIEW and functional programming languages and LabVIEW is not (even close to) a functional language. Let's imagine a functional programming language called "Functional G". This hypothetical language would differ from LabVIEW at least in the following properties:

1. In functional G wires would pass expressions (the history of the wire), not only values
   
2. In functional G, the VIs would always be re-entrant and stateless
   
3. In functional G, shift registers would not maintain their valus (at least VIs with shift registers would not)
   
4. In functional G, there would not be globals or other joint variables of if there were, these would be constant after referenced the first time
   
5. In functional G, VIs could be passed to and returned from other VIs as parameters with and without parameters
   
6. In functional G, sequences of code could be passed to and returned from other VIs
   
7. In functional G there could be a way to do currying i.e. to define new functions based on old ones like cos(x)=sin(pi/2-x)
   
8. Functional G would possibly allow lazy evaluation, i.e. a wire and it's history could be evaluated as late as possible.
   
9. Functional G would allow storing "continuation" i.e. the state of the execution i.e. a VI to be called next with all of arguments to be passed to it
   
10. Functional G would have a feature called "pattern matching" similar to polymorphic VIs except that a different VI would be called not based on type but value passed to the "pattern matching polymorphic VI".
    

I think a best compromise of a new language would be a programming language that would allow pure functional programming, but would also allow many non-pure properties. This kind of language would allow building very stable and highly concurrent functional programs but also would allow accessing non-functional resources such as files and measurement devices which defenitely have a state.

If you are not familiar with functional programming, see Functional Programming And The Rest of Us.

Has anyone here tried Storage VIs?

what do you think of Storage VIs in LV?

Thanks!

Depends on your needs. Storage VIs are very easy to use. The performance is however a bit slow and undeterministic. I use them in a few projects because Diadem can open TDM files written by storage VIs. On more demanding projects I use HDF5 1.8 library of our own which performs better and more quite a lot more flexible but also more difficult to use. Unlike in TDM there are no limits to data dimensionality or file hierarchy depth or number of attributes. Anybody interested in becoming a beta tester for HDF5 library, please contact me.

I don't think LabVIEW "G" should be made an open standard. Why? Because we already have a good implementation of a development environment. The thing is that no single development environment or programming language never can cover all the programming problems. The general purpose programming languages like C, C++ and Java are quite close to how wide an audience a single programming language can reach.

What would be needed instead of open G is another open graphical language which would bring forward the graphical programming itself. I don't even mean graphical dataflow programming but graphical programming. It may be dataflow or it may not. It would depend on the desing targets that would be set to this general purpose language. Objects oriented programming language must include references to objects, which is not dataflow, but this doesn't mean that dataflow couldn't also exist for problems where it suits better. The best way to achieve this goal would be to standardize a general purpose graphical programming language. Then perhaps try to build an open source reference implementation of the core features of the language. As an open language, the language could be marketed to software companies building software development environments.

If this language would succeed we would see more graphical programming languages to appear.

A programming language is just a tool and no one tool can be the perfect one for every situation (though the "spork" comes pretty close as far as food consumption is concerned). That's why people use scripting languages for text/file parsing and manipulation but not for large application development. I think it is unrealistic to think any kind of standard could be established.

Exactly! LabVIEW is targeted for measurement and is not very good tool outside this field. However graphical programming is a general paradigm. You could create a high performance graphical language, a web programming graphical language and what ever. The reaseon graphical programming is not more popular is that most programmers are not aware of graphical programming. An why is that. The reason is that LabVIEW is that there is no good general purpose graphical programming language on the market.

This question has been asked quite a few times in the past... but NI hasn't told till now how many licenses they have sold/ sell per year.

Ok. Then I have to make an educated guess. NI turn over was 572 million bugs last year. Let's assume that about 40% of this is from LabVIEW so we get $ 286M for annual LabVIEW sales. Then let's assume that each user pays an average of $1500 per year for NI. So we end up to something like 200 000 users. So I assume the real number lies somewhere between 100 000 - 400 000 LabVIEW users around the world.

The one south of Ghana in the Atlanic ocean is also ...(is he/she still swimming?)

"Rohit" lists a first country of Canada. Maybe this person is indicating their home when there was Pangea