jpdrolet

I'd like to be able to reset all VIs in memory to revert to a clean state like when VIs are just loaded into memory. That is to reinitialize all controls to default value and clear uninitialized shift registers. The VI method Revert VI would do that except that it erases unsaved VI changes.

Use a 1D array of cluster containing a 1D array.

I wish the ability to automatically remove the previous source of a wire when I connect a new source. It could be controlled by holding a control key when wiring or settable as the default behavior.

Do these ActiveX based tools port well for distribution on different Windows/ADO versions? I've downloaded LabSQL and the VIs were broken, I had to reselect the ActiveX class on controls to repair them. I anticipate a nightmare if I use them in a distributed application.

That's not the problem. A LabVIEW built executable, with the Run-Time Engine, do not include the functions required to edit, recompile and save any VI, even if the VI is not located in the EXE. Those functions are available only in the LabVIEW development environment.

OK sorry, it was in LabVIEW 6 that there was a folder applib/installs where you could replace the RTE Installer. Why is installing RTE after the app not an option? The Application Builder allows to include an executable (e.g. the RTE) and run it automatically after the application installation. I suggest to contact NI directly to see if there is a way to select langage specific RTE for installation.

I think I read somewhere in the doc/examples that it is inefficient to start/stop tasks at every iteration of continuous acquisition.

You'll find the Run-Time Engines here at ni.com Download the required RTEs and before building an app with a specific langage, copy the required RTE files in the applib directory. The application Builder will copy the RTE from applib directory and include them in the installer. Unfortunately, you'll need 4 different installers.

Thanks Michael, I've found the solution myself. I don't create global tasks. See picture. Tasks are defined separately and don't conflict. Counters has to be set in two different tasks to read the counter values separately. Another task for 4 analog inputs is defined elsewhere in the program. It worked as expected the very first (correct) run :thumbup: That is after having rebooted 3 times.... 1: Oups! forgot to install NI-DAQ on target. Install and reboot 2: An error message for DMA channel not available for the task... can't figure what's up so reboot 3: Another different error message: the board is reset. Can't communicate with MAX either. Can't figure what's up so reboot. 4: The board is properly working and the program runs fine. It's always rewarding to see a program running as expected at the first run (and that board installation problems weren't related to my code).

I'm not familiar with DAQmx and need some guidance to organize tasks settings with a PCI-6024E board. Analog inputs: 4 channels acquired once per second. Timing is not critical, I can use software timing. I don't need waveform Analog outputs: 2 channels. I need to update their values independently once in a while. No need for waveform generation. Digital input: I need to detect a home position so 10Hz read update rate is sufficient. I still can use software timing. Digital output: I need to activate a relay once in a while Counter inputs: I need to count edges on two counters inputs. While there are working examples for each task separately, I have to run all the above from different parts of the program. Do I need to define five tasks or can I regroup them in some way? Do digital input and output need to be on different port or can be on the same (e.g. are lines settable independently for I/O on the same port) ? Can the tasks conflict with each other, especially for timing requirement?< Thanks

Save Toby

If you want to least-square fit a model equation to a data set, I think what you need is Non-Linear Lev-Mar Fit.vi Edit the VI Target Fnc & Deriv NonLin.vi to compute the model equation F(x;a) where a is the set of parameters to adjust for minimization. You are not limited to use formula nodes to compute the result. If F(x;a) is linear relative to a (e.g. F(x;a) = a1*sin(x) + a2*exp(-x) +a3*...) you can use General LS linear Fit.vi. If your cost function is not a least-square, then maybe you should expose your problem with more details to see if we could find a solution.

The menu refnum is not on the VI property list yet. It is on the wish list since 2001. See item 5.1 in the document attached here.

Here are clever techniques that really detect when the user releases the mouse (5.1!). In LatchSlide.vi , the slide value is latched only when the user releases the mouse. There are two sliders on the slide, one for display and one for manipulation by the user (it is invisible and covers the whole control. On the diagram, the invisible slider is constantly pushed offscale (via local) and then read. If the value stays offscale, that means that the user has released the slider and the value can be latched. If the value is still on scale, that means the user still holds the slider and the value is not latched. In MouseTrack.llb there is another technique using a picture control. When a change is detected on a control indicating that the user is editing it, a transparent and invisible picture control covering (and in front of) the whole panel is made visible. The mouse position is read on the picture control. The trick is that as long as the user keeps the mouse button down, the focus remains on the edited control and the mouse position on the picture stays (-1,-1). The mouse up event is detected when the mouse position on pict is different from (-1,-1). One slight incovenient of this technique at the time I designed it is that on Mac and some configuration of Windows, the mouse had to be moved at least one pixel on the pict for the actual mouse position being correctly reported after mouse release. Download File:post-447-1108650884.vi Download File:post-447-1108650886.llb

Some files are in 7.1 in there... And one feature I would like is to be able to manage Top Level VI status in LLBs. That's the only feature why the obsolete "Edit VI Library..." is still required. There is an OpenG VI in Librarian VIs that does that.

Group: Rush Album: Moving Pictures Title: Tom Sawyer

That's part of the conspiration, obviously... :laugh:

Hum.... Moreover, the face on the right looks like a statue from Easter Island. Eerie!

Did anyone else notice the two alien faces one can see on pictures of Titan' surface made by the probe Huygens? One face and one profile. Amazing! It can' be a coincidence! * still looking for a monolith... *

That should do what you want:

I tried to remotely control a VI using an Internet Browser an found two annoyances: - The Web Server retrieved private information from the connected client: the user name was in the log file. That's a privacy breach. - The Web Server doesn't work with Mozilla FireFox. The plugin is not available. Is it Internet Explorer only? EDIT: For LabVIEW 7.0

IBM releases software patents

Here we can share and discuss useful tips and shortcuts you use in LabVIEW after years of experience. (Michael: Maybe this topic should have its own forum if there are many entries...) My favourites: Use one labview.ini file per project There are many benefits to have one labview.ini file per project since different projects may require differents settings. In this labview.ini file, set the default directory to your project directory: the file dialogs will conveniently start from this directory the list of recently opened VIs will be uniwue to each project the builtin SCC can have different location for each project For each project I have created a shortcut to launch LabVIEW with this labview.ini file "path\to\labview.exe" -pref "path\to\project\labview.ini" <optional path to VIs to launch/load at startup> I even have created a custom file extension *.lvini that launches LabVIEW when dbl-click on the inifile. The command line is "path\to\labview.exe" -pref "%l" If you work with several versions, you can create several extensions (lvini70, lvini71,...) Work on SUBST drive When I work on many versions/branches of a project concurrently there are potential problems of cross linking and paths. It is not straightforward to start the same project from a different directory as there are numerous paths still pointing to the previous directory. I used to SUBST the working directory to a logical drive e.g. when launching the project I map its directory to say drive Y: I start the project with a command file located in the project directory: rem delete the actual Y: subst, if anysubst Y: /drem subst the directory where is located this command file to Y: (dot == current directory)subst Y: .rem start LabVIEWstart "" "c:\program files\national instruments\labview 7.0\labview.exe" -pref "y:\labview.ini"rem or start "" "y:\labview.lvini" if the lvini extension is defined This way the project has always the same root path whatever the version I work with. There is less danger of crosslinking since the actual directory is not explicitely referred to.

OpenG VIs are put in the user.lib directory to be easily located by VIs using them. When a VI calls a VI from user.lib, the callee's path is stored relatively to user.lib directory in the caller. Then it is not dependent of the path where LabVIEW is installed and OpenG VIs are easily ported e.g. not always searching and relinking to new location on a new target. In your case, when a VI is saved from one computer and opened from another, it will always link to the local version of the OpenG VI, exactly as it does for VIs from vi.lib. Another solution may be to share the LabVIEW directoty on one computer. On other computers, set the path option "Library Directory" to this share. Then all LabVIEW instances will share the same root directory. That includes the same vi.lib, user.lib, instr.lib and also help and project(Tools) directories. You will have to install OpenG only on the shared instance of LabVIEW I used to do that with LabVIEW executables but the "Library Directory" is not effective anymore in recent versions of LabVIEW (even if the option is still available, it doesn't work). Edit: See here

:beer: Thanks guys! :beer: