Preparation was key for this project. We selected a camera, chose a software plan of attack, mounted the camera, played some pool to “test”, and created a camera driver. The camera chosen was a basic webcam with a 90 degree field of view and 1080p resolution. This made for a wide enough image to capture the pool table felt and the rails. The chosen software was LabVIEW as DMC has experience using NI’s versatile VAS and VDM software libraries with an integration to our existing custom Java based pool application. Once we wrote the driver we were able to start on algorithm development on FedEx Day.

 
The following software was developed on FedEx Day: Software Architecture/Application, Calibration Algorithms, Ball Location Algorithm, Ball Color and Pattern Algorithm, “Active Shooter” Algorithm. The architecture utilized a Producer/Consumer architecture with a single state machine to collect an image and determine the state of the pool table. Each ball was calibrated by snapping an image of the ball to get a known representation of each balls RGB value and whiteness. Each balls location was detected by HSB differences between a ball and the felt. Based on the calibration images captured for each ball, the RGB best match of each detected ball was matched to the corresponding calibrated ball. The pattern of a ball, striped vs. solid, was determined by white content of each detected ball. More white meant striped and less meant solid; lots of white meant the cue ball. To determine when to analyze the state of the pool table, an algorithm was written to detect whether a player was shooting and therefore blocking the camera’s view of all the balls. 

After a day of programming, we did it! The system correctly identified the location of the balls and what balls were left on the table. However, there were some challenges along the way. Lighting, RGB vs. HSB and the USB standard just to name a few. As always, lighting is very important in vision applications. The issue we ran into was shadowing around each ball. The shadowing ruined the RGB color measurement around the edges of the ball which could lead to incorrect ball color detection. HSB is a valuable domain to work in and was useful in distinguishing between the felt of the table and the color of the balls. As far as the USB standard issue, we used a USB webcam for the proof of concept. Although not a devastating issue, we needed to shorten our USB connection to the camera to be under 5 meters since our initial cable was longer and caused camera connection issues.

There are a lot of fun future applications we can do now that we can detect what balls remain on the table. The next major step will be to integrate it with our existing 3/5-way cutthroat application to automatically update what balls are sunk. If you have any fun ideas let me know by posting them below!
 

The post Pool Vision Application appeared first on DMC, Inc..

We gathered at Navy Pier on a beautiful fall day, ready to enhance our technical knowledge, connect with other local NI users, and introduce visitors to DMC. Our tilt table demo proved to be a popular draw and DMC's team had a great time showing it off at the booth. 

As always, meeting and developing relationships with National Instruments and peer integrators was a highlight of the day. We even raffled off a Fitbit Charge HR. Congratulations to our winner, Sonny Mitric of Omron!

There were plenty of insightful technical sessions to choose from throughout the day. The Advanced DAQmx Property Modes presentation offered a deep technical dive into a useful topic that's applicable in many different applications. We also attended sessions on LabVIEW for Embedded Systems and gained hands-on experience using CRIO for Real-Time and FPGA application. Another course demonstrated good electrical engineering wiring practices, shielding, and noise reduction.

DMC is an active participant in the Chicagoland LabVIEW User Group, so we were excited to see the Midwest User Group at NIDays. We stopped by the Midwest User Group booth and met up with users from across the region at a lunch meeting. 

We wrapped up the event with a fun exercise as part of the closing keynote session. Building a LEGO duck as a demonstration of stem execution was an enjoyable way to end a valuable day of learning and networking. 

Don't miss DMC at NIDays Boston 2015 on November 17!

Learn more about DMC's Test & Measurement Automation services.

The post Duck, Duck, DAQmx: NIDays Chicago 2015 Recap appeared first on DMC, Inc..

Interested in having us help with your integration? Here are some projects we have done to integrate vision into LabVIEW!

Learn more about DMC’s LabVIEW Vision Application Development services.

The post LabVIEW VAS Camera Timeout Fix appeared first on DMC, Inc..

DMC is honored to demonstrate our expertise by having the most LabVIEW Certified Architects in the Midwest, as well as an all over strong team of LabVIEW Certified engineers.

NI has three different levels of LabVIEW Certification: Associate Developer, Developer and Architect.

Recently, we added five new engineers to our roster of LabVIEW proficient employees. DMC now has a total of nine Certified LabVIEW Architects, three Certified Professional Instructors, two Certified LabVIEW Developers and three Certified LabVIEW Associate Developers. Check out our full LabVIEW team below:

CLAs (Certified LabVIEW Architects):

• Patrick Corcoran 
• Eric West 
• Ashley Enderlin 
• Mark Locascio 
• Jeremy Green 
• Nick Aroneseno 
• Jesse Batsche 
• Leon Grossman 
• Darren Jones 

CPIs (Certified Professional Instructors)

• Darren Jones
• Patrick Corcoran
• Nick Aroneseno

CLDs (Certified LabVIEW Developers):

• Matt Goedke
• Jason Mayes

CLADs (Certified LabVIEW Associate Developers):

• Devon Fritz
• Bill Sowerine
• Elizabeth Rapport
• Katherine Czaplicki
• Spencer Glesmann

Learn more about DMC’s LabVIEW programming services.

The post DMC Congratulates LabVIEW Certified Architects and Developers appeared first on DMC, Inc..

In case you didn’t make it to NIWeek or weren’t able to join us on August 6, we have posted the presentation to SlideShare. During the presentation, Dan reviewed the many challenges that Leary faces in the folding carton industry. For example, ensuring that glue is properly applied to more than 30 separate locations on a complicated six-pack beer carrier was essentially impossible without a machine vision system. This is especially true considering the folder-gluer can process 10 to 50 cartons per second depending on the size of the carton.

After Dan presented the challenges associated with the high-speed folding carton industry, Ken and I rose to these challenges and presented some theories on designing a vision system. We explained that our favorite hardware platform for high-speed, multi-camera, 100% up-time, machine vision systems is a PC running NI’s real-time operating system. This system is connected to standard cameras as opposed to a smart camera which performs image inspection using an onboard processor.

For many of our vision inspection projects NI’s FPGA cards and expansion chassis have been critical tools for controlling digital inputs and outputs for camera triggering and encoder tracking. Though we mainly focused on giving tips on using the FPGA in this way, I’m also excited about the new tools in the 2014 Vision Development Module that make it easy to offload some intensive image processing algorithms to an FPGA. We did not discuss this in our presentation because it is a brand new feature that was just unveiled at NIWeek 2014. I’m eager to use it in future projects.

We also shared some of the random bits of knowledge we have picked up from experience on these projects. Some of my favorite “Knowledge Nuggets” are:

• Avoid creating and destroying image references. Use a static pool of image references that you create once when the program initializes.
• Use integer math instead of floating point math where possible. We demonstrated a 2.5x increase in processing speed for the same mathematical calculation using integers compared to double-precision numbers.
• Use the VI Profiler tool to determine which VIs are taking the most time to execute. This is how we discovered that some of our VIs were spending too much time creating and destroying image references.

Overall, the presentation went well and was well-received by the audience. I hope that audience members gained some useful tips that they can use on their own projects.

NIWeek 2014 had a vision summit that included some other interesting announcements. I already mentioned the FPGA Vision IP that I am excited to use. Another great new product is the cRIO with integrated display for user interfaces. NI’s real-time operating system is great for high-speed vision inspection that requires 100% availability and reliable, deterministic processing. The only downside was that there was no way to program an interface in the real-time operating system. Our other RT vision systems use a separate PC (typically running Windows) to serve as the HMI, communicating with the RT PC via TCP protocols. Now, we can streamline our development by integrating the HMI into the real-time program. Good job, NI!

The post High-Speed Vision Inspection Presentation at NIWeek 2014 appeared first on DMC, Inc..

The problem is, he’s right.

LabVIEW has a suite of powerful vision tools, most of which work fantastically well out-of-the-box. IMAQ Find Straight Edges 3 is unfortunately not one of them. It takes an image, a region of interest (ROI), some fitting parameters, and generates an array of rake points. Those rake points are used as the inputs to a linear fit, and if the fit is sufficiently good, it is presented as the output. There are a few fitting options, but none of them seem to handle noise very well.

The problem lies not with the rake points, but with how they are processed. A relatively small deviation in the rake points from a perfect line will systematically throw off the fit. The solution is to do the fitting ourselves.

To start, we use IMAQ Rake 3 to generate rake data using the same parameters as IMAQ Find Straight Edges 3. There are a few outputs, the most general of which is an array of search lines information. Each array element contains the endpoints of a given search line, as well as an array of found edge locations along the search line. We can then condition this data into an array of points (x,y) where x is the search line index and y is the distance between the start of the search line and a found edge.

Now we have an array of points on which to do linear regression. How do we learn from the mistakes of IMAQ Find Straight Edges 3? Stay tuned next time for the exciting conclusion in I Only Have Lines for You or An Array to Remember!

That was a Rocky and Bullwinkle joke.

 I apologize.

Anyway, back to the answer: if we can measure the fitting error for a given point, we can weight it accordingly and devalue points with high error. The algorithm is as follows:

1. Acquire conditioned rake data.
2. Perform a linear regression with uniform weights.
3. Until settled, or some max number of iterations has been reached:
   1. Generate weights as a function of error from the last fit.
   2. Refit with new weights.

The choice of a weight function should be something that decays quickly and monotonically to zero as abs(error) increases. Either a top hat or Gaussian centered at zero are good choices. Each family of functions is easily parameterized by a length scale, which makes for a great input parameter. Many other functions should work just fine, but these are simple to implement, and they perform well.

Once all of this is working, it’s easy to add further fitting options. A constraint on orientation can be achieved by constraining the slope of the linear regression. A line score for the output can be generated by measuring the average fitting error in various ways. It is useful to measure other fit properties: number of points with small error, line length, etc.

With all of this in place, we can start to get fancier with the analysis. A composite line score can be generated by taking a linear combination of functions of line metrics. We can run a window across an image, perform many fits, condense fits if appropriately close, and select the best results based on the composite score. We can do this for both rising and falling edges, correlating results to find rising/falling pairs based on similarity in orientation and separation. We can take these candidate pairs, and evaluate the pixel distribution of the region between them in order to verify that they bound a straight line.

Suddenly noise isn’t such a problem after all.

Learn more about DMC’s LabVIEW programming services.

The post Improved Straight Edge Fitting in LabVIEW Vision Applications appeared first on DMC, Inc..

To control this laser, Keyence supplies the LJV-7000 series laser controller with LabVIEW drivers and a DLL. These are at the core of editing controller parameters. Here is the download link (you must login to Keyence's website to complete the download).

Now that you have the drivers, and a very helpful user manual, you can begin your LabVIEW coding.

Note: All the pre-built driver VIs use calls to the library (LJV7_IF.dll). Each of these calls is documented very well in the user manual supplied in the download; I will reference it a lot in this tutorial.

1. Initialize Laser 

This sets up communication with the target device either over Ethernet or USB. You could use the DLL call, but I recommend using the pre-built driver which already defines the library function call and reads the error code out.

2. Set Your Parameters 
This puts the specified setting to the controller, but does not change the setting (more on that in step 3). The configuration VI is called ‘Set Setting’ which has the library function call defined in it. The inputs the set setting function takes is:

• Depth – Use Write Area so you avoid conflicting parameters running on the controller at the same time.
• Device ID – Make sure it is the same one you used in the initialization.
• Target Setting – This tells the controller which setting you want to change. The three items that make up this are Category, Item, and Type. The user manual is used to find what values these are for your setting.
• Data Set – The format for this entry is also in the user manual.

Example: Setting the Encoder Trigger Mode to 2-phase 2 times (left-user manual, right-code).
   

The manual shows the Category is 0, Item is 7, and Type is whatever program you want to write to. I am using Program 0.

3. Reflect Settings to Running Area 

Since I wrote all my parameters to the Write Area of the controller I need to now make them the run parameters. This will make the parameters written to the controller reflected in the run settings.

Note: If you try writing parameters that cannot exist on the controller (like 64 kHz sampling without binning), then none of the parameters will be set.

Now you can customize the Keyence LJ-V series lasers for your LabVIEW application!

Learn more about DMC's LabVIEW vision application development expertise.

The post Using LJ-V Keyence Lasers in LabVIEW appeared first on DMC, Inc..

NI Alliance Partners participating in the Vision Specialty program have proven expertise in imaging and vision systems and are identified as experts for customers who require software development, integration or consulting services. National Instruments reviews the capabilities of each Alliance Partner participating in the Vision Specialty and uses the AIA System Integration Company Certification to achieve industry validation of machine vision excellence.

“DMC is one of 10 companies internationally selected for this level of partnership,” said DMC Project Director, Darren Jones. “Recognition within a distinguished group of companies with proven NI platform proficiency further demonstrates DMC’s high level of expertise in Machine Vision and NI Software.”

“For almost 15 years, NI has provided software and hardware tools for vision applications to help engineers and scientists meet a diverse set of challenges,” said Tony Vento, vice president of systems assurance and partners at National Instruments. “By establishing the new Vision Specialty, we’re recognizing the expertise of our top Alliance Partners in the vision space.” Learn more about NI’s Vision Specialty at www.ni.com/alliance/specialties/.

About the National Instruments Alliance Partner Network The NI Alliance Partner Network is a program of more than 600 accredited companies worldwide that provide engineers with complete solutions and high-quality products based on graphical system design. Since the program’s inception in the early ’90s, NI Alliance Partners have evolved into a global network of companies that offer system integration services, add-on products to NI software and hardware and turnkey solutions for companies spanning multiple industry and application areas. From products and systems to integration, consulting and training services, Alliance Partners are uniquely equipped and skilled to help solve some of the toughest engineering challenges. Readers can learn more about the Alliance Partner Network at www.ni.com/alliance/.

About National Instruments Since 1976, National Instruments (www.ni.com) has equipped engineers and scientists with tools that accelerate productivity, innovation and discovery. NI’s graphical system design approach to engineering provides an integrated software and hardware platform that speeds the development of any system needing measurement and control. The company’s long-term vision and focus on improving society through its technology supports the success of its customers, employees, suppliers and shareholders.

National Instruments, NI and ni.com are trademarks of National Instruments. Other product and company names listed are trademarks or trade names of their respective companies. A National Instruments Alliance Partner is a business entity independent from National Instruments and has no agency, partnership or joint-venture relationship with National Instruments.

The post DMC is recognized as a National Instruments Vision Specialty Partner appeared first on DMC, Inc..

For me the biggest appeal for OO programming in LabVIEW was the increase in organization, manageability, and code-reuse that it offers. The implementation requires you to go a little beyond just creating VI’s and using controls, indicators, and functions that are in the standard library, but as this LabVIEW Object Oriented Introduction shows, it is not that scary.

I was totally sold on the Board Testing example (available in LabVIEW 8.2 and later in the directory “labview\examples\lvoop\BoardTesting\Board Testing.lvproj”).

The key to understanding the benefits of an OO solution for this problem compared to a “traditional” LabVIEW solution lies in grasping that we can look at a circuit board test in 1 of 2 ways. We can look at it as each circuit board type is different and thus needs to have its own explicit test VI written for it, which will be similar for each type, but not the same; or we can look at each circuit board as an object containing a collection of component objects, so that we now define which objects a circuit board type has and then these component objects test themselves. This example demonstrates the following shift in mindset:

Traditional LabVIEW:

1. I have a bunch of circuit boards to test
2. There are several types of boards which each have different pass\fail criteria since they have different layouts of components
3. I need to create a test VI for each type of board
4. I need to create a test sub VI for each component
5. I can leverage code reuse by making sub VI’s to test each component, which I will drop into each board type’s “Test” VI
6. If I create a new board type, I will need to explicitly define the test procedure for it

LabVIEW Object Oriented Programming

1. I have a bunch of circuit boards to test
2. Each board can be thought of as an object containing component objects. Thus different types of boards are simply child classes of the “Circuit Board” class
3. I need to define the component set for each Circuit Board type
4. I need to create a “Test” method for the Circuit Board class and for each Component class. To test a board, all I need to do is call the “Test” method for the board which will iterate through all of its components which will call their own “Test” methods
5. Code reuse is leveraged by reuse of component “Test” methods and by inheritance, which allows similar board types and components to use some of the same sub-pieces of the “Test” methods
6. If I create a new board type, all I need to do is define the components, since the “Test” method of each circuit board simply calls the components’ “Test” methods

Of course there are many other OO design concepts besides the one discussed here (which is a Hierarchy Design I believe), but this pattern alone lends itself to many applications in LabVIEW. Some quick examples would include TDMS files (made up of Channel, Property, and Group Objects), any sort of testing (each test is made up of Test Step Objects), and even something like a sensor reading or vision inspection application (each reading is made up of different Limit, Value, and Reference Point Objects).

Having picked up a good feel for proper use of LVOOP, I look forward to using it in future projects, and I know that it will continue to reduce complexity and improve the project development.

Learn more about DMC’s LabVIEW programming expertise.

The post Introducing LabVIEW Object Oriented Programming to your Toolbox appeared first on DMC, Inc..