-
Posts
367 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by jpdrolet
-
QUOTE(JFM @ May 30 2007, 06:26 AM) Or rather, "It's 97.73% of them!"
-
It looks like a bell shape (gaussian, lorentzian) mutiplied by a polynom or a sine/cosine function. If these are waves produced by a drop, then it might be Bessel functions (wave solutions of an oscillating membrane).
-
For sure it works, maybe the syntax is wrong. Alternatively, you can include the following lines in the application INI file: server.tcp.port=33363 server.tcp.access="+*" server.tcp.enabled=True server.vi.access="+*" server.tcp.paranoid=False You can also enable the Applcation Item "APP_OPTIONS" in the run-time of the application and edit the VI Server options there. Lines similar to the above will be written in the INI file. The above settings exposes all VIs to all incoming connections so you may want to restrict access only to your intranet or come VIs. I usually set server.vi.access="+Server*" so only VIs with names beginnig with Server are accessible from the VI Server interface. Maybe the "+" is missing in arg3, so sorry my mistake...
-
QUOTE(Neville D @ May 15 2007, 01:06 PM) Why does this myth still prevail? When you read a value property node, you get a copy of the control value at the read time, the same way you get a copy from a local. I think this come from the idea that control references are data pointers which they are not. They are only control references, a value that allows to identify the control. And while the reference can be carried around without the control data being copied, data is indeed copied when you use the value property from the reference.
-
Decimal point scan a timestamp from string
jpdrolet replied to Eugen Graf's topic in LabVIEW General
The problem is not with the decimal specifier but with the time format itself. The format string %<%H:%M:%S%3u>T expects the timestring "15:55:29000". The correct format string should be %<%H%M%S.%3u>T with the decimal separator in the time format. -
Communication with LabVIEW Run-Time Engine
jpdrolet replied to NadavC's topic in Remote Control, Monitoring and the Internet
Try this: http://forums.lavag.org/index.php?act=attach&type=post&id=5683 The VI Server is enabled in APP1. Using the VI Server, APP2 detects Main.vi state and closes the panel if it not running (Idle). When an app has no front panel opened, it exits. -
QUOTE(sachsm @ Apr 30 2007, 08:55 AM) And of course, the Plug and Play Vibration Toolkit Ad was "context sensitively" displayed... :laugh:
-
I also have random problems with ESP300 (NI Forum Thread). The device doesn't seem quite reliable with communications, at least with LabVIEW Make sure that the command is completed before exiting a VI since when a VI becomes idle, the GPIB port is closed and the ESP300 sometimes hiccups on that. Some delay between commands seems also to help. See also Newport site on this issue
-
http://forums.lavag.org/index.php?act=attach&type=post&id=5643
-
QUOTE(LV Punk @ Mar 30 2007, 01:55 PM) It is far from being evident that LabVIEW keeps the strings data in the queue. While it can keep as many as string handles as the queue size, I doubt it keeps the data itself in the queue but just place holders for handles. I would think it is the same for variable length data like arrays and variants. On dequeuing, does LabVIEW copy the string to the caller (keeping an copy internal to the queue) or just pass the string handle?
-
There is a VI method named "Export VI Strings" that you can use to export strings into an XML file. The method "Import VI Strings" does the reverse. So you Export-> Modify file -> Import. Needless to say that the VI must be idle (not running) in Development (not run-time) LabVIEW for that to work. There are also scripting methods that would allow to modify block diagram constants but I'll let the experts to comment on that.
-
Wow. That switch requires some serious debouncing...
-
Calling VIs in main program from Dynamic VIs
jpdrolet replied to ars_stowers's topic in Application Design & Architecture
QUOTE(gleichman @ Apr 11 2007, 10:40 PM) In therory that works but in practice, you have to make sure that VIs in DE don't change at all or else a plugin VIs may work in DE and be broken in RTE. I used to keep a "frozen" (read-only) copy of my project in a directory especially to develop plugins for a specific version of the application. Otherwise modifications in the project induced changes that break the plugins in RTE. For example, adding/removing/renaming a control in a global VI forces recompilation of all callers and a plugin linked to the new global VI will be broken in an application using a previous version, even if the plugin diagram is not affected by the change (yet another reason why globals are evil). Now I relink directly to the built app. -
Calling VIs in main program from Dynamic VIs
jpdrolet replied to ars_stowers's topic in Application Design & Architecture
QUOTE(chrisdavis @ Apr 11 2007, 04:22 PM) If it doesn't work on LV8.2+ I guess you'd have to build another project with LLB instead of EXE. The improtant thing is to load a copy of the VIs as they are in the EXE because Vis in LabVIEW DE maybe modified in a way that will broke plugin VIs when loaded from the executable. -
Calling VIs in main program from Dynamic VIs
jpdrolet replied to ars_stowers's topic in Application Design & Architecture
To make sure that plugins VIs are correctly linked to VIs within the executable, in DE I load the executable VIs directly from the application file .exe in and then load the plugin VIs. LabVIEW DE will relink the plugin VIs to the executable VIs. Then save plugin VIs to the location they have to be relative to the application .exe. Look at the picture Load APP.vi includes VIs from the executable file itself. So loading the plugin VIs afterward wil link them correctly and they will be recompiled if needed. Then I save the plugin VIs in a LLB in the plugin directory of the application (\Modules) where they are expected to be. http://forums.lavag.org/index.php?act=attach&type=post&id=5469 -
Calling VIs in main program from Dynamic VIs
jpdrolet replied to ars_stowers's topic in Application Design & Architecture
I use the plugin architecture and it is common that a plugin VI becomes broken (causing error 1003) in the run-time environement (RTE) because VIs in the development (DE) have been recompiled for some subtle reason, sometimes because a subVI has changed. So the plugin VI works well in DE but would need to be recompiled to be correctly linked to VIs in the RTE. I have developped a technique to correctly compile/build plugin VIs to make them compatible with a built application but it may not work for LV >= 8. On the diagram of a VI I put the Top Level and Dynamic VIs (to include the whole hierarchy) of an executable. I do this using the Select a VI... dialog and typing the name of the VIs in the executable. Open the folder containing MyApp.exe and type in the file name MyApp.exe\MyApp.vi. Save this application loader VI. When you need to distribute a plugin, load this VI first then open your plugin VIs. That operation will recompiled the plugin VIs to make them compatible with the VIs in the application. However, if the plugin VI is still broken, that is probably because you made a change in the application VIs in DE that makes them incompatible with the previous version in the executable. After the plugin VIs are loaded, save them in a LLB using Save with Options...> Application Distribution. If LV>=8 does not allow to select VIs in an executable to make the application loader VI, then you could save a snapshot of the application's hierachy in a separate LLB and load application VIs from there. I'd like to see this functionality included in the OpenG Builder e.g. preloading fixed, compiled libraries of VIs and build the plugin with the RTE VIs rather than the DE VIs. I may work on this if I find time for OpenG development... -
QUOTE(lraynal @ Apr 10 2007, 10:12 AM) You could trap Ctrl-E directly and then set the private VI property "Block Diagram Window:Open" to TRUE. See http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">Scripting to enable private properties in LabVIEW
-
QUOTE(alfa @ Apr 2 2007, 12:55 AM) So you manged to measure the universal constant with a forth significant digit? Your skills are improving,erm evolving?
-
QUOTE(crelf @ Mar 19 2007, 12:26 PM) http://diswww.mit.edu/tla/humor/20' target="_blank">Hmm...Meat...
-
Sorry for my short sight... To prevent the main hierarchy from being unloaded before the garbage collector does its purpose, have Garbage Collector to open a VI reference to MainVI.vi. That will keep its hierachy in memory after it comes idle. Garbage Collector can itself have its FP open but in "hidden" state, see the Open FP method. I'm pretty sure that it will keep the application running without visible window.