MTConnect Agent SDK for .NET


I do quite a bit of my work in the area of industrial automation, and one of the more interesting initiatives to come along in a while is called MTConnect (“MT” presumably for “Machine Tool”).  MTConnect is an open standard for communicating with a machine tool to retrieve information about its current or past status – everything from executing controller line of code to tool head positions.  It’s interesting enough that I joined the Technical Advisory Group and am helping to review and improve the specification (version 1.1.0 was just ratified last week).


As frequently seems to be the case, there was a bit of interest from other members on exposing MTConnect data from tools running Windows OSes (both CE and XPe), but no one working on providing an actual SDK to allow a standardized way to actually do it.  Well implementing code from nothing but a spec is actually something I find pretty fun and interesting, so I took up the challenge.  My first attempt was, as is typical, more of a throw-away attempt at writing code to help me understand how the spec itself works.  I spent a couple weeks on it then tossed it all out.


I then took the knowledge I gained from that first effort and put together a more coherent SDK that I’m releasing a loose Beta of today over on Codeplex.  It’s not done – in fact I wanted to get a few more features in and get it to a releasable point before publishing it, but I’ve already gotten inquiries and volunteers to test out the beta work, so I’m publishing early to facilitate sharing the code between teams and to allow me to track bugs and discuss the SDK in a publicly searchable location.


I’m working on a specific project that is going to use this SDK, so I have a specific set of funtionality that I’m driving toward, but that doesn’t mean I’m not open to making it easier for everyone to use. If you’re working on machine tool controllers and are interested in exposing data meeting the MTConnect standard, I encourage you to take a look at the Agent SDK, post questions in the Discussions area and report bugs/desired features to help drive the effort forward.

Updates to OpenNETCF.IoC Framework

We recently ported a desktop SCSF/CAB application over to use the OpenNETCF.IoC framework.  The primary thinking here was that the SCSF has way, way more stuff than we really need, want or use and the SCSF wizards had done wacky things to a few Studio installations, so we wanted to get rid of all of that as well.


I’ve checked in the fruits of the labors into the Codeplex project, including new desktop project and solution files.


Now you can be even closer to one codebase for both desktop and device projects.  If nothing else, it allows you to not have to remember two different injection frameworks if, like me, you end up doing a lot of work on both platforms.

OpenNETCF.IO.Serial Library moved to Codeplex

As you may have guessed from some of my recent blog entries, we’re making a push to get a lot of our shared source code out to the Codeplex servers.  Our serial library is the latest one to make the move.  It’s now available at http://serial.codeplex.com.  As with all of these libraries, if you have the desire to contribute, fix, extend, or whatever just let us know and we’ll add you as a developer.

OpenNETCF.Desktop.Communication library has moved to Codeplex

In an effort to clean up our servers, to make code easier to find, and to hopefully make it easier for the community at-large to contribute, we’ve moved our popular Desktop Communication library over to the Codeplex servers.


Visit the project at rapi.codeplex.com.

WIA Library Update

As it seems is always the case, as soon as I published the WIA library, I found some problems.  The original library worked fine in the test application, but as soon as I moved it into a larger-scale application that does a lot of wacky multi-threading, multi-AppDomain and reflection calls I started to see bad behavior.  It all worked fine if you kept the original list of cameras, but if you added or removed them they started shifting around or existing cameras no longer worked.  So I’ve debugged and reworked it a bit and the new version appears to be much more stable and friendly in a production environment. 

Download the code at the original blog entry.

AudioTagR: Oh Cecilia, you’re driving me nuts….

Last Christmas (2006) I gave my father a USB turntable so he
could start ripping his hundreds upon hundreds of vinyl albums to MP3.  Of course I assumed that all was going well
for most of the year, as he was using it and seemed happy with it. 

Then about 2 months ago I actually got a copy of the Simon
and Garfunkel song Cecilia from him (don’t tell the RIAA) and I noticed that it
didn’t show up in my Zune software or in WMP. 
A little further digging and I found it down in “unknown artist, unknown
album, unknown song”.  How wonderfully useful.  So I asked him why the hell it didn’t have
the track info.  He replied that the
software he has basically ripped the vinyl to one giant wave file, then another
piece of software would divide it into MP3 tracks, but it didn’t have a good
way of tagging each track efficiently. 
To give it track info, he’d have to pull it into some other software
like WMP and alter it there, which is a very tedious process.

Well I decided to take a look into how media playback
software actually got the info about the tracks.  I assumed it was something embedded in the
software so I did a little searching for a specification, and found that the
info is indeed stored in what is called an ID3 header tag.  Well since I enjoy writing software from
nothing but a spec (really, I do – masochistic I know) I decided that maybe I’d
put together some software that makes tagging albums just a bit easier using
mostly drag and drop and inferring info based on how it’s organized in the file
system.

The first step, however was to create a library that allowed
me to read and write the ID3 tags.  That
yielded the OpenNETCF.Media.MP3 library (this library does *not* offer MP3
playback capabilities, so don’t ask).

Once I had the library mostly done (meaning coded but not
heavily tested) I then started on a desktop application I called
AudioTagR.  The idea behind AudioTagR is
that most people organize their music on their file system.  My dad and I both have a single folder that
contains a folder for each artist.  Each
artist folder contains one or more folders for each album.  Each album folder contains files that are the
MP3 songs, and the song filenames are in the format “NN <song name>.mp3”
where NN is the track number from the album. 
AudioTagR assumes that you use this hierarchy to infer a lot of the
information about unknown tracks (though it allows you to turn off inferring).

So the paradigm is that on the right is a folder view of the
file system, with a root being the “root” of where your music is stored.  On the left is an “organizer” that is used
for nothing but tagging tracks through inference.  You drag a song from the file tree into the organizer
tree and it infers artist, album, song name and track if nothing exists.  If some info exists, or you drop it onto a
node in the ordanizer that already exists, it will use node info instead of
inferring.  The actual algorithm is a
little more complex than I feel like explaining, but it all makes logical sense
when you use it, so if you really want to know how it works, try it out.

So the day before Christmas I delivered v1 to him, and less
than 2 minutes later he found the first bug. 
After a couple versions of deploying via FTP, I decided there had to be
a better mechanism.  Since this is a
desktop app (yes, sometimes I begrudgingly work on non-CE stuff – but hey, the
ID3 tag library is fully CF-compatible) I decided I’d see what the whole
ClickOnce deployment and publishing stuff was about.  Sure enough, it turned out to be crazy
simple, so I set up a publication that allows installation from a web page and
now the software auto-updates on his machine every time I make a fix.

So now  that it’s
done, I guess that there may be other people out there that received these nice
USB turntables and are having a similar problem, so I say Merry Christmas to
you all.  I’m giving away AudioTagR,
along with the full source if you want it, to everyone as another OpenNETCF shared
source project (MIT X11 license).  Since it is free, you
get no support, and I take no responsibility for its use or consequences.  If you screw up the titles on all of your
existing music I’m sorry but it’s not my fault. 
Make a backup.  If you find a bug,
by all means let me know and I’ll see what I can do to fix it.  If you add a feature that you like, send me
the code and I can integrate it in.
 

If you simply want to install and use AudioTagR, click here.

Download the full source (C#) here
Get the OpenNETCF.Media.MP# library source here

OpenNETCF.Media.MP3 Library

Before I go any further, let me state for the record that this library does not provide any ability to play MP3 files, so if that’s what you were thinking from the name, then don’t get too excited.

The OpenNETCF.Media.MP3 library is a library that allows you to read and write ID3 tags to MP3 files.  It’s both Compact Framework 2.0 and Full Framework 2.0 compliant.  For a usage sample, see the AudioTagR project.

The general object model looks like this:

It’s licensed under our very open MIT X11 license.
Download the full source code (C#) here.