FactoryTalk Design Studio: Subroutine Improvements
A detailed guide to FactoryTalk Design Studio's improvements to subroutines.
A detailed guide to FactoryTalk Design Studio's improvements to subroutines.
Get new content delivered to your inbox every month.
No spam, unsubscribe anytime.
If you've ever found yourself wrestling with reusable subroutines in Studio 5000 Logix Designer, you're not alone. Although parameterizing subroutines worked, it always felt janky and there were lots of opportunities for errors.
FactoryTalk Design Studio changes all of that. Rockwell has fundamentally changed how subroutines work by introducing Routine Scoped Tags and proper interfaces for subroutines.
In this post, I'll walk you through what has changed.
Before diving into the improvements, let's acknowledge what made subroutines such a source of frustration in Studio 5000 Logix Designer. Understanding these limitations helps explain why the FactoryTalk Design Studio changes are so significant.
Traditional subroutines in Studio 5000 aren't truly self-contained because they didn't have their own data scope. In Studio 5000 Logix Designer, a subroutine had to use program or controller tags for data. This creates a dependency that makes it hard to reuse subroutines across projects.
To pass data into and retrieve data from a subroutine in Studio 5000 Logix Designer was a pain because there were so many manual steps and so many opportunities for mistakes.
You have to manually add input and output parameters to the Jump to Subroutine (JSR) instruction's interface.
Inside the subroutine, you need to use a Subroutine (SBR) instruction to retrieve those input parameters.
Finally, you need to use a Return (RET) instruction to return data from the subroutine.
Each of these steps is a potential failure point. If you get the parameter count wrong, mix up the order of parameters, or misalign data types, youcan be left scratching your head. For something as fundamental as passing data to and from a subroutine, this process felt unnecessarily complex and error-prone.
FactoryTalk Design Studio has improved subroutines in a pretty dramatic way.
First, FactoryTalk Design Studio has introduced Routine Scoped Tags. Each routine in Design Studio can now declare its own tags, completely independent of the calling program. This means your subroutines are truly encapsulated—they carry their own data scope and have no dependencies on external tag definitions.
Think about what this means for reusability. You can take a subroutine from one program and drop it into another without worrying about tag conflicts. The subroutine brings everything it needs with it.
When you define Routine-Scoped Tags in FactoryTalk Design Studio, you can designate them as:
Tags designated as input and output parameters are automatically added to the JSR instruction interface. No more manual parameter configuration, no more counting parameters, no more worrying about order or data types. The instruction parameters also take the name of the input and output parameters to give more context to the JSR instruction and validates the data type of the parameters.
Remember that three-step dance with SBR and RET instructions? It's gone. When you call a subroutine in Design Studio, the input parameters are automatically passed in, and the output parameters are automatically returned. The system handles the data flow transparently.
This isn't just about convenience—it's about reliability. Fewer manual steps mean fewer opportunities for errors. The interface is enforced by the system, not by your ability to remember to update three different places when you change a parameter.
Design Studio's subroutine improvements are genuinely impressive, but they're not perfect. There's one significant limitation that I hope Rockwell addresses in future releases.
Currently, you can't store subroutines as reusable definitions in the project library. This means you can't centrally manage subroutines and deploy them across multiple programs the way you can with Add-On Instructions (AOIs).
Yes, you could use AOIs for this purpose, but AOIs come with their own limitation: they're not editable online. For many applications, the ability to make live edits during commissioning or troubleshooting is crucial.
It would be ideal to see Design Studio support both library-managed subroutines and online editing capabilities. This combination would give us the best of both worlds: centralized management with operational flexibility.
After years of working around the limitations of Studio 5000 subroutines, it's refreshing to see FactoryTalk Design Studio tackle these issues directly. The combination of true encapsulation, automatic parameter management, and simplified data flow addresses real problems that have been frustrating automation engineers for too long.
While there's still room for improvement—particularly in library management—these changes represent a significant step forward. If you're still on the fence about migrating to Design Studio, the subroutine improvements alone make a compelling case for the transition.
The future of automation programming is moving toward better modularity, reusability, and maintainability. FactoryTalk Design Studio's approach to subroutines shows Rockwell understands this evolution and is building tools that support modern development practices. That's exactly the kind of innovation our industry needs.