LAVA 1.0 Content

I saw him yesterday.

There are functions in LV to stop individual VIs/application and a function in the LV RT utilities to restart a RT controller (shutdown/retsart), but short of pulling the power plug or controlling a robot to flip the power switch on the front of the PXI chassis you can not shutdown a RT controller to an OFF state programatically.

Correct. A fork in the wire constitutes a copy and creates another instance of the object.

These are configuration files used by the NI-DAQmx driver. They are used by the driver software to identify and communicate with the hardware in your system. A corrupted configuration can cause the behaviour you describe.

You can dowload it now from NI download site ni.com/downloads, select evaluation and then Labview 8.2. If you havve an SSP I am told your current serial number will work.

Using the VI Server/Application Control functions you can access control/indicators on any VI using their name as a reference. You do have to use the Variant data type to handle different data types. Download File:post-3370-1154819808.zip

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.

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.

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)

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...

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

I've got toget to 667 posts some how

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

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?

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

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.

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. The LabVIEW library I have written implements central parts of the HDF5 C library. It currently ony works on Windows.

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.

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.