AMI-RS and ASQI: A FactoryTalk Optix Migration Engagement
ASQI partnered with an OEM on their FactoryTalk Optix migration. This spanned initial Optix architecture through technical working sessions that built out their master template.
Automated Motion, Inc. (AMI-RS) is an OEM with a long Allen-Bradley HMI history and a mature master template process for their FactoryTalk View ME projects. FactoryTalk Optix became worth a serious look as the platform for new machine projects because it is where Rockwell is investing. AMI's programmers attended a one-day Optix class at their local distributor to get started.
Around the same time, we crossed paths at Pack Expo. The conversation turned practical quickly: AMI had engineers with real ME template discipline and a clear goal of building their own Optix master template. What they needed was expert direction on Optix-specific patterns as the build progressed.
That became a focused engagement: a group session to introduce Optix architecture, followed by a series of working sessions to build out a master template the team can carry into future projects. The work below covers that second phase, where most of the substantive decisions get made.
The group class
The engagement started with a two-hour Teams session with five engineers covering Optix architecture and project setup. Topics included IDE navigation (Properties panel, Project View, Methods panel, Output window for runtime debugging), file system layout (project vs. application vs. runtime, Templates/Libraries/Screens/Models folder structure), and naming conventions.
For a team coming from FT View ME, the IDE shift is the first adjustment: most configuration happens in the Properties panel rather than directly on the screen, and layout properties replace pixel-counting as the sizing model, covered in Optix Layout and Positioning: Avoiding Common Gotchas. The session also introduced template and alias fundamentals, project navigation patterns, and a live demo of cross-references and hyperlinks all built into a custom demo project derived from their existing ME application.
One-on-one working sessions
After the group class, the engagement moved to technical sessions. AMI's engineer drove in Optix and ASQI provided direction, patterns, and live debugging. Topics were set by whatever was blocking active development or coming up next in the master template build.
Across a few months of working sessions, topics ranged from types, aliases, and custom variables through button and slot template patterns, login popups and user permissions, project view organization, pages vs. tabs vs. panel-loader navigation, faceplate aliasing, browse path bindings and extended tag properties, panel download, screen and button image scaling, numeric formatting, and alarms. Two threads ran through almost every session: getting the master template foundation right underneath, and getting the reusable UI layer right on top. The subsections below cover each.
Master template foundation
Templates, aliases, and model variables are the three primitives that determine whether an Optix master template scales across machines or fights you on every new project, and most of the early working sessions focused on getting these right. Sessions covered building a template from a working dynamic instance using the "transform instance into type" workflow, alias passing so each machine instance resolves to its own tag path at runtime, model objects for HMI-contained state that needs to flow between templates and screens, and dummy bits as alarm placeholder nodes.
The static-versus-dynamic template decision on data screens also came up repeatedly: some screens are genuinely static across machines, and knowing which ones avoids unnecessary alias overhead. Getting this foundation right is what determines the ROI of everything built on top of it, a topic covered in depth at The Architecture Advantage: Why Optix Template Design Determines ROI.
Reusable UI components and navigation
With the template foundation in place, sessions moved to the reusable UI layer: button templates, menu structure, popups, and faceplates. Login popups are a good illustration of where alias passing pays off at the UI level, one template that every screen reuses by passing a different context alias, the same principle detailed in Building Reusable Popup Templates with Alias Passing in FactoryTalk Optix. The same alias pattern carried through the faceplate templates for VFDs and IO.
Client perspective
As an OEM, we have been programming Allen Bradley's panel view series HMI's for many years. I still recall installing RSView32 from floppy disk before it eventually became FTView which is our standard today. Recently, we had an opportunity to convert one of our projects for use with FTOptix and hope to begin using Optix on more projects going forward. Because Optix is a completely different approach to HMI programming, we needed help. While ASQI offers a migration service, we wanted to understand the process and be able to make changes and build our own projects.
Carter tailored a very flexible plan to help our team not only get our feet wet, but to also work one-on-one to solve problems as they would occur during development. His amazing attention to detail and genuine interest in solving problems was a huge help with developing a working Optix project. I have already recommended ASQI to our end customer for this project.
Chuck M.
Controls Engineer
Programmer Automated Motion Inc.
A working Optix master template is the asset that determines how the next ten machines go. The topic list above is roughly what that build looks like in practice. If you are scoping similar work for your own team, those are the substantive areas to plan for.
Building your own Optix master template?
The engagement above was the right shape for this OEM. What worked was a group class to introduce Optix, followed by working sessions through the build. If your team is scoping similar work, reach out and we'll tailor the blend to your needs.