AutoMeasure

I think the XControl is more fun and nifty than it is useful. I can think of one scenario where it would be useful. In a company that has many programmers working on many Labview programs of the same class, and one of the programmers is in charge of maintaining a library of useful code pieces. Before LV8, the library would consist of VIs and maybe some customized CTLs. Now with LV8, the library would also contain XCTLs.

Andrew, I don't see a problem on my machine (LV 8.0.1 on Win XP). I can right-click on the XControl's terminal and select Create Reference. I can wire that reference into a subVI. In that subVI, I can wire the reference terminal into an Invoke Node. I can click on that Invoke Node to see a list of methods. My custom XControl methods appear at the bottom of the list under a separator line.

Hi, George. I see what you mean in LV 8.0.1. The way to edit the XControl while leaving all your VIs open is to 1) open the .xctl file. It opens in a Project Explorer type window. A little padlock icon appears at the top, and the window title bar says LOCKED. 2) right-click the .xctl icon and select 'Unlock Library for Editing'. On the VI you had placed the XControl on, the XControl is replaced by a broken-XControl icon. 3) edit any of the XControl's VIs, then save them. 4) right-click the .xctl icon again and select 'Apply Changes to Instances'. The XControl returns to locked mode, and your VI shows the XControl correctly again. 5) close the XControl explorer window.

Oh, bad news. It ain't just booleans! See attached VI using a 1D array of floating point numbers. Fortunately, I don't think I would ever be replacing array elements inside a loop with an array that didn't pass through a shift register first. I will have to keep that in the back of my mind though, not that there's any space left back there. Download File:post-3297-1142949315.vi

If you can get away with having a fixed number of radio buttons in your block of radio buttons, then try the following: Drop a Radio Buttons control on the front panel (that's 'Buttons' plural). Add more radio buttons to the cluster until you have the number you want, and arrange them as you want. Change each button's label to the values you want in your enumerated data type. Then for each radio button, make the label invisible but keep the 'boolean text' visible. One radio button at a time, right-click on the radio button and select Create Property Node. You get a property node for that single button on your diagram, rather than a property node for the whole cluster. On the property node, change it to the property Boolean Text.Text. Now by wiring to this node, you can programmatically change the words next to the radio buttons. If the number of radio buttons in the block is not fixed in your application, note that the Visible and Disabled properties of each individual button are also available programmatically, so you can effectively change the number of buttons in the block.

Wow, that's a weird one. Good find. Trying many different simpler situations to duplicate the problem, I see that you need to have the unusual situation of nested For loops, and the incoming boolean array must come in without shift registers prior to the Replace function. See attached much simpler VI that demonstrates this same problem. Warning: when I ran this twice then attempted a Save As, Labview crashed (LV 8.0.1). Download File:post-3297-1142881770.vi

Ryan King of NI answered my questions: "Actually, the state is saved automatically whenever you save a VI that is using the control. The state is saved with the VI, not in an external file. Saving the state of a control is absolutely necessary for making the control behave like other LabVIEW controls. For example, when you set the properties on a waveform graph, save your VI, close it and re-open it, the properties are still set. Saving the state of an XControl allows it to have the same functionality. "The Convert State For Save ability allows you to modify the state before saving it to disk. Typically this is done to remove any nonpersistent information that you might have stored in the state, such a references or local data storage (for example, in an XControl I'm writing, I have an item in the state to indicate whether the mouse is currently depressed and over the XControl, this information wouldn't be meaningful the next time I load a VI using the XControl, so I may as well remove it from the state before saving to save space in the disk footprint)."

This bug was NOT fixed in Labview 8.0.1.

This bug has been fixed in Labview version 8.0.1.

I see that an 8.0.1 Run-Time installer is available for Mac and Linux, but not for Windows? Looking at the date on the file 'LabVIEW_8.0_Runtime_Engine.exe' in the directory ftp://ftp.ni.com/support/labview/windows/runtime/8.0/ versus in the directory ftp://ftp.ni.com/support/labview/windows/runtime/8.0/8.0.0/ the dates and file sizes are exactly the same. Do I take this to mean that the Windows Run-Time 8.0 works fully with 8.0.1 EXEs, or have they just not updated the FTP site correctly yet? Must be the latter. I see that my lvrt.dll file was updated by the 8.0.1 development system installation.

Yay, LV 8.0.1 came out today! I've verified that the above original demo VI and XControl work correctly as a built EXE in 8.0.1. In the above post I wrote Can anyone shed some wisdom on that subject? Thanks.

I used occurences a lot when they first came out (Labview 4?). At that time I found tricks that would stop them from exhibiting illogical behavior. For example, I found that I needed to put the Wait On Occurence in a loop and in the first call set 'ignore previous'=F with a short timeout, ignore the result, then set 'ignore previous'=T on subsequent calls. And the actual instance of the Wait On Occurence placed on the diagram made a difference. I couldn't use 2 separate Wait On Occurence functions placed in sequence -- I had to place just one instance and use a loop to call it twice. Weird! With Labview 6, before we could generate Events programmatically, I used Notifiers quite a bit. In Labview 6.1, when you read a notifier message using Wait On Notification, the message was automatically removed from the notifier's memory, similarly to how Dequeue Element works. With Labview 7.0, my programs no longer worked right because now I had to call Cancel Notification before every Wait On Notification instead of just a single call to Wait On Notification. When I reported that issue to NI, the answer I got back was to use the new programmatic Events and stop using notifiers. I think this is good advice for half the situations. Events have some unique behavior that doesn't fit every communication need, such as always queueing events even when the subVI isn't executing, and undefined behavior when two different subVI's Event structures are looking for the same event.

Best thing is to have one top-level VI and all the other VIs be subVIs in that top-level VI's hierarchy, then make sure that all the subVIs are in the same folder as the top-level VI or in one or more sub-folders of that folder. Then when you open your top-level VI in Labview, all the VIs will find their subVIs even if the relative paths have changed. There are a lot of considerations here, but to make a long story short: In Labview 7.1, go to Tools > Options, then select Paths from the top pull-down, then select VI Search Path from the pull-down below that one. The defaults are usually more than adequate, as it looks in your top-level VI's folder and all subfolders (\* means all subfolders), then in folders that it's found other VIs in, then in Labview's vi.lib, user.lib, and instr.lib folders. If you're really in a bind, add some absolute paths to this list to get all your VIs to find their subVIs without giving you any pop-ups. Best of luck.

This QBX system was presented and demonstrated by Erik Goethert at the Boston Labview user group meeting yesterday. I love it. A flexible and practical platform. I hope a good variety of DAQ squares get released in this form factor. Now I can branch into developing tiny smart instruments and still use Labview. Mike Ashe, nice meeting you at the Labview meeting. I forgot to mention in our conversation -- thank you for helping people so much on this forum and on Info-Labview!

Does anyone know of a graduate school that offers a D.Eng. (Doctor of Engineering) degree in Virtual Instrumentation, Measurement & Automation, Automated Test Systems, Automated Controls, or a related concentration?

Everyone's so creative around here! I'm embarrassed that the answer is not more esoteric. The Answer to the brain teaser for Labview nerds "What's the ironic little significance of my avatar?" is . . . The code snippet takes up the same size and shape of block diagram area as Mean.vi from Labview's mathematics library. The irony is that Mean.vi is provided to us like it's a good thing, for it takes twice the time to execute as the code snippet. Thank you all very much for playing and for your efforts!

Good guesses. OK, time for hints. HINTS: 1) The answer has nothing to do with me or my name, just with Labview. 2) A key word is "ironic." Not coincidence, nor play-on-words, but irony. 3) The shape is significant.

Thanks, guys. But you're cold! The answer has nothing to do with me but with Labview.

What's the ironic little significance of my avatar (the snippet of G code in the square to the left)?

That's bad. I really like that feature. I just posted an XControl in the LV8 forum that uses drag-n-drop listboxes. If it's not going to work in a built app, I can't use it!

Attached is a demo of an XControl I constructed that allows the user to edit an ordered list of items using drag 'n drop. This is something that would have come in handy in several old projects. Source code included. It's great how an XControl behaves like a typical control including local variable, its own custom properties and methods, and value-change event. What do you think of XControls? I think it's a neat, compact way to package what I could have done with a nice library of subVIs. It will occasionally be useful, I think. I would have liked to see better documentation. How and why the 'state' of the XControl is saved is not clear to me, and this involves the Init ability/VI (with its backward-compatibility bit of code) and the Convert State For Save ability/VI. I notice that the description of my method VI appears as the context help for that method in an Invoke Node, which is great for making the XControl useable for programmers. But I can't figure out how to put text in the context help for properties in a Property Node. Thanks for reading! NOTE: In Labview version 8.0, this XControl does not work in a built EXE. Enjoy it in the full development environment only -- until the patch version comes out! Download File:post-3297-1133036946.zip

Sergey Liberman of Solidus Integration (my local competitor!) has been working a lot on this sort of thing for the past year or so. Please visit: http://www.solidusintegration.com/si_lvrttargets.htm

A couple notes just in case: By calling your custom dialog VI in parallel with your other code, as opposed to in series (sequence structure or wired), your other code can continue to execute and update displays while your dialog is popped up and showing. Also note that if your dialog waits using a polling loop, then you must place a Wait in the loop to allow your other code to share the CPU time. But better to use a non-hogging architecture in your dialog such as an Event structure (in which you could wire your dialog-go-away time to the structure's Timeout terminal (hourglass) and possibly not need a loop).

Hi. Blocks the user interface thread? Not sure what you mean. But anyway if you call the One Button or Two Button Dialog in parallel with the rest of your Labview code, then your code should continue to execute and update visible VI panels. You can make a little pop-up manager with a parallel while loop, and use local or global variables, events, or synchronization functions to command the pop-ups from your main code. Were you asking how to make your own custom pop-up? You know that one VI can call another VI like a subroutine, with inputs and outputs, right? Just make a separate subVI whose panel is just what you want the user to see. Put the controls and indicators you don't want seen, particularly those wired to the connector pane, out of view off to the side. Configure this subVI to "Show front panel when called" and "Close afterwards if originally closed." You can also configure centering on the screen, displaying menu bar and scroll bars, etc. Have fun experimenting. Good luck.

Hi, Thomas. Thanks for trying out the bug. I made another VI that does not use the Unflatten and posted it as a new topic.