Michael Aivaliotis

Yes, for example, if only 10 elements are visible at a time then you can overlay 10 transparent booleans overtop each element of the array. Using logic you can enable\disable each boolean for the coresponding element of the array that needs handling.

Are you talking about the splash screen for the run-time engine INSTALLER? As far as I know there is no way to avoid this. The only other option would be to create your own install routine using other installers such as Installshield etc.

There are some examples and documentation here: OpenGOOP info I've used OpenGOOP in some of my projects and it works well. I suggest you post your question or concern here: OpenG "Pkg - Others" Forum Do you have a specific question or problem? If you post here I can try and give you a an answer.

I guess there is a place for a new type of constant however I don't feel that it is really such a big issue. Personally I prefer to use a sub-VI for placing constants. I don't understand why you need to have one VI per constant. Most of the time constants belong in groups. For example you would have DAQ settings or Instrument settings. You would then place all constants on the diagram of a subVI. Of course you would put them inside of a cluster then output that cluster to a terminal of the VI. A simple unbundle will give you what you need. If you don't like clusters and unbundle then use multiple output terminals instead. Why is this so hard? There is also a hidden potential here that is not evident at first but I will explain. If you created a VI for each functional group of constants you could easily convert them (down the road) from static hard coded data objects into flexible variables that can be abstracted and manipulated externally, even as a built executable. Each constant VI can be edited and replaced with a read\write from ini file. This allows you to implement code

Can you include a screencapture of the graph? That would help a lot in figuring this out.

Actually, this was impressive at the time and an excellent solution to the problem, however this is now built-in to LabVIEW. This is using a picture control.

Sorry, what kind of instrument are you trying to communicate with?

Here is a good link to an NI article on serial communications: Serial Communication Starting Point

We use a brand new copy of LabVIEW 7.1 Professional development suite

Here's the link to the National Instruments Certification Program Tasks and Objectives: Tasks and Objectives If you can handle the above material you should be ok. By the way, most or all of the material is covered in NI Basics 1 and 2 courses. Perhaps the advanced course as well. All of this is specified on the NI website. NI does a good job of clarifying what material is covered. On another note, being self-taught is nothing to be worried about. Most of us learn more on the job and by diving into real projects than the NI support engineers themselves. We're the ones that push LabVIEW to the max and use it in ways that it was not even designed for. The problem with the test may be that you may not know the proper terminology that's used or required by NI in their questioning.

The question then becomes, how do you pick the review board?

Yes, Alliance members get support now however it can only be registered in one name. So be sure to transfer ownership of the support capability to the engineer who is most involved with technical issues in your company. In our case it was setup to our main sales person which wasn't much help.

I believe this is what jpdrolet had in mind:

How did you even get 256 colours? As far as I know, LabVIEW wants 16 colours max for built executables.

Are you sure you did this correctly? Even if the block diagram is password protected, LabVIEW should still be able to load the VI and recompile it for the new version. I think it's more likely that the 3 VI's are calling other subVI's that you didn't bring along to the new machine. It could even be a DLL call that cannot be made because the DLL's are missing. Who knows? Create and save new blank (Untitled) VI in 6i and plop the 3 VI's on the diagram of this new VI. Now from the menu select File>>Save With Options. Make sure you select Save entire hierarchy in the dialog box. Also select include vi.lib files and external subroutines. Save to a different directory and then try opening this Untitled.vi in 7.0

When you say vertical string, do you mean stacked or clockwise? You won't be able to use the caption of the control if you want to put it in an array. The problem is that if you write text to the caption, all elements in the array will use the same text. Only the value of an array elelment can be different. If you want stacked behaviour then this is easily obtained by placing one character per line in the string box.

Yes, I too use Install shield Express. I find it very powerful for the price. In using merge modules however, my complaint is that there is absolutely no documentation regarding this capability. To make thing worse, using the merge modules the way we do is unsupported by NI. I'm sure if you report a bug, it will be put to the bottom of the priority list. I really don't know why this is the case. Perhaps someone at Ni can enlighten us. I know there are many of us out there that want to use the merge modules and have knowledge about how to do this. Using an external installer allows us to customize how drivers are installed and selectively include what we need. One thing to watch out for in using merge modules is that the refcount on the shared dlls inside the merge module is not incremented. What does this mean? The following scenario: If you install 2 separate LabVIEW applications on the same computer, they will both install the LV run-time engine from the merge module. This is fine however if you uninstall one of the applications, it removes the LV-runtime engine totally. This will cause the other application to be crippled.

Well I don't have extensive experience with DAQmx however I have used it enough to be dangerous. I have quite a bit of working knowledge using the old stuff. One thing I detested in the old method was that it was always a lot more work to get an efficiently running DAQ system. The Easy IO stuff was way too slow. Here is where DAQmx excels I believe. It is smart enough to know when you are using the drivers in an inefficient way. For example, acquire 1 point 100 times should be as efficient as acquire 100 points in one shot. One thing I haven

Well, for starters, why would you buy an Agilent device to use with LabVIEW? Are you trying to make your life more difficult? If I were you, I would try my best to contact your supplier and ask for a refund. Even if they charge you a restocking fee, it is worth it. NI sells a USB GPIB controller called: NI GPIB-USB-B which works well with LabVIEW. In any case, there is an application note at NI's site that describes how to use an Agilent GPIB plug-in Board with LabVIEW. Now I realize that you are using USB however there may be something there that may give you some hints of things to try out: How Can I Use an HPIB Board with LabVIEW or CVI? To summerise the content goes like this: 1. If you have HP-VISA already installed then you must uninstall it first. 2. Install HP-SICL. This was included with your Agilent\HP controller. 3. Remember to configure the Agilent\HP card using the Agilent/HP I/O Config utility. 4. Install the NI-VISA driver. 5. After you have installed the NI-VISA run-time library, go into the Measurement & Automation Explorer, select "Tools>>NI-VISA>>VISA Options", choose the Passports tab, and enable the NiVisaTulip.dll Passport. 6. NI-VISA will automatically find and access any GPIB or VXI devices. However, NI-VISA will not configure the Agilent/HP hardware; you must still do that with the Agilent/HP I/O Config utility. You should now be able to use LabVIEW to communicate via your Agilent\HP GPIB controller. If you have both National Instruments and Agilent/HP controllers in the same system, you must configure the cards at different system addresses, such as GPIB0 and GPIB1. If both vendors try to use the same interface address, NI-VISA will report an error from VISA Find Resources.

With the release of LV7.1 we see something added to the Application builder that was previously only settable via an ini setting. Previously (LV7.0), the workaround to the bug listed in this posting was to add the following to your LabVIEW.ini file: BldApp.RemovePolyVIsandTypedefs=False

This was submitted to NI and was confirmed as being a new bug. This means it did not get dicovered early enough to include a fix into 7.1. In other words, this bug exists in LV7.1.

So I guess your wish is that NI improve the toolkit installation procedure? I find the Report Generation for MS Office to be a real pain. The problem becomes worse when you have to support a customer that has a different version of MSOffice. How do you handle this? Also, why would you uninstall the old version if you need to support it in older LV versions like 6.1 etc.? I have some experience with building installshield setup files and know for a fact that it is possible to handle these upgrade issues simply by modifying the installation script. You can perform checks to see what is already installed and place things where they belong. If NI doesn't want to do this then they can release a new version of the toolkit for each new version of LV. This way you would know exactly what to install where. I also wouldn't mind to have NI require me to run the installation multiple times for each LV version. That would be the most straight forward approach and the easiest to implement on their part.

Actually, this is already available however it has only been released for the LabVIEW PDA module and the LabVIEW FPGA module. I'm not sure why it has not been released to the windows platform. I have attached a VI with this structure. You should only use it if you are running PDA or FPGA module since it is NOT a supported feature for other platforms. Use at your own risk! Download File:post-14-1086500298.vi

I was discussing this issue with a colleague of mine lately and I was wondering what the consensus was out there on this issue. When you develop an application for a customer, do you give them the source code or do you only distribute executables?

As an employer myself, I have to admit that I have a difficult time evaluating potential candidates for programming positions. Any LabVIEW test that I might put together would only cover a few areas of interest. If you look at the Tasks and Objectives of the Certified LabVIEW Developer exam, you will see that many key areas of LabVIEW knowledge are tested. The reality is however that I cannot reasonably say that I will ONLY accept LabVIEW Certified Developers (CLD's). This excludes a huge population of people that are just as qualified. I can only say that if I was to sort through a pile of candidates with equal skill levels, all the CLD's would be in my short list.