Mike Ashe

You also should expect some differences in fonts. That may sound minor, but when font changes mess up your nice GUIs ... You can import truetype fonts into most of the major linux distributions. If you have much in the way of GUIs, do yourself a favor and bring over the same fonts from Windows and use have them set up on you linux box. As for DLLs, if you have the source code you can make equivalent functions using gcc, etc, then change the call library nodes in labview to use mylibrary.* instead of mylibrary.doo or my library.so and labview will auto switch which library it links to based on the OS environment. You still have a lot of work, but this helps a little.

I've seen much worse, in government LabVIEW code, but I can't repeat it here ... On the NI comments, I'm actually surprised that we haven't seen more of this over the years. Lots of people I know put in temporary comments, and on a large project and deadlines they often do not get cleaned up. My current client (Lockheed) uses color coding on temporary comments, so I have been thinking of making a scripting tool to go searching through a VI hierarchy for all text comments of a certain color(s).

Agreed. And lets not forget lots of good examples VIs as part of the documentation. This is a big project and with a big one like this you fall flat if you don't have all those additional items Rolf mentioned. It would really be sad to invest that kind of time, unpaid, and not have it be used. However, if you selected only a smaller subset of the functionality, then maybe you could deliver a complete package on just the functions you initially support. Remember, most users do not actually use most of IMAQ Vision. If you did a small opensource subset of functions and provided docs and examples showing how to use it for an initial specific industry problem, then at least within that niche you might get some traction. Specific Niche: Maybe successful as open source General Purpose Vision: forget it, way to big to do it unpaid YMMV

There are examples at NI's DevZone: Changing the Mouse Cursor Appearance ... Cheers, :beer:

With LabVIEW 8.x you can do a Find & Replace of the instances of your VI,, then do a reverse F&R later.

I had to laugh at this one. I agree with you, but it reminded me of when the original Star Trek series came out. It brought SciFi to the masses, and in that respect it was fantastic, a completely new paradigm for the "Leave it to Beaver" family. But as SciFi goes it was obsolete on arrival, broke no new ground, just exposed the masses to what was now cliche in the SciFi world, ... old hat. The LabVIEW Project Explorer sort of reminds me of that. I am very glad to have it, but I sort of wish it was more mature and up to speed with explorers in the various text languages. I don't mean that as a criticism of the LabVIEW team, it obviously took a lot of work and I'm sure we'll see additions and improvements with each new version, still. I agree. I was on the "Beta" (read, technical reviewers team) for the recently released book, "LabVIEW for Everyone, 3rd". We didn't make a mint, but we were all paid a small "honorarium" of a few hundred. Nothing compared to the hours that went into doing a good review, but it established a contract and expectations and it paid for a couple of good date nights with my wife, which partially compensated for the time spent. I think, as a first step, NI could adompt this model and pay a few beta testers a few hundred each and get a vastly improved beta program. Confession time: I did that, once, (and only once), but it was at my customer's request, because the new version had features we had to have (working both linux and windows, linux was the reason for using beta software) and we had the benefit of knowing that our project was going to take long enough that we would not be finished before the real version came out. Doing the first couple of deliveries with beta software really moved our development along, but it was painful, really painful. Never again, even if it is requested. (Well, maybe I have to qualify that ... I cannot honestly say that, "they couldn't pay me enough to do it again" )

Hi All, At my current client's lab they are having problems with printing test result graphs to HTML. They typically have two almost identical VIs with graphs. The first one is the operator's GUI, colored, lots of buttons, etc. This displays properly. When it comes time to print the test reports they send both data and graph attributes, such as scales, etc, to a simplified version of the graph VI. This second VI has a white background, all the operator's buttons have been removed, a few new summary tables usually get added, then they tell this VI to print it's front panel to HTML. Been there, done that. The finished HTML reports often show that the second, white, VIs sometimes do not have the correct graph scaling. The data looks correct, but the scales are way off. I have not yet been asked to look at the code, but that is probably coming soon. I have been asked to ask my LabVIEW contacts for general ideas related to this technique. Unfortunately the code is on a secure system in a secure lab, so I cannot post an actual VI from the project. I seem to recall seeing similar problems on a project long ago and the solution(s) involved keeping the printing VIs open and the order that data and attributes were applied, etc. The code is very very legacy and cannot be replaced at this time & budget, I may be asked for help in finding a quick modification solution. Any thoughts, sequence of steps, things to remember to check, etc are appreciated.

I second the TCP/IP recommendation, as well as the Googling for VB code samples. For Example: Google: VB TCP/IP code example You get a big list, one is at Developer Fusion community forums. http://www.developerfusion.co.uk/vb/41/ Check the article: A TCP/IP socket server object for Visual Basic - Overview The author includes code you can cut & paste & modify. Cheers,

Great list Mike, I agree with all of them. I am wondering where the line would be between adding all these in GUI enhancements, or when we start to get into a scripting enhancement. I suppose some of that could be handled by launching an EXE like you mention. I am also wondering if any of these are covered by patents from other companies, like perhaps InstallShield.

I would think that the IQ and R on the icon would suffice, considering the name of the function. I agree the actual terminal names are a bit overdone on the mathematical rigor ... But on my own list of priorities, this one is pretty low.

I like this one too, except when I hate it when I'm trying to quickly put them to a non snap position.

I use the RSS feed feature in Firefox, so it scrolls across the bottom.

You can do this with scripting, but it would be nicer if it was built in.

Glad to know these two are on your radar. Another thing that would be really nice is if the Hierarchy window would optionally show shared libraries, the function called and path. It would be great to be able to save the text of a Find filtering.

I'm kind of fond of the enhancements to the 3D picture control functions. The Save comes in a very close second.

Welcome aboard! What do you do for NI and what areas do you think you will be making nifty contributions in?

This sounds like a Homework Hustle. If it is go elsewhere unless you are willing to do some homework yourself first. That being said, you can often get a lot of help here if you will post a VI(s) showing how you have already tried to solve the problem and asking for specific help.

Well, you certainly *can* do it that way, as crelf's example shows, now as to the question as to whether you *should* ... From a programming standpoint you probably ought to use an array of your different settings, perhaps in a cluster, each cluster having sample period, frequency, etc, unless there is a compelling reason for displaying this information to your operators. If you have fixed time intervals you can set this up with a timed loop or in hardware in your DAQmx settings. Do you have an example of your upper level VI that you could post? We could offer some more specific advice that way.

Well, that last point ( :beer: ) puts an upper bounds on the overkill ... The limit of engineering elegance, as overkill approaches "no :beer: " is ... Q.E.D. On a semi more serious note, I try to look at what the realistic prospects are that the system, once delivered, will then be either reused or extensively modified post delivery. Feature-creep often makes what initially seemed like overkill into near clairvoyant foresight. I've been beaten about the head and shoulders for "overkill" before, only to have my praises sung later when it became apparent that we needed to make large additions and mods and the architecture and hardware were already in place to support that. I've also had the experience where I made it so easy to make mods that I "overkilled" my self out of the follow on work because the client was now able to do it on their own, one of those cases where you're both proud of the result and hitting yourself on the forhead at the same time. That being said, if you are pretty sure that this is a One-Off system, then I'd lean towards just getting it done, as quickly and as cheaply as possible and moving on to the next project. Managers never ever ever complain that you came in too far under budget and schedule and that you should have spent more time, to the point of "overkill". Maybe, but really great programmers have an honest appraisement of their own programming ambition and know how to make trade-offs when business factors outweigh or mitigate engineering elegance. It sounds like you are well aware of and quite willing to make those trade offs. Good luck and good :beer:

Welcome to LabVIEW & LAVA! I'm very glad to hear that the forum(s) help, but not at all surprised. The LabVIEW community, in general, has always been among the more helpful I''ve seen online. When I was starting out the only thing we had was the Info-LabVIEW mailing list and it was a lifesaver at times. Now we have a lot more choice, but LAVA is my favorite. Hope to see some of your contributions in the future, good luck!

The 3rd Ed of "LabVIEW for Everyone" has a lot of material that should take you past the basics, including material to help you study for the CLD exam. I was one of the technical reviewers for the book, and what I saw was good. But after the reveiw period was over Jim Kring added a lot of material before it went to press to make it even better. For the price you can't beat it.

Do you have any examples of using this to implement linked lists yet? That and Data Tree structures would seem to be logical uses for your toolkit. Thanks for posting!

I obtain almost all my queues by name. I also like to be able to keep track of where queues are being used and monitor them, so I often use a couple of wrapper VIs to facilitate housekeeping. If a VI wants a queue, it calls the wrapper, which returns the queue, but also updates tables of queue name and who (which VIs) are using each. It lets me do a simple monitor that shows all the named queues in an application and loading. If you put things in debug and single-step modes and watch the queue list it sometimes helps in debugging a big app that uses a lot of queues. YMMV

Ditto on the start time comments, sweet!! And so are a lot of the other new upgrades, thanks especially for the DLL improvements!

Welcome aboard as well. I'll pass on saying that, or much more, in french, as mine dates back to high school, which was more than a few years ago. Thanks for letting us know a little about you. Now we know who to come to with our optics questions. Wish we had known you back when I was working on the SOAR Telescope control and instruments systems. Salud! :beer: