Vladimir Drzik

I think the main problem is in the value of Packet Size. The FireWire bus always transmits 8000 packets per second. With packet size 388, you are transmitting just about 3MB of data per second. While the size of 640x480 image is about 300kB, you cannot reach 25 FPS. I'd recommend always setting the packet size value to the highest number the driver allows you. This rule might not be true only if you are using more cameras on one bus.

The second issue is the length of your triggering signals. I am not quite sure, but 50 us seems a bit too short to be reliable. We are using the Guppies in an industrial enviroment and transmitting the triggering signal over a 10m cable. Under such conditions, 1 ms triggering pulse time is not reliable, while 10 ms is. Perhaps your setup is not so sensitive, but anyway, I wouldn't trust the 50 us pulse.

Thanks for your help. The idea with the custom probe is just great . I must try it as soon as possible.

Many times I am using reentrant VIs, which have more clones dynamically opened through VI server. Their front panels are not visible. I find it quite hard to do any debugging, because in order to place a breakpoint, I need to access the clone's block diagram. The only way I'm currently using is programmatically opening the front panels at the time the VIs are being opened. However, that means changes being made to the code just for the debugging session, which is quite clumsy. What do you guys use?

Write a static dispatch VI -- it does NOT have to be a member of the class, assuming the dyn disp VI you're trying to invoke is public -- that has the same conpane as the dynamic dispatch VI except that the terminals aren't dynamic. Have the static dispatch VI call the dynamic and then use OpenVIRef to open ref to the static dispatch VI.

Actually, I am currently using this method. However, I also need to get the reference to the newly run DD VI, because I need to insert its FP into a subpanel. In my current workaround, I have to send the reference of the DD VI from itself back to the calling module through a queue. Which is not nice and requires modification of the existing code. That's why I was searching for a simpler solution.

If the class has an exposed property which links to its parent (and it probably does have it somewhere), then you can iterate over the override VIs from the bottom class to the top one.

I'm not sure if this is possible in the run-time environment. I tried experimenting with opening a reference to the LVClass, but skipped my effort immediately because it's unsupported in run-time engine.

Wire the class wire into the Get LV Class Path VI. This should return the path of the specific class on the wire.

Use that path to open a ref to the VI (it should already know it's a part of the class) or append the DD VI name to the class if it's already in memory (remember that you need to use the format A.lvclass:myVI.vi to get a fully qualified name) and use that to open the reference and run the VI.

Yes I was thinking about using Get LV Class Path. However, I can't find a reliable way to use the class path to get the path of the overriden DD VI. Appending the string ":myVI.vi" is unfortunately not reliable, because the VI might not be implemented in the child class itself, but in one of its ancestors.

I don't remember ever running DD VIs using the Run VI method, but I believe this should work.

It works indeed. The only trick is to get to the overriden VI's path .

For application based on LVOOP and using asynchronous modules, it is often needed to open reference to a dynamic dispatch VI to be run asynchronously. For Open VI Reference (OVR) node, you have to supply a path to the VI you are opening. Is there any way how to get the path of the correct override VI?

I can think of some workarounds. However, all of them require altering the classes in question (adding some helper member VIs). I am seeking a solution, which can leave the original classes intact.

Dynamic dispatch means that you don't know at compile time which VI will execute, and it would be impossible to preallocate a clone of an unknown VI.

Now I got it. Thanks

This is what LV help says:

A reentrant VI can have dynamic dispatch terminals only if the VI shares clones between instances. This VI preallocates a clone for each instance.

To fix this issue, you must either change the terminal in the connector pane to not be dynamic or change the reentrant execution in the VI Properties dialog box to Share clones between instances.

Do you know why this is so?

Thanks guys, I got it

I'd like to turn off the automatic numbering of icons for new VIs (and class methods). Anyone knows if that's possible?

I hope that makes sense. I'm sure there are other ways to code this but this is working well for me right now.

Yes I think I understand. Thanks

I do something similar to this. I have multiple senders posting messages to a receiver. In my case, I wanted the system to be lossy since I only care about the most recent message from any one sender.

I have each sender use a notifier to send it's message. I then wait on multiple notifiers and then process all the notifications at a maximum rate of 1 second. The notifications contain a queue ref from the sender. I filter the array of notification data to throw away dups (the lossy part) and then process each unique queue to get the data it contains (these are single element queues).

I find a mix of queues (used as dynamic memory elements) and notifiers (for signaling) works quite well.

I don't quite get this. The notifier itself can carry data, so why are you passing a reference to a single-element queue?

Is this is the 'UI thread' often talked about on the forums? I've never quite understood if they meant the Labview UI, the VI UI, or maybe even the Windows UI.

I'm also curious about the who does the user thread management. I take it LV is responsible for deciding when to invoke one of the threads from the pool. Does LV also manage all of it's own thread switching? Does the OS get involved in LV threads or does it stay at the process level?

Some good startup information can be found here. However, some of the info is outdated, such as the one about two threads per execution system. In the latest LV versions, there can be more than two threads per execution system.

Yair: The need for polling is one of my worst programming nightmares . I need to pass each message ASAP and I can't use 100% CPU time. I think that's not achievable by polling.

silmaril: Good idea! I usually use queues with just one sender and one receiver, so I haven't thought about the possibility you propose. The only technical drawback is that each sender has to send its ID together with its message. But that's definitely possible to do.

I'm implementing a universal message passing subsystem to pass messages between several asynchronous parallel modules.

For the communication, I'm using (naturally) queues. However, I need the message passing subsystem to wait for new element in any of several queues. There is no such primitive in LV, only waiting for multiple notifiers. I know I could work around this by using an additional notifier for each message queue, but is there a more elegant solution?

QUOTE (Gavin Burnell @ May 27 2009, 02:07 PM)

Technically I think you probably could build a very limited labVIEW code builder using scripting and a picture control, however (a) it would be very hard work, (b) it would require a development system to be installed on the target machine for the scripting to work and © I'm pretty sure that this is explicitly forbidden in the various LabVIEW licenses.

Ugh, interesting, but you gave me two good reasons (a+c) why not to follow this way . Anyway, I'm surprised that this is forbidden, provided that you still need to have the development version installed.

QUOTE (Yair @ May 25 2009, 06:38 PM)

If you really want, you can open a VI and then embed its BD window inside your front panel using the Windows reparenting API functions. You should be able to find something if you search for MDI. You could probably even use a subpanel and play with the window bounds to avoid showing the window frame, but this would probably be fragile and I doubt it's worth it. Also, it might create some issues if you have subVIs and you try to open them.

Yair,

Interesting idea, thanks. Maybe I'll look into that a bit further.

I contacted NI and the answer is the option of embedding the editor is not supported. The Vision Builder probably uses some parts of LV core to implement its Calculator step. Well, it seems like this is not the way to go.

Vladimir

Guys,

Thanks for the answers. Well, it also seems unlogical for me for NI to include LV editor in the runtime. But... the calculator step in Vision Builder is actually THE LV editor. It even uses the settings from LabVIEW.ini of the current LV development version. And it works also without development version installed (though I'm not sure which INI file it uses then).

Anyway, it wouldn't be a big problem for me if the development version was required to use the editor inside my application.

I'll also contact NI and let you know if I find out any new information.

Vladimir

QUOTE (ShaunR @ May 21 2009, 05:20 PM)

Subpanels. Example in the usual place.

Shaun,

Subpanels allow you to embed a front panel. I need to embed the LV editor. Or am I missing something?

Vladimir

Hi guys

I'd like to embed LabVIEW editor in the window of my LabVIEW application. The same thing that e.g. Vision Builder does in its Calculator step. The user would be able to write his own VI, using a restricted set of nodes. How can this be done?

Vladimir

QUOTE (Aristos Queue @ Apr 1 2009, 03:20 PM)

Lots of documentation... it's one of our "six major reasons why you should use LV classes" that I presented at NI Week 2008. I linked to a bunch of stuff in http://forums.lavag.org/LabVIEW-Class-Data-Preservation-Details-t11259.html' target="_blank">this forum post.

Nice. However, sometimes I'd like to be able to do a special data conversion from the older version. Is there a VI that can get the object's class version from the flattened string? Yes I know I can do it by parsing the string...

As Yair has already said, the bad part is that the version history is lost after renaming of the class. Well, maybe that could be solved (in rare cases) by manually renaming the class on disk to keep its version history and modifying the flattened strings by parsing and regenerating them with a different name.

Vladimir

QUOTE (Yair @ Mar 31 2009, 06:59 PM)

The better advice I can offer, however, is to use another method. Some options include LVOOP, the OpenG variant config VIs and MGI's read-write anything VIs. They allow you to open older versions, newer versions, etc. without having to write any additional code and work very well.

Thanks for help guys

Yair, are you serious that you can open older versions of LVOOP objects? Never heard about that... How does the conversion work? Is there any document that describes the mechanism?

Vladimir

QUOTE (shoneill @ Mar 31 2009, 04:47 PM)

Well, why don't you save the control as a normal control instead of a Typedef.

Shane.

While my large cluster is in its current version, it's good to have all its nested data typedefined. But before I make any change to the data declaration of the large cluster, I always make a copy of its current state into a version history folder. But the copy has to be "frozen", so that it does not change in the future when the typedefs are modified. That's why I need to disconnect the typedefs.

Vladimir

Hi

I use a very large cluster, consisting of many nested type definitions. For this cluster, I keep the complete version history, i.e. each version of the cluster is a separate file. In this file, however, I no longer want to autoupdate the nested clusters when my typedefs change. That's why I'm disconnecting all the typedefs each time I create a new file (new version).

This takes quite a lot of time. Can you think of a simple way how to do this "batch disconnection" more simply?

Vladimir