Michael Aivaliotis

Here's the modified example to address the concerns about unregistering the mouse down if clicked outside the indicator. Download File:post-2-1126073019.llb

Where is your improved solution then? Read my signature...

As I understand it, you want to call the same VI twice. In one case you want the front panel to open and in the other case you do NOT want the front panel to open. Well, there are two ways to do this. One way is to setup the subvi node to behave differently for each call on the diagram. You right-click on the VI and select "sub-vi node setup". This will allow you to define how the VI will behave for that call and only that call of the VI. See images below: The other way is to place a property node inside the sub-vi that controls the behavior. Then you can feed in a control wire that activates the proper behavior. The default behavior would be not to show the panel unless the boolean is set TRUE.

A question on Info-LV prompted me to answer with an example here on the Forums: Here is a VI example (LV7.1) that acomplishes this. You need to register the Mouse Up event dynamically on the indicator that will receive the drop: Download File:post-2-1125948351.vi

This can't be done. The resize object only works for a single object. Grouping them doesn't work... sorry. Well, the instructions mentioned give you some capabilities with zero programming. Of course if you tap into the panel resize event and want to do some programming then you can do whatever you want. Anything is possible in LabVIEW once you use this event.

Why not write it in LabVIEW? Is it a driver or something?

This will not help you. The Eval Formula VI works at run-time allowing formula parsing and evaluation. The Scripting VI indicated above is a development tool that creates a formula node during edit time. Here is a picture of the code so you can create it yourself in 6.1

Oh no. Please don't use global variables of ctrl references. If you absolutely must store the reference somewhere, use a functional global (while loop with shift register). Also, I'm NOT a proponent of writing directly to front panel controls from one VI to another because it makes code unnecessarily obfuscated. When debugging problems, it's hard to know what is coming from where.

This error message is comming from Windows, not LabVIEW. It happens when you double-click a VI to launch it from file explorer. LabVIEW 7.1 takes very long to load (longer than previous versions). This triggers some sort of timeout in Windows because the associated application (LabVIEW) has not launched yet.

I may be wrong, but my understanding is that you can only run a LabVIEW EXE on the platform for which it was built on.

This is a bug. Originaly (pre-LV6i), the formula node used ^ for exponent. I think in LabVIEW 6i they changed the exponent to ** for the formula node. They forgot to change the Eval node. See attached image of the formula node online help for LabVIEW 51 showing the exponent notation used.

No, S-parameters are NOT patented, I was talking about the calibration algorithms. As far as LabVIEW's capabilities, I have yet to find any limitations. Even in the RF\Microwave field. Are you using any automation at the moment? If so, what software are you using? Another thing to look at is NI's add-on RF Software tools for your industry. Perhaps if you explain what specific problem you are trying to solve then I can guide in the right direction.

Well, since you asked...When the person is placed in the box, her head sticks out one end and her feet stick out the other. The magician then spins the box, and when the feet are pointed away from the audience the assistant retracts her real feet and replaces them with a pair of fake feet. The lady is a contortionist, so she folds her legs into the upper part of the box and the magician "saws her in half." Because we saw the lady stick her feet through the holes, we assume they must be her feet the entire time, and the illusion is completely baffling!

Chilly Charly, wow, I had to do a whole multi-media presentation to get you to finaly post something to the Forums. Whew, that was a lot of work, but I finally got Chilly Charly to join us over here at LAVA.

I misunderstood. I thought you were interested in the display aspects of S-par values. This is why the post was moved to the user interface forum. Perhaps another move is necessary. In any case, I assume you've seen the complex palette? PJM always calls me a master of the obvious but I'm always surprised by how many people miss this palette. No, LabVIEW does not have functions to operate on multiport S-parameters. On the other hand, why should it? Are you trying to perform correction on the measurements based on calibration data taken for the multiple ports? To do this you need to apply the formulas required based on your calibration method. Most of these correction formulas are public knowledge and can be easily implemented using basic math primitives. All the primitives (+,-,/,etc) work natively on complex numbers so no special transformation is required. Some calibration methodologies are patented and can only be used after paying royalties to third parties, however those are not always necessary. BTW, are you doing a full 12-term 2 port calibration on the analyzer ports? I assume you are using some sort of switch matrix to automate the calibration and measurement process, right?

Are you talking graph displays like Smith Plots? Look under the Graph palette.

Damn! my secret has been revealed. PJM, you know better than to reveal a magicians secrets. If you're told how the lady is cut in half, it's not so exciting. Yes, well, a few years ago and with lot's of experimentation time on my hands, I discovered the secret to cool panel behaviors. The Window Size settings in the VI properties that allow you to scale all objects as the window resizes is CRAP. Don't ever use that, you will only end up with distorted overlapping front panel controls everytime you resize your panel. The key to the fancy autosizing panel stuff is using the Scale Object with Panel option from the Edit menu. Actually this setting has been there since LV5.1 but few people ever use it. Perhaps because nobody ever explained its usage. You can only use this setting for one object at a time. However this is enough for most situations. The key is to focus attention on one central object that is important to you. In the case of Commander, It's the multicolumn listbox. In your case it may be a text box or even more exciting: a picture control. You will notice that once it's enabled, the object will always size towards the bottom and to the right. This means you need to anchor your panel to the topleft origin. This can be easily done with a property node upon startup. This isn't critical but will make editing easier. Also, make sure to limit the minimum size of your panel. This will give you a stable size from where your panel can grow. When you edit the panel you should save it to this minimum size so all future edits start from this reference. Once this basic setting is defined and you central resizable object is set, you can then go crazy with the surrounding buttons and other objects. The trick to using that is knowing how the scalable oobject affects its surroundings. The objects stretch and move along with the resizable object. Here's a video that shows how 3 buttons re-position themselves as the panel resizes, very annoying eh? Download File:post-2-1125450588.avi You need to group all the buttons together but that is not enough. You must anchor them to the left or to the right of the resizable object by grouping them with a dummy object. This can be done with a decoration as shown in the video below (zipped for size): Download File:post-2-1155790921.avi As you can see, this can now be a powerfull tool once you understand the behavior of the resizable object and how the surrounding objects relate to it. If you want to elaborate on the above technique you can group some objects to the left and some to the right depending on how you want things to move related to your central object. Another good idea is to lock your central resizable object to your panel because this will prevent it from sliding around.

Are you saying that after you do a write to flash, you will lose that data if you do any file IO before the write timer expires? This is odd.

It's interesting how this bug only appears when you delete the TRUE case. If you remove the FALSE case and leave only a TRUE then you get a broken VI which is the expected behavior.

Yes, but have you seen a Labview licence plate?

I don't see a lot of problem with overhead. Are you saving all the data at one time? Perhaps you want to change to saving line by line if using ASCII. The input to you VI can be variant, but the file save format can be something else. If you're saving as an ASCII then you will be limited to the resolution of the precision you picked in your format to string function. I would recommend using exponential notation in addition to high precision. This way you get the highest precision for the units you are using. Also, what is a MATLAB format?

If want to throw another app on your already application drenched computer... Here you go: http://www.google.com/talk/

Oh god, if only I could post the diagram of some code I had to review and evaluate lately. It made me want to take a hammer to my laptop (it's a very nice laptop, btw). The chaotic mess was burned into my retina. I had to watch Britney Spears videos for hours just to wipe away the images from my brain. I thought to myself, God almighty! Is it really possible that there are such bad LV programmers out there? Picture this... Suppose someone asked you to write LV program, and the only way you could pass data around was via the "value" property and using ctrl references. Now you get the picture. So when you say you can easily figure out LV code quicker than C code, think again. You'd be surprised.

Yes, this is good. Just to be blunt about it, I would recommend LabWindows. I've developed my own test executive to handle various RF measurements in LV and it wasn't easy. I only manged it because I had 10 years of LV and RF testing experience under my belt. BTW, RF formulas don't translate well to LV primitives. The nice thing though is that all the LV primitives work on complex numbers. They're polymorphic that way. I even managed to build a full 12-term 2port calibration routine in pure G. In any case, it sounds like C is your forte so stick with it. With LabWindows, you get the nice compatibility with the NI hardware, the many GPIB IVI drivers and the user interface tools which give you graphs and other instrumentation type goodies. Have you considered test-stand? It will help get you started on the test executive which you won't have to build from scratch. The only bad thing about going with LabWindows is we won't get to see you on the forums.

Wow, this is one for the record books. Strange. Try turning video acceleration OFF in your video driver.