Connect FactoryTalk Data Logger to Excel
FactoryTalk Data Logger writes to SQL — and Excel can query SQL — so pulling Data Logger data into a workbook sounds straightforward. The friction is that the SQL Express database lives on the same machine as your production HMI, the schema isn't analyst-friendly, and the data volumes can bring Excel to its knees without the right preparation.
If you've already tried something and hit a wall, the list below is probably why. The barriers aren't obvious until you're already in the middle of them.
Why it's hard
Seven reasons the Data Logger → Excel path is harder than it looks.
SQL Express has a 10 GB storage cap — and data disappears silently
Data Logger stores everything in a local SQL Express instance with a 10 GB database limit. On sites with high-frequency logging, the database fills up and new data stops being written — with no visible error. By the time an analyst notices a gap in the workbook, days or weeks of data may already be gone.
Tag names and values are in separate tables — Power Query needs a join
Data Logger's schema stores tag definitions (with human-readable names) in one table and timestamped values in another. Without a join, a Power Query pull returns a column of numeric tag IDs beside a column of values — meaningless without knowing which ID maps to which tag. Writing and maintaining that join in Power Query's M language isn't something most Excel users do regularly.
Untuned logging frequency creates row counts Excel can't handle
Data Logger can log at every PLC scan cycle — often sub-second. Sites that haven't explicitly configured a logging interval accumulate millions of rows per tag per month. Pulling even a few weeks of data for a handful of tags can lock up Excel during refresh, and a full year of data for a busy system will exceed what Excel's in-memory model can comfortably work with.
Distributed sites have multiple Data Logger instances — one query per machine
On a site with several PLCs, there's typically one Data Logger per HMI workstation — each with its own SQL Express database. Combining data from multiple lines or units requires separate Power Query connections to each machine, separate credential management, and manual merging in the workbook. There's no single query that spans the whole site.
Connecting to SQL Express means connecting directly to the HMI workstation
SQL Express runs on the same machine as the HMI. Getting Power Query to reach it means opening a network path from the analyst's laptop directly to a production OT workstation — which most OT security policies prohibit. Getting IT to agree to that path, document it, and maintain it is a significant coordination effort, and the exposure is real.
Excel for the Web can't connect to OT SQL Express at all
Excel on the web (SharePoint Online, Teams tabs, browser-based workbooks) can't reach SQL Server instances on private OT networks. Any workbook built around a Power Query connection to Data Logger SQL Express is desktop-only — it won't refresh in the browser, and it can't be shared as a live web workbook.
Data Logger only logs what's been configured — gaps surface at the worst time
Data Logger logs only the tags that were explicitly added to its configuration. If a tag wasn't configured, or was added after logging started, that data doesn't exist in SQL Express regardless of how long the system has been running. Analysts often discover coverage gaps only when they go looking for a specific data point for a report or investigation.
The approaches teams usually try
Three common paths — and where each one runs into trouble.
Power Query to Data Logger's SQL Express
Connect Excel's Power Query directly to the SQL Express database on the HMI workstation. This is the most direct path and works when you're on the OT network or have a VPN that reaches it.
The catch: Every analyst machine needs a network path to the OT workstation, SQL credentials, and knowledge of the two-table schema. The workbook breaks if the OT network changes, and it won't work at all in Excel for the Web. And if the SQL Express cap is hit, the data isn't there regardless of the connection.
Data Logger's native flat-file export
Configure Data Logger to write to CSV or flat files instead of (or in addition to) SQL. Some teams set up a scheduled task to copy these files to a shared network drive that analysts can access.
The catch: The files are append-only logs — not structured for pivot tables or time-series analysis. Combining multiple files across dates or machines requires manual work. There's no auto-refresh path back to a live workbook, and the files accumulate quickly, creating their own storage and maintenance problem.
Manual exports from FactoryTalk tools
Use FactoryTalk View or other Rockwell software to export trend data as CSV or Excel on demand, then import into the analyst's workbook manually.
The catch: This is a manual process every time — requiring either OT access for the analyst or a handoff from someone on the OT side. There's no scheduled refresh, no live data, and every export is a one-off copy that's immediately out of date.
How TrendOps solves it
TrendOps Edge reads Data Logger's SQL Express database locally on the OT network, normalises the data, and forwards it to the cloud over outbound MQTT. TrendOps Link — a Microsoft 365 Excel add-in — then surfaces that data in any Excel workbook, desktop or web, without any OT network connection from the analyst.
TrendOps Edge reads Data Logger locally on the OT side. Analysts access data through TrendOps Link — a standard Excel add-in that calls the cloud API. No VPN, no firewall exception, no path to the HMI workstation.
TrendOps handles the join between Data Logger's tag and value tables. In Excel, tags appear by name — not by ID. Analysts work with the data, not the database schema.
Choose the polling interval that matches your reporting needs. TrendOps normalises high-frequency Data Logger data before it reaches Excel, keeping row counts manageable without losing meaningful resolution.
TrendOps consolidates data from multiple Data Logger instances across a distributed site. TrendOps Link sees one unified tag namespace — no separate queries per machine, no manual merge step.
TrendOps Link is a Microsoft 365 web add-in — it runs wherever Excel runs. Workbooks refresh in the browser, in SharePoint Online, and in Teams tabs, not just on desktops that happen to be on the right network.
Once data is in TrendOps Platform, the 10 GB SQL Express limit is no longer relevant. Historical data is retained in the cloud for as long as you need it, and Excel can query as far back as your retention window allows.
Data Logger data lands in the same TrendOps Platform as AVEVA PI, Wonderware, DeltaV, and any other connected source. One workbook can pull from all of them — no separate queries per system.
TrendOps Edge pushes data to the cloud over one outbound MQTT connection. There are no inbound ports to open on the OT network, and the HMI workstation is never reachable from outside.
What you end up with
Data Logger data in any Excel workbook — desktop or web — with no OT network connection required from the analyst.
Desktop, browser, SharePoint, Teams — TrendOps Link works wherever Excel does.
Analysts never need a VPN or firewall exception to the OT workstation.
Tags resolved by name, frequency normalised, and schema translated before Excel sees it.
Data Logger alongside every other OT historian — one workbook for the whole plant.
Your team shouldn't need a path to the HMI workstation to pull Data Logger data into Excel
TrendOps moves Data Logger data to the cloud securely, so any analyst can work with it in any Excel workbook — no OT access required.
Book a Demo