Figure 2 DEWETRON TRIONet3

Figure 3 DEWETRON XR Modules

Figure 4 One of the Completed Test Carts with a Blender on Top

DMC is also a long-standing NI partner, and we leveraged our deep LabVIEW programming experience on this project to deliver a high- quality solution.

The cart measures current, voltage, speed, and temperature, and displays them appropriately on the custom user interface. As a sequence is running, the UI shows the progress in addition to the live data. There’s a separate tab for viewing any alarms, such as application errors, e-stops, or out-of-range values, using DMC’s Alarm Handling toolkit.

There’s also a tab for customized settings, where the customer can specify the units, scaling, and type for each physical channel in the system, depending on what unit they’re testing.

Figure 5 A View of the Test Software with Sequence Monitoring, Data Plots, and a Live Data Table View

Conclusion

DMC’s expertise in a variety of hardware and software platforms made us a great fit for this consumer goods test system, and we’re always looking to do more. Our customer was pleased with how easy it was to switch over to the new test carts,and is excited about adding new features and expanding, already given the system’s flexibility for upgrades. Every product is different, and balancing streamlined features and maintainability with customization and expandability is a challenge DMC is always up for.

Learn more about DMC’s Test & Measurement consumer goods test system expertise and contact us for your next project!

The post Turnkey Automated Blender Test Cart  appeared first on DMC, Inc..

Specification

The vision experts at DMC assisted the client with selecting camera type, resolution, optics, and lighting for that precise application. For this project, client scientists would be constructing new tests and experimenting with a variety of settings on many different material types. They needed a custom piece of software that was as flexible as their test arrangement.

DMC listened to client staff and distilled their use cases and requests into a realistic strategy. We proposed to support any industrial camera that adhered to the GenICam XML standards. This would allow NI Vision to interface with a variety of different camera makes and models. Leveraging the client’s programming skills and LabVIEW’s approachable nature, we were able to design a Processing and Grading VI template. 

This ultra-flexible setup would allow LabVIEW-savvy client staff to create VI IMAQ content inside individual subVIs. These user-created VIs, as long as the terminals remained consistent, could be called and run by the built executable.

Outcome

The final application consisted of two primary parts: the Configuration screen and the Main Test screen. The client would attach a Camera, and LabVIEW would find and list the new device, along with all currently loaded settings. An extensive Attributes list displayed all editable settings exposed to the user. Double-clicking on any Attribute would launch a configuration window, displaying valid settings and a description to help the user properly edit values.

Once settings were established correctly, the client could save the attributes to disk. A camera could easily be reconfigured for a new test by loading a different configuration file from disk. Acquisition settings, such as frame rate and exposure time, could also be configured. SubVIs, created earlier by client staff, containing different image processing algorithms, are listed under a dropdown by name. The user can select a Processing and Grading subVI to run on each image.

Once a camera is configured and set up to acquire, the user switches over to the Main Screen, where they can start the acquisition. Each image produced by the camera is passed through the Processing and Grading subVIs, with live results displayed on the screen for convenient viewing. The program could also be configured to automatically save all or only ‘failed’ images to disk at a given compression ratio.

As always, DMC transferred the entire LabVIEW codebase over to the client staff. The bundle included example Processing and Grading VIs along with other DMC libraries for easy extension and modification.

Learn more about DMC’s LabVIEW programming services and contact us for your next project.

The post Enabling Flexible Vision via Custom LabVIEW Desktop Application appeared first on DMC, Inc..

Specification

DMC engineers provided platform and device options after reviewing the tight timing considerations, IO list, and system needs. We determined that an NI FPGA was the best option after ruling out the response time of leading PLC modules and estimating the number of FPGA cycles and the timing of analog output assert based on card types.

After selecting hardware, DMC also mapped out a full software design for the three separate but interconnected applications. Messaging, data exchange, and network and state diagrams were provided for programs running on the real-time target, FPGA target, and logging HMI PC.

Development & Outcome

After specification, DMC began to develop each software piece. We wrote and tested custom LabVIEW FPGA software responsible for protecting expensive high-voltage equipment before the final assembly of the RF system. Digital inputs were queried at a rate of roughly 300ns, with response times (debounce and trigger assert) hovering around 23us.

This custom FPGA software successfully replaced the client’s old detection circuitry, providing circuit changes with a few code modifications plus compile. We leveraged this flexibility by adding redundant sense lines to the routine throughout the project along with state-based reset masks and varying debounce modes.

Alongside the discrete trigger lines and rapid response, the FPGA supplies analog values to the real-time application. The real-time application, after launching the FPGA portion at boot, collects and scales a wide range of sensor data from the FPGA.

PID control, lower-speed limit alarms, and process logic are all handled by the real-time LabVIEW application. Data is sent from the cRIO chassis by the real-time program to the disk-heavy HMI PC with ample storage. Client engineers can configure slew rates, alarm limits, and power outputs on the HMI application. The HMI LabVIEW software, along with supplying a handy manual mode for local operation, can command warmup and ramp sequences.

Adding to the complexity of this solution, the cRIO program also responds to network commands from a remote line PLC. Although DMC didn’t program the PLC software in this instance, the client appreciated that we leveraged our cross-training when debugging a National Instruments and Allen-Bradley system.

Learn more about DMC’s LabVIEW programming services and contact us for your next project.

The post Real-Time FPGA System for Fast-Responding High-Voltage Arc Detection appeared first on DMC, Inc..

DMC developed a LabVIEW application that allows flexible test sequencing across different test stands. In addition, we integrated generic PC peripherals with the LabVIEW application to ensure that high-level functionality of common interfaces (Ethernet, USB, and Serial) was verified. Pairing precision instruments with everyday IO in a custom test sequence allowed for end-to-end product testing and was made possible by the NI TestStand development platform.

The test system is also fully integrated with a Microsoft SQL server database to ensure compliance with modern production requirements. Database-level traceability, especially in the automotive industry, allows manufacturers to confidently and securely store production data with ease of recall for internal reporting or external audit. SQL offers an extensive toolchain for custom data analysis and process performance analysis to ensure the system continues to run reliably throughout its lifecycle.

PCB function test systems are prevalent in modern production environments. Today, Embedded PCB devices have many sub-systems, so achieving complete test coverage with automated test solutions can be demanding. By utilizing a flexible hardware design, customizable software technologies, and partners with the expertise to integrate the system components, manufacturers can ensure a highly productive and effective path to delivering high-quality products.

Learn more about DMC’s Test and Measurement and Embedded expertise and contact us for your next project.

The post Bed of Nails PCB Functional Test System, Automotive Gauge Cluster Controller appeared first on DMC, Inc..

DMC stepped in and enabled its priority pipeline to funnel engineers from across the company and country to quickly analyze, document, and diagnose existing temperature control code. The first step the engineering team took was to create a list of opportunities for codebase improvement for the client to review. These improvements were focused on time to deployment, with an emphasis on system architecture preservation and minimum disturbance to ongoing production tests.

DMC delivered a solution that addressed fundamental issues in thermocouple reading and furnace PID control calculations as well as parallelization and independence of test fixture control. PID control was redeveloped for faster cycle times and smoother temperature trajectories. By solving these issues, temperature control accuracy was improved by 2000%, from an average swing of 60 degrees to 3 degrees over a 24-hour period. By implementing a custom PID gain scheduling algorithm developed by our certified LabVIEW developers in tandem with NI PID control VIs, DMC was able to decrease the unit test time by 1500% without negative consequences to test subjects. We were also able to supply the client with critical operating system updates for their legacy hardware.

Engineers traveled to the client site to aid in tuning, testing, validation, and deployment of the upgraded codebase. After validating the improved control, DMC empowered the client to perform system upgrades independently with rapid deployment tools and detailed documentation. This allowed the client’s engineering team to regain familiarity and confidence in the production system while spending less of their budget on external engineering hours. Within two weeks of upgrade validation, the client had recommissioned all 100 test frames at their site successfully.

Learn more about DMC’s LabVIEW FPGA & Real Time expertise and contact us for your next project.

The post Upgrading and Deploying LabVIEW Realtime Temperature Control Code on Legacy cRIOs appeared first on DMC, Inc..

This is a common scenario, as many manufacturers only provide an EXE-based interface. Rather than working against this limitation, we embraced it by embedding the DewesoftX window directly into our LabVIEW application. LabVIEW’s support for displaying external executables allows us to present DewesoftX as just another “device” in the system, maintaining a unified user experience while respecting the boundaries of what can and cannot be customized.

DCOM Interface and Python Integration

What DewesoftX does expose is a DCOM interface that allows external programs to control it. Functions such as loading setup files, starting acquisition, and retrieving data are available through this API. Unfortunately, LabVIEW does not have strong native support or comprehensive documentation for directly calling DCOM interfaces.

To work around this limitation, we introduced a Python wrapper. LabVIEW can call Python code using built-in Python nodes. We wrote a Python module that wraps the DCOM calls, making them accessible to LabVIEW as simple function calls, such as StartAcquisition(), LoadSetupFile(), and GetChannelValues().

This allowed us to bridge LabVIEW and DewesoftX programmatically while staying within the client’s preferred software stack.

Additional Hurdles: Reference Handling and Launch Timing

During development, we discovered that the DCOM object reference didn’t behave consistently in all contexts. When LabVIEW was called from TestStand, or when using object-oriented LabVIEW code, the reference would sometimes become invalid. To address this, we made the DCOM object a global variable inside the Python code, ensuring a stable and persistent reference regardless of how or when the call was made.

We also encountered timing issues when launching DewesoftX. Simply initializing the DCOM interface wasn’t always sufficient; the EXE had to be launched and ready before certain functions could be called. To solve this, we added a command-line call from LabVIEW to launch the DewesoftX EXE, followed by the DCOM initialization steps. This two-step launch process ensured consistent startup behavior.

Outcome

The result of this project was a testing solution that seamlessly integrated DewesoftX into the client’s preferred tools, NI LabVIEW and NI TestStand, while preserving powerful measurement functionality and adding automation and flexibility.

Why Use DMC for Your Next Project?

DMC specializes in solving tough integration challenges by bridging best-in-class platforms through creative engineering. Our ability to combine commercial software tools like LabVIEW and Python with OEM measurement devices like DewesoftX, using custom scripts and flexible architecture, ensures that clients retain the functionality they know while gaining the automation they need.

Contact us today to learn more about our Test and Measurement solutions and how we can help you achieve your goals. 

The post Integrating DewesoftX into LabVIEW Software using Python Nodes appeared first on DMC, Inc..

DMC worked with the client to identify potential areas where inspection speed could be increased by modifying image processing algorithms, hardware, or test sequence. With estimated cost and benefits of each option under consideration, the client was able to make informed decisions and improve the program as budget allowed.
The following image processing steps are currently included in the program utilizing NI vision tools:

1. Dot matric calibration for image distortion correction
2. Background image subtraction
3. Combining raw images to form a single composite image from each scan
4. Stitching of composite images of different areas of the part to allow analysis of larger parts
5. Brightness and contrast adjustment
6. Histogram and line profile of selected areas
7. Point-to-point measurements in real-world units
8. Color mapping to custom color scale

DMC engineers continue to work with the client to plan and implement new features for accommodating complex image processing challenges.

Learn more about our Test & Automation Solutions for Aerospace & Defense and contact us today for your next project.

The post Automated Vision Inspection for Aerospace appeared first on DMC, Inc..

Machine Vision Hardware

Since DMC’s customer wanted to package the inspection system and incorporate it into their existing packaging line, keeping hardware costs low was a priority. DMC and the customer created a custom real-time PC from standard components and installed the LabVIEW Real-Time operating system to run the application. Each GigE camera is connected to a dedicated network adapter. Inputs on the PCIe-8255R FPGA card connect to encoder and trigger signals from the packaging machine. FPGA outputs control the cameras and lights.

Image Acquisition and Results Tracking

The glue is often applied in two or more stages, requiring multiple inspection stations. Due to machine components that block the view from a single camera, each station may comprise two cameras, up to a total of four cameras connected to one vision controller. Since the cartons may vary in size and length, a line scan camera acquires images of variable size. Line scan cameras also simplify lighting, since they require a single line of illumination rather than a large 2D area. A concentrated line light helps keep exposure times low, allowing for high-speed image acquisition.

Each carton passes a photoeye to trigger the camera(s). A program running on the FPGA tracks the trigger signal and encoder position. After the inspection system determines a pass/fail result, the FPGA sends an output signal at a specified position on the line to signal to the packaging system that the carton is good. The packaging equipment rejects any carton that doesn’t have a pass signal. The timing diagram below illustrates the relative timing between the input trigger signal, image acquisition, pass/fail result determination, and output signal to the system.

User Interface

The customer uses an existing Windows application to configure their folding and gluing machines. The customer wanted to seamlessly integrate a user interface developed by DMC without requiring DMC to modify over their existing source code. To accomplish this goal, DMC developed a .NET application that is called by the existing application and covers a portion of the interface while it is active. The .NET application communicates with the LabVIEW Real-Time application via TCP messages to send configuration information down to the controller and to receive images (with result overlays) for display to the user.

Inspection Algorithm

The vision system checks the position of glue lines to verify proper glue application. The ideal glue positions and tolerances for each glue line are configurable per product (see the next section). The software creates a “Region of Interest” for each expected glue line. For each region of interest, the inspection algorithm verifies the following:

• Glue is present
• Glue starts within tolerance
• Glue ends within tolerance
• Glue width is within tolerance
• Gaps in glue (for dot patterns) are smaller than the maximum tolerance

The system also checks that there is no glue found outside of an expected region. Usually, unexpected glue is a bad thing. In some cases, glue is tolerable in a certain region but not required. The system allows the user to create a region that is ignored.

The image below shows glue lines detected by the system (in yellow), surrounded by the “Region of Interest” for each glue line (in orange).

Inspection Configuration

The inspection system needs regions of interest defined to perform the inspection described above. To configure the ROIs, the user has two options:

• Automatically “learn” ROIs based on several cartons
• Manually configure ROIs and tolerances

Typically, for a new product, the user will use the “automatic learn” feature. The system analyzes several cartons and creates ROIs around the average glue positions. If the glue on the template cartons deviates too much from carton to carton, the learn process must be retried. After the automatic learn is complete, the user may tweak the auto-generated ROIs to fine-tune the inspection.

Users can save the inspection configuration with a user-defined “job-name.” In the future, if the customer runs the same glue pattern, they can reload the same configuration by selecting the job name from a list on the user interface.

Inspection Result Display

The real-time vision system transmits images with results markup to the .NET application to display inspection results to the user. The system stores the last ten pass and fail images for review by the user. The user can choose different image processing and overlay options to help them analyze the images and determine failure modes.

The image below illustrates a failed image with some analysis options enabled. Red highlighting indicates bad glue and failed ROIs. Glue found outside of an ROI is circled because sometimes a speck of glue is hard to see.

Conclusion

DMC combined our expertise in vision systems, LabVIEW development, and .NET development to create a powerful and highly flexible inspection system. DMC’s direct customer sells the glue inspection system as an add-on to their existing folding/gluing machines allowing for a competitive advantage over other companies that create packing machines. End-customer facilities all around the world have the system installed.

Learn more about DMC’s vision systems, LabVIEW development, and application development services.

The post Glue Inspection Vision System For Packaging Industry appeared first on DMC, Inc..

Test Specification

The functional test specification required:

• BMS firmware flashing
• Cell emulation
• Thermistor emulation
• Temperature and voltage tests
• Communication over CAN and serial buses
• Analyzing LED status indicators

Each BMS test results in a report with metadata identifying the DUT, test system configuration, and test results with limits included.

Systems Engineering

DMC had to factor in many requirements including test accuracy, cycle time, operator ergonomics, and overall system envelope. DMC leveraged our internal fabrication shop and carefully selected external vendors like Pickering for robust hardware solutions. The software design leaned on DMC’s existing platforms and tools to minimize costs while maintaining performance and reliability.

DMC divided the hardware design into modular sub-systems: data acquisition box, Bed-of-Nails test fixture, and instrument rack. The rack design housed multiple Pickering LXI chassis containing cell simulation and thermistor cards. The interfaces between these sub-systems were well defined early in the design process, along with consistent communication to minimize design siloing.

Software Design

Software customizability was a major consideration for the client, DMC built upon its proven Battery Production Test (BPT) platform to meet client’s software requirements. Some highlights include:

• Intuitive user interface and user experience design
• Customizable test sequences through NI TestStand
• Traceable reports with MES integration
• Tracked and version-controlled test configurations (workspaces)

Conclusion

DMC delivered a robust and highly configurable system on a deadline, providing our client with BMS test capability ahead of their full battery pack assembly line. The solution detects manufacturing defects and provides traceable test results to each battery under test.

Learn more about DMC’s Battery Production Test (BPT) System, check out this BMS Power HiL Test System, or contact us to discuss your next project.

The post Bed-of-Nails Battery Management System PCB Test Station appeared first on DMC, Inc..

DMC started this project with a clear request to provide a BPT-based system within the Client’s strict budget.  DMC carefully analyzed their battery pack design, interfaces, and operating modes, and their overall testing requirements. This analysis revealed that the Client’s battery pack interface was relatively low-complexity, and their initial testing needs were rather basic. Since their requirements did not necessitate the use of DMC’s more full-featured BPT composition (see this case study), we initiated a new, lower-cost design, leveraging existing DMC hardware control modules. The result was a simple modular concept for achieving the basic battery pack tests that this Client required, while also meeting their aggressive budget demands.

This basic, but very cost-effective, BPT implementation allowed the Client to optimize use of their capital budget by purchasing only the test capability they needed for their current product. However, since this solution leverages the BPT platform software and NI hardware, they can still achieve the flexibility required for later expansion if needed.

Hardware System

To achieve this new BPT design, DMC leveraged the modularity of the NI platforms that form the basis of the BPT software and hardware system. Switching out the more capable, but also more costly, NI PXI systems for very cost-competitive NI cDAQ platform modules was easily accomplished with the NI DAQmx interface. DMC quickly transitioned our larger and more flexible BPT Low Voltage battery pack interface to a more basic one for control of all the required interfaces of a typical automotive battery pack: Vbat, IGN, GND, HVIL, CAN (see Figure 1). Similarly, DMC converted our larger and more complex ‘High Voltage Contactor Module” into the smaller and simpler sub-system shown in Figure 2.  While the resulting hardware system would have easily fit into a smaller test system rack, the Client wanted to reserve room for future expansion and selected a 36U high test rack, as shown in Figure 3. 

Software System

While the BPT hardware system was optimized for cost though selective hardware design, the software system of BPT was simply expanded to allow full control of the new low voltage and high voltage hardware sub-systems.  As such, users of this more cost-effective BPT system still have full access to the rich BPT software feature set, and full testing capability, including:

• Test Execution Management.
• Test Sequence programming using NI TestStand (Figure 4).
• Automatic and Manual run modes (Figure 5).
• Control of DMC hardware modules using pre-configured TestStand Custom Steps.
• Easy to use NI XNET CAN interfaces.
• Automated and customizable Test Results Reporting.
• Optional Custom Overview and Data Display Screens (Figure 6).
• Optional System Link integration. (Figure 7).
• Optional MES and Server Integration.
• Optional interface for common PLC communication protocols.

Conclusion

This new BPT model perfectly fit the Client’s battery pack test requirements, and their business needs:  Providing maximum test value, with optimized capital spend, and room for future expansion.

Learn more about DMC’s Battery Production Test (BPT) System and Custom Battery Pack and BMS Test Systems or contact us to discuss your next project.

The post Cost-Effective Battery Pack Test System appeared first on DMC, Inc..