Between company shutdowns and working from home over the last few weeks, some organizations are slowing production and running into various struggles to keep moving forward. For DISTek’s VT Anywhere team, we have been getting even more done now than ever before. While Slack calls and meetings have completely replaced in person interactions, the team has remained focused and very productive.
In June of this year I had the opportunity to attend our DISTek-led Modeling and Simulation training course. Currently, I am the lead of the Automation and Test group here at DISTek, but in my previous roles I have been heavily involved in desktop application development, as well as test system development primarily using LabVIEW. My exposure to modeling and embedded has been somewhat limited thus far, so I thought it would be a good experience to learn some of the basics.
Have you ever played the game “telephone”? It’s where you have a line of people and starting on one end someone whispers something into someone’s ear. That message is then passed on to the next person and so on and so on. Once it reaches the final person, you may find out that the message was misinterpreted. “Big dog” may have changed to “bed bug”. This is one of the major problems that have plagued software design and something I see on a regular basis. Engineers receive requirements that were already passed down through other people, so the engineer is left to interpret them the best they can.
Welcome back to the blog! Today, I will be talking about how to operate a Cognex smart camera via a LabVIEW program. The way I will be communicating with the camera is via TCP/IP. There are other potential ways to communicate with the camera from LabVIEW, but this was determined to be the best way, giving us the most control over the camera. I will walk through some basic terminology that is necessary to discuss building a Cognex vision test. Then, I will create and set up a vision test and finally, I will briefly describe how to program LabVIEW to send/receive information to the camera and to trigger an image acquisition.
As LCD vehicle displays have become more prevalent and versatile in both on- and off-highway, the time it takes to ensure proper display functionality after a software release has increased dramatically. It is not uncommon for displays to have 15, 20, or even 30 different screens, each of which having multiple sub-selections available. If you take into consideration different supported languages, the scope of the test grows dramatically. DISTek, as a company, is always attempting to define the future needs of customers in the off-highway industry, of which vehicle display testers are one of those needs.
If you’re a regular reader of this blog, then you probably know a lot of about the areas that DISTek works within. Our expertise ranges across the off-highway vehicle industry (including agriculture, construction, and forestry) with engineers that specialize in a variety of disciplines. Out of convenience, we typically group these disciplines into three big areas (“embedded software”, “automation and test”, and “modeling and simulation”), but the reality is that we do all kinds of projects that cross-over between these disciplines.
In college, I had a physics class called Modeling and Simulation of Physics Systems in which students wrote code to model the physical behavior of various systems. The final project of the class involved choosing a system of interest, developing a model for it, and presenting the results with some sensatory aid.
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. …
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.
Recently I was provided the opportunity to work with someone who utilized Simulink to create plant models for our customer. My experience and knowledge about Simulink and modeling was non-existent. I have heard of Simulink and seen some models, but for the most part, I am Simulink illiterate. This made my initial conversations with my co-worker an endless session of learning. It was all new to me. Add into the equation that his goal was to create a plant model; I was even more overwhelmed – seemed like I was drinking from a fire hose.
When I was attending classes at Northern Illinois University in pursuit of a Computer Science degree, I enrolled in a class called Software Engineering. The general idea of this class was training in the ability to elicit requirements from someone without a knowledge of how software works or how it should be created. The thinking was that someone with a better understanding of how a system should work would be led into providing the guidelines for the implementation so that the software developer could create their vision. But what if there was a way for that person to directly transfer their ideas into software, leaving the developer free to work with lower levels of implementation and the real nitty-gritty of the development?
For software engineers who use Simulink to do Model Based Software Development (MBSD), the ability to manage variables, also known as signals and parameters in Simulink, has always been a challenge. It has been possible but not without shortcomings, especially when dealing with large software systems.
For those not familiar with Simulink, Here is a brief outline of what the past issues have been.
