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.