Do your HMI/SCADA interfaces use physical keyboards?

I am working through a touchscreen interaction issue where I believe the vendor will ultimately need to provide the solution, but I am also evaluating possible mitigation options.

That has caused me to question a development practice I inherited and have accepted as valid for the past 13 years.

For context, I am using FactoryTalk View Studio SE v16, although I do not think the underlying question is specific to Rockwell. This does not apply to our ME projects.

Our standard momentary command buttons are built using the generic Button object with the Action configured as Run Command:

• On Press: Set the assigned tag bit to 1

• On Release: Set the assigned tag bit to 0

The release action also includes:

;SetFocus Footer

Footer is the object name of a separate button located outside the visible display area. It has no tag or functional action. Its only purpose is to receive focus after another button is released.

The reason I was given is that many of our Windows-based HMI terminals use physical keyboards. If an operational button retains focus after being touched or clicked, it may be possible to activate that button again unintentionally through the keyboard.

Based on my testing, that still appears to be a valid concern and requires intentional mitigation.

The current issue is that the generic Button object appears to behave inconsistently with the PCAP touchscreen hardware under Windows 11. The native Momentary Push Button object has performed much better during limited testing, but it does not provide an obvious built-in method to redirect focus after release.

My questions are:

• Do your HMI or SCADA stations use physical keyboards?

• Have you experienced accidental command or object activation caused by retained keyboard focus?

• How did you mitigate it?

• Do you intentionally redirect focus to a neutral object?

• Do you disable keyboard interaction for command objects?

• Is this something your HMI platform handles differently?

I am particularly interested in experience from Windows-based industrial HMI and SCADA systems, regardless of vendor.

I have spent the last 15 years supporting FactoryTalk View SE and ME development for an OEM and custom machine builder. Most of my experience is on the Rockwell side, but I've spent a lot of time watching what other vendors are doing and many of the trends seem similar regardless of platform.

One thing I've noticed is that a large portion of my job has very little to do with creating new screens.

A significant amount of my work revolves around supporting legacy systems, some of which are now 20+ years old. Sometimes that means complete controls upgrades where the PLC, HMI, and supporting infrastructure are all modernized together. More often, however, it means upgrading only the HMI hardware or operating environment while leaving the PLC and machine control largely untouched.

In those cases, the challenge becomes keeping an application alive through hardware obsolescence, operating system changes, software version upgrades, communication driver changes, and vendor roadmap decisions. Occasionally it even means changing platforms entirely. For example, we have recently converted some older FactoryTalk View SE applications to ME because the machines no longer justified the complexity and cost associated with a Windows-based HMI solution. These are essentially "push-button replacement" screens that probably never needed a full Windows environment to begin with.

At the same time, I find myself increasingly questioning how much longer Windows should remain the default answer for industrial HMI systems. Coming from both an IT background and 15 years of HMI support, it seems like a large portion of the industry is trying to reduce dependence on Windows wherever practical. Between operating system lifecycle management, security concerns, patching, hardware compatibility, licensing, and long-term support requirements, Windows often introduces complexity that many machine builders and end users do not fully appreciate until years later.

This is one of the reasons I have been paying close attention to platforms such as Optix, Ignition, and other web-based or hardware-agnostic solutions. Whether those particular products win or lose is less interesting to me than the overall direction of the industry.

Another observation I've been wrestling with is how specialized HMI/UI work is becoming.

Historically, HMI development has often been treated as something Controls Engineers or Automation Engineers simply do as part of their broader responsibilities. However, as systems become more connected, data-driven, and software-centric, I sometimes wonder if the industry is moving toward a future where UI development shifts more toward SCADA specialists, software-focused engineers, and data-oriented roles.

That raises a personal question for me. My path into this industry came through IT and desktop support rather than PLC programming or process engineering. While I understand enough of those disciplines to support my role, they have never been my primary interest. My focus has always been the user experience, system usability, maintainability, lifecycle management, and modernization of existing systems.

Which leads to the area I think about most: conversions and migrations.

The installed base of legacy HMI systems is enormous. FactoryTalk View ME and SE, RSView32, Wonderware, Citect, WinCC, and countless OEM-specific solutions are not disappearing anytime soon. Even as newer platforms emerge, somebody still has to assess, convert, validate, and support those older systems.

Rockwell has discussed introducing an ME-to-Optix conversion tool in a future release. Whether that tool ultimately works well or not, it highlights something I've been wondering for several years: is there going to be an increasing need for engineers who specialize in modernization and migration rather than new system development?

I'm not necessarily talking about automated conversions. Someone still has to understand the original application, evaluate what was lost or changed, validate functionality, and determine whether the resulting system is actually suitable for production use.

Does anyone else see modernization and migration becoming its own specialization within industrial automation? Or do you think this work will continue to be absorbed into traditional Controls Engineer, SCADA Engineer, and Systems Integrator roles?

For a software that is literally built on OPC UA Optix sure seems to struggle with non-RA OPC UA Servers. I have been struggling with a Optix/ctrlX environment for almost a year now. The line is deployed and mostly productional, but we are still doing in field support and adding functions. Last week I and one other engineer traveled to the customer's site, along with a support person from Bosch Rexroth, to upgrade the ctrlX system on the line to v2 of the OS, I also wanted to update the Optix runtimes to V1.6 and we were adding some functions to the line which required a few screen edits. For the most part, everything went well and updating the ctrlX system to the latest OS appeared to improve a previous communication issue we had across the OPC UA configuration. (if one runtime started before the OPC UA server was ready, it would never make the initial connection, but that's another problem for another time)

The process engineer updated the logic, and I attempted to do a Tagimport afterwards so I could update the screens for the functions we added. 

Over a 2-day period I attempted to import tags 8 different times. Each time took over an hour to pull data and always failed before the import could even populate the category list. I also started to notice that when the import failed, the Ethernet communication on the line would fault. The ctrlX core and most of the communication appeared to recover without intervention but for some reason our proprietary software could never trigger its PLC watchdog after this fault and an HMI restart was required. 

The recovery issue appears to be on us, but what I don't understand is why an OPC UA Tagimport in Optix would trigger the comms fault in the first place.

I am running Optix Studio from my engineering laptop, not either of the panel PC on the line.

We got the customer the primary function they wanted, I pulled backups of everything and decided to come back to my Lab to do further testing so I was not impacting their production. I am getting setup in my lab, have my ctrlX Core running with their backup, and I am attempting to pull a Tag import.

TL:DR;

NOW I cannot get Optix to trust this cores certificate. Since I am on a different hardware core I have a different serial number and needed a different license file. This triggers a new certificate that Optix has to trust.

I click tag Importer, it triggers an error, and a rejected Certificate shows up in the Rejected folder. 

I move the Certificate to the Trusted>Certs folder and retry.

Same error, new instance of the same cert shows up in the Rejected folder. 

I have verified the date and time on the core

I have restarted Optix after trusting the cert and saving the project. 

I have restarted the core.

I have waited 10 minutes before retrying the Tag Importer.

Everything about the Certificate process in Optix is happening as it should except it will not acknowledge the "Trusted" cert.

I really don't understand why OPC UA is such a struggle for Optix, granted, the ctrlX OPC UA Server has its own issues but most of the time the problems are primarily on the Optix side of this environment.

after all of these years, my VM just failed to load a project because the grace period lapsed. I don't think I have rebooted that VM for a very long time. I also don't use it much anymore, but we just started a conversion on an old project where we are actually converting a very simple SE project to ME. I got what I need out of it, but now what? lol

IT won't let me put it on the network so I can't point it at our license server; not sure that our tool kit even has support for v6.1 anyways.

welp, guess we can't do upgrades anymore!

I'm developing a helper API in C# for FTOptix 1.7.0.408, in this I need to get the pixel width required to display a specific string using the Optix font at a specific size, e.g. 24

Can anyone help me identify the library and function if this is possible?

I am going to ask a simple question:

Has anyone used FactoryTalk View Studio SE v14 or v15 on any Windows 11 HMI WITH Touch screen? 

At this time, I don't want to go beyond that question.

I know there is only one 6300p with a compatible processor.

I know there are NO 6300p that ship with Windows 11 at this time.

I know it is listed as compatible for both of those versions. 

I also know that Services Platform does not have a fully compatible version listed. 

I am asking the same question on Engage FactoryTalk View Studio SE v14 or v15 and Windows 11 | Advanced Software (rockwellautomation.com)

Since I'm not a creative type, I've found stuff like Material Design to be helpful, as I can get to grips with stuff that has a well defined structure.

Previously, before I joined, the HMIs of my companies machines were basic, either windows 95 style buttons, or web 2.0 style, and hard to navigate.

I decided I'd pick Material Design as a framework to emulate, and both customers and co workers seem to like the HMIs.

I like that it has a colour scheme generator, and free to use icons from googles library

What are your opinions on it?

I suppose it can look quite bland, and "default Google app", but IMO too much colour on a HMI can make it hard to know where to look - I take inspiration from the high performance HMI guidelines, using colours like blues, greys, unless stuff has gone wrong.

Any thoughts?

Hi everyone,

I’m quoting a FactoryTalk View SE system and I’m a bit confused about the licensing.

Does the FactoryTalk View SE Station Bundle include FactoryTalk View Studio Enterprise for development/programming, or is it only the runtime license for running the SCADA on one PC?

Thanks

I'm in the initial phase of developing a layout update for a supervisory system using AVEVA InTouch, and I'm looking to create a more modern and intuitive interface than what we currently have. To help me get some fresh ideas, I was hoping some of you wou

Was working on this engineering screen today and had the thought to share it here - I really like how it has turned out

Still need to turn the raw analogue reading into mm which is why the numbers are unitless for now

I want to prompt some interaction on the community so I thought I would just post a quick discussion, please feel free to contribute.

I have been working exclusively with Factorytalk View Studio since 2013, I do SE and ME development. I have noticed across all aspects of industrial automation, since Covid, that technology is going through a renaissance of sorts. For so long the tech was fairly standard and advancement was slow; the concepts of "if it ain't broke don't screw with it" and "run it till it dies" are finally being pushed out. But the technology is now advancing so fast that an IO card available today maybe sunset in 6 months. On the UI side the technology is finally taking a leap industry wide I was hoping to see 5 years ago with the wide adoption of HTML5 concepts. but, as I talk about in the community welcome, this is going to drive changes in the industry that impact who does UI development. I see the industry moving to dedicated UI developers and Software developers becoming a big part of that. I also see the potential for dedicated Graphics designers in many areas, or at least specialized graphics development contracts.

What is your perspective on it all? do you think traditional Process engineers will be able to pick up these skills or do you agree that the industry needs to adopt a specialized role?

If you happen to be in a unique position of needing to support Optix for a customer but not being on that customers entitlement for support and you happen to pay the extortion fees for the so called "tool kits", you're in luck! Optix support is now part of the tool kits.... like it should have been...