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..

Starting from the bottom, we can see that our operator-side HMI is exposed anywhere on the internal company network (with the correct login information) via Internet Explorer. This provides a reduction in downtime, because if HMI hardware fails, any other computer can be put in its place right away. Technology used for this implementation was ICONICS WebHMI, which easily converts between local HMI projects and HTML ActiveX Web pages.

Via the production network, the thin client speaks to one of two ICONICS DataWorx servers to send and receive production tags. ICONICS DataWorx has built-in redundancy and failover options which determine which of two OPC servers should be used to communicate to production devices such as PLCs.

Recipe data as well as data acquisition and reporting are stored in SQL Server 2008 R2. SQL has built-in features for customizable back-up and storage, which we are using to minimize the possibility of data loss. The SQL server communicates with our OPC server via a custom, configurable .NET service we have written, deployed and tested on several previous systems.

The last important step in reducing downtime is virtualization. Each of our three servers is virtualized using VMWare. This allows us to save backups of entire servers on independent storage devices, preserving all program installations and configurations in the event of a total meltdown of the physical servers.

Complete redundancy is not a simple task. A lot of thought has to go into specific requirements, hardware/software architecture, network layouts, and program configurations. Testing is also key (for us, simulation off-site of various failure modes provided insight into software configuration requirements). After working on this and previous redundant systems, I would recommend repeating the fundamentals described above:

1. Server-centric solutions with thin-client operation
2. Off-the-shelf solutions where available
3. Virtualization with independent back-ups of all servers

Happy programming!

Learn more about DMC's Iconics programming services.

The post Automation Redundancy Using ICONICS WebHMI Solutions appeared first on DMC, Inc..

We’ve had a few upsets along the way, but for the most part, the favorites proved why they earned the high seeds. After a last minute video review overturned what looked initially like a C++ victory in the semi-finals, this inaugural championship is between Microsoft’s C# .Net and review beneficiary, Sun Microsystems’ / Oracle / Open-Source-Independent, Java.

Amazingly, put perhaps not surprisingly, the architectures and syntax of these 2 platforms is remarkably similar. For a complete look at the similarities, there are a number of great sites exposed by a simple Google search. Some of these differences are significant, while some are cosmetic, but diving into all of them is well beyond the scope of a simple blog post.

Now, admittedly, I have done much more work on C# projects than I have with Java, and my Java experience is strictly from what I’ve done working with Android Development and anything I could learn from the Java Unleashed book I bought back in 1997 (you know, when I was in seventh grade and they had to give you a CD-ROM with the SDK and examples, since AOL dialup was still too slow to download anything real from the new-fangled “Internet” thing.)

Jumping from C# into Java, I’ve been perfectly able to make basic Android apps, and all else being equal, I honestly would lean towards Java for the simple reason that it is inherently cross-platform. Like other cross-platform languages, this means that code I write on my Windows computer can be compiled and run on a Mac without worry. This advantage means that we don’t have to build the same application 3 times to run on Windows, Mac, and Linux devices, a huge business case for commercial software companies. The Java VM mechanism used to achieve this is pretty neat too, even if it does mean that we are constantly getting barraged by Java update requests at startup. C# is making progress here with the Mono Project, but there is still a long way to go to get the same foothold that Java has.

So the winner is Java, right? Well, not so fast. C# gets a chance for a rebuttal, and rebut it does. By most accounts, C# is slightly ahead of Java when it comes to features, although both, it seems, have been doing a flip-flop where one adds a useful feature and then the other copies it. The biggest area where I think C# stands out is the integrated usage and implementation of types and classes for each. It might just be because it’s what I’m used to, but the system in C# makes a lot more sense to me than does Java.

For example, Java lacks static classes, doesn’t have a tool like LINQ, won’t allow named and optional method inputs, can’t pass inputs as references, doesn’t integrate arrays and collections, and has only watered down support for Generics. Project file management also seems better in C#, with conditional compilation flags and a level of abstraction between assemblies and files and between files and classes. Now, I know that each of these are subjective features, and you can probably even argue that some features are intentionally left out of Java, but I personally have become accustomed to the C# programming style and think that it makes sense.

The bottom line is that both C# and Java are excellent, high level languages, with many similarities and a few individual strong points. I think that environment has a strong impact on which you prefer, but for me, being in a strongly Microsoft-centric workplace, C# is my go to language. Therefore, strongly weighing my own opinion of my own opinion, in a wild game, with a controversial play, at the very last second, on a strongly contested Hail Mary, C# wins in what will safely go down as an Instant Classic.

Semi Final Flashback

Relive the Excitement

The post Programming Madness National Championship appeared first on DMC, Inc..

Without anything from day 4 to really write home about though, I figured I’d jump back to Tuesday to highlight a Windows Embedded presentation given by NI’s Andrew Mierau. I had worked on Windows Embedded a few times over the years, but never had the chance to really reap all of the benefits, so it was helpful to hear someone with significant domain knowledge recap his top tips.

Firstly, the newest embedded version of Windows, Windows Embedded Standard 7, seems much easier to work with and is fully compatible with LabVIEW and many NI drivers. This customizable build of Windows 7 offers many robust features and shouldn’t be grouped with the watered down embedded version, Windows CE (or Compact as they are calling it now.) There is also a Point of Sale tailored version, but it probably doesn’t fit for a lot of what we typically work with.

One of the coolest WES7 features is the ability to protect the system from unintended or malicious modifications. The first tool to do this is the Enhanced Write Filter, which keeps file changes in RAM instead of pushing them to disk. This means that as soon as you reboot, you’ve got a clean image back from when you enabled EWF. A beefed up version of EWF is Hibernate Once, Resume Many or HORM, which lets you essentially lock in a hibernate point from which the system will always resume.

Last but not least, Andrew presented the ease of replacing the Windows shell, explorer.exe. The Windows Explorer is really just an application like any other, so by changing a registry key, you can have windows run your own app for every user or just certain users (note that if you only want to change it for one user, go to HKCU\Software instead of HKLM.) This is great for specialized terminals that are running kiosk or test stand applications, where you only want users to have access to the application they need to be running. Remember to leave a way to get back to explorer or to shut down or log out or you will end up stuck pretty badly.

Well, that’s it. The last post for NI Week 2012. In all, it was a good experience, and even after 5 years of LabVIEW and becoming an architect there were still useful takeaways to gleam (and some of them were even .Net related!)

The post NI Week 2012 Wrap Up – Customizing Windows Embedded 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..

In a nutshell, the system calculates the volume of an object on a forklift pallet. This is achieved by scanning the object with a laser, taking multiple images and analyzing these images with computer vision algorithms.

The project also involved motor control, Linux, C++ and a lot of number crunching to derive the volume result.

US Patent 8,134,717 was awarded on March 13, 2012 to Ken Brey and me from DMC and Robert Pangrazio, Greg Pangrazio and Alan Pangrazio from LTS Scale.

The post DMC receives Patent for Dimensional Detection System appeared first on DMC, Inc..

In the new office, we were able to dedicate a large space in our front lobby for the demo case, allowing us to install larger shelves with better spotlights. On these shelves, we updated all of the display items, featuring projects in areas from manufacturing to aerospace to energy. Last but not least, we created nice graphics and summaries for each of them.

Excitingly, there should be more improvements in store, as FedEx Day 2011 is quickly approaching. A couple of ideas for upgrades are advanced gesture recognition, easy customizations, enhanced multimedia, and a new head tracking algorithm.

In the meantime, I just wanted to upload a couple of quick videos of the system to show off some of our work. The first is a high level intro and the second is a first person view of the system in action. I hope you enjoy watching as much as we do!

The post DMC Kinect Demo News and Updates appeared first on DMC, Inc..

• Allowing us to use less expensive projectors and wall mounted displays that don’t have proprietary digital interfaces.
• Unifying connectivity to all displays, regardless of brand or function. (Projects are the same as flat-panels)
• Freeing us from passing video cables

The LiteShow III is the best solution that we’ve found, but it does have some drawbacks that we hope to see InFocus address in software upgrades or future products:

• The native resolution of the LiteShow is 1280X800, which doesn’t optimize our full 1080p displays.  We would like a 1080p version.
• The LiteShow software always asks you when you connect to switch to 1024X768 resolution.  We wish it wouldn’t ask. 
• We have found that 1440X900 is the best computer resolution to use with a LiteShow.  It sets the LiteShow in the right aspect ratio with the minimum interpolation.

The LiteShow III can operate through wired networking, or using its wireless interface as a client or an access point.  We have found it best to connect the LiteShow to a wired infrastructure network, and use wireless other access points to connect to the network.  Unintuitively, before disabling the wireless network, it is important to set the SSID to the room name because that is what will be used to select which LiteShow on the network to connect to.

We have found that it important to configure a static IP address for the LiteShow.  While it has a DHCP client, it only seems to look for an address at startup.  After we had an extended power outage, when the liteshows booted before the DHCP server, they took a default address and never connected to DHCP.

Learn more about DMC’s company culture.

The post DMC uses InFocus LiteShow III for Network Projector Sharing appeared first on DMC, Inc..

If you are using Visual Studio 2010, much of the setup is created for you and is outlined in this walkthrough on Creating an Occasionally Connected Application. I found the lack of consistency in sample databases between the various walkthroughs on this topic confusing but most of the information is there. It is not obvious from the walkthrough that you should connect to the local copy cached copy of your database and then use the synchronize command to synchronize the data back to the central store.

The second thing that wasn’t obvious was the need to enable upload explicitly in the code-behind of the sync provider by setting bidirectional mode for the tables which need two-way synchronization. Fortunately, there is a walkthrough for this problem as well in Extending the Local Database Cache to Support Bidirectional Synchronization. Pay particular attention to the section on “Removing Server Tracking Columns from Synchronization Commands” if you are not using SQL Server 2008 or above as you will have to add extra code to prevent synchronization errors.

Finally, you have to handle data conflicts and errors. The first step is to design your architecture such that conflicts are unlikely to begin with but there are still cases in any application where conflicts can occur.  Understanding Data Conflicts and Errors outlines the steps necessary for handling these problems when they arise in your application.

Our latest application to use this functionality is a timer replacement for the Quickbooks timer application. By creating our own application to replace the mid-90s application we were able to give our engineers the ability edit time offline (something the alternative web-based solutions could not do), write our own export code directly into Quickbooks using QODBC which saves an hour a week of management time, and provide custom user interface functions that dramatically improved the time entry process for all of our staff.

Learn more about DMC’s Microsoft consulting services.

The post Occasionally Connected Database Applications with Microsoft Sync Services appeared first on DMC, Inc..

I started with the simplest solution using a “GetCommandLineA” Windows API function from kernel32.dll. It was supposed to return a pointer to the command line string, so I assumed that its return type would be string (sounds logical to me).

' The return type of the GetCommandLineA is long
' But it is supposed to be a pointer to the string. 
' Assumming that all VBA strings are passed by pointers
' Just declare it's return type to be a string
Declare Function GetCommandLineA Lib "Kernel32" () As String
 
Sub ReadCmdLine()

   Dim strCmdLine As String ' Command line string   
   ' Read command line parameters into the string
   strCmdLine = GetCommandLineA

End Sub

' The return type of the GetCommandLineA is long
' But it is supposed to be a pointer to the string. 
' Assumming that all VBA strings are passed by pointers
' Just declare it's return type to be a string
Declare Function GetCommandLineA Lib "Kernel32" () As String
 
Sub ReadCmdLine()

   Dim strCmdLine As String ' Command line string   
   ' Read command line parameters into the string
   strCmdLine = GetCommandLineA

End Sub

Surprise – it caused exception and crashed the application. Hm, apparently VBA handles a pointer to the string differently than GetCommandLineA. Not wanting to spend time figuring out why, I decided to copy the string to VBA string using another kernel32.dll function “lstrcpynA”.

' Declare the return type to be a pointer (long)
Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _ 
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string     

   pCmdLine = GetCommandLineA
   ' Copy from the pointer to VBA-Style string 
   ' 300 characters for command line seems to be enough
   lstrcpynA strCmdLine , pCmdLine, 300	   

End Sub

' Declare the return type to be a pointer (long)
Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _ 
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string     

   pCmdLine = GetCommandLineA
   ' Copy from the pointer to VBA-Style string 
   ' 300 characters for command line seems to be enough
   lstrcpynA strCmdLine , pCmdLine, 300	   

End Sub

This worked better by no longer crashing the application, but the strCmdLine was always empty. After short Google search I found this Microsoft article. Apparently, the lstrcpynA function (as other DLL functions returning strings) can’t change the size of the VBA-style string. In order to reserve the space for that return data, we need to fill the string with a bunch of zeros (vbNullChar).

Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string   

   ' Get the pointer to the command line string
   pCmdLine = GetCommandLineA

   ' Fill the string with zeros
   ' 300 characters for command line seems to be enough
   strCmdLine = String[DollarSign](300, vbNullChar)

   ' Copy from the pointer to VBA-style string
   lstrcpynA strCmdLine , pCmdLine, Len(strCmdLine )

   ' At this point we got the string
   ' But rest of it filled with 0 characters.
   strCmdLine = Left(strCmdLine , InStr(1, strCmdLine , _
      vbNullChar) - 1)
   	   
End Sub

Declare Function GetCommandLineA Lib "Kernel32" () As Long
Declare Function lstrcpynA Lib "kernel32" ( _
   ByVal pDestination As String, ByVal pSource As Long, _
   ByVal iMaxLength As Integer) As Long
 
Sub ReadCmdLine()

   Dim pCmdLine as long     ' Pointer to the string
   Dim strCmdLine As String ' Command line string   

   ' Get the pointer to the command line string
   pCmdLine = GetCommandLineA

   ' Fill the string with zeros
   ' 300 characters for command line seems to be enough
   strCmdLine = String[DollarSign](300, vbNullChar)

   ' Copy from the pointer to VBA-style string
   lstrcpynA strCmdLine , pCmdLine, Len(strCmdLine )

   ' At this point we got the string
   ' But rest of it filled with 0 characters.
   strCmdLine = Left(strCmdLine , InStr(1, strCmdLine , _
      vbNullChar) - 1)
   	   
End Sub

This code finally worked as expected, returning command line arguments.

Hopefully, this article is useful in saving someone 15 minutes of frustration.

Learn more about DMC’s software and web development services.

The post Read Command Line Parameters from VBA appeared first on DMC, Inc..