Mike Ashe

This bit me a couple of times between 7.0 and 7.1 I thought about doing the directory swapping bit but then stopped using 7.0 much. I agree that this is a problem.Thanks to Michael for the INI file notes and Jim for passing along the NI support reply. This helps.

At the end of your program put an "Exit LabVIEW" node. This can be found in the Application Control pallete. You might want to put a CASE around it with a boolean so that you can turn this off during development.

I find that for me a string is more flexible as the command than an enum. I also use this often as the input to a case, so the string gives me the readability in the case structure. However, I often put a plugin interface call in the default of my CASE structure. That way I can load up extension plugins at startup (or on the fly later) and if a command comes in that the basic state-machine does not recognize it goes to the default frame. There I search a list of the plugin VI names (sometimes stripped or pre/postfixes and/or .vi extensions) and if found then I do a VIServer call to that plugin, passing the variant array as parameters. This lets me add extension commands easily. I do these as named variables in the variant array. I search the variant array by name. If the optional variables are there I process, if not, move on. I agree totally on the wrapper. I also put a wrapper on the queue creation and sometimes create queue pairs that normally just pass one to the other. This allows the option of "hooking" in-between the queues and filter/processing of the command/data stream simular to subclassing in Windows OS. Another good architectural technique. I sometimes prepend <replyXXXXXXXX> (not the brackets) to the beginning of Send Messages. On the receive side I look for "reply" anchored at the beginning of the command string. If I find it, then I know that XXXXXXX is the input queue name of the module to reply to. If not found then no reply is expected. Actually, with a little more work this is not quite true any more. It is easy to flatten anything to string or variant and you can even do it without wiring by using VIServer "Get Control - Variant" method. The rub comes on the "decoding end", but again, you can either use VIServer to write the data, as variant at the decoding end (this is assuming you are using some type of plugin architecture) or you can do a parse of the variant data tree. For a great example, (and code!) see Jim Kring's Universal Probe or the Variant Config File example VIs. Again, with a little work.... You can add a named attribute to a cluster in a variant, then use the variant config cluster VIs to write to your cluster. Anything that doesn't get written gets reported back as an error, but the data variables that do match (by name and type) will get written successfully. I didn't believe this either til I saw it work a few months back. Its pretty nifty. We've come an extremely long way from when all we had was Flatten to/From String. For all practical purposes we can now implement polymorphism if we want to put in the work. The decision is, is my current project worth the work to make it that generic? or is it overkill for this application? As the OpenG set of tools expands, we will have more examples and code snippets that implement the above techniques and make it easier too.

On another thread in the forums we ended up getting into some of the same stuff here. I don't like to cross-post, but I felt it might help a few more people see and also avoid some duplication. Is there anyway to consolidate two topics into a single topic if their material has started to converge significantly? (Good question for the other Michael)

Okay, here is the initial code. As I said, it is ugly, a hack and very minimal, but it gets the ball rolling and gets it out of my hands. For quickness sake I included a slightly modified version of Jim Kring's Universal Probe. You can get the original on OpenG. Download File:post-45-1104631195.zip LV7.1 (if enough people get interested I'll resave in 6.1 or 7.0) Here is what it looks like for now: First open the zip file in a directory, then open Wires to Probe-Table.llb>>Probe Table.vi, Now open Test subVI.vi and also its diagram, and browse to it in the path at the top of Probe Table.vi, run ... If you click on a row of the table you should see the corresponding wire in Test SubVI.vi go to highlight mode. You can quickly click around and see highlights set and clear. Now double-click a row to attach a universal probe to that wire and also open the probe. Open up a couple, then run Test subVI.vi and play around. Thats as good as it gets for now. Enhancements: 1. Get All VIs and use to populate a listbox or menu of VIs as an option vs the file path of a VI. 2. Put this ugly hack into a proper queued state machine, ready to add lots of goodies to. 3. Look up a list of custom probes and populate another listbox on the front of Probe Table, and select from there for the desired probe type. 4. Even better: detect the type of wire, decode, and assign correct probe type(s) automatically. 5. All the enhancements from my list above 6. Timestamp the stuff in the probes. 7. Only have the universal probe update its front panel tree if the data changes 8. Logging, configuration save/restore - I know I said it above, but this is really important. :clock: Anybody got a little time to add a few features? :beer: Cheers

Yes a very big happy birthday young man ! Sorry that I am a day late on this BD wish, but I'm slowing down with old age myself Cheers and best wishes for the New Year and your new year :beer: :beer:

Hmm, how far to go back... I have used LabVIEW for (partial list): - Submarine weapons handling system immulation and test (VME based) - Submarine torpedo circuits and modules test (VXI, GPIB, serial) (my first test executive) - Biomedical image processing with ConceptVi (before NI bought and renamed to IMAQ) - RF antenna / radio switching control - Cable Modem box production testing - Data retrieval from a no-longer-supported church membership database - Professional Observatory/Telescope control (SOAR Telescope in Chile) Current Projects: - Hospital Bed Management system. (no hardware, distributed client-server via TCP/IP) - Fruit Inspection and Grading/Sorting - Open Source development (Open Source Test Executive, WorkSpace2003, OpenG tools) I must say, working with LabVIEW I have not been bored ...

The thing I would like to have now is a single, floating palette of open source tools, that opens up and sits in the corner when I start LabVIEW, and which takes all the current OpenG tools under the .\LabVIEW\projects subdir as plugins and gives me quick one button access. It would be even nicer if NI gives us a way to add this to the LabVIEW toolbar area. They have already given us ways to include our tools in various menus (File>>Restart LabVIEW... or Tools>>Workspace>>Workspace 2003...) now if we can get them into the button toolbar. V8?

I think the grid is useful and has its place, but is also in need of a little more refinement before it is fully ready for prime time. Don't get me wrong, I am very glad NI implemented it and don't want to seem ungrateful. I just wish it had a few things "polished up" a bit. Perhaps in LV 8?

In many text based languages you can open up what is commonly referred to as a "Variables Watch Table". You can specify a list of code modules, and which variable in them you want to see. Then you run your program, and in the Table you see the variables you have requested change as the program runs. All in one small convenient place. I like being able to place probes, especially for more complex data like clusters, its much better that a simple text table. Still, I may have lots of probes open, floating over other things I want to watch. I also have to open and close them again *tomorrow* when I continue to debug what I am working on today. What I want (and am working on) is a way to: 1. Specify which VI(s) I am interested in, either in memory or on disk. 2. Very quickly list the wires, sources and data types in each 3. Very quickly select only the ones I want and attach probes 4. Have those probes all report data back to a central display tool/table/tree 5. Be able to save and restore sets of the above so that if I see problem "X" six months from now I can open probe set "Y" in two button clicks and be looking at the data I want, across the whole VI hierarchy. 6. Lastly, log all this data. That would allow for a "golden data set" or "signature" to be used to recertify a module or entire hierarchy later after code mods, either by myself or others. Right now I have code done (based on the "Clean up all wires" code that someone else did) that will let you select the VI off disk, list all the wires, their source, their type descriptor enum type, and attach a new copy of Jim Krings Universal probe. This all works okay, but is incomplete per the above wish list. Next is to make a modified version of the probe that sends the data (timestamped maybe) back to the Probe Table.vi and instead of putting it in a table it puts it in a single Universal Probe type tree, but using the probed VI's names as the first level tree branches. I probably don't have time to do all the above in the near future, so when I get just a little more done I will post it here and also either start a new SourceForge project or include it in the initial utilities code for OSTE. Then others can contribute and incrementally add functionality. Be advised that the initial code is really, really ugly...

Hi Jeff, I was a little rushed before, sorry, and didn't have time to do a better example jpg, etc. Here is a simplified version of the 2 loop QSM using a Command cluster as the queue data type; The cluster that serves as the queue data looks like I hope this shows up in the post okay, if not I will edit. This method of using two loops, one for UI and the other for doing the work is one I have been using in various forms since the early 1990s. Fortunately new feature in LabVIEW make this easier. Initially I used a LV2 USR type global as the "queue" (since we didn't have queues then) and we used the flatten to string functions to make an array of clusters of data names and flattened data. This is so much easier and flexible now using variants. No one was happier than me when Jim Kring, et al, did all the variant tools in the OpenG Toolkit. We don't have polymorphism yet, but variants take us pretty close from a practical standpoint. If you download and install the OpenG Commander off of SourceForge OpenG Commander you will find several of these items or very similar ones inside. The Open Source Test Executive Editor (and other components) will also be based on this type of architecture.

You might want to look at passing variants or arrays of variants. These are some nice tools in the OpenG Toolkit for working with them and converting between clusters, etc. You might want to look at using the event structure to drive a QSM in another loop. This is becoming pretty common nowadays. To make it slightly more flexible don't pass just strings in the queue, but a cluster of the command string and an array of variants that serves as sort of a polymorphic parameter list to the command string. This all takes a little more work, but pays off in a very flexible and extensible architecture.

All of the functions above are part of one version of what is called a Test Executive (TE). Creating configurations, calling drivers, saving data, saving configs and scripts to be reused later. There are two main models of TE: 1. The TE calls "Modules" or discrete Tests, each of which has a PASS/FAIL and may internally call one or dozens of drivers/instruments. This is the model favored by TestStand and the majority of TEs that have been built for the commercial market. 2. The TE calls individual drivers/instruments, returns the data which maybe logged, or evaluated by analysis plugins. This is the model favored by the Open Source Test Executive (OSTE) project some of us are working on. Of course, most TEs can be made to work with either model above, and only favor one type or the other. On the production floor, version 1 seems to predominate, but in the laboratory, during design, development and later debug, version 2 predominates due to the greater need for interactivity with the test and more flexible control of the instruments available.

Thanks Jim, guess I should RTFM more often. Oh, we don't have a manual for scripting yet... still I should have caught that. I'll try to do penance by coding up some of the stuff I was asking for above.

Hi Jimmy-Chen, You should download and install the OpenG Toolkit. It has VIs to do what you want. The Toolkit is at: OpenG Toolkit Get the all_packages 2.3.1 and install. In the meantime, here is one VI from the toolkit that clones a VI, makes a template, opens it returning a reference to the newly cloned template after deleting the disk clone (but leaving the clone in memory). If you put this VI in a case, in a loop connected to your boolean button you will have the start of what you asked for above. Happy New Year Download File:post-45-1104502205.vi

Yes, you can group, but that is a hassle if you are doing a lot of controls and moving stuff hither and yon while trying to lay out a new interface. Hmm, maybe I should submit a bug report.

You can map multiple network drives on your machine, all pointing to your application's subdirectory. You can then create shortcuts to run "MyApp Instance 1", "MyApp Instance 2", etc, etc...

Part of this, as others have pointed out is that when you build the builder pulls in everything from \vi.lib etc, etc.... One way to see this is to do a save with options on your top level VI and include \vi.lib in a custom save. The resulting library will probably be quite a bit bigger than your original. This then gets reduced down by deleting the diagrams, and then build back up with the addition of lvapp,lib and a few other goodies to make an executable.

Interesting. If you combine these two then you would not be using the application builder, so in that case could you argue that you were not bound by the NISLA? Yes, it's a nitpicky way to make the argument, but considering the unbounded breadth of the NISLA clause... On another note, has anyone ever tried to add a VI to an EXE after it was made? We know that you can change *.exe to *.llb and then treat it like any other llb (but you don't have diagrams). Could you then add a VI to that *.llb, change the extension back to *.exe and run and have access to the new VI? And obviously, the next question is, could you exchange an old VI for a new one of the same name? And finally, is there any reason that you could not do this programmatically? Might prove to be an interesting way to push updates out to distributed executables. It would also be a pretty serious security flaw.... I think I'll go experiment a bit.

This all sounds like another nifty small utility begging to be coded. Michael Aivaliotis coded up a utility somewhere on LAVA that alternately colors nested loops and structures using scripting. It seems that once you have the references we could also do something to show the structure selected (by highlighting programmatically), then allow us to do the descriptions above in a batch wise fashion in a table or from a single text control on the utility.

Has anyone else noticed that if you have several items spaced out just the way you want them, then you select them all and hit shift-up|down|left|right that as they move they INDIVIDUALLY snap to the gird, ruining your spacing? Most annoying.

Good point, but this is what LabVIEW Scripting is for. Speaking of that, has anyone managed to set a breakpoint programmatically using scripting? Another good starting utility is one that "Finds" a specified set of wires, either in the VI-of-interest or optionally it's subVIs, and returns a list of them and their references, in a listbox and selecting the wire ref in the listbox connects it to a slightly tweaked version of Jim Krings universal probe tree. One of the things we still don't have (LV 8?) is a decent variable watch window. The two items above would be a small start. Perhaps we could call this type of stuff from Eclipse using ActiveX.

Has anyone had a good experience in optimizing applications that use multiple Firewire (1394) cameras? I have an application that needs to use 4 (or in the future 5) cameras at 15 FPS each, do some simple sizing and color detection on a single computer. Doing the application and the functional architecture is not the hard part. Squeezing the last bit of efficiency out to get the speed up and consistent is the challenge. :headbang: I am thinking of using the multiple buffers in the 1394 driver from NI. I am also wondering about how much to separate things out into different threads. Tips tricks and examples are appreciated.

Or that some of us can't or won't make some tools with it. But it would be nice if we had a little easier time with it. Ah, so many things to code, so little :clock:

Ditto on checking George's toolkit out. The price is trivial for what you get and George has been pretty responsive when I have asked for help on a couple of examples.