Last month we discussed a little bit about what National Instruments DAQmx and Measurement Studio are and how they can be used to create .NET applications which leverage National Instruments data acquisition hardware. This month we are going to jump in to a high-level practical explanation on how to get started doing data acquisition in .NET.
National Instruments provides a wide array of data acquisition hardware for use in many platforms, operating systems, and busses. The most common way provided to interface with the hardware is through the NI-DAQmx drivers. These DAQmx drivers can be used to interface with hundreds of different DAQ devices across several different application development platforms. In this three part blog series, we are going to explore specifically how to use National Instruments data acquisition hardware in .NET applications. Part one will introduce a little bit of background into DAQmx and Measurement Studio. Part two will explain how to get started in adding National Instruments hardware to your .NET project. Finally, part three will provide some examples for hybrid systems combining LabVIEW and .NET as a way to fully utilize National Instruments hardware while retaining the advantages of .NET.
A few months ago in this blog I gave a very broad overview of Task Controller (TC). The Virtual Terminal is probably the best-known ISOBUS feature given its visual prominence, but TC is a popular topic to discuss in the ISOBUS world because it offers many intriguing possibilities … and seeks to fulfill many of the promises of precision agriculture across manufacturers. I thought it would be useful to spell out some of the details of TC as it can be a quite confusing subject. In this post, I will walk through the components and the steps of a typical TC session.
In a world of complex systems, it may be easy to forget some of the basic concepts that build these systems. Software applications can consist of hundreds of individual files as part of one very large project. Those files all work together to achieve amazing functionality within an embedded system. There are instances where a project may include files written by teams located in different countries. We like to think that when this software is put into production all the bugs have been discovered and the software will work perfectly. Unfortunately, there always seems to be unintended use or a sequence of events that result in undesired functionality. Other times, there is just a plain old bug that managed to find its way into production software.
Somehow I happened to fall into the last slot of the year for the DISTek blog. I am not complaining as it gave me a few more days to prepare. …
Until about a month ago, all of my experience writing code had been with text-based languages like C and Java. I had mostly written code to command microcontrollers or for signal processing. C allowed me a very procedural view of how the microcontroller would execute the code. One line of code could tell the microcontroller to turn on an LED and the next could tell it to turn the LED off, and the microcontroller would always execute the first line first and the second line second. Then I started at DISTek and learned how to code in LabVIEW. LabVIEW is quite the departure from text-based languages. I would like to describe how LabVIEW compares to text-based languages and some of my experiences learning LabVIEW as a new software developer.
Commenting code is one topic, that until recently, I hadn’t known was such a widely debated issue in the programming world. It was something taught to me from day one in Computer Science at the University of Northern Iowa. Recently, my workplace posted a simple question on an open-discussion white board. “Should we comment our code?” The plethora of anonymous comments was certainly enough to pique my interest. According to the discussion, hardly anyone could agree on this question.
It certainly can be scary looking at a long bug list with a short deadline, but identifying and fixing software bugs can be manageable with a few strategies.
A second set of eyes.
Sometimes a very simple software error can be staring at us, but we miss it because we have been staring back so long. An example I faced was a section of code appeared to be setting a value used elsewhere in the code, but that value was never changing. When I finally had someone look at that code for me, the first question was “Isn’t that a pointer?”
|
|
|
| photo: arduino.cc | photo: ni.com |
The Arduino and chipKIT microcontrollers are popular for students and hobbyists alike. They provide various interfaces that can be used to interface with a myriad of devices and sensors. These interfaces include, but are not limited to, digital I/O, analog input, I2C and SPI communication, and PWM. Microcontrollers have been used for many varying projects from basic data logging to home/environment automation and robotics.
Recently my team was given the opportunity to completely redo a particularly messy and troublesome piece of legacy C code, and as a team we decided to give MBSD a try. We had tried a few simple models before, all of which turned out to be more complicated than had we written the C code ourselves. But this time we were determined to do it right: we allocated plenty of time, received one-on-one training from the local MBSD guru, and reviewed the original requirements to ensure they met the needs of the system. Finally after exhausting all of the time, continually pestering the guru with questions and modifying the requirements several times, we succeeded in having a model based software design that actually worked the first time we tested it on the vehicle. It was a valuable experience overall and helped illustrate the drawbacks and benefits of MBSD over the typical C development.
This year’s theme focused on “Engineering Leadership – Changing, Guiding, Influencing”. I had the opportunity to sit in on several technical sessions that included some of the top panelists from across the country. The list included Deere & Company, Case New Holland, Caterpillar, Inc., Eaton and a variety of university professors.
One of the common topics I came across was how to address the increasingly complex and volatile landscape of vehicle products and control systems. How today’s engineers, across all organizations, need to develop strong adaptive thinking abilities and problem solving skills for their customers.
If you have lots of data or find yourself doing repetitive tasks with small sets of data, then you might want to consider NI DIAdem software to navigate, view, analyze, and report your data.
