Hello,
I have configured Tag Data Sync between an Edge Gateway (8.1.44) and Central Gateway (8.1.43), and it's working as expected. When the Central services are stopped and restarted, no data is lost, as the Edge and PLC stay connected and sync data once the network is restored.
However, I’d like to know if there’s a way to log this synced data from Edge to Central in a custom SQL table with a specific structure and defined columns, rather than using the default format.
Thank you for your response. I understand that Edge supports only Ignition's standard historian tables. However, I’m specifically looking for a way to log the synced data into custom SQL tables in the Central server (not in Edge). Is there any possible way to achieve this, perhaps using custom scripting or other methods on the Central server?
Any further guidance would be greatly appreciated!
Yes, I understood that. There's no way to intercept the history data delivered to the central server before it is inserted into the central server's database in history format. And that format is one tag value per row, with no synchronization of timestamps, so there's no practical way to reshape into the "wide" tables you are after. You must generate wide rows at the source, but Edge cannot do that.
If you're looking to log data from tags in a specific format, I'd recommend using Ignition's SQL-Bridge module. For your case specifically, you'd either need to connect your central gateway directly to those tags to use the module, or you could purchase a new Ignition license with only the base and module (no expensive visualization component required!)
I think this module would give you exactly what you're looking for with minimal effort on your part (besides the cost of course).
If they are relying on Edge's store and forward, putting SQL Bridge in the central server will be a disappointment. All data while disconnected will be lost.
@Brandon_Peterson Thanks for your suggestion.
but @pturmel That's a valid point. We have data synchronization in both the edge and central servers to ensure zero data loss, even if the central server services are stopped and later restarted. This functionality is working as expected.
However, historical data from the central server is needed in a custom sql table format for the next data processing step.
Change from Edge to Standard Ignition in your facilities. Make an ordinary database connection there and use either SQL Bridge Transaction Groups to insert through the standard S&F engine, or script your data storage using system.db.runSFPrepUpdate().
Write schedule scripts in your Central server to retrieve historical data, repackage it into the desired format, normalized timestamps to correlate as best you can, and insert to your custom tables.
I would choose option #1. Option #2 is likely to be a nightmare.
Option #1 appears to be quite challenging for me, as there is no longer any use of Standard Ignition on the shop floor. Currently, we only have a single device connection with a 7-day data log (which is quite rare), and no screens or additional functionality in place.
Regarding Option #2, I am open to exploring it further, as I have previously used SQL Transaction Groups to log data, and functionality and screens were developed based on that approach.
Please let me know if there's an opportunity for further clarity or assistance with Option #2 or other alternatives.
An Option #3 might be to challenge the requirement for custom tables. Would you be able to create methods by which other sources are able to access the default Ignition Historian data tables in a 'universal' way?
Edit: A couple of examples:
Create a SQL View which returns a customized table to the user based on a more complicated series of queries.
Create an API (via WebDev module) which utilizes Ignition functions to return the customized table to the user.
Option #1would require a new license, and you could put it on the same computer/server/device.
This sounds like either a standard/rule or a description, either of which are worth changing, imho. The time and hassle it'll save you to do this custom data format thing of yours could justify the extra cost too.
I'll leave the rest to you and the others to make this decision. I don't mean to push my opinion any further, just wanted to clarify a bit.
