Tuesday 8 November 2011

MTConnect MC2 Conference Notes - Cincinnati Nov 7-8, 2011 - Day 2

I am here again at Day 2 of the MC2 MTConnect Technical Advisory Group in Cincinnati and want to keep everyone posted on what is happening.  Today the goal is to present the status of where the MTConnect XML Schema is at the moment.

Will Sobel feels that the standard has most of what people need for machine monitoring and inter-device communication on the shop floor. Next stage for Ver 1.3 could include the following items for May-June 2012 time frame:
- Accessory Equipment
- Metrology (popular choice)
- Parts
- Enhancement to alarms & Warnings

Other areas to look at:
- File Management
- Non traditional (like water-jet, etc)
- Enabling MTConnect write functions
- Operator Input

IMTS 2012 Machine Tool Trade Show - What to Do?

MTConnect not emerging anymore - but perhaps 2012 will be last time MTConnect will be added in. So MTConnect will be just an exhibitor using the same booth that MTConnect will be using with the Defense Manufacturers conference in December. A better focus on applications will be the highlight.

Notification Project Update:
Delivered by John Turner, Director of Tech, FA Consulting & Technology

Report of project called "Reduction of Unplanned Downtime in Defense Manufacturing MTConnect" Project steps included adding sensors with 76 Data Types extended to 2700. Tried to classify notifications from Project machines. Use this feedback to enhance the future MTConnect standard 1.3. All alarms could be classified in Release 1.2.

The challenge was that system type of alarms required a lot of text string parsing to fit it into the alarm categories. John gave an example of an overheat alarm on the X axes which showed up 3 different ways depending on what view you looked at. The Servo Motor Overheat was the same as a Drive Alarm was the same as the System Alarm - 3 alarms from one event!

The basic alarm information is not tagged to subsystems of the machine. The existing MTConnect schema is 1 dimensional now. We need alarms tied to components - a 2 dimensional capability is needed in real life.

- define Additional "Systems" to represent the Device in More detail
- Add Component Type "Composition" to provide more detail
- add "CompositionID" to Source Attributes

Devices
|
Device
|
Components
|
----------------------------------------------------
|                       |                 |              |
Controller     Systems      Axes      Door
                       |
                    Hydraulics
                    Electric
                    Pneumatic
                    Coolant
                    Lubrication
                    Tool Management
                    Chip removal
                    Probe
                    Loader
                    Other...

There is a limit to the levels of details that need to be modeled. The Law of Diminishing Returns may come into play here. The existing standard had a state only before - OK, Warning, Fault. Now we can add the 2nd level of basic detail to describe the situation more clearly without the baggage of full device status - color the data in other words. XML is self-describing, but the Law of Diminishing requires a simplification for future applications.

CompositionID Definition (New):

A unique identifier that references a specific Composition Source.

An example (for a "SoftThermal (OVC)" Servo Axes Motor Overheat Alarm):
<Source componentID = "CONTROLLER"
  compositon ID = "MOTOR"
</Source>

Issue was raised that the machine tool builders could be overwhelmed with trying to classify all their alarms and that they wondered who would use it. I pointed out that the maintenance departments and the MRO community could really use this extension. We used the basic 16 alarm categories that Fanuc used, but stopped short of encoding the 900 possible alarms, some not even used by the machine tool builder. This is the sort of compromise that we have been talking about.

An open source piece of software called the "Classifier Application" made by Will Sobel (System Insights) will break down the alarm text strings down and add the ComponentID source automatically. This requires certain rules, but greatly enables the addition of source data into the flow. I call this a message "sanitizer" for ease of implementation.

Also there is a challenge of which bucket certain alarms should go in - e.g. E-STOP. Also there is a lot of cause and effect issues - what is the root problem that caused all the alarms?

With the increasing complexity of machines and the declining number of highly skilled maintenance people, this advance and extension into alarm classification and sequencing. This could really help with the future of machine tool maintenance and reduced warranty claims for machine tool builders.

OPC-UA & MTConnect Collaboration:

An exciting alliance is MTConnect linked to OPC (OLE for Process Control) which is a standard for the PLC-based automation sector. MTConnect linking with OPC opens up a rich series of mature and robust SCADA type applications. With a MTConnect Universal Machine Gateway one can link CNCs and PLCs to the Human Machine Interface (HMI) industry.

With a mapping of OPC variables into the MTConnect name space, one can extend the MTConnect platform for special situations. MTConnect is extensible with these type of custom extensions.

John Synder from Benet Labs Presented the "Production equipment Availaility" Report - which is available from AMT at http://www.amtonline.org/AboutAMT/WhatisManufacturingTechnology/productionequipmentavailabilityameasurementguidelinefourthedition.htm. It unfortunately costs money, but the report is a good one for deciphering availability standards.



1 comment:

  1. I am a service engineer and recently I had a problem with the machines in my firm, I looked up on the Internet for some help and found this company named FANUC Repairs. I decided to contact them and give them a chance and to be fair I was very pleasently surprised by their services and I would recommend them to anyone with a similiar problem.

    ReplyDelete