NI_Eagle

I'm not sure what posts or issues you're referring to, but if you contact me directly, I'll help you take care of it. jeffrey.phillips@ni.com

The release of LabVIEW 2016 just a few short weeks ago marked the 30-year anniversary of the seminal 1.0 launch of LabVIEW on the Mac. To ultimately improve your productivity in building engineering systems, NI has consistently invested in abstracting low-level programming tasks, exposing leading technologies and compute platforms, maximizing performance and memory management, and of course doing all of this inside of a stable platform. You might think that the features you’ve see over the past few releases, such as Channel Wires, represent the totality of the investment being made in LabVIEW. But, you would be wrong. NI also announced the NI Software Technology Preview, a program designed to provide current users of NI software active on a Standard Service Program contract with an early look at conceptual capabilities. Through this program, you can access pre-release software builds, product guides, reference materials, help modules, and discussion forums to help you along the way. The software builds available today demonstrate investment in these 6 key areas: Approachable Automation Integrated Learning and Help Content Interactive Data Analysis and Management Enhanced Productivity for Programing Modern UI Development from the Desktop to the Web Server Side Data Analysis and Management The Next Generation LabVIEW Features for Desktop DAQ and Instrument Control Technology Preview build demonstrates the fruition of these investments in graphical programming specifically. Visit ni.com/techpreview to sign up and ZOOM into the future of LabVIEW now! (Note: You must have an NI software serial number with an active SSP contract)

This type of feedback is invaluable for the LabVIEW team here at National Instruments. Knowing where users struggle with existing features or what future functionality could ease development pains helps us prioritize the scope of each release. I would highly encourage you to post your ideas to the LabVIEW Idea Exchange. This public forum is designed to give the LabVIEW Community a place to present ideas to both the rest of the Community and the LabVIEW development team. You can vote other ideas up, and the most popular ideas get added to each version. If you have any questions, just let me know!

Argosta, Answering such a question would involve much more detail that I feel like this single post could entail. I would really encourage you to visit this page: http://zone.ni.com/devzone/cda/tut/p/id/10864 This link will take you to page where you can schedule a personal "online visit" with one of our Applications Engineers, who can get you started with the LabVIEW environment, and personalize the demo to fit your needs. Regards, Jeff

Joe, To your point of buying a single version of LabVIEW and getting bug fixes for that version free, that was the intent of SSP. Take the following case: You bought LabVIEW 8.6 in September of 2008 In March 2009, you received LabVIEW 8.6.1 In August 2009, you received LabVIEW 2009 March 2010 rolls around, and LabVIEW 2009 Service Pack 1 releases At this point, all you have to pay is for the renewal of your service. Each year, you pay one renewal price, and that gives you the August release and the following Service Pack. In your scenario, you would have to pay a significantly larger upgrade price each time LabVIEW is released. If you want each version and the bug fixes, then the SSP model is much more cost-effective for you. Really, it is more cost-effective to stay current on SSP and only upgrade your version of LabVIEW once every 3 years than it is to pay the upgrade price for LabVIEW every three years. You also keep the support and training resources through that time. Respectfully, Jeff

This is Jeff Phillips, one of the LabVIEW Product Marketing Managers. I just wanted to take a moment to clarify a few things: First, if NI comes across a bug that is critical, our policy is to release a public patch for LabVIEW that is available to everyone. Second, we've been down the path of delivering the "maintenance release" as a true fix for LabVIEW, meaning you install it on top of the original version. In order to improve the user experience, we switched the Service Pack to a stand-alone version, which means that activation separates who can and cannot use it. Third, the price that you are paying for SSP includes a lot more than just the bug fix version. As mentioned before, you also receive a new version of LabVIEW each August, followed by a service pack containing bug fixes for that version, along with support from Applications Engineers, and access to specialized training content through the NI Services Resource Center. Anyone who purchases LabVIEW 2009 is entitled to that version, the following Service Pack release, and the release the following year (i.e. LabVIEW 2010). If your service lapsed between the release of 2009 and the release of the Service Pack, then that means that you received LabVIEW 2009 as part of your previous service (at a MUCH discounted rate compared to a true upgrade). Our goal in switching to a subscription-based service was to make it possible for us to integrate feedback and fix bugs more easily and frequently. Having a yearly release cycle allows us to introduce new features more frequently, while mitigating the risk associated with introducing those features into a stable code base. Respectfully, Jeff

Argosta, My opinion here is of courses biased, as a LabVIEW Product Manager, but I'll hopefully provide some insight nonetheless. You are quite right that the GUI of LabVIEW is more user friendly. However, the advantages of using LabVIEW extend far beyond just the ease-of-use of the GUI. The power of the GUI comes really comes into play when you connect your applications to hardware. Being able to visualize the results of your application in-line with the data that you are acquiring or hardware you are controlling helps you to connect what is going on in the real-world with that of your LabVIEW application. Secondly, the LabVIEW compiler simplifies development by providing edit-time feedback on errors in your application, and abstracting typical programming tasks such as variable instantiation, memory and thread management, and performance optimizations through the ordering of code execution. Also, the graphical approach to programming (we believe) helps to align more with the natural way an engineer would express his/her thoughts or lay out the solution to a problem. Code parallelism is much easier to visualize graphically than in serial text-based text. MATLAB does have its benefits, and I'm not here to shoot that down. The .m file language is a highly-abstract language, and simplifies many tasks, such as not having to declare variable types, no compiling, etc. Most linear algebra and matrix-style operations are easier, faster, and more naturally expressed in the .m file implementation. One of the benefits of LabVIEW is the MathScript RT Module, which provides a native compiler for your custom .m files within the LabVIEW environment. That gives you the ability to bring most .m files that you have already created into the LabVIEW diagram, and deploy them as part of your application. I'd be happy to provide more information if you're interested! Regards, Jeff

Right now, I'm an Applications Engineer in the IMAQ/Motion group. I'm hoping to transition into a marketing role related to either Vision or LabVIEW somehow! I have specific knowledge is MathScript, Vision, and general LabVIEW issues!

Greetings All!! I just found out about this fantastic resource, LAVA. :thumbup: I am a M.E. graduate of the University of Tennessee and currently an Applications Engineer at NI. Just wanted to introduce myself, as hopefully, I'll have some interesting information to contribute!!