AutoMeasure

Does anyone know how to get and be able to use the "Database Variant To Data" XNode without installing the Database Connectivity toolkit? I'm not using databases in my project, but that function is a really handy, compact way of converting an array of variants into a cluster. Or is there another way that's equally neat and simple? Thanks. -Joe

For my projects, a big plus of the action engine design is data handling and speed of execution/performance. In many applications, it makes sense to have the action engine acquire and buffer continuous, large data sets and keep the data inside the action engine in shift registers rather than passing it out. Then you call the action engine to do operations on that data within itself such as averaging, decimation, peak detection, statistical analysis, graphing, saving to file. As you said, a downside to the action engine is when you have a lot of different actions with each one requiring a different set of inputs and outputs. Then you have to write in the VI description which inputs apply to which actions, and that's a little messy. LVOOP methods are neater because there is a different subVI for each action showing only the inputs and outputs that apply to that action.

Well, something did malfunction as I illustrated in my earlier posts. At first, I was able to pass the element named nPixels from one dynamically-dispatched child method to another method using bundle/unbundle. This must have accessed the child's cluster element of that name, and as you say if the name overlaps a parent element, it doesn't matter. But then when I made the parent's nPixels element accessible via Property node, the child's bundle/unbundle ceased to function correctly. But as mentioned, when I attempted to duplicate this behavior in a new simpler project (with the same erroneous duplication of parent/child cluster elements) I could not recreate the problem. Anyway, I'll avoid duplicating parent's element names in children clusters from here on.

Wow, thank you for posting! I screwed up. I mistakenly thought that a child class's control cluster should have all of its parent class's elements plus its own specific elements. Also, it's interesting to learn that a parent's elements cannot be accessed by a child method using bundle/unbundle. I will edit the code and hopefully heal all without corrupting things. The only thing I did right was making the property accessor VIs NOT dynamic dispatch even though the method VIs are all dynamic dispatch. Request: a broken arrow, warning, or run-time error if a child class cluster contains an element of the same name as an element in the parent class.

I think that my problems may have started after trying to change the folder location of my class hierarchy of VIs and supporting files. The project displayed conflicts. I couldn't figure out how to resolve the conflicts, so I was forced to put everything back in its orginal folder location on my machine. It's a dangerous situation that we can't smoothly relocate nor rename OOP VIs, files, and folders. NI needs to test and debug all common code maintenance maneuvers with OOP. I could probably fix my problems by reconstructing all my classes and their VIs, but that is a huge amount of work for what I've built. For this project, it looks like I'll have to stick with only accessing object elements using the Property Node.

I'm not able to replicate the issue by making a smaller set of VIs. In new VIs and classes I put together using the same technique, all the Bundles and Unbundles work correctly. My project that has the bugs is large and connects to in-house-made external DLLs and .NET assemblies, so there is a lot to install in order to not have a broken arrow and I can't really send it outside. Mass compiling did not help. I continued to run into bugs until I made all elements of the class cluster accessible via Property Node and then replaced ALL Bundles and Unbundles with Property Node writes and reads in all member method VIs. After doing that, the bugs were cured. If I send to NI the .lvclass file alone, can NI analyze it for corruptions? Thanks. -Joe

Yah, that can be a gotcha in Labview. That's not my problem, though. The problem happened in several subVIs that worked correctly at first. Then, without modifying those subVIs, I made some properties accessible to the outside world via Property Node, and at that point the application and those subVIs no longer worked correctly as described in the above postings. Thanks. -Joe

...I just made a simpler project (in LV 2013 f2) that duplicates this same sequence of actions, and I did not get the incorrect behavior. So either it was a temporary corruption or it was fixed in 2013. Thanks. -Joe

Good question, thanks. The method VIs are all dynamic-dispatch-override VIs. Each child class object contains all the elements of the parent class object plus some elements specific to the child. nPixels is common to all the child classes so is in the parent class, too. Should I have kept out from the child class cluster all the elements of the parent class cluster? I don't think LVOOP works that way, does it? Earlier in the program flow, the parent object wire is cast to the required child object using 'Get LV Class Default Value.vi' and 'To More Specific Class' function. Thanks. -Joe

Thanks for the help. These pictures illustrate the problem. It's a large Labview program with hundreds of subVIs. It worked correctly. Inside a class member method VI, it updated a class object element 'nPixels' using a bundle by name: Later, I made nPixels accessible via Property Node to VIs outside of the class. Then, the program no longer worked correctly. I discovered that subVIs that wrote to specific object elements using bundle-by-name did not have the new value preserved in the calling VI. If I probe the object wire coming out from the bundle-by-name, it has the new value correctly. But if, on the calling VI's diagram, I probe the object wire coming out of the subVI, it does NOT have the new value. The workaround was to replace the bundle-by-name with a Property Node write: and then everything worked correctly again. -Joe

I wrote a Labview program that uses LVOOP that worked correctly. I then modified a class to allow access to one of the object control elements via a property node outside of a member method VI. As a result, a member method VI that writes to that element using named-bundle ceased to function correctly. No broken arrow nor broken wire, but the object output of the VI did not include the new value in that cluster element. I cured the problem by writing to the element using a property node instead of named-bundle. But I shouldn't have had to do that because I should be able to update elements using cluster functions if on the diagram of a member method VI, right? Do you think this a Labview bug, or is LVOOP supposed to work this way? LV 2012 SP1 f5 on Windows 7 32-bit. Thanks. -Joe

Has anyone with Developer Suite SSP received DVDs yet with Labview 2012 SP1 on it? Thanks. --Joe

Has anyone heard when Labview 2012 SP1 will be released and what new things will be in it? I think that the SP1 releases have occurred in February for the last 2 or 3 years. Thanks. --Joe

I'm looking for a LabVIEW expert to join the Test Engineering group at Aegis Lightwave and help us develop state of the art LabVIEW-based test stations and automate processes and R&D. If interested, please e-mail resume and cover letter to jobs@aegislightwave.com. --Joe Czapski, Test Engineering Manager, Aegis Lightwave, Woburn, Mass. Job Title: Senior Test Engineer Company Overview Aegis Lightwave is a technology growth company with revolutionary products, rapidly growing revenue serving an international base of customers and very solid financials. Aegis’s world-class team of employees develop and manufacture products for video, data communications, telecommunications and other fast growing markets. Aegis is the first company to deliver low-cost wavelength monitoring products that are enabling service providers to cost effectively deploy high-bandwidth video services such as High Definition TV, IPTV, and Video-on-Demand. The company is the first in the industry to commercialize tunable thin-film filters that are easily manufactured using proven methods from the semiconductor industry and has filed more than 30 patents on the Active Thin Films technology platform and its applications. Visit our website at www.aegislightwave.com. Description of Job Aegis Lightwave is looking for a Senior Test Engineer responsible for developing and maintaining automated test stations throughout the fiber-optics product family. Work will include collaborating with operations and development groups to define test requirements, designing test stations and software, and qualifying test systems. Typical Project Work Includes Design and develop automated production test software for next generation products. Maintain and continually improve existing test stations through hardware and software upgrades. Develop automated tools for R&D of new and existing products. Debug and analyze device test failures. Study product performance issues and specifications. Manage capacity requests for production test stations. Manage projects including hardware, software, documentation, resources, and schedules. Create and execute test station validation projects with a formalized report deliverable. Work on multi-developer software applications. Utilize and contribute to shared software library. Experience and Education Required BS in Engineering or Science. EE preferred. MS a plus. 5+ years LabVIEW application development and system integration. Manufacturing test station design and construction. Electronic circuit analysis and troubleshooting. Signal integrity, sampling theory, noise issues, signal filtering, curve fitting, and measurement precision. Technical document writing and communications. Project management. Additional Experience Desired NI Certified LabVIEW Developer or Architect. National Instruments data acquisition products expertise. Fiber optics connection, signal, and measurement issues. GPIB-controlled optical test instruments including tunable laser, polarization controller, optical spectrum analyzer, lightwave multimeter, attenuator, and optical switches. Other Job Information Position type: full time, permanent. Location: Woburn, Massachusetts. Salary: will be commensurate with experience and competitive with the local market. Benefits: Aegis offers a comprehensive benefits package that includes health and dental plans, a 401k plan, disability insurance, life insurance, and stock options.

Hi. I'm looking for a good bug and issue tracking system that integrates with Subversion. I searched the web and found about 15 products that do what I need and appear to be effective. Have you used a bug tracking system for Labview projects? Or do you know of one that works particularly well for automation related projects? I'd appreciate any recommendations. Some packages cost money, including yearly and per user license fee, and some are free. Some run on a standard web browser, some have a client application. Some we can host on our server along with Subversion, some are hosted only on the product's server. Thanks for your help!

I need to continuously sample one analog voltage at 1.25 megasamples/second, 16 bits. I'm considering the NI PCI-6251 card in a desktop computer vs. a USB-6251 BNC with a notebook computer. My question is, are there any issues with the USB version keeping up with continuous sampling and data moving at that rate robustly? And are there any issues or problems at all with using the USB product instead of the PCI card product? Thank you very much for your advice on this!

I understand that one of the issues is that the consumer USB cameras are not made for taking snapshots but for streaming live video. A driver would likely have to keep up live video streaming from all the cameras simultaneously in order to be ready to grab a frame when it's time to take a snapshot. There is then an issue of USB controller bandwidth. Irene He of Hytek Automation explained this to me. They have a software product that handles these issues, which I might try.

Thanks, Joris. That's very good to know. However, it's very disappointing. Regarding opening and closing the camera for each snap, I read this information from the NI-IMAQ for USB Cameras support page: "Known Issues: "Opening and closing a camera session causes a small memory leak, so it is not recommended to do this repeatedly." My application would be opening and closing on the order of 20 times per minute for up to a month, so the memory leak is a concern.

If you are just taking snapshots, not simultaneously, can you have multiple sessions open and leave them open? My application requires 12 cheap USB cameras each taking a snapshot twice per minute. I've tried NI-IMAQ for USB successfully with one camera. I only have one camera to experiment with at the moment. A session is opened with 'IMAQ USB Init.vi' and closed with 'IMAQ USB Close.vi'. I'm wondering if I can call Init 12 times, keeping 12 distinct session refnums alive, and cycle through taking snaps with at least 2 seconds pause in between snaps, successfully. Thanks.

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.