Leaderboard

Thanks for the replies, I am aware of how to obtain this information using VI server. I just find it odd this tool does not exist. Sounds like something I will have to develop and submit to the LAVA code repository. So this thread has now become suggestions on developing a VI Task Manager tool.... Please reply with your ideas!

Hi Alex, I think your being way too ambitious, and trying to develop many advanced concepts simultaneously. Personally, I couldn't learn and use dynamic VIs, queues, QSM architecture, etc. on top of learning FPGA and your imaging equipment itself. Introducing one new thing is a good learning experience; introducing several is a terrible experience as you'll never untangle the nest of interacting bugs. And it's heavily over-engineered. This code is to collect images and display and/or save them, right? Why does it need six separate loops (four dynamically launched) to do this simple sequential thing. For example, your "Listen to Image FIFO Stream" loop loads it's image data into a set of three queues and sends it to your "Display and Save Image Data" loop; you could easily do that in one VI and save the (buggy, BTW) implementation of the queues. You could probably do this program with a single QSM, or at most a QSM with one extra loop controlled by a single notifier (as I suggested in your other thread). The best course of action I can suggest is: 1) Get a basic prototype working that does the basic image collection and display functions you want. ONE VI, ONE loop, no QSM, no architecture, no queues, no control references. Simple data flow only; it's just a prototype. 2) Use that experience to get a set of basic subVI's such as "Get image", "Save Image", "Trigger", etc. (no loops internally, these just do one action each). At this stage, think about clustering related information (type-def clusters or objects). 3) NOW start fresh on a architecture, using your new "driver" of subVI's. It would be best to use someone else's already debugged, and well thought-out, template (such as the JKI-QSM, which is what I use). I suspect you might only need one loop (with the Trigger->Get->Save steps in the timeout case of the JKI-QSM) but if not, use a separate loop on the same diagram controlled by ONE incoming communication method (not multiple polled control references and global variables). If you want to continue with your current monster, here's some issues I can see: 1) In the QSM design, every state calls "idle", including "idle", which causes the loop to execute the "idle" state (which does nothing and has no delay) at maximum speed, monopolizing the CPU (what's the "idle" state even for?). 2) Your three queues to send one image design is buggy since the queues can get out of step with each other when errors occur, Also, your queues will fill up and crash the program if the receiving "Display and Save Image Data" VI isn't running. And "Display and Save Image Data" will display and save default data if it doesn't receive an image every 5ms (the timeout you've added to each queue). 3) Your "Stop Stream Refnum" design neither starts, nor stops, your "Listen to Image FIFO Stream" VI. It doesn't actually do anything. As I said, simultaneous bugs on multiple levels is very difficult to work through. Personally, I only use dynamic VIs via a template (worked out and debugged on simple test cases), and use someone else's template for a QSM (JKI). Combined with an initial prototype to learn the new functionality (often I just play with the example VI's provided), this makes debugging manageable. -- James

This isn't a terribly complex API call, so I doubt you'll need this, but I had a play at it. The cluster should be typedef'd, but ehhhh. If you use this and your computer explodes, I am not liable, etc etc. I've only tested it on Windows 7 x86, LV 8.6 and LV2009. A customer has had me doing a lot of API-based stuff lately, so I've developed a sick fascination with these. I had a pipe-dream of developing a ShellIcon library in LV, that might come to fruition soon. GlobalMemoryStatusEx.vi Get Win32 Error Message.vi

> I always figured there was some magical subtlety I was missing that made the pattern worthy of a special name. Nope. Patterns are patterns, even the very common ones. Having said that, it is amazing how often in software design that people go to great lengths to solve problem XYZ, and someone else pipes up with, "Why don't you just do MNO?" where MNO is some common action. That's often the case with the facade pattern... rather than trying to call an api directly, create a facade that you call through.

I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: the linker information (the list of other LV files upon which this VI depends), the identity of the VI (which library owns this VI), the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code), and probably some other stuff not relevant to this conversation. In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded.