jpdrolet
-
Posts
367 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by jpdrolet
-
-
My problem is:
I have a dynamic number of arrays, each one with different length (size). If I initialize a 2-D Array and then "Insert Into Array" inside a for loop, from the second iteration on all arrays (if greater than the first one) will be truncated to the size of the first array.
What I need is a data structure where I can store a dynamic number of variable size arrays. As if each row of a 2-D array had a different number of columns.
I've tried using clusters, but the problem is that they can't be of dynamic size.
Any Ideas?
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.
-
Its not that "make current value default" isn't working, its the VI you're trying to operate on.
When you use "make current value default" you have to save the VI to make it stick. The VI you want to change is inside the .exe. The .exe is being executed by the operating system. Generally speaking OS's lock the .exes before running them so they can't be deleted, renamed, overwritten, etc while they are running (saving the VI would overwrite the .exe). The exe is locked, and by extention so is your VI, hence the error.
"Make current value default" should work fine from an .exe, just not on a VI inside the .exe.
Sparc
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.
-
Unfortunately, I suspect this won't work, since the content of the applibs directory is totally different from the rte directory under Shared. In shared you'll find the dll's and the control prototypes and in the applibs they are packed into the ".msm" merge modules which (to my knowledge) are used for the dist-kit builder.
Tell me if I'm wrong
Didier
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.
-
JP
Sorry for coming in late on this. I've been using DAQmx awhile and am still new to it!
Looking at your code - you've hit the marks - only comment - do you really want to 'start' the tasks immediately after configuration? I don't know your overall code, if it's a queue state machine.
I do the DAQmx "Start" in the acquire state.
Be wary of odd performance problems using Timed loops and DAQmx...
Regards
Jack Hamilton
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
-
-
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.
-
Thanks for reposting this in 7.x Eliezer. I have used older version of your library in the past and am grateful for this version. It would be nice if it had a function to open a VI from the Manager. I added that to one of your older versions a long time ago.
Here is my version. I don't know if it is as up to date as yours with LV 7.x:
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
-
-
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
-
-
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.
-
In our research lab we have a few Windows XP machines, networked together, for data acquisition and processing purposes. The actual computer I'll be using depends on which experimental system I'll be using, but I'll be using the same acquisition and storage VI's on each computer.
The issue comes with synchronizing VI updates. If I update RoutineX on Computer1, then if I use RoutineX a few days later on Computer2 I want to use the updated version. And similarly, if I update the routine again, I want the changes back on Computer1.
The way I am dealing with this now is by arbitrarily picking one lab computer as a 'server', where I store all my VI's. When I load VI's to insert, I always do it through the network, so VI's have a pathname like :
"\\ComputerName\username\Routines\Acquisition\Measure.vi"
This method works pretty well, all my routines work fine and will be properly updated if I change them, no matter which computer in the lab I am accessing them from.
I have just started using some other user-supplied tools, such as LuaVIEW and OpenG. LuaVIEW can put its VI's and palette menu anywhere, so I do that over the network. But - the OpenG tools want to go to the local computer, in the LabVIEW install directory. So for I need to install the OpenG toolkit on each local computer that I want to use it.
I'm wondering I'll be shooting myself in the foot sometime down the road. As long as each computer has the exact same version of OpenG stored in the same path, then it shouldn't be a problem whether I use a subVI that comes from the network or locally.
I'm wondering if anybody else has thought about these issues, even if you don't use OpenG or other add-on libraries, to keep your usage of VI's synchronized from a network.
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:
Reinit VIs in memory
in LabVIEW General
Posted
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.