Mike Ashe

Thanks, nice tool. I'm trying to cross pollenate it with some other scripting odds and ends I have. So many goodies, so little time.

Followup. I found out from NI that MAX does not allow programmatic access/setting of the driver/camera designation and probably will not for the next version either. They are making a couple of improvements that will be beneficial in the next version, but this problem likely won't be solved, so if you try to connect using anything other than a single cable (ie, extension cables or through a hub) you run the risk of losing the MAX setup/names of cameras each time you power down the PC.

Hmmm, I would have to second the Dell vote, not that I want to endorse a particular mfr, but they seem to have good bang for the buck and their systems are easy to work on. I also personnally prefer using 2 monitors, so I bought an older Matrox G450 dualhead 32 meg video card on ebay and a couple of HP A4033A 20 inch monitors. Very few bucks and it gives me a lot of real estate to work diagrams on. I also bumped the RAM memory up to 1 gig, again, cheap these days. NOTE: I do not, as a rule, write huge diagrams, rather, I use the space to have more diagrams and front panels open. I still try to keep each diagram to 1024x768 and only scroll horizontally no more than 2x the size visible. This is good code management. Bigger diagrams than that mean I should probably break it into more subVIs. (This is a strong guideline, not a rule).

FLASH !! This headline just in from Hollywood Variety: long lost clip of J. Belushi's unsuccessful screen test for the part of Luke Skywalker found in basement of Skywalker Ranch... (or was he testing for a part in Highlander ...?) Thanks for the link, this was a hoot.

Okay, this is not an elegant solution, but rather quick & dirty, but it works for this type of problem in general, not just databases. When I have had to remake files in the past, including databases, I created a blank version of the file, in your cases a blank of your MS Access file. I usually set up the tables, etc as well. Then I make a LabVIEW VI to read in the file *AS BINARY* just using the LabVIEW read VIs, not using database VIs. I then have this VI put the file into a control, and I save the control data as default. Then add a function to rewrite the file later, again as binary. That way my LabVIEW app has the database template built inside. Simple, works. Later, I tended to make this template VI dynamically loadable, so that if I wanted I could load a different version of it, from outside the application, so that after delivery, if I wanted to update the database, etc, I could, while still holding the original inside as a factory default.

There is no one best system configuration since *best* is probably dictated more by what you are using the sytem for than for LabVIEW itself. Is it used on a factory floor for optically grading fruit? In a dentists office for imaging of teeth? In a clean control room for operating a professional telescope observatory? A hospital IT room for running bed management,.....? I have seen/been involved in all the above and every one needed a different PC System and setup. If you just mean a system to write LabVIEW code on, which will be run somewhere else, then the answer is probably whatever system is easy/available for you. You probaby do not need the latest and greatest. When upgrading systems I usually go for 1-2 generations behind the latest bleeding-edge system. That seems to usually be the "knee" in the price-performance curve. YMMV

I believe there is a user interface example floating around called Draw.llb that was essentially an etch-a-sketch type tool using the picture control. It allowed the user to draw wires, ellipses, boxes, etc, fill them in and so on. (Actually I have seen more than one of these). Draw.llb even had a rudimentary UNDO. If you took this as a starting point and added a database array of your widgets, rules and VIs for managing wiring, connectivity, etc and a *LOT* of mouse finger grease, you would probably end up with something approaching what your ask for above. Not impossible, but a fair amount of work.

I am running a LabVIEW optical inspection application under WinXP. Each iteration through the processing loop is triggered by a IMAQ-1394 (Firewire) camera occurence. We then grab images, analyze ROIs, select lookup table values and switch digital outputs (PCI-DIO-96). I have a time budget of about 70 milliseconds/iteration to keep up. In reality I am using about 15 mS/iteration as shown by a time chart. The time line is pretty stable and flat. Every so often, (a few seconds, etc) for no apparant reason the time will spike up to some value between 25-150 mS. I am assuming that the WinXP OS is doing something, or some other application, etc. The installation is on a new Dell machine, the default installation. What do you guru's turn off in XP to make your apps as smooth as possible and how do you disable/delete said items? Thanks in advance for any wisdom anyone has to offer.

I use the dual monitors, both the same size, 20.5 inches. The are HP A4033's which are actually made by Sony for HP. Trinitron tubes, multisync. I bought a pallete of them a few years back on ebaY. Yes, they are bulky, but the price was right and they have been extremely reliable. You can pick them up on ebaY now for $50.00 - $100.00 I use a Matrox G450 or 550 card (depends on which machine, I have two set up like this :-) ) 32 meg dual head. To get the screen resolutions right I made up a flat black background with rectangles marked off in white from the upper left for all the regular screen sizes, 640x480, 800x600, 1024x768, 1280x1024. That was when I was using 1600x1200. Now I've chopped off the high and low ends and just eyeball it. I have been thinking of checking out the Matrox card that does three monitors, you can never have enough real estate ...

Hmm, another engineer I am working with just discovered a little more about the problem. We have been trying to use a Firewire Extension cable from SewellDirect.com since the computer needs to be further that 4.5 meters (14.7 feet) from the cameras. When we connect with just a regular 4.5 meter Firewire cable we do not get the problem on restart of Windows. But with the extension cable we do. It seems that the extension cable has some type of repeater chip at the end to boost up the signal so you can go longer than the 4.5 meters per the Firewire spec. This works okay, we are getting the images through the longer cable length, but on restart we have to reassign the NI-1394 drivers. We have some powered hubs coming in Fedex. I am wondering if they will show the same problems, showing up as a generic on startup. I guess the real issue is, is there a way to programmatically, through NI-MAX or LabVIEW make the devices use the NI-1394 driver.

I normally use two monitors, both at 1280x1024 so I get 2560x1024. I used to use 2x1600x1200 but after 40+ the eyes just are not what they used to be. Still, I don't use that much monitor realestate to have big diagrams, rather I use it to have more VIs and diagrams open at the same time, while still trying to stick to my 1024x768 guideline. This keeps my code editable on a laptop with 1024x768.

In the OpenG toolkit there is a VI that you can point to any other VI and it will make a copy of your VI, as a template, then open a copy of the template, (get it into memory) then delete the physical copy it just made. Palettes>>Application Control>>OpenG Application Control>>Open VI Clone Reference. Not only is it a nifty VI, it is a good, compact example of templates, etc. (But you should still study the NI Week 2004 presentation referenced above).

In general, I try to keep to 1024x768 size per diagram. If I have to go larger I try to scroll only horizontally and then limit it to about 2 screens in width, so 2048x768. These are not hard and fast, but when I have to go outside this range, my "make some subVIs" nerve starts to twitch a lot.

I seem to be losing the IMAQ driver for 1394 (Firewire) B&W cameras on Windows restart. The cameras are Basler 601f black & whites. We are using the NI-IMAQ1394 driver and are doing our acquisitions using an external trigger from a conveyor, waiting on 1394 occurances to get our image(s). So far, so good. We had the cameras (4) setup in NI-MAX as: cam0 ... cam3. When we shut down Windows and restarted we found that the cameras were "gone" and in both NI-MAX and Windows Hardware Manager the cameras were listed as a generic consumer firewire camera. When we tried to run the LabVIEW application software we got errors which we traced to the above problem. We can get the cameras back on line by going into MAX, selecting each camera and from the popup menu select to use the NI IMAQ-1394 driver again. While this works as a work-around we obviously don't want the customer to have to go through this each time they shutdown and restart the machine. Hopefully I'm doing something simple, wrong, stupid, etc. I am troubleshooting from the customer's site. Has anyone else seen this behavior and if so do you have a clean programmatic fix? I will check back here a couple of times a day, but just in case the LAVA site is down or inaccessible from here please CC directly to me at: michael.ashe@imaginatics.net Thanks in advance everyone.

Very interesting. This might provide a way of "watermarking" a VI, or creating an indelible trademark. It also creates an effective way to place a timelimit on how long an application runs, even if you provide source code. Put a typedef cluster constant on the diagram and wire or not, and let the software run. After you exceed the timelimit have the application delete the typedef VI. This will break your application the next time it is restarted, with no way to fix unless the end user gets another copy of the typedef.

Although Child Windows are nice for some applications, and you can use the technique Michael Aivaliotis posted, might I suggest that you make your general interface like a Toolbar/Sidebar and then use VIServer and instantiations of GUI templates for your individual documents? This gives you a more flexible interface at the cost of a little more UI management code. It also has the advantage of being 100% G code and is therefore platform independent

Yup. The original patents are pretty thick reading. Bring and Instant Freeze-Dried lawyer with you to help decypher the legal-speak portions of the patents. The real crux of the patents was the graphical implementation of dataflow, not dataflow itself. NI never claimed to have invented dataflow. Before LabVIEW and the Java based stuff, there was SmallTalk and a few other dataflow languages. The concepts have been around for a while. Not sure where the original papers are published on dataflow concepts. Graphics are certainly the best representation and Jeff Kodosky and the others at NI seem to be first at graphical While Loops, CASE structures, FOR Loops, etc, as well as the hierarchical subVI representation. Most of that stuff got covered in the first patents. Which are due to expire very soon. The basics of NI's implementation of G have changed very little over the last 17 years. I am wondering if they will remain the same once the patents expire and work commences on ANSI/IEEE Standard G ? In the meantime, Softwire's case is pretty interesting, especially in light of all the Open Source work going on in and out of LabVIEW. I hope they decide to release the source. Pretty cool stuff coming from open source these days and pretty competitive too. A great example being Firefox which I use all the time now.

Hmm, I should have provided more detials. I also have learned a little more. Your (my) computer can have several IP connections at the same time. Under Windows in Control Panel >> Network Connections. You can see your connections here. You can also go to a command prompt and run IPCONFIG which will give you a list of the current connections. Normally I only have one IP address. But if I then open a VPN client to another network, the VPN Client adds a connection to the list. It appears that new connection IPs are added to the *TOP* of the list/stack and become the default until closed or another new IP supercedes it. When you start up LabVIEW, it takes the top of the list as it's default IP, but, that can be the wrong one depending on what software you have running at the time. By opening your Network Connections dialog and going to the Advanced menu >> Advanced Settings submenu you can get to a dialog with an Adapters & Bindings tab and you can reorder the Adapters & Binders. This is effective if you have multple cards, etc, but IT people at some of my clients are frowning even as I type this. The real solution is to have you specify an IP in LabVIEW for your server or client side and have LabVIEW connect to that and only that IP/mask or else return an error which should include the default IP. Guess I should post this to the bugs section...

Very nice. I noticed that it displays data backwards from how it is listed in the file. You might want to reverse the listing and sub the new version in here. Again, great little tool. :worship:

Sadly, I have to agree on the incompletemess of the code. Perhaps I should have put in a disclaimer on the Applicatin Note reference. Thanks for holding my feet to the fire on that. But I must respectfully disagree on the type-agnostic code and the use-cases. There are lots of use cases, there just has not be a good way to do them in LabVIEW until recently. The OpenG toolkit and variant data tools in it have changed that. There are a lot of tools/VIs there that make writting type-agnostic code possible now. Notice I did not say easy, not yet. The OpenG VIs need some additions (and I'm happy to say that I know that work is getting ready to rev up on that again ). Jim Kring also did some stuff for autocreation of SQL INSERTs from a cluster. The Universal Probe I mentioned above has a parser that does a pretty good job, but still needs a little work. The parsers in the Variant-Config-File example VIs are better, almost bulletproof (not quite, but close, and they'll be perfect in another couple months as we are going to make heavy use of them on an application) Yes, but variants also include that type data, and if you are careful with insuring your variants have a good naming convention and use a good parser you can get pretty generic code. Not perfect yet, but improving and will get much more complete this year. :thumbup:

I am rather ignorant of JAVA at this time, but the OpenGOOP implementation does make instrument driver implementation easier, and the methods can be used to separate out the different functions of the same instrument/driver as you need.

Very nice!! Thank you for contributing this Derek! Another good example of scripting. You also mentioned that you had been able to create a control VI and controls now. Any chance that you could upload an example of that? It would really help out with another utility I am working (actually trying to find time to work on...) on that makes DLL wrapper VIs. The code example you gave above is already helping with that.

And we should remember that this NISLA clause is only in LV 7.0 and 7.1, not 6.1 which is another reason to do more and more of our development back in version 6.1

Yes in deed it does, for me at least. I'm on DSL, so my display time was already good, but this speed increase is very noticeable. The config is also great. Maybe we can find places to immulate this...

The Type Descriptor is explained in NI's application note AN-154c.pdf, you can get a copy at: LabVIEW Data Storage I agree that recursively parsing the TD array/data is hard, (the first time) but it has already been done and the code is available for free in the examples I referenced before, therefore it is no longer hard and is less a matter of new engineering than one of scholarship. The OpenG Toolkit also has lots of tools/VIs for doing this type of thing and I seem to recall a couple of LabVIEW Technical Resource (LTR) articles about these techniques. This wheel has been invented. Now someone needs to give it whitewalls, raised lettering and some decent hubcaps :thumbup: