Jump to content

Dan Press

Members
  • Content Count

    41
  • Joined

  • Last visited

Community Reputation

3

About Dan Press

  • Rank
    More Active
  • Birthday 09/17/1975

Profile Information

  • Gender
    Male
  • Location
    Boca Raton, FL

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
    1995
  1. Dan Press

    Game of Thrones

    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.
  2. 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!
  3. 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
  4. Dan Press

    DMA FIFO

    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
  5. 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.
  6. This game is fun, and I think it accesses that part of the brain where LabVIEW lives. http://pleasingfungus.com/
  7. 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
  8. 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
  9. 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
  10. I whipped up something that could form the beginnings of an XControl. It does basically what you describe. Check it out. MCLB Pulldown.vi
  11. 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?
  12. 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
  13. 1,481 downloads

    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.
  14. 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.
  15. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.