Mike Ashe

Great race this year, multiple finishers unlike last year. I am sure a LabVIEW based entry should finish next year, better yet, win.

It makes sense that they would be working on such tools. Now that property panels for front panel controls are actually LabVIEW VIs NI is finding that it has even more LabVIEW VIs to maintaince, retest, etc, and these VIs are not examples, they are integral. If they do not function the users notice. Rumor has it that we have some nifty tools coming down the pike.

Excellent suggestion. I'll see what I can do.

Not impractical at all. I agree that a subVI has to make sense. Note that I said to present the user a table of suggestions, which can be highlighted by selecting different lines. It is then up to the user to actually do the subVI operation, to add or subtract from a highlighted group to define a grouping that can be made into a sensible subVI. I'm not suggesting that we turn this into a mechanical operation (not yet, ... if it could be made sufficiently intelligent ... but that is another kettle of fish) just something that could quickly go through code and give an intelligent operator suggested groupings flagged based on parameters selected. This would be either as an analysis operation, like running the Profile tool, or a continous operation that runs in the background every so often and then scans the open VIs.

I was just cobbling this up for some reporting, when you guys saved me the trouble. Thanks! I'll see if I can't add some stuff and return the favor soon.

We could do this in an analyzer version with scripting now. Another variant would be to count up the total number of nodes or structures or nesting level of structures, etc, etc, and then allow you to set alarm/warning level. PIE in the sky extra credit feature: after analysis, if certain thresholds are exceeded, then do a second analysis and suggest structures or groups of code to be converted into a subVI (do we have a subVI scripting function?) by the user. Present the suggestions in a table and highlight the currently selected group. Now THAT would be useful.

On another note here... How many of you are really finding the Navigation window to be a help in your own work? I'm not talking about refactoring someone else's work, but in initial development or maintenance of your own (or your team's) code?

Well, a hospital application I worked on had over a hundred connections during testing, so I know you shouldn't have a problem with 20. By any chance are you making a connection between each of the modules to all the others? In that case each module will have 19 connections and 20 modules .... 20x19=380 connections. Thats quite a few. Depending on how you designed your software you may be causing LabVIEW to run so slowly (or to be hanging if you have race or dependency conditions) that you lock up or slow down so much it appears you are locked. Have you tried 2 modules, then 3, then 4, etc... In that case, where do you start to have problems?

Nifty little scripting tool. Now if you also create a string constant or control and wire it to the new CASE selector node, it will convert the CASE from ENUM to string mode, save a voila!Download File:post-45-1129054241.vi

Of course, you can also use an event structure that detects when you click on a picture control and use that instead of a boolean. Slightly more work, lots more flexibility. Seems I recall that the LabVIEW GUI book had a nifty example code in it that replicated the functionality of the Outlook sidebar using the picture control and lots of setup options for the "buttons" that were loaded at startup from picture files.

Yeah, several years ago, back when Win98 (or was it 98SE?, memorys getting foggy...) first allowed multiple PCI video cards I did a project demo with 4 cards and 4 monitors. That got me hooked on >1 monitor. The real reason I want a 3 head is not so much Windows or LabVIEW, but video editing. :camera: I want to edit video on 2 monitors and show the output on a TV monitor during rendering, etc. Just a new hobby. Cheers, Mike

It depends on the customer and contract they want. Most of my projects have required the source code, since I usually work with companies that already have LV programmers, OR, part of my services is that I not only developed code but have provided training to their personnel, sometimes formally, sometimes informally. I usually have a clause in the contract explaining that part of what I bring to the project is code snippets, libraries, techniques, etc that I have developed from other projects and that they understand that I will use this in their project to save them time and money, but that they also agree that I will retain the right to reuse general purpose VIs, snippets, techniques that I develop in their project for some of my other future projects. If they balk at that, I do not argue, I simply change the terms to reflect developing everything from scratch for them and often the cost differential makes them see the light of reuse. In all cases, unique code developed for their application to their specifications becomes the right and property of the client. I never try to retain that, although once I did put in a clause that restricted the client from distributing any version of their software without my say so, in return for a large price reduction. They owned and received all source and can use it internally for anything they want, but cannot give or sell it to anyone else. Special case.

This is a great diversion for a few minutes at lunch. I really wish I had kept a scrap library of code like these examples over the years, both diagrams and front panels. However... I remember one that was for a small measurement tester for hard drive heads that was chartreuse green and magenta ... which my boss and I started dissecting as we were evaluating taking the rescue (excuse me, "refactoring") job. We were laughing until we noticed that the senior engineer in the back of the crowd was turning bright red, ... it was his code and we were humiliating him in front of his peers. I vowed then never again to criticize code like that in public unless the person who wrote it was there and had told us to pull no punches. Good grief, I'd hate to have to critique the first couple of VIs/project that I did. Still, the scrap library would be funny for private laughs...

Look in the 34970a driver library, it should have a VI to change the scanning rate.Look in the ..LabVIEW\examples\file\smplfile.llb library. It will give you examples on writing and reading both binary and text data to files and a data acquisition example to show the whole process. Cheers, Mike

Sounds good. Will the testing be laboratory testing for development and offline sampling, or are you also planning to do online testing of each unit on the assembly line? For the former, Dell would be a good choice. For the later, unless the factory floor is exceptionally clean you might want to look into an industrial PC or even a PXI chassis if your pockets are deep enough.

Search on "Probe Table" here on the forum. Gets you most fo the way there, and lets you add custom/generic probles as well.

I was involved in a telescope control project that used Tcl heavily. Mostly we just used Call Library nodes and passed the items back and forth between Tcl/Tk and LabVIEW. It was reasonably fast and very reliable after the kinks were worked out.

I agree, great idea, but I hope you're not holding your breath. Creating a subVI to do the expression parsing and choose from a list of the CASE strings is more likely to get done before christmas.

Hmmm..... Methinks that the near term way to get this is to create a VI that parses an input text path, makes some system calls and/or calls to the registery to get that requested variable, then inserts and converts to path.

Hmmm...... It's not exactly what you want, but I wrote something Probe Table that might get you part of the way there, with modification of course. The Probe Table project was meant to be able to define and save/restore lists of probes, throughout a VI hierarchy and have the data returned to either a series of generic probe windows or a table. To do this it makes a list of wires in a VI it is pointed to and lists the sources. It is not hard to get the endpoints for a given VI and lookup what is at the ends. Perhaps you'd care to take a look and add a little to the alpha code.

What I really want is to be able to put a state diagram in the label which will pop up if you make the label visible and you hover over it with the mouse. We use CASE structures for state machines so often these days that having a simple 2D state-diagram (and/or) table graphic would go a long way to making them more readable.

I have to second this, but what I really want is to be able to put a state diagram in the label which will pop up if you make the label visible and you hover over it with the mouse. We use CASE structures for state machines so often these days that having a simple 2D state-diagram (and/or) table graphic would go a long way to making them more readable.

Yet more toys. I'm backfitting into my chimera.

Good luck on your system. If you don't mind my (our) asking, what type of testing / development are you going to be using the system for? Could you describe a bit and the environment? Might give us a further thought or two that might help.

The really neat thing about Michael's original diagram coloring tool was showing how to traverse a diagram hierarchy. I have modified it to do a couple of specific things before, but keep waiting for a truely generic spider to be released. Did I miss something somewhere? Did PJM ever release the package he mentions above?