I've published new updates to our MTConnect projects on Codeplex. Both the MTConnect SDK and the VirtualAgent have changes and for detailed info take a look at the change logs in the Source tabs on the project.  Here's a high-level list of what I think the important additions are:

• I've added a fully working reference implementation of an MTConnect Adapter for Okuma THINC controllers (full source is included).  If you have an Okuma machine with a THINC-supported controller on it, you now have a simple agent and adapter you can drop onto the machine to start publishing data immediately. I hope to find time to put together a reference implementation for Fanuc FOCAS controllers.  If you're interested or in need of that support, let me know and we can discuss prioritizing it and the features you need.
• I've added support for SHDR adapters.  At the [MC]2 conference in Cincinnati there was concern that once you selected an Agent technology (either ours or the reference MTConnect C++ Agent), then you were locked in to creating Adapters only for that Agent.  That is no longer the case.  Our Virtual Agent now can easily consume data from your existing C/C++ Adapters written against the reference Agent.  No changes are required in your existing Adapters at all.

If you have any questions on implementation, etc, feel free to contact me.  For more info on our entire line of MTConnect products, take a look at our web site.

With the upcoming MTConnect conference next week, we've been extremely busy getting things ready for our talks as well as our booth on the show floor.  I think we got feature complete (at least as far as we want for the show) today, so I'm merged all of the latest changes into the public trees for both the MTConnect Managed SDK as well as the OpenNETCF Virtual Agent.  I have an updated Machine Simulator that we'll be using for the show, but it's not quite ready for public consumption, so the release of that will have to wait until after we get back from Cincinnati.

I've again refreshed OpenNETCF's MTConnect Managed SDK with a few changes.  Most of the changes are the result of us dogfooding the SDK and making things more thread-safe and solid. 

In preparation for the upcoming MTConnect: Connecting Manufacturing Conference where we'll be both speaking and have a booth, I'm also creating some hands-on labs and tools.  One of the tools is a Sample Client application that consumes the Client side of the SDK.  The full source for the sample application is also available with the SDK download over on Codeplex.

I've published a refresh of the OpenNETCF MTConnect VirtualAgent code up on Codeplex.  This is a major refactor from the last publication which extracted the VirtualAgent engine capabilities into a separate IoC module.  This change greatly simplifies integrating VirtualAgent capabilities into an existing application as well as allowing an app to publish other Padarn REST services and ASP.NET pages without having to modify the VirtualAgent engine code base.

I've again refreshed OpenNETCF's MTConnect Managed SDK with a few changes, including:

• Added support for some current and sample filtering (not all filtering is supported, but I've added device name and data item ID filtering)
• Added AgentInformation to the EntityClient so you get information about the agent returning a data set for a probe
• Miscellaneous bug fixes and refactoring

As always, if you find a bug or would like me to work on implementing a specific feature from the specification, add it to the lists over on the Codeplex site.

I've been extremely busy for the past few months putting together a cross-platform MTConnect Agent.  The result, along with our other MTConnect offerings, is the OpenNETCF MTConnect VirtualAgent, which is shared source (MIT license) and runs under either the Compact Framework (3.5) or the Full Framework.  The default implementation uses Padarn as the web server, but it's designed to deliver content through an interface so that can, in theory, be swapped out pretty easily (I say in theory because I've not tested it with another server at this point).

The VirtualAgent offers a boatlod of interesting things that a general Agent doesn't most notably the ability to load up custom Adapters that you can use to encapsulate a process model or even drive control logic.  We've got a simple example of a Hosted Adapter in the code base now and will be adding more complete and robust samples as time progresses.

At any rate, if you need to get a machine tool (or really any sort of device) publishing MTConnect data on a plant floor, we've got a solution that can get you there in well under a day in most cases and at a remarkably low cost.

OpenNETCF's MTConnect Managed SDK now has Common and Client projects supporting Windows Phone 7.  This means you can now consume MTConnect-published data in your Phone 7 projects.  I'll also be publishing and open-sourcing an MTConnect viewer for Phone 7 in the future, but if you want to get started on your own, you now have the tools.

I've published a major upgrade to the OpenNETCF MTConnect Managed SDK over on Codeplex.  Earlier releases only had Agent support, but this release adds Client support.  The SDK supports both the Compact Framework and the Full Framework (version 3.5 of each).

If you're wondering exactly what MTConnect is, it is a standard for how data should be published from machine tools as XML over a simple Web interface.  More information on the standard can be found on the MTConnect Institute's web site, including the full specification.  This SDK allows managed developers to publish and/or consume data according to the standard.

The MTConnect Agent SDK I published last week is really only useful if you implement a Host to actually serve up the data.  The IHost interface isn't complex, but if you don't have an example, it's a bit difficult to understand my intent.  I've published a desktop implementation that uses Padarn as the web server.  In theory the same code should work under Windows CE as well, but I've not yet tested it to be certain.

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.