At DMC, we’ve been at the forefront of this evolution, building robust, scalable, and future-proof battery test solutions for major OEMs, EV startups, and energy labs. As part of our journey, we’ve continued to work with a variety of legacy and cutting-edge battery cycler platforms, including a longtime staple in the industry: the Aerovironment battery cyclers, now rebranded under Webasto Charging Systems following their acquisition.  

If you walk into a battery lab or R&D center today, there’s a good chance you’ll still spot AV-900, ABC-150, or ABC-170 cyclers humming away in a corner. These workhorses have been around for years and have built a track record for staying accurate and dependable under heavy use. They’ve been put to the test on everything from older lead-acid cells to the newest high-performance lithium-ion packs, and they’re still getting the job done. The challenge isn’t the hardware—it still performs as reliably as ever, but the built-in software tools haven’t evolved alongside the rapid changes in battery testing. Many of the original integration options now feel dated. The good thing is, modern automation platforms and updated integration methods make it possible to breathe new life into these proven systems. 

Modernizing Control & Automation with LabVIEW and TestStand

At DMC, we’ve built dozens of test systems that interface with Webasto/Aerovironment cyclers using a variety of control strategies.

Common strategies include:

• Remote Operation System (ROS) scripting, which requires C-based development, offers basic command-level access—but lacks user-friendly interfaces and extensibility for long-term test programs.  
• Legacy DCOM Drivers for Windows applications like LabVIEW have been available but are notoriously outdated, lacking support for modern toolchains and requiring extensive debugging.  

To simplify the process, DMC has developed custom LabVIEW drivers, reusable APIs, and scalable frameworks that integrate Webasto cyclers into full-featured test automation platforms.

CAN-Based Communication remains the most effective, open, and performant option for high-speed integration—especially for systems with dual outputs or demanding test sequencing. These DMC solutions are built using NI LabVIEW, TestStand, and CompactDAQ/PXI platforms, often tightly coupled with MES systems, high-speed instrumentation, and safety interlocks.  

Whether retrofitting an older AV/ABC cycler or building a new test stand that supports multiple equipment types (Webasto, Bitrode, Chroma, Arbin, etc.), we ensure operator-friendly UIs, data-logging pipelines, and real-time feedback for test traceability and compliance.  

DMC has expertise and proven software control routines to support these common Aerovironment/Webasto cycler models:

• MT-30
• ABC-150
• ABC-170 / CE
• ABC-600
• AV900 / 900-EX

Typical Use Cases We’ve Enabled

• End-of-line (EOL) validation of high-voltage EV packs
• Functional verification of Battery Management System (BMS)
• Remanufacturing and warranty diagnostics
• High-throughput cycling for R&D across multiple chemistries
• HiL simulation of charge/discharge behavior with Webasto cyclers

In all cases, we help customers move beyond “bare-bones” PC control to a fully automated, traceable, and scalable test environment.  

Should You Build it Yourself or Work with a Partner?

DMC brings decades of expertise, a deep portfolio of turnkey battery test systems, and partnerships with industry leaders like NI, Webasto, and Microsoft. So, whether you’re modernizing a legacy test bench or developing a brand-new validation platform, you don’t need to reinvent the wheel or the driver stack. We’re here to help you accelerate development, reduce risk, and build for scale.  

Let’s Talk Battery Test Automation

Want to bring new life to your AV/Webasto cyclers? Looking to scale your test infrastructure with modern tools? Contact us to learn more about how DMC can help you integrate, automate, and future-proof your battery testing workflow. 

The post Modernizing Battery Testing with Webasto Cyclers and LabVIEW Integration appeared first on DMC, Inc..

In this post, I’ll detail some of the pros and cons, as well as the typical applications of Arduino microcontrollers, PLCs and custom embedded projects.

What’s the Difference?

Arduino is a common brand of microcontroller with built-in digital and analog, inputs and outputs. Their specific performance, memory, and input/output (IO) capabilities vary from model to model, making it easy to switch from one to another as changes are needed.

The tremendous number of tutorials for Arduino platforms also make them a great choice for learning programming and quickly prototyping early design. For this reason, Arduino’s an excellent choice for rapid prototyping and small-scale hobby projects.

PLC stands for Programmable Logic Controller. PLC manufacturers include Siemens, Allen-Bradley, Honeywell, Omron, Beckhoff, and countless others. Like Arduino, the performance memory and IO capabilities all vary from model to model, but, unlike Arduinos, most PLCs have little to no built-in IO.

Instead, most PLCs use IO cards that add digital and analog, inputs and outputs. These features contribute to PLCs for being known as more rugged then Arduinos since individual parts can be replaced as they wear out or are damaged. In general, PLCs are the solution of choice for rugged environments like factories, where reliability is paramount.

Custom hardware solutions, often called embedded solutions, is a generic name given to custom hardware and software designs made for specific applications. As a whole, it’s the most versatile of the three groups presented here, but individually each solution is typically tailored to do only one particular task. Because the processor(s), and hardware are largely designed specifically for the project the performance, memory, and IO can all be adjusted independently to suit the project’s needs.

Why are these Devices Used?

Arduino provides a free IDE (Integrated Develop Environment), that uses a slight variation of the common C programming language, making it a good starting point for new and experienced programmers alike. Most Arduino hardware is based on TTL (Transistor-Transistor Logic), with voltages of 5V or less (relative to ground), and current sourcing and sinking abilities of a few hundred milliamps total. This makes Arduinos well suited for battery or low power applications, although it limits their ability to control relays, motors, and solenoids.

Below is an example of a text based language used by Arduinos and most embedded projects. 

void ShowSplashScreen(){
  display.clearDisplay();   // clears the screen and buffer
  display.setTextSize(2);
  display.setTextWrap(true);
  display.setTextColor(WHITE);
  display.setCursor(15,5);
  DisplayString("DMC inc.", 8);
  display.setCursor(4,23);
  DisplayString("Do-Dad Box", 10);
  display.setTextSize(1);
  display.setCursor(19,43);
  DisplayString("(303) 223-1801", 14);
  display.display();
}

void ShowSplashScreen(){
  display.clearDisplay();   // clears the screen and buffer
  display.setTextSize(2);
  display.setTextWrap(true);
  display.setTextColor(WHITE);
  display.setCursor(15,5);
  DisplayString("DMC inc.", 8);
  display.setCursor(4,23);
  DisplayString("Do-Dad Box", 10);
  display.setTextSize(1);
  display.setCursor(19,43);
  DisplayString("(303) 223-1801", 14);
  display.display();
}

Below is an example of Ladder Logic used by most PLCs. 

Arduinos vs. PLCs

The most striking difference between Arduinos and PLCs is the size. PLCs have been ruggedized to work in industrial environments to work at higher voltages (typically 12V-24V) and use differential voltages to reduce noise and interference on communication lines. The output cards also have the capability of sourcing or sinking multiple amps, specifically for relays.

Most PLC applications are expected to work for years if not decades without interruption, and for the most part, they do. Programming PLCs is mostly done in Ladder Logic, an easy to read and modifiable language based off relay wiring. Combined with the visualization tools most modern IDEs have, it’s relatively easy to identify and fix faulty wires, sensors, and actuators.

While Arduinos and PLCs are prebuilt controllers, with pre-selected processors and IO capabilities, embedded projects have a near limitless variety of processor, IO, and hardware. This variety makes custom embedded projects the solution of choice for large volume or consumer goods, where even small savings on part costs can quickly add up to significant overall savings. The downside to embedded programming is the longer development time. Every aspect that is designed custom takes time and upfront cost.

Whether you’re using an Arduino, a PLC, or designing everything from scratch, it’s important to know your tools and be able to select the best tool for the job.

DMC provides solutions for all three of these controls. Contact us today to learn about how we can help you with your automation and control project. 

Learn more about DMC’s Manufacturing Automation and Intelligence Services.

Learn more about DMC’s Embedded Development and Embedded Programming Services.

The post Automation with an Arduino, PLC, or Custom Embedded Controls? appeared first on DMC, Inc..

The solution I discovered is very quick but a bit unintuitive, so I wanted to pass along that information here. This blog will be short and sweet.

NI MAX could see my MXI Connection but could not recognize the chassis or its modules.

Solution

If your PC is unable to see your modules associated with your PXI chassis, try shutting down and then repowering your PC while your NI Chassis is connected and powered on with its associated modules connected. It is important to note that you must Shut Down your PC, rather than just restarting, for reasons I explain below.

If you shut down and repower your PC while the PXI Chassis is powered-on and connected, and you are still unable to see some or all of your chassis modules, try repowering it again with just one module connected at a time. You should be able to do this for all of your modules one by one until NI-MAX can see all of the modules within your PXI Chassis.

Success! Shutting down my PC allowed me to see my PXI Chassis and Modules

Why do I need to shut my PC down (instead of just restarting)?

PXI chassis modules connect to PCs by writing an enumeration value into the System BIOs of your PC. National Instruments has a great blog to explain how this process works and how you can ensure your PC has the Bus Resources required to store your PXI module enumeration values.

The practical impact of this process is that your PXI chassis modules will be invisible to your PC until you power on your PC from a shut down state while the modules are connected. System BIOS are not modified during a PC restart, so simply restarting your PC will not affect your PC’s ability to recognize a PXI Chassis Module.

It is possible that during a PC startup, your PC may view some of your PXI chassis modules but not all. If this is the case, it may help to power on your PC with just one PXI module connected at a time. Most PC’s retain their System BIOS values between shutdowns, so you can iteratively write each module’s enumeration value to your PC’s BIOS until all are visible to your PC and can be viewed in NI-MAX. Some industrial PC’s do not retain this enumeration portion of their system BIOS between shutdowns. For these PC’s, you will need to ensure your PXI chassis is powered on and connected with all of its modules every time your PC starts up.

This System BIOS behavior applies no matter how your PXI Chassis is connected to your PC (MXI cable directly, MXI cable to express card, etc.).

Bonus–Automatically Power on your Chassis using your PC

With one industrial PC that I used, I found that even after I had successfully connected to my PXI chassis and its associated I/O modules, I still lost connection to them every time I powered off my machine.

My machine worked by powering on my PC and then, slightly after, turning on my PXI chassis. By the time my PXI chassis had turned on, it had already missed the opportunity to write to my PC’s system BIOS. The industrial PC that I used did not retain the chassis modules’ enumeration values after a shut down, so I would lose connection to the modules every time I turned my machine off and on.

The only solution I could perform was to leave my machine and PXI chassis powered on while manually shutting down and repowering my PC. Only then, after my PC had booted up with the PXI chassis powered on and connected to it, could I see my PXI modules using NI-MAX. The problem with this solution was that shutting down and repowering my PC every time I turned my machine off and on was a tedious and time consuming process, and it left room for confusion from new operators.

Luckily, NI has an executable that can trigger your PXI chassis to automatically turn on whenever a PC that is connected to it through an MXI cable turns on. This will trigger works before your PC accesses its system BIOS, so that every time you shut down and repower your PC, the PXI chassis can write the appropriate enumeration values anew.

You can also find the executable to configure your PXI chassis.

Once I used this executable, my PXI chassis turned on at the same time as my PC, and I was able to power on my machine and immediately achieve connection between my PC and the PXI modules.

Conclusion

Although shutting down your PC is a very quick debugging step to address your PXI modules’ connection issues, many PXI users may not be aware of the PXI module to PC connection process, and thus will not know to try this troubleshooting step. Hopefully this blog saves you some time, and helps you along the way to a successful project using the NI PXI chassis!

Do you have an out of date LabVIEW project that you’re looking to upgrade? Check out our test and measurement automation services to find out if DMC could be a good fit for you!

The post Why Can’t I Connect to my NI PXI Chassis Modules? appeared first on DMC, Inc..

Upgrading from Fieldpoint to CompactDAQ modules can be a rewarding and worthwhile process for the success and longevity of any system. However, significant hardware and software differences between CompactDAQ and Fieldpoint modules can complicate upgrades, requiring a complete driver rewrite and complex hardware decisions.

Below is a guide for upgrading your system from NI Fieldpoint to CompactDAQ modules including the most commonly-made mistakes and how to avoid them.

Replacing Hardware: Chassis

Fieldpoint(FP) and compactDAQ(cDAQ) Input/Output(I/O) devices center around the chassis—communication equipment that interfaces between compatible NI I/O modules and an external host such as a PC running your LabVIEW application.

When looking for a cDAQ chassis to replace your Fieldpoint controller, consider the following:

1. Communication Protocol to Host: cDAQ chassis can communicate with PCs over ethernet, USB, or WiFi.
   
   You should select your chassis based on the communication abilities and available ports on your PC. To ensure a successful upgrade, consider simply matching the communication protocol that your FP controller used, which will be either ethernet or serial (USB).
    
2. Number of Slots: A Chassis contains slots that communicate with I/O modules via its backplane. (See pic below). Each of your I/O modules takes up one slot.

Replacing Hardware: I/O Modules

The chart below shows applicable properties to align when procuring cDAQ modules to replace your FP modules, depending on the I/O type. Here, we look at analog and digital inputs and outputs along with a special type of analog input: a thermocouple.

While factories contain diverse sets of conditions and no one list can encompass all relevant properties for any FP to cDAQ swap, the properties detailed in this chart must be aligned for any potential upgrade.

Terms

I/O Type: The way signals received from or given to your project hardware are interpreted by your I/O device. If your FP module had a channel for an analog input current value, your cDAQ I/O must also include a channel of this type.

I/O Range: The range of your cDAQ channels must match those of your FP. If your FP channel expects a 0-20 mA analog signal, your cDAQ channel must be compatible with that range configuration. Larger ranges can work but may involve adjustments to the data scaling performed on that channel.

Number of I/O Channels: You must have the same or a greater number of channels than your FP I/O for each I/O type/range.

Shared COMs: Common references allow NI modules to interpret differential signals relative to a fixed value. If your FP module had COM ports and they were unshared, your cDAQ module may need to have unshared COMs as well.

Sinking vs. Sourcing (digital modules only): In Digital I/O, sourcing devices provide the power or a positive power differential to push the current through the load while sinking devices provide a path to ground. The sinking/sourcing status of your Digital I/O modules must match from your FP to cDAQ modules.

Supported Sensor Types (thermocouple only): Thermocouples read temperature by using a differential voltage signal across two wires of dissimilar metals. The type of thermocouple refers to which two metals are compared. Types include J, K, E, T, N, B, S, and R. Many FP and cDAQ modules are compatible with many thermocouple sensor types. Your cDAQ thermocouple replacement should be compatible with whatever thermocouple type your Fieldpoint module is configured for.

Building your NI-MAX Configuration

FP modules are configured via iak files that can be opened in NI-MAX. These files group controllers and modules into folders containing I/O tags that represent each channel. Below, we see a fieldpoint configuration of an FP-2100 controller with several I/O modules. The Analog Output 200 module (in slot 5) is extended revealing 8 configured channels.

Fieldpoint module I/O channels are passed into software drivers in your LabVIEW application via these configured NI MAX tags. For a single channel, a path string into your FP driver will link through each hierarchical folder to arrive at your channel. The path string for slot 5’s AO-200 module channel 0 is: “Fieldpoint\MyFieldpointCongif\cFP-AO-200 @5\Channel 0”.

Note: FP drivers can access all channels in a module in order from low to high using the "All" tag. This passes in the FP data from channel 0 to channel 7 as a single task. To replace this driver functionality without necessitating extraneous code rewriting, you should create an analogous DAQmx task with the same channels in the same order as your FP module. This way, you can pass that task’s data directly in to replace your FP data and can handle these values identically in the software.

To build your new cDAQ NI-MAX configuration, you will first need to add your cDAQ chassis and associated I/O modules to the “Network Devices” folder of the “Devices and Interfaces” folder. If you are building your configuration with a PC that is properly connected to your cDAQ module, you can add these devices to your configuration (if they do not already show up automatically) by right clicking on Network Devices –> Find Network NI-DAQmx Devices.

If you want to build your configuration without connecting hardware to your PC, you can do so with a virtual chassis.

Add a Virtual Chassis and Configuration

1. Right-click on Devices and Interfaces –> Create New.
   
   

   

2. Select Simulated NI-DAQmx Device or Modular Instrument –> Finish.
   
   

   

   
    
3. Select your chassis (CiompactDAQ Chassis –> your chassis name), and select OK.
   
   

   

   
    
4. Once your chassis is created, add in your I/O modules: right-click the chassis –> configure your simulated cDAQ Chassis.
   
   

   

   
    
5. Add your modules to the appropriate slot.
   
   

   

Best practices for handling your new cDAQ NI-MAX configuration are to create virtual channels–which are linked to cDAQ hardware (connected or simulated)–for each I/O point. These virtual channels can stand alone as I/O tags or be grouped together into tasks, both of which can be passed into your LabVIEW software driver (see next tip).

You should create global virtual channels or tasks for each of your FP I/O tags. As mentioned in the NOTE above, FP tags to "All" module I/O should be replaced with a DAQmx task that uses the same I/O channels in the same order as they are in your FP module.

Creating a Global Virtual Channel

In the NI-DAQmx Global Virtual Channels folder, you can:

1. Right-click –> Create New NI-DAQmx Channel.
   
   

   

2. Select the appropriate I/O type (example below shows analog voltage input).
   
   

   

   
    
3. Select the correct channel from the list of compatible connected or simulated DAQ physical channels.
   
   

   

   
    
4. Name the channel and finish.

Creating a Task from Virtual Channels

1. Right-click NI-DAQmx Tasks –> Create New NI-DAQmx Task.
   
   

   

   
    
2. Select the first virtual channel of your task (select type, then tab to Virtual). Add the channel to retain the link to your global virtual channel. Copying the channel will copy the physical I/O of the virtual channel at that moment, but will not adjust if the virtual channel’s physical path changes.
   
   

   

   
    
3. Name your task and finish.
   
   

   

   
    
4. Add other global virtual channels as necessary to complete the desired task (Plus button, then select channel type).
   
   

   

Replacing Software Drivers

Both the FP and DAQmx pallets center around two polymorphic VIs: Read and Write. In many cases, these VIs can stand alone as LabVIEW’s only window into data collected by the modules.

FP Read/Write VIs accept a Fieldpoint IO Point which links to a tag you created in NI-MAX. Examples of I/O points based on the tags we review earlier are:

1. “Fieldpoint\MyFieldpointCongif\cFP-AO-200 @5\Channel 0”
2. “Fieldpoint\MyFieldpointCongif\cFP-AO-200 @5\All”

For FP Read, users can also enter the I/O type. For FP Write, users must indicate a value (True/False for boolean commands, numeric for analog commands) and can set the driver to only write to the I/O module on value change. For both VIs, users can loop-in an error wire.

The DAQmx pallet also centers around the polymorphic read/write VIs. Although these can be configured in many ways, the general best practice is to wire in your NI-MAX-created virtual channel or task as a task/channel constant. The drop-down of your channel/task constant will automatically populate based on the compatible, configured tags in NI-MAX. You can also set timeout values to adjust the time that LabVIEW will wait for feedback before erroring.

Here we see the drop down for a channel constant fed into a single channel analog read VI with a set timeout of 10 seconds (the default). Both our AIVoltageFlowmeter and VoltageFrom HeightSensor, voltage analog inputs we configured in NI-MAX, appear in the drop-down. The write VI can be configured as a polymorphic VI and wired in the same way.

For best practices, I recommend creating custom reusable VIs that accept a channel/task, timeout (optional), error (very strongly recommended), and value (for outputs). This will allow you to make edits to your software drivers in a modular way. For analog and digital I/O modules, custom VIs should be created for each variation of these factors:

1. Analog or digital
2. Input or output
3. Accepts one virtual channel vs. a task
4. Variations to option wirings such as timeout

See below for an example of a reusable digital input driver that accepts one global channel and clears the task when it's finishing. Clearing the task is not required, but it does periodically abort the boolean driver thus releasing any resources the task reserved and avoiding unnecessary memory allocation.

Variations of custom DAQmx VIs can be created for many applications and can use any of the VIs in LabVIEW's extensive DAQmx pallet.

This blog will not review all driver possibilities. New users can accomplish simple I/O read/write applications using only the DAQmx Read and Write polymorphic VIs.

Wiring in Your New I/O

For some hardware upgrades, rewiring your new I/O modules can be as simple as a one-to-one swap. However, differences between FP and cDAQ modules create some potential pitfalls.

1. FP modules may have Vsup ports associated with certain channels. These ports are for providing external 24V power to a sensor/device and they do not affect the signal that is read/written. If your FP module channel includes a Vsup port that is wired out to your device but your cDAQ replacement does not have a Vsup port associated with that channel, you can simply rewire that connection to any 24V DC power supply.
    
2. Some FP modules have COM ports for each channel but share COMs among the entire module meaning all COM ports in the module are connected. cDAQ modules often streamline this configuration by including only one COM port per module. If your FP module shares COMs, you can simply wire all COMs together into the single COM port of your new cDAQ module. If your FP module does not share COMs, your new cDAQ module may need to have COM ports for each channel as well to allow for the variability that was present before your upgrade.
    
3. Your FP analog modules may have channels that are configurable for current or voltage signals with each channel including ports for Vin, Iin, and COM signals. For each channel, either the Vin (voltage signal) or Iin (current signal) port should be used, and both may be referenced to the COM port of the associated channel. Most cDAQ analog channels are permanently configured to either read/write a set voltage or current, so you will need to wire your FP current/voltage analog signals into their appropriate cDAQ counterpart. If your FP module includes analog input channels that are not connected to COM ports, consider grounding these ports for more consistent readings.

Conclusion

Upgrading your system from Compact Fieldpoint to cDAQ hardware can be a complicated process, but the increased robustness, modernity, and performance of cDAQ modules make the process well worth the effort. Once you’ve selected a chassis, specced your I/O modules, built the NI-MAX configuration, rewritten your software drivers, and wired in your new I/O, you will have successfully upgraded your I/O devices and significantly improved your machine.  

Find out how we replaced Fieldpoint modules with DAQmx modules for a customer: “NI-DAQ System Modernization” 

Do you have an out of date LabVIEW project that you’re looking to upgrade? Check out our test and measurement automation services to find out if DMC could be a good fit for you!

The post Tips and Tricks for Upgrading your NI Compact Fieldpoint to CompactDAQ appeared first on DMC, Inc..

Based on other requirements of the software, DMC chose a PC-based control system using National Instruments hardware. The customer wanted the control computer to be located far away from the electrical panel that contained the data acquisition and control hardware. Given the desired distance between the PC and control panel, the customer requested an Ethernet CompactDAQ (cDAQ) system. However, concerned about the latency of the Ethernet connection, DMC decided to compare the functionality of the following data acquisition hardware:

• NI cDAQ-9188 – NI CompactDAQ 8-Slot Ethernet Chassis
• NI cDAQ-9178 – NI CompactDAQ 8-Slot USB Chassis

National Instruments published an article on How to Choose the Right Bus for Your Measurement System. In this article, they compare various buses in five different categories. The comparison for USB to Ethernet is copied below:

The Waveform Streaming category makes the Ethernet cDAQ appear “faster”. Waveform Streaming defines how quickly a large block of buffered data can be transferred to the PC. In order for our control loop to function properly, it needs to read an input, then calculate and set an output as quickly as possible. For this control application, Single Point I/O is the most critical category since we have a small amount of data (i.e. a “single point”) that we need to quickly update with minimal latency.

To test this, DMC implemented a program with a control algorithm which used a 10ms loop rate. This program was then run on a USB cDAQ and an Ethernet cDAQ. The result of the test was clear: a USB cDAQ is significantly better for high-speed control applications. The Ethernet cDAQ was approximately 5 times slower – the control loop still ran at 10ms, but the output to the hydraulic cylinder was delayed by 40-50ms, which completely threw off the control algorithm.

The graphs below clearly illustrate the effect of the Ethernet’s latency. The exact same control algorithm and loop rate was used to generate these graphs, the only difference was the hardware.

Ethernet:

USB:

In the end, DMC chose to use the USB cDAQ based on its vastly superior performance in this particular application.

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

The post Comparing Ethernet and USB cDAQs for Control Applications appeared first on DMC, Inc..

A variety of business demands can require a company to convert their industrial equipment from one vendor’s gear to another supplier’s tools. The most common reasons for conversion include: improving market position, maintaining and keeping up with corporate standards, pursuing new business opportunities or increasing financial advantages. In any of these instances, software is likely the biggest area of concern during transition. Nonetheless, conversions can be managed effectively when companies plan their conversion strategy well. 

In light of these concerns, John will talk about three different approaches to converting software code for a company that is adapting their industrial equipment from one vendor’s to another’s.

Benefits of Attending:

• Learn the advantages of converting industrial equipment and software
• Understand pitfalls and areas of concern in order to ensure a smooth transition 
• Delve into three strategies for converting software and learn the pros and cons of each approach
• Explore conversion tools available to help you speed up the conversion process
• Find out when a systems integrator can bring value to your conversion
• Discover how to choose the right SI to meet your unique needs

Presenter Bio:

John Sullivan holds a B.S. in Mechanical Engineering from Rose-Hulman Institute of Technology with a certificate in robotics. He is a Licensed Professional Engineer in the State of Illinois, and is a Certified Siemens Solution Partner, LabVIEW Developer, and Microsoft Certified Professional (MCP). John’s previous work experience includes Solar Turbines and General Electric-Aviation. He enjoys athletics of all kinds, including rugby, volleyball, and running, as well as outdoor activities such as backpacking and skiing.

Register for Changing Machinery, Changing Software.

The post Informational Webinar 11/12: Changing Machinery, Changing Software appeared first on DMC, Inc..

The first time I saw a blue LED was in a trade show in 1998. One booth of lighting equipment has a light that was a brilliant deep blue. I asked the man about the product, and he said the blue LEDs were just out, and cost him $15 each. His small light product had hundreds of them – hand soldered in a solid square pattern. 

Today, blue LEDs can be found everywhere. In our homes and businesses, white LED lighting is becoming more popular as the most efficient form or architectural lighting. White LED products actually work by placing blue or ultraviolet LEDs behind white phosphorescent materials. We are more likely to see blue LEDs in their raw form as part of today’s brilliant outdoor advertising signs and stadium displays.

In machine vision, we use blue LEDs as general purpose lighting for monochrome systems. In 20 years since their invention, blue LEDs are twice as bright as any other color. We also use blue LEDs in combination with red and green to create balanced lighting that can appear white, or about any other color. The same technology is also used in the multi-color mood lighting of my car. 

Because blue light has a shorter wavelength than other visible light, it makes clear images in microscopic and medical imaging. In that field, blue, or multi-color light sources including blue have largely replaced incandescent light sources with color filters.

It took 30 years from the commercial production of the first red LEDs to the production of the first blue LEDs. And during that time the importance of blue was not lost on anyone in the industry.  It obviously took great skill and dedication to make this leap which we all now benefit from.

So, thank you to Isamu Akasaki, Hiroshi Amano, and Shuji Nakamura for your invention and congratulations on your prize.

The post Nobel Committee Recognizes Inventors of Blue LED appeared first on DMC, Inc..

Since the unit showed no signs of powering on, the first order of business was to verify the main power source. Finding nothing wrong with the 12V external power adapter, I set off to get my hands dirty and investigate the internal circuitry.

Thankfully, NI made the DAQ very easy to disassemble. The entire PCB assembly slides out in one piece after the removal of a couple screws. Nothing seemed charred or obviously damaged and nothing dramatic happened when I tried giving it power again. So, I started the highly technical operation of poking around at various chips to see if anything was hot.

Nothing felt scalding hot, but there was a section of circuitry warm enough to raise suspicion. Especially so because a nearly identical set of components nearby was cool to the touch. The hot circuits included an LM2673-ADJ adjustable switching regulator (U54) connected to a 33uH power inductor (L6) and 5A-rated BAT540C Schottky diode (D25). The circuit was regulating the 12V from the external adapter to a somewhat strange 1.2V. The neighboring circuit, on the other hand, was taking the same 12 volts and outputting a standard 3.3V.

Checking the datasheet for the LM2673-ADJ, I discovered that its output voltage is controlled by a resistive voltage divider. I found the appropriate resistors in the PCB, measured their resistances, and calculated the designed output voltages for the two regulator circuits. The circuit supplying 3.3V was designed as such while the one outputting 1.2V should have been outputting 5V.

The most likely cause of this discrepancy was that the regulator was supplying excessive current due to a damaged component somewhere on the 5V power rail. In doing so, it would trigger its over-current and/or over-temperature protection and reduce its output voltage. I checked and found that there was indeed a very low amount of resistance between the 5V power rail and ground. Whatever component was causing this would be sinking a lot of current and therefore necessarily be quite hot.

It didn’t seem like the sort of thing that’d be hard to find.

My prime suspect was diode D25 that sits across the regulator’s 5V output and ground. I removed it only to find that 5V and ground were still shorted together. I verified with my multimeter that the diode was damaged and contributing to the short, but it clearly wasn’t the only offending component. Thinking that the problem was isolated to the immediate vicinity of the regulator, I removed output capacitors C125, C126, and C127. No dice. A little desperate, I removed the regulator chip itself. 

Using an adjustable current limit lab power supply, I can feed power directly into the shorted 5V power rail. Whatever component was causing the short would surely heat up enough for me to detect. With the power supply voltage limited to 5V, I started cranking up the current. Eventually, I found myself pouring over 3A into the circuit board at a mere 1V.

I found two potential culprits. Just above the 3.3V regulator circuit, there was a circuit block that contained a power inductor designated L11 and a tiny 6-pin surface mount component designated Q38. Both were intensely hot. Under the assumption that inductors don’t just go off and fail, I turned my attention to Q38. I could make out the markings “A41AC” yet no amount of searching yielded any useful results. Frustrated, I decided to remove the chip altogether.

As soon as Q38 was gone, the short-circuit I was hunting went with it! I knew the DAQ wasn’t fixed, but I couldn’t stop myself from attempting to power it on right there. All I had to do was plug in the external 12V power brick while simultaneously using the lab power supply to replace the 5V regulator I removed.

Once connected over USB, NI MAX detected the DAQ immediately. I was ecstatic. It amazed me that the device seemed to be functioning normally. The digital I/O seemed to work, so I went to test what I needed from the DAQ in the first place: analog output. The behavior I saw was puzzling. When commanded to output +10V, I would get +2.5V. Similarly, commanding -10V would result in -2.5V and the voltages in between scaled linearly.

Of course, the one feature I needed from this DAQ was the one that was still broken.

When additional searching turned up nothing useful regarding the mystery chip, I started reverse engineering the schematic for the circuit block in which it lived. Very fortunately for me, just like the 5V and 3.3V regulators from before, there was a doppelganger to this circuit block as well. It too contained an A41AC mystery chip. Here is the partial schematic I came up with:

Q38 and L11 were the components that I had felt getting very hot. Q39 and L13 were cool to the touch. These two circuits look like classic voltage boost converters. To get a better feel for how these circuits worked, I used an oscilloscope to probe the undamaged circuit at the points indicated on the schematic.

Let’s assume the mystery chips Q38/39 are N-channel enhancement mode MOSFETs. Pins 1, 2, 5, and 6 would be the drain, pin 3 would be the gate, and pin 4 would be the source. On the undamaged circuit, the scope shows a ~1MHz square wave with ~80% duty cycle at the gate. When the gate is high, the transistor turns on and pulls the drain to ground. This forces current to increase in L11, allowing it to store energy. When the gate is low, the transistor turns off, forcing the current stored in the inductor to flow through the flyback diode, D23, to the output of the circuit. This operation matches exactly that of a boost converter operating in continuous mode. 

The relevant equation to be aware of here is Duty cycle = 1 – Vin/Vout. Since Vin is 3.3V and Vout is 20V, the duty cycle should be 83.5%. This result matches closely to what I saw being fed to the MOSFET gate. Out of curiosity, I checked what kind of waveform was being fed to the damaged circuit and found a ~1MHz square wave with ~75% duty cycle. With Vin being 5V in that circuit, Vout is predicted to also be 20V. At this point I speculated that the undamaged circuit was used to supply the reference for the DAQ’s +/-10V analog input and the damaged circuit supplies the reference for the analog output. With Q38 removed, the broken boost circuit would simply output the 5V that it was fed. This explains why I could only get the DAQ’s analog output to swing between -2.5V and +2.5V.

Now it’s time to tackle the issue of actually finding a replacement part for Q38. Using calipers, I measured the dimensions of the chip to match the TSOT-23-6 package. Searching for N-channel MOSFETS in this package on DigiKey, I found several pin-compatible parts!

Extremely satisfied with myself, I ordered a FDC5661N_F085 which had the highest rated power rating at 1.6W. I also grabbed a BAT540C and LM2673-ADJ to repair the 5V regulator circuit before running around the office to gloat over my victory.

The parts came in the mail the next morning and I eagerly got to work soldering them in their places. I first restored the 5V regulator circuit which fired up without a hitch. After that I dropped a new MOSFET to replace Q38. Giving myself a pat on the back, I powered up the DAQ to run a final test. This time, none of the DAQ’s status LEDs showed any activity. Not five seconds later, I detected a burning smell and saw the dreaded trail of smoke emanating from the new MOSFET.

After cutting the power and staring at the circuit board for a while in bewilderment, I set off to find out what went wrong. I made sure that I installed the MOSFET in the correct orientation and verified that its drain and source were not shorted together. The fact that the new MOSFET was burning up so quickly and taking out the entire power rail with it could mean that electrically it was connected directly across +5V and ground.

I decided it wouldn’t hurt too much to try to see what was going on with the oscilloscope. I hooked it up to the new MOSFET just as I had done previously with the undamaged circuit. I was able to get this trace by briefly toggling power to the board:

The strange waveform didn’t reveal much more information than I already knew. At least it was interesting to see the electrical havoc being wreaked.

I checked diode D22 to make sure nothing on the output side of the circuit could interfere with the MOSFET. That leaves us with a single remaining suspect: power inductor L11. Since inductors are simply coils of wire, I was incredulous that it could be damaged. Furthermore, a resistance measurement will reveal that they are indistinguishable from a simple wire.

Lacking an inductance meter, I set about building an inductor test circuit. Inductors resist changes to the current flowing in them, as shown by their characteristic equation: V = L * (di/dt). Applying a voltage V across the inductor will cause current to rise linearly with a slope of (V/L). The test setup I made looked like this:

The inductor under test was connected in series with a 1 ohm resistor. The oscilloscope measured the voltage across the resistor which would indicate how much current was flowing at any given time. The capacitor would be charged to 10V before being discharged through the inductor. Its purpose was to provide a low-impedance voltage source to the inductor under test.

First, I ran my test using a known good 33uH inductor I found in the lab. Here is what the scope trace looked like:

The current initially rose linearly for about 10us before jumping up to 10V. The discontinuity happened due to the core of the inductor reaching saturation. The slope of the linear region was slightly under 0.4V/us (which corresponds to 0.4A/us). Since V = 10V, we’d shown, experimentally, that the inductor was around 25-30uH.
I removed L11 from the circuit board and ran the same test. Here is the scope trace:

This time, the current jumped up to 10A immediately, showing that the inductor was behaving as a short. When this inductor shorted for an unknown reason, it caused a huge current to flow through Q38 whenever it was switched on. I figured that the 5V regulator would go into current limiting mode, dipping its output voltage to the 1.2V I measured at the beginning of my investigation. After several red herrings, we’d finally found the actual culprit!

The only thing left to do was to find a suitable replacement inductor. I found and ordered a 100uH inductor (Bourns PM3316-101M-RC) that had an almost identical footprint to our shorted inductor. In the meantime, I was impatient to get the DAQ working again. Referring back to the Wikipedia page on boost converters, we could see that as long as they were operating in continuous mode, the output voltage depended only on the switching duty cycle and was completely independent of inductance.

Feeling adventurous, I shoehorned the 33uH power inductor I found lying around into the circuit. I also replaced Q38 with another fresh MOSFET. With the oscilloscope connected, I cautiously turned on the power. Just like that, the DAQ came to life without any drama. I measured a solid 20V output from the repaired boost converter circuit and the scope trace showed a clean waveform:

I connected the USB DAQ to my computer and was able to get accurate and precise analog voltage outputs across the entire +/-10V range. Exhausted and relieved, I finally started on the proof-of-concept project for which I need the NI USB-6351 in the first place.

Learn more about DMC’s LabVIEW programming services.

The post Repairing an NI USB-6351 X-Series DAQ appeared first on DMC, Inc..

The post USB Charging Overview appeared first on DMC, Inc..

DMC has sent engineers from each of our Chicago, Boston, and Denver offices to present on topics ranging from automation, to battery management systems and vision inspection. Catch today’s presentation entitled Real-World Techniques in High-Speed Vision Inspection given by Darren Jones, Project Engineer at DMC; Ken Brey, Technical Director at DMC; Eric West, Project Engineer at DMC; and Daniel McCarty, Sr. Software Development Manager at W.H. Leary Co., Inc. 

The presentation will address the urgency of vision inspection performance in the age of fast-paced automation. Using case-studies and examples from recent projects, Jones, Brey, West and McCarty will offer advice and insight on effective, high-speed vision inspection. The team will also cover hardware selection, custom training and more.

Real-World Techniques in High-Speed Vision Inspection will be held Wednesday, August 6, 4:45pm-5:45pm in Room 17B.

The post 20th Annual NI Week Conference Vision Inspection Presentation appeared first on DMC, Inc..