jpdrolet

QUOTE(JFM @ May 30 2007, 06:26 AM)

It's not one car. It's all of them!

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

Here:

APP1 enables its VI Server on its specific port.

APP2 connects using Open Application Reference.

QUOTE(Neville D @ May 15 2007, 01:06 PM)

I think you are correct. Property nodes won't create copies,

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.

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.

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)

I think we would have seen some pretty outrageous results if google adsense could parse media files for contents keywords? (They probably can already, but have not put it online yet.)

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

QUOTE(LV Punk @ Mar 30 2007, 01:55 PM)

http://forums.lavag.org/index.php?act=attach&type=post&id=5370

http://forums.lavag.org/index.php?act=attach&type=post&id=5371 (LV 8.0)

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?

QUOTE(jpdrolet @ Mar 4 2007, 10:08 AM)

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!

OK I thought I'd have time to modify it to use Registry VIs but here it uses regedit.exe.

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

QUOTE(gleichman @ Apr 11 2007, 10:40 PM)

I still don't understand the problem.

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.

QUOTE(chrisdavis @ Apr 11 2007, 04:22 PM)

I hadn't heard and/or thought of this technique, very interesting option. Do you know if this technique would work in LV 8.2+?

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.

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

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)

That's a good way (I knew), but I would like something "quicker" than that!

I told you this is just for fun, I don't really need that, so I'm looking at a great way to do.

Actually with the code above, CTRL+M and CTRL+E, I go to the point. In the future I would be able to show the bloc diagram without the menu with only with CTRL+E (or else!).

But thanks for this tip, very usefull!

Laurent

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)

97.73 of you are at animal level, that's why I am your president.

So you manged to measure the universal constant with a forth significant digit? Your skills are improving,erm evolving?

QUOTE(Jim Kring @ Mar 29 2007, 01:56 AM)

I prefer not to use loops, at all -- just use a unowned (floating) feedback node.

http://forums.lavag.org/index.php?act=attach&type=post&id=5331

http://forums.lavag.org/index.php?act=attach&type=post&id=5332

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?

QUOTE(crelf @ Mar 19 2007, 12:26 PM)

It's the animal's fault - I'd be a vegertarian if they didn't taste so damn good

http://diswww.mit.edu/tla/humor/20' target="_blank">Hmm...Meat...

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!

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.