Tomi Maila

As far as I know there is no need for semaphores. Queues are thread safe.

QUOTE(Thang Nguyen @ Jun 26 2007, 10:18 PM) I've not tested building process but I guess the following should work. Place the whole class including the dynamically called process VI outside the executable. Tomi

Hi Ton, Try to do the activation via Tools -> GOOP -> Product information. That may work. Tomi

QUOTE(Jeff Plotzke @ Jun 16 2007, 10:47 PM) Are you saying Crelf is hiring too many and too talented guys to VI Engineering so that he can spend all his office hours at LAVA? Well, congrats Crelf! Don't stop contributing. What would LAVA be without you...

Do you have an open position for CTO as well ?

QUOTE(Jeff B @ Jun 13 2007, 06:29 PM) Thanks Jeff for your answer. I'm still wondering if inplaceness algorithm works better if inputs are required....

QUOTE(brianafischer @ Jun 12 2007, 07:15 PM) I guess with "data" you don't mean data values but typedef type? Typedefs don't specify data values. When you change the type, you also change the layout as there is no way to convert one layout to another. For example there is no way to convert layout of an I32 control to a layout of cluster of string array and boolean. So the answer to your question is no, it's not possible. I don't really even understand what you actually expect LabVIEW to do in these situations. QUOTE(brianafischer @ Jun 12 2007, 07:15 PM) 2. How does everyone deal with updating typedefs if this is the case (lose layout when updating typedef). Is it best practice not to use typdefs for front panel layout? When to use strict Use strict typedef when you want to change the typedef look and feel and want that look and feel change to propagate to all controls using that specific typedef. Use non-strict typedef to allow changing the look and feel of each control connected to a typedef but still keeping the type the same. Both typedef and strict-typedef update both the type and the look-and-feel when the type of the typedef is changed as the old look and feel can no more represent the type content of the typedef.

I just posted a new article Concepts Behind OpenG Class Templates to ExpressionFlow. The article explains what OpenG Class Templates fundamentally are and how they are used. Tomi

I'd like thank Endevo and especially Mikael Holmström and Jan Klasson for supportting open source templates. Without support from Endevo there would not be open source class templates as there would not be an easy way to use these templates. Tomi

QUOTE(yen @ Jun 11 2007, 10:29 PM) Well, I'm not a native English speaker...

If you still have problems with this issue, please check out OpenG Active Object Template. Tomi

Here is a link to the OpenG Class Templates thread.

QUOTE(yen @ Jun 11 2007, 08:38 PM) For some reason the state of the blog post had changed from public to private. It's visible again. Sorry for this.

Hi all, I'm very happy and excited to announce that beta versions OpenG Class Templates have just been released for public testing. OpenG Class Templates are templates for LabVIEW Object-Oriented Programming for creation of classes beyond the limits of native by-value LabVIEW OOP. Two most interesting OpenG templates are a queue based by-reference class template and a class template for active asynchronous objects. For more information see my blog article at ExpressionFlow. Tomi

QUOTE(didierj @ Jun 8 2007, 10:01 AM) As always, it would be easier to explain should you submit a project that reproduces the problem.

I decided to test this issue. I wrote two identical VIs from scratch. One of the VIs is with required connector and the other is with recommended connector. Both VIs compute +1 for an U32. I made a test VI runs both of these VIs in two parallel loops and measures which loop runs faster. Then I made another test VI that is identical to the first test VI but the required subVI is replaced with recommended subVI and vice versa. Both of these test VIs show that VI with required input runs faster than the VI with recommended input. I considered the option that LV schedules VIs according to their name so I switched the names of the VIs. Still the required VI was faster. The speed advantage for this task was about 1%. Let's see what could happen under the hood of LabVIEW. If we have a subVI with a required connection, LabVIEW compiler knows that it always has an input buffer connected to the required terminal. On the other hand for a VI with a recommended or optional terminal LabVIEW doesn't know at compile time if a buffer is connected to the input terminal. So LabVIEW needs to insert a snippet of code to allow both options. Let's speculate what happens when LabVIEW calls a VI with required input. - The callers pushes input buffer pointer to a stack - The caller jumps to the entry point of the subVI - The subVI pops the input buffer pointer from the stack - The value of the input buffer is incremented by one inside the subVI - The subVI returns Let's also speculate what happens when LabVIEW calls a VI with recommended input. - The callers pushes input buffer pointer to a stack - The caller jumps to the entry point of the subVI - The subVI pops the input buffer pointer from the stack - The subVI checks if the input buffer pointer is a NULL pointer - If it's a NULL pointer, LV creates a new buffer for the evaluation - The value of the chosen buffer is incremented by one inside the subVI - The subVI returns Actually the recommended case process can be even worse if the in-placeness algorithm cannot optimize for the reusage of input buffer. Even though there is enough information available to be able to reuse the input buffer, it doesn't mean that LV actually does this. In this case there will be memory copied once or even twice each time the subVI is called. Tomi

It may very well be true. In theory required inputs can be optimized better at compile time of the VI. For not-required inputs VI needs to create a memory buffer for the particular input. For required inputs VI can more easily reuse the input buffer. The added benefit would be lost if LabVIEW did optimization that would depend on the block diagram environment into which a VI is dropped. But it doesn't do this.

QUOTE(Thang Nguyen @ Jun 7 2007, 12:11 AM) In a few days you'll get the answer p.s. See also another thread: http://forums.lavag.org/index.php?showtopic=8394&st=0&gopid=31246' target="_blank">http://forums.lavag.org/index.php?showtopi...amp;gopid=31246

Set Control Value doesn't work in a built application unless you force the VI front panel to be included in the built. By-default the front panels are removed. In headeless environments the front panels are always removed so Set Control Value is never availbale in headless environments. I and Jim Kring brainstormed this set control value issue a few months back and came into a conclusion that the best way to pass data to an asynchronous VI is using a named queue. As this question seems be popping up often I try to explain in more detail When you want to use a named queue to pass data to another VI, you must verify that the name of the queue is unique and that both VIs use the same queue name. VI name is a good choise for the queue name but it's not unique for reentrant VIs. Therefore a unique name can be constructed from VI clone name which is always unique for any reentrant instance of a VI. After opening a reentrant reference to a new VI, use clone name property for the reference to get the VI clone name and create a queue using that name. Then inside the reentrant VI itself use static VI reference to get the clone name of the VI itself. The simplest way to do this is simply place the clone name property node without VI reference input to the block diagram of the reentrant VI. Use this clone name inside the reentrant VI to get a reference to the same queue you create inside the calling VI. Now you can use this named queue to pass data asynchronously between the calling VI and a reentrant instance of another VI that works in built applications and headless environments. EDIT: If you do not have access the VI reference because you have not written the template by yourself, then you may force the front panel to be included in the build from build settings. See also this thread: http://forums.lavag.org/Question-about-Lab...y-VI-t7669.html Tomi

Thang, if you are ready to wait for a few more days, there will be something interesting coming up from the LabVIEW open source community that may help you to taggle your problems. I cannot go into detail yet. Tomi

QUOTE(Jeff Plotzke @ Jun 6 2007, 06:25 PM) Hehe... Google ads barely cover the hosting fees. No you are not going to make money by blogging directly. Indirectly you may get interesting job offers...

I don't have much time to take a look at your stuff. A quick look indicates that you are using clone name for the create VI. This will not work as your create VI is not the one that is cloned by the process VI. So use the clone name for the process VI you are about to launch to create a named queue. Then inside the process VI find out the clone name of the process VI a second time to get reference to the same queue you already created for this particular clone instance. I may be able to give more detailed help at the end of the week.

EDIT: See Jim Kring's blog article http://thinkinging.com/2007/03/29/reentrant-vi-clone-name/ Tomi

I cannot create multiple instance of one class because the name queue is hard code. Yes you can. Open a VI reference and use clone name property for the VI reference to specify the queue name. This is different for each instance so you get separate queue for each instance. Tomi

I'm whit Jim here in that by blogging you reach a wider audience and your blog articles can be more punctual. In addition you are able get direct feedback via user comments. Tomi