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?

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.

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.

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

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?

Yes I think I understand. Thanks

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

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