AutoMeasure

Thanks for replying, Aristos. As I said, I just purchased and installed the Mindstorms 1.1 CD which includes the latest NXT driver, supposedly compatible with all flavors of Vista. The FAQ page of your link was written prior to Lego's release of Mindstorms 1.1 last year.

The 'Scan for NXTs' function from the NXT Toolkit finds my NXT unit on my Windows XP machine but doesn't find it on my Windows Vista machine. Both machines are Dell, 32 bit. The NXT is connected to a USB port in both cases. On the Vista machine, Windows sees the NXT - it's listed in the Device Manager under Lego Devices. But both Labview and the Mindstorms software do not see it. I tried to fix the problem by buying the Mindstorms software 1.1 upgrade, but that didn't help. Can any of you kind experts offer advice? Thanks very much.

QUOTE (Travis H. @ Apr 7 2008, 09:52 AM) Is Kring's 'fast mass compile tool' that he made for the 8.0.1 upgrade still the best way to go when I need to do a mass compile (and does it work in 8.5.1), or is Labview's built-in mass compile efficient enough now? Thanks.

If I build a Labview application and installer with Labview 8.5 running on Windows XP 32-bit OS, and the installer includes the Run-Time Engine, will it install and run correctly on a Windows Vista 64-bit machine? Thanks.

QUOTE (asd @ May 5 2006, 03:37 AM) Searching on 'dynamic executable' and finding your post got me past a roadblock. Thanks! And I found that besides updating the type-specifier after a typedef changes, you also must prevent yourself from checking on 'disconnect typedefs' in the executable build options.

Thanks! I got a few e-mails from others who also found it useful. I cleaned up the functionality and added some options features, and made an app out of it. You can download the installer from: http://automeasure.com/pulse_resp_1_0.zip (5 MB) or http://automeasure.com/pulse_resp_1_0_lvrt.zip (53 MB, includes LV8.5 run-time)

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) 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 http://www.crystalfontz.com/products/635serial/ 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.

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. 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:

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.

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.

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.

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.