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. 

Ready to take your Test and Measurement project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals. 

The post Modernizing Battery Testing with Webasto Cyclers and LabVIEW Integration 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..

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 piece details the design and implementation of a thermoregulatory chamber that DMC engineers collaborated with Lurie Children’s Hospital staff to develop. Used to diagnose sweat abnormalities in children with rare diseases, development of the chamber required not only the effort of DMC as a system integrator (SI), but the partnership of the hospital clinicians, researchers, architects, construction crews and patients as well. 

Performance, safety, tolerance and accuracy were of the highest priority in terms of development and functionality, which led our engineers to choose the National Instruments compactRIO to operate the system. Data collection was another key feature for which unique and specialized requirements were made.

Most importantly, the chamber was designed with children’s comfort in mind, and “the team looked for solutions that would be as noninvasive as possible.”

Since implementation of the system, the hospital has made numerous diagnoses that have better aided in patient treatment. DMC is proud to be a part of an initiative aimed at improving the quality of life for children nationwide.

Learn more about this project below.

The post DMC featured in ISA InTech Magazine appeared first on DMC, Inc..

A recent project at DMC brought this social benefit even closer to home with the opportunity to work with the Ann & Robert H. Lurie Children’s Hospital of Chicago. 

DMC was approached with a very special need—to develop the world’s only Thermoregulatory Chamber designed and built from the ground up specifically for children. DMC partnered with the hospital clinicians, researchers, architects, and patients to deliver this one-of-a-kind solution.

“Working with DMC was a spectacular experience for us,” said Dr. Debra E. Weese-Mayer, Chief of the Center for Autonomic Medicine in Pediatrics and Professor of Pediatrics for Northwestern University’s Feinberg School of Medicine. “We actually found kindred spirits who understood what our needs were for building a chamber specific to children.”

Learn more about DMC’s partnership with the Ann & Robert H. Lurie Children’s Hospital of Chicago in the video below.

Learn more about DMC’s expertise in LabVIEW programming for real-time and FPGA.

The post Engineering Meets Pediatric Medicine at Lurie Children’s Hospital appeared first on DMC, Inc..

Anyone with a significant .NET background who has also worked with LabVIEW has probably stumbled on NI’s .NET tool, Measurement Studio. I know to some that NI providing .NET tools sounds kind of like Twitter having a Facebook page, but the fact is that .NET does a lot of things really well and becomes ultra-powerful when coupled with NI’s unbeatable hardware.

I had looked into Measurement Studio some in the past but had never gotten the chance to try it out, so I was as giddy as Ken working on a new Geek Challenge questions. Fellow Pollock Anna Kozminski showed within the first few minutes that a simple DAQ application could be written in just 6 lines of code! In addition, it integrates with DAQ Assistants to configure channels, works with NI-MAX, and even has a TDMS API.

Even if the features and functionality of Measurement Studio alone hadn’t been enough to convince me, today also offered a session on WPF tools for Measurement Studio new in 2012. If you aren’t familiar with WPF, it’s a Microsoft platform that facilitates rich, user-friendly UI’s and extensive use of the MVVM architecture to cleanly separate program logic from visual presentation. As a developer, WPF and MVVM allow you to code in the best way, creating clean, streamlined program logic; pretty, user-friendly screens; and a manageable view model to glue the two together.

Well, NI seems to have imbibed the Kool-Aid too because, with the new 2012 release, Measurement Studio now includes WPF controls. These new, professional, modern controls let you use NI hardware with a brand new, totally customizable look that far exceeds what you can do natively in LabVIEW and definitely blow LabVIEW 1.0 out of the water. 

With the WPF controls and Measurement Studio, you can create outstandingly usable interfaces that increase user productivity, reduce operational errors, and differentiate your applications from the rest of the field.  Last but not least, the NI team made sure to go all the way with WPF, implementing data binding and dependency properties, meaning that a true MVVM implementation with Measurement Studio is tantalizingly accessible.

Now, I’m sure that none of this means that LabVIEW is going to be phased out, as FPGA, RT, and vision applications are still better implemented in LabVIEW, and there will always be customers who prefer one over another. However, I am very much looking forward to opportunities to implement Measurement Studio and WPF.

The post NI Week 2012 – Data Acquisition Done Right – Happy .NET Day! appeared first on DMC, Inc..

The aim of this discussion is to outline key questions that will be helpful in selecting and asset management solution for projects involving multiple National Instruments targets. I have taken specific focus on Real-Time and FPGA platforms, as they are most commonly deployed in large quantities. Let’s begin with some basic understanding of asset management:

What is asset management?

Asset management is generically described as a system that monitors valuable resources.

In large volume deployments, it is critical to have an understanding of the state of critical components to properly maintain and optimize the uptime of a given system. For example, a common application of asset management technology surrounds fleet vehicles. For a large number of vehicles, say sanitation trucks, a central monitoring system is often used to monitor routes, break downs, and track maintenance schedules which ensure each vehicle is optimized for continuous use.

How does asset management relate to National Instruments?

As larger volume systems are deployed, groupings of PXI controllers, multiple cRIO embedded systems, OEM SBRIO integrated products; it becomes critical to understand the technology available within the LabVIEW platform that describes a given target, and grants the ability to manage it. National Instruments customers are familiar with Measurement and Automation Explorer, which is NI’s approach to asset management in smaller lab settings.

CHALLENGE:

Refresh the Remote Systems sub-section of MAX with 10+ Real Time Targets connected to a network. Configure their IP addresses to place them in a common subnet.

EXTRA CREDIT:

Update each of those targets to run the same version of LabVIEW Real-Time and your custom program.

If you accepted my challenge and were emboldened to complete the extra credit, you will note that this task is tedious, time-consuming, and not optimal for long term support procedures.

What are my options for managing large deployments of NI Real-Time Targets?

National Instruments released its first response to the question of asset management in 2010. The System Configuration API is a suite of programmatic tools designed to allow access to target information through driver level experts. This API directly exposes the nature of a given targets configuration for consumption by a given application.

Now, to answer your first question, yes this directly leads to custom code development. There is not currently an offering by National Instruments that acts as a robust central monitoring service for Real-Time Targets. However, the System Configuration API can be coupled with the power of LabVIEW Web Services to create a highly scalable framework for asset management.

By utilizing the power of Web Services, native to LabVIEW, the System Configuration API can populate Restful Web Services that provide agnostic connectivity any number of Commercial Off the Shelf (COTS) asset management tools. As NI hardware can now be described in common XML, it may be addressable by any subsystem that can provide/consume Restful Web Methods. Some example technologies include Microsoft SQL Server/Sharepoint, Oracle, and IBM.

How do I calculate my Return on Investment (ROI) for an asset management solution?

As National Instruments does not offer a comprehensive solution for asset management, there is a significant time investment required to implement a scalable and robust infrastructure. Things to always consider at the beginning of development:

1. How many systems do I anticipate deploying?
2. Will my deployment be locally networked, or globally deployed?
3. What is the impact of a single failure? Multiple failures? Fault detection time?
4. What is the anticipated maintenance requirement for a deployed system?
5. How often might this system require updates during field use?
6. What is the cost of continuous field personnel versus remote monitoring application software?
7. What type of system security must be maintained?

It’s important to point out that smaller subsystems have a number of options for basic application management. National Instruments systems engineering has produced a reference design for image management on Real-Time targets. The Real Time Application Deployment Utility offers a comprehensive example of how application software can be managed and maintained for multiple targets. This solution, however, does have a number of scaling concerns, especially as network complexity increases. 

As deployed systems and embedded targets become common place, National Instruments hardware will require integration with more scalable and maintainable solutions than Measurement and Automation Explorer. The joining of the System Configuration API and native LabVIEW Web Services begins to offer developers and system administrators a pathway to integrating National Instruments hardware into common asset management technologies. 

Further Reading

Welcome to the NI System Configuration API

LabVIEW Real-Time Application Deployment (RTAD) Reference Application

Microsoft Software Asset Management

SharePoint Consulting Services

SharePoint Dashboards

Learn more about DMC’s LabVIEW programming for real-time and FPGA services.

The post National Instruments Real-Time Target Asset Management appeared first on DMC, Inc..

Today is the first official day of the conference, where the largest ever audience (3300 people!) will be introduced to the latest products, trends, markets, and emerging technologies.

We kicked things off at Alliance Day yesterday, where the day’s keynote and sessions are dedicated to NI’s partner network.  DMC has been a part of the NI Alliance Partner network for close to 15 years, and it was great to interact with the technical and strategic staff as well as network with other integrators.  We also got a sneak peek at new products.

Speaking of which, my favorite so far is the new dual-core compactRIO controller.  The 1.33GHz controller launches the cRIO platform into capabilities that start to rival the powerhouse PXI platform for automated test, control, and measurement.  We’re going to have fun with these things, I can see it already.

Other notable new products include a CAN for compactDAQ, new motion controllers for cRIO, 4-channel SMU, a 14GHz RF analyzer, and dedicated test hardware for smart grid power applications.  The last one was featured as a collaboration with Siemens, where a smart power switch from Siemens is powered internally with a cRIO controller and chassis.

Last, I’ll part with something to give all LabVIEW programmers a sigh of relief– LabVIEW 2011 is released and includes an upgraded “silver palette” of new controls and indicators, which includes…. drum roll… the ability to select and deselect graph plot visibility. Simple I know, but something we’ve all been waiting a long time for.

Best from Austin,

Darren, Ashley, and Leon

The post It’s here!! NIweek 2011 appeared first on DMC, Inc..

Attend the NI Technical Symposium to:
• See new product demonstrations and network with colleagues and professionals
• Learn how industry leaders are adapting NI products to meet their specific application needs
• Further your knowledge and maximize the use of your NI tools
• Build your application development expertise through hands-on tutorials
• Collaborate with exhibitors to discover product and integration solutions
 

Highlights Include:
• What’s New in LabVIEW 2010
• Best Practices for Software Development in LabVIEW
• NI FlexRIO and LabVIEW FPGA for Test Applications
• Remote Measurements with NI C Series Hardware
• What's New with CompactRIO
• Hands-On: Introduction to CompactRIO and LabVIEW Real-Time 
 

The Chicago Technical Symposium will be held Thursday, October 21 at the Wojcik Conference Center at Harper College in Palatine, IL.

To learn more about the National Instruments Technical Symposium and register for an upcoming event, visit ni.com/techsym.

Will be there with our famous ping-pong machine demo– stop by and introduce yourself!

The post DMC exhibiting at the National Instruments Technical Symposium appeared first on DMC, Inc..