AutoMeasure

I wrote a Pulse Response Examiner VI that I think is useful, and I'd like to share it. Click the Run arrow then slide the R, L, and C sliders up and down and see the effects. Fun for signal-integrity nerds. Uses the complex FFT to do a fast inverse Laplace transform. Requires Labview 8.5 full development system.

Download File:post-3297-1204653831.llb

QUOTE(LV Punk @ Sep 18 2007, 01:47 PM)

...

http://zone.ni.com/devzone/cda/tut/p/id/5860

...

Thanks, LVPunk. That web page is a very good resource! Yah, I remember seeing a demo of the FlexStack at a local LV user group meeting 2 years ago. Nifty product.

Gabi1, CompactRIO is a good suggestion. It's compact enough that it could conceivably fit in a box instrument product. It only has one RS-232 port and no easy way to add more ports unfortunately. But I see that Crystalfontz has a nice general-purpose mini display with integrated keypad that requires only one port. See

and they can integrate other keypad arrangements on larger displays on a custom basis.

I've read the recent NI marketing regarding the Labview Microprocessor SDK and compatibility with products (PowerPC, ARM7, TI C6x, x86, XScale, Coldfire, Blackfin). I'm interested in ramping up my capability to offer services in embedded Labview as the brains of a box instrument product. When I've done it in the past, it involved a single-board Pentium computer running Windows 98SE. I'd very much like to avoid putting the Windows OS in future boxes.

My question is: to use the Labview Microprocessor SDK, do I need to develop the main circuit board, or is there an off-the-shelf general solution available? Such a board would include:

• microprocessor
  
• plentiful memory
  
• plentiful non-volatile memory (flash)
  
• analog input (at least 1 channel)
  
• analog output (at least 1 channel)
  
• digital I/O (at least 8 in, 8 out)
  
• serial lines for keypad interface
  
• serial lines for display interface
  
• USB port with interface driver for Windows
  

Thanks for your help!

One of my old apps did not work correctly after I upgraded from LV 8.2.1 to 8.5. I discovered that an array processing subVI was outputting empty arrays. I had it running as 'subroutine' priority because it runs many times a second and is calculation-intensive. I changed it to 'high' priority and turned on Allow Debugging, and then it worked correctly. Then I saw that checking or unchecking Allow Debugging makes the difference.

I deleted parts of the VI until all that was left were the parts that made the bug occur. The resulting VI is attached. If you run it with Allow Debugging checked, it outputs and graphs a sine wave. If you run it with Allow Debugging unchecked, it outputs an empty array. Funny that the VI needs all those parts and arrangement for the bug to show!

Reported to NI. (will post CAR # later)

After wondering where you can get away with wearing the off-white short sleeved dress shirt with LabVIEW Certified Developer embroidered on it, why not ask your friend/spouse with a sewing machine to make it into a nice souvenir pillow for your office?

Are VIs saved in 8.2.1 fully openable and editable in the 8.2 development system? Thanks.

A large Texas-headquartered company needs an electronics engineer who can develop data acquisition systems and analog signal conditioning circuit boards. It's a full-time position located in Waltham, Mass. If you're interested, contact the recruiter Dan Correia at 860-678-1555 or dan_dkc@sbcglobal.net.

Fifteen years ago NI was explicit in the Labview manuals that we had to include a specific copyright statement in the About menu item in a distributed Labview executable. Is that still the case today? If so, what is the specific statement? And to what degree is it 'required'? Thanks.

Hi. I need to acquire 1 analog signal and 2 digital signals simultaneously at 300 kS/s per signal, with sampling triggered by another digital signal. I'm considering using NI's PCI-6122 simultaneous sampling daq card and acquiring the digital signals using analog channels. But do you know of any better/cheaper alternatives? Are there any products or configurations that can sample analog and digital channels simultaneously? I don't think a two-card approach would be cheaper, and there may be difficulties with programmatic synchronization of data.

Thanks very much.

Arrays as UI elements are generally a bad idea, so the fact that they have scrollbars is not really a bonus.

Well, that's just plain false. I've had many situations where using an array of front panel controls, or clusters of controls, has simplified my diagram so that I only have to wire to a single terminal instead of to twenty. The scrollbars give me more power in this area.

File I/O primitives - A lot of file utility VIs were thrown out with 8.0 and fundamental changes made to the primitives that I think are flawed ...

I agree. The lower-level File I/O functions had evolved over many years to where they worked very well and made sense and were powerful. Granted, newbies have had trouble learning the File I/O and tended to use the higher-level VIs, which I would absolutely never use. But a thorough tutorial and examples would have solved that problem. Should have left the lower-level functions alone.

ADDED 29-DEC-2006: Now that I've used the new file I/O functions in LV8.2 a lot, I think they are generally an improvement. Nice work, NI!

Aristos,

I very much appreciate your post. That's helpful. Anytime you feel inclined to remind us of specific Labview capabilities, I for one will read your post with interest. I had forgotten about the Afterprobe and the array scrollbar. Those are two very useful things.

:thumbup:

The Inovke Node just puts a big ugly text block on your diagram instead of an elegant subVI node. Please don't ask for support for the Invoke Node... I'm not sure I could write code through the tears.

Wow, what a Labview purist you are. I like that! I've been coding Labview almost every day for 15 years and am much of a purist myself, especially in architecture style, use of a deep hierarchy of subVIs, and use of wires and shift registers instead of globals and locals. However, I've never made a pictorial VI icon! They only have tiny text in them over a pastel blue background. I see your point. But, for me, the Invoke Node and Property Node for Labview objects would be convenient options to have, and wouldn't be too ugly. Here, I'll pass you a box of tissues.

This was reported to R&D (# 3QPET23Q) and was fixed in LabVIEW 8.2 ...

I tried it in LV 8.2 and, yes, it's fixed. Great news!!! Thanks. That bug has given me trouble for several years.

Regarding passing-by-reference vs. passing-by-value when wiring data into and out of a subVI: I would like to see that handled by the Labview engine behind the scenes. One great thing about Labview is that it's a very high level language, and the programmer doesn't need to be concerned with a lot of low-level junk, because in many cases we're physicists number one and programmers number two. Greg McKaskle indicated in his posts years ago that in specific past versions of Labview, there was some intelligence regarding passing data to subVIs, and in some cases Labview would NOT make another copy of the data when it's wired into a subVI. So, at least in the past, Labview was able to intelligently decide whether to pass by value (make a new copy) or pass by reference (keep the data just in its one place in memory), based on forking and parallelism and based on whether the data is modified or just read.

The only missed boat I see here is that it would have made sense to have the standard Property Node be able to read and write the cluster elements of the object. I don't think that would be hard for the LV developers to implement.

Wouldn't that violate the whole point of data encapsulation? At that point, you might as well just use a cluster.

No, I think it would be quite appropriate. That's why the Property Node is provided. It allows you to read and write the properties of an object, such as an ActiveX object, with the list of properties being specific to the object's class. The elements of a .lvclass object's control cluster are what we should think of as the object's properties.

By just using a standard cluster, you don't get the benefit of class inheritance with the automatic 'polymorphism' of method VIs when wiring superset clusters. That's a nice benefit.

Also, I'd like to see all the method VIs, and inherited method VIs, accessible with an Invoke Node with the object wired in as the node's reference input. Then it would feel more like I'm using an object rather than a kind of polymorphic VI.

I don't understand Dave and Toby's objections. From what I can figure out, the object wire behaves as a reference, so if you wire it in and out of VIs you are 'passing by reference.' You can create multiple objects of a class by making an array of objects, using the Initialize Array function or a For Loop with a class constant inside that you dragged from the project window. You can pass that array around via a global variable, an uninitialized shift register (LV2-style global), or wired. The object is destroyed when the wire ends, just like any other kind of data wire, so you don't need an explicit destroy function.

Regarding being able to name objects, I don't see the need. This is Labview, not a text language with text variable names. Naming has proven useful with Queues and the other synchronization functions because they're part of your program architecture and you don't use very many at once. And with the naming, you don't need to pass the queue reference around nor worry about who created the queue first. Objects, on the other hand, are data, a completely different animal. You might have thousands of objects of a class existing at once, in which case you don't want to name them, but you do want them in an array.

The only missed boat I see here is that it would have made sense to have the standard Property Node be able to read and write the cluster elements of the object. I don't think that would be hard for the LV developers to implement.

I'm trying out the new OOP in LV 8.2. I see how the inheritance works in practical terms. Say I make Class1 a cluster with elements A and B, and I make Class2 a cluster with elements A, B, and C. Then I make Class2 inherit from Class1. Now I can wire a Class2 object wire to a Class1 'method' VI, and the method VI will work as long as I've used Unbundle/Bundle By Name inside. Essentially there is now a way to wire different clusters to the same subVI node without dealing with polymorphic VIs, and keep things organized with a classes and inheritance hierarchy. This is a very good new feature, I think.

The only way so far I can figure out to change the object's cluster elements is to make a method VI to handle it. Outside the method VI, I can't use an unbundle/bundle on the object wire. Also, I tried wiring it to the reference input of a Property Node. It connects without a broken wire. When I saw that, I thought 'wow' I'd be able to pull down a list of the cluster elements as the object's properties. But the list was empty. So, are method VIs the only way to change the cluster elements?

Now I see in the Labview Help: 'Class cannot be bundled or unbundled because the class private data is empty: You cannot bundle or unbundle any LabVIEW class that has no private data. A LabVIEW class need not include any elements in its private data cluster. But if the class has no private data elements, there is no need to attempt to bundle or unbundle those elements. To correct this error, you can add elements to the class private data or leave the class private data empty and choose an operation other than bundle or unbundle.'

My private data is a non-empty cluster, but I still get a broken wire when trying to bundle/unbundle. Maybe they are talking about only inside a method VI.

Is anyone else having trouble receiving messages from Info-Labview, or does anyone know of anything wrong with it? I haven't received a message in about 5 days, and subscribe requests are bounced back as 'no such domain.' Thanks.

NI support says it'll be a few weeks before an RTE installer will be available... However, building an app installer from an updated system should install the updated RTE, right?

Also, 8.0.1 built apps are supposed to run with the 8.0.0 RTE.

No word on what actually changes in the 8.0.1 RTE.

I just noticed that there's a file in the FTP folder named 'LabVIEW_8.0.1_Runtime_Engine.exe' and dated March 9.

I've adopted the style of not including the RTE in my installers so that the installer ZIP file is a reasonable size for e-mailing or downloading, especially helpful when sending frequent updates. I give the user a link to NI's FTP site to download the RTE.

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