Hi,
I’m using Remote Tag Providers via the Gateway Network.
Locally, reading around 60 tags with system.tag.readBlocking takes about 0.003 seconds,
But via the Remote Tag Provider on the central Gateway, reading the same tags takes about 2.5 seconds.
Setup:
Multiple remote Gateways connected to PLCs
Default scan class (1 second)
Very low network latency
Goal:
Read and, when necessary, write around 4000 tags per Gateway (100 Gateways) in less than 1 second on the central Gateway.
The central Gateway must be able to not only read but also write tags back to the remote Gateways.
Questions:
When using readBlocking or readAsync on a Remote Tag Provider, does it return the cached value from the central Gateway or does it always request the value from the remote Gateway?
How can I ensure the read and write speed on the central Gateway is as fast as local tags?
Is using Document Tags a recommended approach to handle this amount of data?
Could Document Tags introduce significant overhead on the central Gateway, especially when ~400k tags need to be processed and written to local tags?
Would using Historical Tags be a suitable option for this scenario?
IIUC, the only "cached" value is for tags that are currently bound (subscribed) somewhere in the central gateway. Everything else will need a round trip to the other gateway.
You can't. Local will always be faster than remote. I'm kinda surprised you think this is possible.
You might get some advantage with message handlers in local gateways that are written to perform multiple tasks in one central/local message round trip.
Perhaps you could share more about why you need this. In case this is an XY problem.
Thank you, pturmel, for patiently and thoughtfully answering the questions.
In our control scenario, there is a central server hosting the main user interface and primary databases.
Users control the systems through this central server.
The central server is connected to several dozen Edge Gateways, each managing multiple Siemens S7-1200 PLCs.
Critical data from each Edge Gateway is transferred to the central server via Incoming Connections and stored in the main database. Local databases on the Edge Gateways also store this data.
Synchronization scenarios have been implemented to keep databases consistent.
Each Edge Gateway allows direct user connections in emergency situations such as communication failures, but the primary user interaction with the interface occurs via the central server.
Our current issue is a significant delay in reading and writing tag values from each Edge Gateway.
I have tested both blocking and asynchronous methods, and the results are roughly similar.
Due to the similar structure of most control PLCs, I have used UDT tags. UDT tags from the Edge Gateways are fully accessible on the central server without issues.
A thread-based script runs on the central server to read from and write to the Edge Gateways as needed.
When a user connected to the central server makes changes, such as editing fields or sending boolean commands, these values must be sent to the corresponding Edge Gateway. However, this is occurring with a noticeable delay, outside the expected timeframe for the project.
Therefore, I am looking for a secure and reliable method to read and write tag values from the Edge Gateways with latency under one second.
We assume network latency is very low and connection stability is excellent, using dedicated lines for PLC to Gateway communication
Ignition Edge doesn't support database connections. Do you mean "edge" gateways in the generic spoke context? If actual Edge edition gateways, you'll have to clarify.
Are you using remote tag providers? Are you not using tag bindings in your UI to point at tags in RTPs? I'm not clear on why you need scripted reads for user interfaces.
Do you mean UDT instances in the edge gateway tag providers? (Which would be visible in the central gateway's RTPs.) Or do you mean UDT properties in your user interfaces? If the latter, you should completely redesign your UIs to not do that. Wherever you think you need such, provide a string tagpath parameter and use indirect tag binding to access individual UDT members.
Note that Remote Tag Providers are deliberately blocked from updating tag values faster than once per second, no matter what the origin gateway's tag group says to do. If you want tag updates on a UI to be faster than that, you must run the UI directly on the origin gateway.
Are your "edge" gateways in the same facility as the central gateway? If so, why?
Yes, I mean the official Ignition Edge Gateway version installed on the edge gateways.
I have used the MongoDB module to establish the connection to the database.
I use Tag Providers and have assigned a real-time name for each Tag Provider.
I read tag values using scripts because I need to store them in the MongoDB database.
Reading tag values via scripts is for storing current data and important parameters in the database, while writing tag values via scripts is used to restore setups and configurations when needed.
This process is completely separate from the UI and is solely intended for storing data in the database and restoring parameters and configurations from the database.
My UI is dynamic and already uses a structure that accesses the tags with parameterized tagpaths.
Yes, this method provides an acceptable speed, but unfortunately, this scenario is not approved in the project structure. The main focus is on using the UI from the central server, and direct access to the edge gateways is defined only as a precaution for possible connection outages in the project scenario.
No, the edge gateways and the central server are not located in the same facility. Their communication is established over the internet and high-speed internal networks
Is using Document Tags by filling Document Tags on the edge gateways and rewriting them to local tags on the central server—and vice versa on the edge gateways—a proper method? Or has Ignition provided a better solution to address this issue?
Seems like a long time.
How long does 1 tag read take (on average, over 10 reads)?
What is the average ping response time between Central & Edge gateways?
Would it be better to use OPC-UA to connect to these remote gateways? This would allow faster data and report by exception, so should be efficient and tags for scripting would be local tags at that point, but you would have to create those tags in the central gateway.
Is MongoDB natively supported in the Standard edition of version 8.3?
Our project manager previously spoke with Ignition representatives, and they stated that in version 8.3, MongoDB would be supported natively in the Standard edition without the need for an additional module.
However, I couldn’t find any documentation confirming this.
Also, we have this module not only on the Edge version but also on the Standard Unlimited version on the server side.
I would appreciate it if you could guide me on this matter, as I need to gather sufficient information before migrating from Edge to the Standard edition
Our goal is to focus on the native capabilities of Ignition and its core solutions.
Considering that Ignition has introduced tag import, it is expected that the speed and quality of communication should be better than OPC-UA.
I will test this method to see the results and share the outcome in this thread.
Thank you very much for your guidance.
OPC-UA is part of the capabilities and core solutions of Ignition. You just need to enable remote connections on the Edge gateways and allow access to the tag provider, then you can link to any existing tag in the Edge tag provider you want.
Thank you for your guidance. However, the issue is that the Ignition Historian does not support MongoDB directly.
We need to display MongoDB data in Grafana as well. This is one of the reasons why, in practice, we cannot rely heavily on the Historian.
The solution you proposed is excellent, but in reality, for about several dozen gateways, it would require at least 30 times more cost.
That is unfortunate. I'd be migrating away from all dependencies on MongoDB. If you weren't using it, then Edge's own historian, sync'd to your Central gateway, would likely significantly boost performance.
How much skew can you tolerate on the data flow to MongoDB? If you switched to IA's historian for primary recording, you could regularly query the forwarded history in the central gateway to push in bulk to MongoDB.
With that, you'd still have data in Mongo, Edge edition in your facilities to keep license cost down, and likely superior network performance.
Thank you, this solution definitely offers better performance.
Currently, we are planning to test sharding and clustering for our MongoDB database.
The goal is to have tags read directly via scripts on the local gateways. In this case, due to caching values in the buffer, the latency is less than 200 to 300 milliseconds. Then, the values are sent to the mongos; in this way, besides writing data to the local database, the values are also written to the central server database.
This solution is likely to perform better in terms of timing, but it requires testing and evaluation.
Please share your opinion on this matter.
We will definitely test the solution you mentioned as well. It is probably a good option too.
Again, I sincerely appreciate the time you took to respond and guide us.
