Re: [Emc-users] MTConnect

[Ted H. <las...@gm...>]

Kirk,
I think MTConnect would be a great addition to LCNC; I started to play 
with the building of an adapter shortly after MT was released at IMTS 
some years ago, but quickly got stalled. I have an MTConnect-compatible 
agent/adapter on my Mazak 410 machine, and it's pretty much a duplicate 
of the basic info (DROs, program/run status, spindle and axis loads) 
only. It is NOT intended to be a remote-control platform.

It's not much more useful than that, in a single machine installation, 
however it's not MT's fault, it's the limitation of the agent. I do 
occasionally run a terminal server window instead (the Mazak uses Win XP 
embedded for GUI control on top of the Mitsubishi motion platform) - 
which for all intents is just as capable as someone who already runs 
LCNC in a remote xwindow.
(BTW, for the top level overview, MTConnect spec defines three levels of 
soft-ish-ware; the adapter (optional) is the hard worker part that is 
specific to the machine and does the unification of useful data; the 
agent, one level up is the "middleware", and effectively the webserver 
or dbase; and the client is the "top view" that actually displays or 
parses the useful info. That's the really short and vague version.)

I was playing with building an MT adapter/agent for my lathe, (agent 
would just be httpd to start) that would basically replicate the 
information that the Mazak would deliver - this is where I started to 
run into universal problems with development; since LCNC is so modular 
and adaptable, there would be machines that would have some features and 
lacking others (spindle load % for example) - so writing a comp to 
"cover everything" became too daunting.

That is the best and the worst of MTConnect, and by design; the adapters 
(or more often adapter/agent combos now) are specifically deployed 
unique to your machine (or at least unique to your machine family) and 
it unifies the info for serving up to the client viewer/app/dbase.

Since MTConnect spec information is "free", it's certainly of value to 
expand one's knowledge. I was hoping to contribute to the LCNC community 
with this type of development, but the challenge so far has been that it 
would be like needing to have an additional HAL layer of connectivity 
just to accommodate all the possibilities of HAL itself. The XML 
definitions by the adapter would accommodate where the data would go to, 
what the data was, and how it was formatted, but the spec doesn't allow 
for additional info, such as "where it comes from" - ie the HAL pin it 
would be connected to, and at that point I had lost too many brain cells 
to spend more time writing something that couldn't be extended.
It might be feasible to just accommodate "all" the general DataItems in 
the dictionary, expose a ton of pins to the LCNC integrator, and if not 
useful or connected, they return null or 0; but when it comes to the 
tool cutting info, however, it just gets plain messy.

In regards to Rockhopper, IIRC, that was more than just a status window, 
it was intended to be a [complete] doc builder on the LCNC installation 
(?), but did have a status window, that for simplified intents, would be 
similar in result. Perhaps that is the better starting point, in that 
the same variables that are exposed that RH was referencing are the same 
ones used to build the initial MT adapter.

If there are some that wish to form a collaboration on something like 
this, I'd be happy to contribute, though!

Ted.

On 8/30/2013 12:30 PM, emc...@li... wrote:
> Is MTConnect something worth learning more about? Has anyone used it
> with LinuxCNC?
> http://www.amit-deshpande.com/2008/06/mtconnect-live.html
>
> -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ 
> http://www.wallacecompany.com/E45/