Dan Press

If you happen to be a GoT fan, the finale is being screened at The North Door. After that, of course there is the meetup at Banger's.

Great work! It is always exciting to see LabVIEW getting access to a previously dark corner of the UI. When I run the Taskbar Example it works the first time, but will not show the thumb buttons again on successive executions. If I close the VI (dump it out of memory), reopen it and run it, the buttons appear again. Is this another peculiarity of the API? Thanks!

Systems Engineer PrimeTest Automation, a 10 year-old multi-million dollar organization based out of Boca Raton, Florida is growing and looking for an additional Systems Engineer to join our family who is highly motivated and excited to work with LabVIEW. The opportunity will allow the right candidate to work on varied projects touching areas such as aerospace, medical, packaging, military, automotive, advanced research, and much more. Candidate must be detail oriented and able to adjust quickly to work on multiple projects while having the ability to bring smart solutions to bear. Candidate must also have the ability to be hands-on when need be and work with a diverse team to bring projects to a successful completion in a timely manner. Base pay is commensurate with experience. Responsibilities and activities specific to the position include the following. Design and develop software in LabVIEW Assist in the specification of components to build test systems and automation platforms Gather software requirements and generate detailed documentation Train staff and customers to install and operate software work product Estimate the level of effort to develop software given a basic set of requirements Eventually achieve Certified LabVIEW Architect status from National Instruments PrimeTest is proud to have the resources in-house to handle everything from full PC-based test and measurement systems through custom assembly automation systems, handling projects from the very small to multi-million dollar in scope. The PrimeTest team is constantly working with cutting edge technology and we have a proven ability to develop solutions for just about any challenge put in front of us. You can view our website at http://primetest.com/ for examples of some of our work, and please view the “PrimeTest Advantage" page to see what sets us apart from the ordinary custom machine builders. Requirements: Systems Engineer Accredited 4-year engineering degree or computer science degree preferred Understanding of data acquisition systems Knowledge of programming concepts such as loops and variables Familiarity with process flow concepts such as flow charts Automation / machine-building background is preferred Strong excitement about working with LabVIEW and other National Instruments tools Effective communication with management, customers, and vendors is a must. US citizens only please Please email resume and cover letter to hr@primetest.com

The FIFO depth that you configure on the FPGA side is more of a "transfer buffer" if I understand it correctly. The depth you can dynamically set on the host side is the DMA's footprint in system RAM. You can make the host depth very large as long as you have the free RAM available. So increasing that depth on the host side should help a bit. The CPU hogging is happening, as has been pointed out before, because you have no wait in the while loop. Here is where an interrupt would help you. It is far less costly in CPU cycles to wait for an interrupt than to wait for samples to arrive in the FIFO. Of course, you have a different problem. The samples are already there! That's because you are using a loop rate in Windows that is much too fast to be reliable. The latency in Windows is just not low enough for 20 msec. You must interpret your requirements and see if you really need to loop that fast. If so, I would recommend RT. I think if you boost your FIFO depth on the host side (does not require FPGA recompile!) and grab more samples less often, you should be good to go. - Dan

There's Champions in the Courtyard Marriott right across the street from the convention center. I think you can actually see it from the registration area. Not sure if they screen Versus though.

This game is fun, and I think it accesses that part of the brain where LabVIEW lives. http://pleasingfungus.com/

Title should read "array OF refnum"... This is a crosspost. This one just bit me so I thought I should share. It looks like the Search 1D Array function behaves unexpectedly when used with an array of VI refnums. So far I have only reproduced it in LabVIEW 2009 SP1, but I ran some code in 8.6.1 that seemed to have the same symptoms. When I run the code above, I always get a zero for the output "index of element". In the example shown I expect to get 3. In fact if you change that 3 on the array index to any number, you get zero on the output. My workaround is to typecast the refnum array to an array of I32 and also typecast the refnum that I'm searching for. That makes it work, but I'm still freaked out by the odd behavior. Note that the VI you throw the snippet into must be reentrant. I believe the search is getting confused because the refnums all point to the same VI, albeit different instances of that VI. Of course, that is the whole point of using the search 1D array function. I am trying to identify a particular instance. Can anyone repeat this one? Thanks, Dan

This one has my wheels spinning a bit. I think it is because I am thinking of too many different ways to accomplish something, and I just want some opinions on what is best. I have an application that supervises an inspection process. The application reads the results of the various inspections and logs them to a database. The customer has requested multiple charts and graphs to present statistics based on database queries. Since the customer keeps dreaming up different views and P-charts, Pareto Charts, etc. I would like to make each chart type into a plug-in and deploy them to the customer as a single file (ZIP or LLB perhaps) that they can drop into a designated folder. The application would then list the contents of that folder and make the plug-in available through a menu. Where I get stuck is on the build / packaging of the plug in. I want to make use of some subVIs that are already in the main application, but I know that I will need to include those subVIs that are only in the hierarchy of the plug-in as well. So what is the "best practice" for packaging my plug in such that it includes what it needs and excludes what is already going to be in memory as part of the main application? I see my options so far as the following. Who cares about duplicate subVIs? Just make a Source Distribution to an LLB from the Project and let it throw everything in there. If the subVI is already in memory, it should just use that, right? I care about duplicate subVIs! I can make the Source Distribution, but I can painstakingly exclude all the subVIs that are already part of the main executable. The operative syllable being "pain". Perhaps I can beat the OpenG Builder into some horribly disfigured mess that will do what I want. I could create a tool to do this while feeling like someone already did this. Did they? There is NO.... number 5. Or maybe there is. Thoughts? - Dan

Name: PTA IP Address Submitter: Dan Press Submitted: 02 Jul 2009 Category: X-Controls LabVIEW Version: 8.2 Version: 1.0.1 License Type: BSD (Most common) Make this available on the VI Package Network?: Undecided Copyright © 2007, PrimeTest Automation, Inc. All rights reserved. Author: Dan Press --see readme file for contact information Instructions: This code has been tested to run under LabVIEW 8.2.1 and 8.5.0. Just unzip the code into any folder of your chosing and select the file "IP Address.xctl" as a control. Features: - Exists as a string control / indicator for IP addresses - Provides a convenient way to enter an IP address - Filters all but number keys - Advances through the four bytes of an IP address automatically Support: If you have any problems with this code or want to suggest features, please post to the LAVA forum. Version History: 1.0.0: Initial release of the code. 1.0.1: Added custom icon to the block diagram terminal (thanks Mike!) Fixed vertical resize (very short) on drop in 8.2. Added support for backspace and delete. Using character values instead of scancodes for key down filter event. Learned that the decimal point in the keypad and the delete key have the same scancode. Added documentation to the XControl properties. Click here to download this file

I whipped up something that could form the beginnings of an XControl. It does basically what you describe. Check it out. MCLB Pulldown.vi

A great book indeed! So, that code does allow reading and writing of some custom data in PNG files. The thing is, when examining a file that contains IMAQ "Vision Info" it does not show what the Vision Info is. Sure, there is a Version tag, a couple timestamps, an image type, an actual height (no data), something about lost packets, but no ROI data. That means that the ROI data is hidden somewhere else. Oh... and what's with that pesky DLL? Shoud we change the name around here to DLLAVA?

As many LabVIEW experts and other tech savvy people already know, Portable Network Graphics (PNG) format is wonderful. It supports the alpha channel for transparency, is unencumbered by patents, provides the option of lossless compression, is compatible with LabVIEW in several ways, and it can store customized information in addition to the image. The IMAQ Vision Development Module ships VIs that can read and write PNG files with "Vision Info". So, you can save an image and include stuff like the ROI and other overlays that can be loaded up later. That's all very nice, but when you try to peek under the hood all you find is a DLL call. Now, Chris Relf (crelf) wrote in his book Image Acquisition and Processing in LabVIEW that "The source code to realize this techinique is available at the National Instruments Developer Zone". The thing is that now I cannot seem to find it. Looking at the PNG file format itself, it seems simple enough to extract the text items. I just get that reinventing the wheel feeling, so I figured I'd ask around here if anyone has that example code lying around. Also, is there any documentation for how the IMAQ Vision Development Module stuff is storing the ROIs and stuff. I wouldn't want to mess that up, and it would be neat to be able to read that without making a dreaded DLL call. Thanks, Dan Press, CLA PrimeTest Automation

It looks like a good time to jump into LVOOP! You can use Dynamic Dispatch to launch the appropriate VI based on the type of DUT.

According to the specifications, the input delay time for the 9435 is 3 msec (2.8 msec in the manual). That means a signal must remain in the ON or OFF state for that amount of time before the device registers the transition. So, you effectively have that filter always enabled. It's just that you do not have the ability to easily change the time constant the way you do with the industrial digital I/O cards like the 6514. If your glitches are less than 3 msec long, you should be fine with the 9435. If they are longer than that, you will have to do some extra filtering in your LabVIEW diagram. If you are using the 9435 in a cRIO, you can fairly easily create that same API behavior with your FPGA VI. If you are using the cDAQ, you would have to do it on the host.

Mine looks slightly different. This is from some old code, but it does work.

I agree with Gavin, it's tough to squeeze the old shield down to size. What looks better? A: Brown University shieldor B: Any fellow Brunonians here?

I haven't seen that error, but did you make sure to include the "...\vil.ib\addons\_office\_exclsub.llb\_Excel Dynamic VIs.vi" in your project? The documentation recommends including the "...\vil.ib\addons\_office\_wordsub.llb\_Word Dynamic VIs.vi" as well.

I've seen stuff like that happen. It seems to be a Windows thing. Lots of stuff is launching at once, and not all drivers and services are initialized before your startup shortcuts are executed. I recommend a little tool called Startup Delayer. It lets you specify a time delay for any number of applications to launch after startup.

The key is the property of a combo box called Strings[]. Feed it the array of file names from your directory listing.

Tim's got it with the AC coupling there. If you want to see the static load as a DC offset, the SCXI-1531 is not the correct module. You will have to step up and get a 4472 or 4474. You can configure the 447x in AC or DC coupled mode. The sensor does output in units of mV/lbf and not a rate of change in force. It's just that when you are AC coupled, you only see a voltage swing corresponding to the amount of change in force.

If it's throughput you seek, shared varibales may not offer the best solution. The way I see it, you have two options. 1. Pad your data such that each Write is at least 2033 elements. Just make sure your first element is equal to the number of real elements you wish to process on the other side. 2. Switch to raw TCP and make your own protocol. I agree that your timing results are troubling. I've seen similar spooky things with network shared variables.

I do not think that those units can be daisy-chained. They are Ethernet interfaces, so you can just wire one or more of them to a subnet. That's not technically daisy-chaining. If you use a dedicated subnet, there should be plenty of bandwidth to do data collection across multiple units. The only performance hit I've seen is that the initial communication with the unit tends to take a few seconds. Once communications are established, the data flows nicely. cFP is not a particularly fast data acquisition platform. It is great for things like air temperature that do not change too rapidly. If you need to sample fast, consider the Compact RIO.

Dan, You have been creating test and automation applications in LabVIEW for years! I've seen your name countless time on this forum and on Info-LabVIEW. You should have plenty to show. Wait, did you switch companies? Last time I checked you were at Stoneridge. We've built several test systems for Hi-Stat here in Florida. All of them are LabVIEW based. (of course). Perhaps the best approach if your boss doesn't know anything about LabVIEW would be to open up the pallets with all the analysis functions. Explain that most of that would have to be programmed and integrated from scratch in some text language. Of course, you can use third party libraries in text-world, but that takes time to understand and debug too. Good luck!

QUOTE(shoneill @ Aug 15 2007, 10:01 AM) I have been using the pattern shown here for some time now. I have seen many varaitions on this. There is one loop for Events (UI) and another for other processing. I will also usually have a subVI tucked in the upper left corner that runs in parallel and at a different priority. That subVI houses DAQ stuff or other hardware interface code. I still consider this a queued state machine (QSM). The difference between this and the "monster" above is that the data is encapsulated in a cluster and there is an event loop. Still, this has its limitations. I have been guilty of amassing a long list of cases inside both loops! http://forums.lavag.org/index.php?act=attach&type=post&id=6630''>http://forums.lavag.org/index.php?act=attach&type=post&id=6630'>http://forums.lavag.org/index.php?act=attach&type=post&id=6630