Sepasoft MES 2.0 Help Documentation
Sepasoft MES 3.0 Help Documentation
Knowledge Base Articles
Online Training (new)
Online Training (legacy)
Contact Tech Support For Implementation
Toll Free: +1(800) 207 5506
Outside US: +1(916) 939 1684
Getting started with Task Routing requires changes to your Ignition license(s). Please reach out to Sepasoft before attempting to implement Task Routing.
The Sepasoft modules are very powerful tools for providing context to all of your operational data. In some circumstances, particularly when the Ignition Gateway server is substantially tasked by the MES project, users have a tool called Task Routing available to them, that enables the off-loading of costly tasks like performing Analysis and serving clients.
For the vast majority of users, MES Task Routing is unnecessary. The Sepasoft MES Suite is designed to be resource-efficient, and perform operations, analysis and serve clients all on the same Ignition Gateway Server. However, in certain very high impact implementations, users may find that their Ignition Gateway Server is consistently taxed. Here are some symptoms of an MES implementation that may be aided or improved by the addition of Task Routing:
In order for Task Routing to be worth considering, Item #1 and at least one of #2 and #3 must be true. If your server load is high, but you are not heavily employing Analysis and/or MES components, Task Routing will not help you. If CPU load isn't consistently high, then Task Routing is unnecessary. In addition, Task Routing doesn't help with load occasioned by Live Analysis, which is always run on the primary or Runtime server, even when Task Routing is implemented.
The Runtime server is the primary server in any Task Routing hierarchy, and it is unlike other server types, in that there can only be one of this type. It is where the Production model is configured, and where the actual MES work gets done. Operations are executed here, tag values are collected here, samples are collected here, recipes are configured and applied here. It acts in all ways as a normal MES server - it can execute Analysis and serve clients, if desired; you can think of it as a Runtime, Analysis and Visualization server, all in one. Another fact to keep in mind is that Live Analysis lives here - if you want other servers to see Live Analysis values, you must designate this server as a Remote Tag Provider to the other servers.
A Task Routing hierarchy can have any number of Analysis servers. These servers must be connected to the same database as the Runtime server, and they simply execute Analysis queries against the database. This saves the Runtime server from having to do the work of actually executing such calls, and parsing and calculating the results. In addition, these servers can serve Clients and show MES components; they can act both as Analysis and Visualization servers. These servers do the Analysis work themselves, but relay all other work to the Runtime gateway. In the Task Routing configuration page for such a server, the user must designate a Route to the Runtime server.
Likewise, a Task Routing hierarchy can have any number of Visualization servers. They do not need a database connection at all. These servers simply help offload the work of serving clients, but they don't perform any MES work - Analysis calls are sent to an Analysis server, and all other operations are sent to the Runtime server to perform. In the Task Routing configuration page for these servers, the user must configure two routes, one to an Analysis server, and one to a Runtime server. This is true even if the Runtime and Analysis servers are one and the same.
Visualization vs. Vision
"Visualization" refers to the graphical display of manufacturing information, not the Ignition "Vision" design environment.
Each gateway can optionally route Analysis and/or Runtime
Only one Runtime gateway can exist in the Task Routing network
Only 1 hop is allowed for remote calls, so the Task Routing network tree should only have 2 levels
In this architecture, the clients talk to main gateway and main gateway routes the Runtime server.
Main gateway just serves clients, forwards the Analysis/Runtime to another gateway. This has the effect of offloading the serving up of clients to a separate gateway.
Main gateway just serves clients, forwards Analysis and Runtime to different gateways. This has the effect of splitting client, Analysis, and Runtime processing.
Different clients can talk to different gateways which do their own Analysis processing but route Runtime to a separate gateway.
Different clients can talk to different gateways which helps to share the load of serving clients. Each of these gateways can further split off to separate Analysis gateways while sharing a Runtime gateway.
Task Routing configuration with a Runtime routing to Analysis is NOT acceptable.
Task Routing settings link:
Task Routing page where you can add task routes:
Task Routing page (after clicking on "Create New Route..." above) where you can add a new route by selecting the route type (Analysis or Runtime) and choosing a gateway from the Ignition gateway network. In this example, an Analysis route is being set up to the gateway named "Ignition-Analysis". This means that Analysis calls will be forwarded to "Ignition-Analysis" for processing.
After successfully creating a new route. In this case, it was a Runtime route defined to the gateway "Ignition-Runtime".
Both Analysis and Runtime routes set up:
Aside from pointing to the gateway network documentation for Ignition, the above is essentially the setup/settings for connecting gateways in a Task Routing network. The above example would be consistent with a situation where the local gateway is a "visualization" type that serves client connections but forwards all of its calls to the other two gateways. All Analysis calls will be forwarded to Ignition-Analysis and all Runtime calls will be forwarded to Ignition-Runtime.