Jump to content

jpdrolet

Members
  • Posts

    367
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by jpdrolet

  1. QUOTE(JFM @ May 30 2007, 06:26 AM) Or rather, "It's 97.73% of them!"
  2. 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).
  3. 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...
  4. Here: APP1 enables its VI Server on its specific port. APP2 connects using Open Application Reference.
  5. 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.
  6. 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.
  7. 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.
  8. QUOTE(sachsm @ Apr 30 2007, 08:55 AM) And of course, the Plug and Play Vibration Toolkit Ad was "context sensitively" displayed... :laugh:
  9. 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
  10. http://forums.lavag.org/index.php?act=attach&type=post&id=5643
  11. 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?
  12. QUOTE(jpdrolet @ Mar 4 2007, 10:08 AM) OK I thought I'd have time to modify it to use Registry VIs but here it uses regedit.exe.
  13. 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.
  14. Wow. That switch requires some serious debouncing...
  15. 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.
  16. 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.
  17. 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
  18. 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...
  19. 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
  20. 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?
  21. QUOTE(Jim Kring @ Mar 29 2007, 01:56 AM) Hmmm... Just looking at the scrollbars there is a hint that the diagram is larger than what is shown... Anything hidden in the 5th dimension, Jim?
  22. QUOTE(crelf @ Mar 19 2007, 12:26 PM) http://diswww.mit.edu/tla/humor/20' target="_blank">Hmm...Meat...
  23. Ahh.... My pet problem with LabVIEW apps solved! I'll pay you beers guys. I have a VI to register file extensions. I'll make it available when I'll have access to it. Great find!
  24. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.