Frequently Asked Questions
I’m not ready yet - what should I do to prepare for doing integration so we’re ready?
- Identify a pilot or two of workcenters that you’d like to get better transaparency on, or projects that are of particular challenge that will be aided by integration/automation
- Make sure those workcenters are networked and available. If you provide me make/model, I’m happy to explore how easy/difficult these are to integrate
- Make sure peripheral required equipment is available/connectable – are we doing lineside labeling, barcode scanning, weigh scales, vision systems, etc.
- Check to see if you have Plex Web Service Credentials. These are required for you company to be allowed to do web transactions with Plex
- Continue to get up to speed on Plex – Plex is a critical component of Mach2. We’re integrating, and often automating functionality of Plex, but we also need to follow workflow, rules, etc. with Plex. The more you understanding things like routing, configuration, reports, etc. the more effective we can setup integration and the associated automation with it.
What preliminary work needs to be started?
- Our common approach is a phased approach with common data/functionality focused on for the first phase to bring transparency and integration of the plant floor with business systems – job/part setup, production recording, scrap recording, and machine status combine and compliment each other along with the business systems to provide an accurate reflection of what’s occurring on the plant floor, real time performance, and synchronization of systems to eliminate silos of information and data entry. To execute the first phase, with integration of Plex, we simply need the cycle/count information from the controllers – this is often rapid for to define standard requirements for access to this information. Most equipment has this information readily available, or quickly configurable. If it’s absent, low cost IOT devices can provide gap fills to provide simple cycle related information that can yield valuable information to the business.
- The second, and additional phases often focus on specific pains (overburdened operators, poor quality, inaccurate packouts or production recording, OEM requirements, automation, visualization, etc.) and are executed cooperatively or independently with Kors, its partners, or independently by the customer.
- Parallel to these efforts are focuses to ‘templatize’ and provide enterprise/global standards to provide common data models from each plant, reduce maintenance, improve consistency across plants, etc.
- Tools are diverse and flexible enough to provide global standards/requirements, while allowing for localized use/requirements as each plant has unique operations, management, data requirements,etc.
When should we do integration? Where do we start?
We are typically a phase 2, or at minimum 1B. As Mach2 leans on Plex heavily, it’s often good to make sure jobs, parts, part routings, rates, etc. are set up and understood. From there we’ll load software, discover networked equipment, and start integration. We usually like to start “small” with cycle counts, machine states, recording production, lineside labeling, performance/OEE, etc. and work functionality of the stack to address more complex functionality of job setup, quality/traceability, workflow enforcement, customer operator interfaces, etc.
Do I need a PC at every workcenter with Mach2 screens showing?
It really depends on how our product is being used. If it’s just to let operators see how well they’re doing, it’s not unusual for customer to have summary screens for an area so it serves multiple workcenters. Many of our customers do use our product for much more and using our products interface to relay job or part specific information, workflow, visualizations, etc. If you’re not sure, you can “start small”, and add on as you see fit.
Since our product is site licensed, you don’t have to worry about paying for each instance – it’s just a browser. As technology as evolved and gotten cheaper, we’ve also seen some creative solutions where customers are using alternatives instead of a PC – tablets, smart TVs, Raspberry Pi, etc. We have one customer that found a deal on Android tablets, and 3D printed something that could bolt it to the press!
Delivery of Mach2 screens is via browser, so you would need some sort of HTML5 compatible browser (Chrome, Firefox, Edge, etc.).
What's Included with the Mach2 Demo?
The demo of the product is to show the “out of the box” functionality. We call this “Day 1”, as we know most people have more extensive needs in validation, traceability, workflow, visualization, etc. So next steps are usually:
- “Flip the switch” and fully enable the product, and provide 2 day training to allow your team to extend the product both in scale and function. This is usually accommodated with a block of hours to get a few cooperatively developed projects under the belt
- Scope a project – in these cases, our customers will provide details around a specific effort. From there we’ll develop according to that scope, then traditionally we bring you in for training, then co-deploy for “on the job training”, as well as getting a specific need addressed if there are critical needs/timelines
Mach2 may run acceptably on lower-rated platforms, or may even require more powerful platforms, depending on the application, number of data points integrated, data poll rate, number of concurrent users, performance expectations, etc.
The minimum Mach2 hardware requirements include:
- Processor: Intel® Xeon® CPU E5-2640 x64 (or better), compatible with dual- and quad-core processors
- Operating System: Windows 7 Professional/Enterprise/Ultimate (32 and 64 bit), Windows 8.1 Professional/Enterprise/Ultimate (32 and 64 bit) Windows 10 (32 and 64 bit), Windows Server 2012 R2 (SP2) Standard/Enterprise, Windows Server 2016
- Memory: 6 GB minimum, 8 GB or more recommended for larger systems
- Hard Drive: 20 GB minimum, more recommended depending on archiving requirements
- Display: Video card and monitor capable of displaying 1280×1024 pixel resolution or greater
- Network Support: Ethernet adapter (10/100 Mb with RJ-45 connector)
- Host Platform (server) should be dedicated to running the Mach2 application only
Plex Web Service Credentials
Mach2 will need Plex Web Service Credentials
Cost of Implementation/Subscription
Option: Flip the switch
If we “flip the switch”, it’s pretty minimal. We allow for some time for adjustments/tuning, as well as recommend a pre-paid labor block to address future projects. Typically in $7,500-$10,000 range
Option: Project Scope
Scope a project – in these cases, our customers will provide details around a specific effort. From there we’ll develop according to that scope, then traditionally we bring you in for training, then co-deploy for “on the job training”, as well as getting a specific need addressed if there are critical needs/timelines
$3,360 for training up to 5 Attendees
Mach2 Subscription is $1,500/Month per site.
Multi-plant discounts are available.
Is there a per seat license?
As its browser based, there are no seat licenses, runtime licenses, development licenses, etc.
What's included in the monthly subscription?
- Mach2 Web User Interface
- Mach2 Engine
- Mach2 Base Model Screens
- Standard Operator Input View
- Standard Workcenter Performance Views
- Standard Area Information View
- Standard Diagnostics View
- Standard Whiteboard View
- Mach2 OPC Client
- Mach2 Standard Screen Software Updates/Enhancements/Additions
- Mach2 Standard Modules Updates/Enhancement/Additions
- Mach2 Standard Screen, Logic, and Module Technical Support
- Kepware Manufacturing Suite
- Kepware Manufacturing Suite Updates
- License Move Support
How is Version Management handled?
We like to stay one release behind Tridium so we are currently deploying V 4.6. We do that to give them time to find bugs and for our developers to have a period of time with the newer release before we give it to customers.
Why isn't support defined?
Mach2 was intentionally designed as a set of tools to create endless opportunities. Without a specification of deliverables, we can’t define what it can and can’t do. Mach2 was intentionally designed NOT to restrict. The more we draw lines in the sand, the less the customer is allowed to do.
Each case needs to be evaluated individually-is it Plex, is it a Kors tool, is it a tridium tool, is it customer logic, is it limitations of system or software.
Definition, design, instruction, etc. not covered (can you, is it possible to, how does)
Covered: for a project specified/delivered by Kors that’s been unaltered
Failure of components, of the whole, etc. will be evaluated on a case by case
Some will be entirely covered by Kors
What is the Cost of Training?
$3,360 per session, with up to 5 attendees per session
Training is done at our office in Waterford Michigan. We have a training lab with five PCs and multiple instances of Mach2, so we can handle between one and five people (although five is a challenge, most companies have 2 – 4 people).
Training is a two day process:
- Day 1 (Approx 8:30am – 4:30pm)
- Day 1 Covers the toolset (Kepware, building logic & screens with Tridium/Niagara and communicating with Plex).
- Day 2 (Approx 9:00am – 2:00pm)
- Day 2 covers your company’s project taught by your engineer.
What is the Security of Mach2?
Mach2 by default has it’s own security function and user management. I say by default because it can be superseded with LDAP if required. Assuming you are using the built-in security, users can be created and granted (or denied) access to literally any individual piece of information within the application. We generally do not get that granular with access, instead creating basic roles (operator, supervisor, administrator) with different access levels to different parts of the application. LDAP would work the same way – the LDAP query would be used to determine a user’s role.
There are 2 ways to access any data within the Mach2 environment.
- Using the developer tool, Workplace, is the first. To access the running application (called the “station”) using workplace you must have a valid license for the tool. You have to log in using a valid username and password (built in security or optionally LDAP). Once logged in your access to the station is based on your user role. Typically only developers/admins will use Workplace and will therefore have full control and access to all data.
- Second, you can log in to the Mach2 web user interface. This interface uses the same username/passwords as above. Once logged in a menu system will guide operators to accessible pages based on their configured role. Each page is role-controlled so that even if a user copies a shortcut to a page, they must belong to the configured role for that page in order to open it.
As for encryption, the Workplace connection to the station is always encrypted. The web user interface can be either HTTP or HTTPS. Since we never recommend customers expose their data to the internet most customers use the HTTP interface internally. Mach2 only includes a self-signed certificate. Customers can provide their own certificate if needed.
Communications with Plex are always done via HTTPS using credentials supplied by Plex.
Finally, Mach2 does require communication with our licensing service to remain active. This communication is done via HTTP but no customer information or credentials are exchanged.
Niagara has a forum at Niagara-community.com as well as some free content for registered users under the “university” link on that page.
How are objects in wireframe created?
Wiresheet objects are compiled Java. Niagara has a published API with source code, and toolkits available for Eclipse and IntelliJto build new modules. Kors has also started an open source project named axCommunity, it is available through sourceforge
How are visual objects for operator screens/dashboards created?
Visual objects can be created in many different ways. The Mach2 main method for content delivery is by creating HTML/JS components that get assigned to a <div> in what we call a layout. We refer to these as “content objects” – a wiresheet object that delivers the dynamic HTML and JS needed to render and interact with that object. A layout is basically an html page divided into rows and columns with sizing applied. Each box/div on the template will get assigned to a content object from a wiresheet. In that way, logic is tied directly to the object that will be used to display and interact with the wiresheet.
Or if you are not using the Mach2 layout tools you can build your own visualizations using the Tridium page builder toolset. Or… if you are an HTML/JS developer you can create your own pages that have access to the Tridium infrastructure/data/functions. Or… if you really want to Tridium lets you create your own servlets that can do pretty much anything you would like. In other words – there are lots of tools for building UI.
When will the platform upgrade to Rest from SOAP for its webservice calls?
Good news from Plex in regards to the HTTP transition (it’s not Rest – it’s just a different syntax to the same old infrastructure BTW, Plex calls it the “HTTP API”). We have been waiting on two major hurdles before jumping on the new bandwagon. First, the new API does not support what are know in classic as “class based” datasources. Those are basically DLL calls. Only stored procedure based calls are available in the new API. One critical call that was a deal-breaker for us was the “get label” transaction, that is class based. If we can’t print labels we can’t do true machine integration of production. That was delivered by Plex early March ’19. Second, the SOAP API provides a way to retrieve a datasource calls inputs and outputs. There is currently no replacement for that in the HTTP API. Being able to dynamically create API clients in our wiresheet is crucial. We don’t want customers to have to type in the names of the inputs/outputs to be able to call a datasource. We are told that functionality will be delivered later this week in alpha form. Once we have that, we will begin to make new versions of our Plex client objects that will reference the new API. We anticipate transitioning to the new API, for new customers, sometime summer 2019.
How do you connect to equipment?
PLCs are most often connected via OPC protocol. Kors Engineering includes the Kepware Manufacturing Suite -which includes support for hundreds of the most popular global makes and models. We’ve also integrated using OPC UA, Matrikon’s OPC, numerous 3rd party OPC, and have even written our own OPC drivers when necessary. We’ve also interacted with controllers through serial to Ethernet conversion, message parsing, FTP, CSV, SQL, XML, UCON. We’ve also got one or two sites doing OPC UA with Euromap 77. Our tools are inherently open architecture, and designed specifically for integration and normalization of diverse systems
Can existing/legacy equipment and systems be taken over?
Our preference is to leverage existing legacy systems. These systems carry localized expertise, are known variables for the plant, in operation, and provide the least amount of disruption of operations. We extend every effort to communicate, or provide gap solutions, to preserve existing systems. This makes for smoother transitions.
Can you do wireless?
Most of our customers prefer wired due to the nature of the plant floor – lots of metal can make things difficult for good wireless coverage, and as machine communications can be critical, most of our customers don’t want to risk missing an event. We do have more and more customers that are strictly interested in performance/OEE/target vs actual/etc. In these cases, capturing the cycle count isn’t as sensitive so we’re able to recommend the Advantech Wise or similar device. These have built in counters, so even if the wireless drops for a second, the device can still count, and we can pick up where we left off. These are nice in that they’re inexpensive (under $250) and up to 8 cycles can be capture by a single device – handy if you’ve got a number of presses in one area.
How is Mach2 affected by Plex CoLocation?
The short version is, SOAP and outbound transactions go away with COLO. The “HTTP API” is intended to be the almost 1-for-1 replacement of datasources. We have tested it and are comfortable with how to use it. We say almost 1-for-1 because there is one major gap – any “class based” datasources will not work. We don’t use a lot of them, but there is one key class based datasource that has prevented us from re-working Mach2 to use the new API – GetLabel. It’s kind of a critical one and as of right now there is no way to do that using the new API. Plex is working on that one for us but that has already been going on for a couple months and we have no progress updates. Once we can print labels, there is no technical reason we could not migrate all of our standard logic to use the new API. What we have not yet built though is a replacement for the “MicroWSC” client object that uses the new API. It’s on our to-do list but we want to wait as long as possible in the hopes that Plex will also create some kind of discovery ability. One nice thing about the SOAP API was that you could make a call to a web service method and Plex would return the inputs and outputs of a particular datasource key. No such thing exists for the SOAP API so we have to either wait for that to exist or come up with some other, rather cumbersome way to build a wiresheet object with the correct inputs and outputs. Because we understand the first COLO projects will probably not be live until Q4, we’re not rushing.
What is the Difference Between Mach2 & Plex IIoT?
There is alot of confusion on what the differences are between the products. We’ve created a product comparison to help “clear the air” and illuminate some primary differences between Mach2 and Plex’s new IIoT. Watch the video to hear more!