Connect FactoryTalk Data Logger to Power BI
FactoryTalk Data Logger looks like the shortest path to Power BI — it already writes to SQL, and Power BI speaks SQL. The problem is where that SQL database lives, what it looks like inside, and what you have to do to your OT network to get Power BI in front of it.
If you've already tried something and hit a wall, the list below is probably why. The barriers stack on each other — fix one and you're looking at the next one.
Why it's hard
Seven reasons the Data Logger → Power BI path is harder than it looks.
SQL Express has a 10 GB storage cap — and data disappears silently
Data Logger writes to a local SQL Express instance, which is limited to 10 GB. On sites with untuned logging frequencies, the database fills up and new data is simply dropped. There's no alert, no error in Power BI — the data just isn't there. Many teams don't discover the gap until they need to report on a period that was never stored.
Tag names and values are in separate tables — every query needs a join
Data Logger's schema splits data across a tag definition table and a value table. A tag ID in the value table maps back to a human-readable name in the tag table. Every useful query requires a join that most Power BI developers — and most analysts building their own reports — don't know to write. What you get without the join is a table full of integers and timestamps.
Untuned logging frequency creates row counts that overwhelm Power BI
Data Logger can be configured to log on every PLC scan cycle — often 100ms or faster. Sites that haven't explicitly tuned their logging intervals end up with tens of millions of rows per tag per year. Power BI's in-memory model wasn't built for raw, full-resolution time-series at that density. Refreshes time out, models balloon in memory, and dashboards become unusable.
Distributed sites run multiple Data Logger instances — one connection per machine
On a site with multiple PLCs, there's typically one Data Logger instance per HMI workstation. Getting a complete picture of the site means connecting Power BI to each SQL Express instance separately, maintaining separate credentials and query logic for each, and combining them downstream. There's no unified view built in.
Connecting to SQL Express means connecting directly to the HMI workstation
SQL Express runs on the same machine as the HMI software. To query the database from Power BI, you need a network path to that workstation — meaning IT has to open a firewall rule or route into the OT environment, pointing directly at a machine running production HMI. Most OT security policies prohibit exactly this. Even when IT agrees to do it, the exposure is real.
No native Power BI connector — SQL Express is the only door in
There's no FactoryTalk Data Logger connector in Power BI's data source library. The only path is the SQL Server connector pointed at the SQL Express instance. That requires SQL credentials, network routing from the Power BI machine to the OT workstation, and someone who knows the Data Logger schema well enough to write a meaningful query.
Power BI Service requires an on-premises data gateway on top of everything else
Power BI Desktop can connect to on-premise SQL sources directly — but Power BI Service (scheduled refresh, sharing dashboards, Teams embedding) cannot. It needs an on-premises data gateway installed somewhere on the OT network, maintained and updated by IT, and registered to the tenant. That's another layer of infrastructure, another point of failure, and another team to coordinate with.
The approaches teams usually try
Three common paths — and why each one runs into the same underlying problems.
On-premises Power BI gateway to Data Logger SQL Express
Deploy a gateway on the OT network, point it at each SQL Express instance, and connect Power BI Service through it. Works in theory — and some teams get it running — but it requires direct HMI workstation access, IT buy-in on OT firewall changes, and ongoing gateway maintenance.
The catch: The gateway itself becomes a dependency. When it goes down — updates, restarts, network changes — every dashboard fed through it goes dark. And you still haven't solved the 10 GB cap, the schema complexity, or the per-instance connection problem.
ETL pipeline: Data Logger SQL → cloud database → Power BI
Extract Data Logger data into Azure SQL or a data warehouse on a schedule, then connect Power BI to the cloud database instead. Removes the gateway dependency and makes Power BI Service refresh reliable — but the ETL pipeline still needs to reach the OT network, still needs to decode the tag/value schema, and still has to deal with high row counts.
The catch: You've added a significant engineering project just to get the data out of the OT network. The pipeline needs to handle the SQL Express cap, downsample high-frequency data, join the tag and value tables, and stay running across Data Logger software updates and network changes.
FactoryTalk Analytics / VantagePoint
Rockwell's own analytics and reporting platform understands FactoryTalk data structures natively. If your organization is already standardized on Rockwell's stack, VantagePoint can surface Data Logger data without the schema translation problem.
The catch: VantagePoint is a separate licensed product that requires its own deployment and training. It's Rockwell-only — it doesn't combine Data Logger data with data from Emerson, Siemens, or other OT systems. And your IT and business users still have to work in a tool that isn't Power BI.
How TrendOps solves it
TrendOps Edge reads from FactoryTalk Data Logger on the OT network and moves data to the cloud through a single outbound MQTT connection — no inbound ports, no gateway, no HMI workstation exposure.
TrendOps Edge sits on the OT network alongside Data Logger. It reads the SQL Express database locally — your IT team never has to open an inbound port to the HMI workstation.
Edge pushes data to the cloud over a single outbound MQTT connection. No firewall exceptions, no VPN tunnels, no inbound holes in your OT perimeter.
TrendOps handles the join between Data Logger's tag definition and value tables. Power BI sees clean, named tag data — not a table of IDs and integers.
Set the polling and forwarding interval that matches your reporting needs. TrendOps normalises high-frequency data before it reaches Power BI — no more in-memory model overflows.
TrendOps Edge consolidates data from multiple Data Logger instances across a distributed site. Power BI connects to one platform endpoint — not one SQL Express instance per machine.
Data is already in the cloud when Power BI reaches for it. Power BI Service connects to the TrendOps Web API directly — no gateway to install, register, or maintain.
Once data lands in TrendOps Platform, the 10 GB SQL Express limit is no longer in the picture. Historical data stays available as long as you need it, and you choose how far back Power BI can query.
Once Data Logger data is in TrendOps Platform, it sits alongside data from AVEVA PI, Wonderware, DeltaV, or any other connected source — one dataset for the whole plant in Power BI.
What you end up with
Power BI dashboards built on clean, cloud-hosted process data — with no OT network exposure in the reporting path.
Power BI Service connects to the cloud — no on-premises gateway to install or maintain.
Tags resolved, frequency normalised, and schema flattened before Power BI ever touches it.
IT never needs to open a path from the reporting tool to the OT workstation running HMI.
Data Logger data sits alongside every other OT source in one unified platform.
Your Power BI team shouldn't need SQL access to an HMI workstation to report on plant data
TrendOps moves Data Logger data to the cloud cleanly and securely — so your analysts can build in Power BI without touching the OT network.
Book a Demo