Ignition Tag History Blanks Mean the History Path Is Unresolved

In this case the Perspective Time Series Chart works: it plots the generic Sine and Realistic tags correctly. The failure is the history lookup for one custom tag. That tag is historized to a MySQL history provider. A Named Query reads its rows from MySQL correctly, but a Tag History binding on the same tag returns a dataset with a timestamp column and an empty Speed column. In the Tag History binding's tag picker, the MySQL history provider browses empty even though tags are assigned to it. The same gateway also shows a symbolic OPC Item path to a Siemens PLC on the native Inductive Automation OPC server, which marks it as an Ignition 8.3 beta build rather than 8.1.x.

Why does the chart get timestamps but no values?

Work through the signal chain from the tag to the chart:

1. The tag is scanned from the PLC.
2. Tag history samples it and writes rows to MySQL through the history provider.
3. The Tag History binding asks the gateway for a window of history on a tag path.
4. The historian resolves that path against its stored tag metadata to find the matching tag record.
5. The historian reads the stored rows inside the date range and aggregates them into intervals.
6. The binding hands a dataset to the chart.

When the binding uses an interval-based return (fixed return size or interval), the historian builds the timestamp grid for the requested window no matter what it finds. If the path lookup in step 4 matches nothing, every value cell stays null. The result looks exactly like this failure: a full date column and a blank value column.

A Named Query skips step 4. It reads the table directly, so it succeeds whenever rows exist. A working Named Query next to a blank Tag History binding tells you three things:

• Storage works.
• The chart works.
• The fault sits in path resolution, the date window, or the build itself.

Treat this as a data-path fault, not a chart configuration problem. Do not touch the chart's series or trend properties until the binding preview shows numbers.

Which signal is wrong, and where do you read it?

Take these readings in order. Each one isolates a single link in the chain.

Signal	Where to read it	Symptom when it is wrong
Live tag value and quality	Designer Tag Browser, UDT instance member	Bad or uncertain quality; history stores nothing useful
Stored history rows	Named Query or direct SQL against the MySQL history tables	No new rows after a value change: history disabled, wrong provider, or storage stalled
Historical tag browse	Tag Browser inside the Tag History binding, under the MySQL history provider	Provider tree is empty: the historian has no path record the binding can resolve
Binding result dataset	Binding preview in the Property Editor	Timestamps present, value column null: path or date-window mismatch
Chart series and trend	Time Series Chart series and trend properties	Binding dataset has values but no line is drawn: column name mapping is wrong

In this installation, the second reading is good: MySQL holds the values. The third and fourth readings are bad. The break is therefore between storage and lookup.

Is the gateway running a stable build or the 8.3 beta?

Check the gateway version before anything else. Read it on the Gateway web page status/overview or in the Designer's About dialog.

• If it reports 8.1.x: continue to the history checks below.
• If it reports 8.3 (beta): stop and change the question.

A symbolic Siemens OPC Item path on the IA native server exists only in the 8.3 beta. Version 8.3 is a significant deviation from 8.1.x. It has its own separate support channel, and no training course material was published for it when this installation was built. A historian browse that comes back empty on a beta gateway can be a configuration mistake or a beta defect. Nothing on the project side will tell you which.

You have two ways out:

• Rebuild the same UDT, history settings, and binding on an 8.1.x gateway. If it works there, the beta is the variable.
• Take the reproduction to the 8.3 beta support channel with the gateway version and the binding configuration attached.

For learning and course exercises, use the released build the course was written against. That removes a whole branch from every future diagnosis.

Is the history actually stored under the path the binding asks for?

Rows in MySQL prove that something was stored. They do not prove it was stored under the path you are typing into the binding. The historian keys each stored tag by three things:

• the gateway system name
• the realtime tag provider
• the full tag path, including the folder and UDT instance member

Any of these changes breaks the lookup for older data:

• a renamed gateway
• a tag moved between folders
• a renamed instance
• data written while the tag lived in a different provider

Decision path:

• Named Query rows keep growing when the value changes: storage is live. Go to the historical browse check.
• Rows exist but stopped at some point in time: something about the tag changed at that time. Compare the stop time against when you last edited or moved the tag.
• No rows arrive after a forced value change: go back to the tag's history settings. The binding is not the problem yet.

Does the MySQL history provider list the tag in the historical browser?

In this installation the MySQL history provider shows empty in the binding's tag picker, even though tags are assigned to it. That empty tree is the key reading. The binding browse and the binding query both read the same historian metadata. If the browse finds nothing, a hand-typed path will usually find nothing too.

Check the UDT instance, not the UDT definition. The definition shows only defaults. The instance member shows what actually runs, including any overrides of history enable, storage provider, or sample settings. Open the instance, select the Speed member, and read these three settings directly:

• History Enabled is true on the member.
• Storage Provider names the MySQL history provider that the binding browses. It must not name another provider or an empty value.
• Sample mode and rate produce rows at a rate you can observe within a few minutes. A deadband set wider than the signal's movement produces almost no rows on a steady signal.

If all three are correct and the provider still browses empty while rows keep landing in MySQL, you have a gateway-side historian problem. On the beta build, that is the point to hand it to the beta channel.

Does the binding path, date window, and return format match the stored data?

Once the historical browser lists the tag, compare the binding against it field by field. Tag path typos and wrong datetime boundaries are the two most common causes of a populated time column with null values.

• Tag path: clear the path and re-pick the member from the historical tree. Do not retype it. A single character difference in a folder or instance name returns nulls with no error.
• Date range: the window must overlap the timestamps you can see in the Named Query result. Start with a realtime range covering the last hour, then force a value change. If you use a historical range, check it against the database timestamps. A time-zone offset between the database session and the gateway can shift the window completely outside the stored data.
• Aggregation and return size: an interval shorter than the sample rate leaves null buckets between real samples. That produces a gappy result rather than a fully empty one.
• Return format: wide format returns one timestamp column plus one column per tag path. The name of each value column is the name the chart must reference.

Is the chart consuming the columns the binding returns?

Check this only after the binding preview shows numbers. The Time Series Chart takes datasets directly. Each trend must name the series that holds the data and the value column to plot.

The XY Chart is organized differently:

1. Define a data source.
2. Reference that data source from the series.
3. Map the time field to the X axis.

Multiple datasets then appear as parallel series. If the binding has values but no line appears, the fault is the column-to-trend mapping. It is not history.

Two workarounds exist for charts that want row objects instead of a dataset.

Workaround 1: script transform. A script transform on the binding can split the time column and value column into a list of records. The adapted transform below keeps the original's column-name check and float parsing. Change the column names and output keys to match your query and chart configuration.

The transform only reshapes data. It does not repair a null column. Feed it a blank Tag History result and it returns an empty list.

Workaround 2: Named Query binding. A Named Query binding against the history tables is a valid way to feed a chart. The trade-off is that you give up the Tag History binding's built-in features:

• aggregation modes
• interval bucketing
• transparent partition handling
• path-based lookup that survives table rollover

For a chart operators will scroll and zoom, use the Tag History binding. Use the Named Query when you need joins or filters that tag history cannot express.

How do you rebuild the binding and prove the trend is real?

Do this on a released 8.1.x gateway, or on the beta with the beta channel engaged.

1. Confirm the gateway version on the Gateway status page. Record it.
2. Open the UDT instance and select the Speed member. Confirm History Enabled, the MySQL Storage Provider, and a sample rate short enough to observe.
3. Force a value change on the tag. Wait at least one sample period. Run the Named Query and confirm that a new row with the new value has appeared.
4. Open the Tag History binding's tag picker, expand the MySQL history provider, and confirm the Speed member is listed. If it is missing, stop here and go back to the gateway historian and build checks.
5. Remove the existing path. Add the member by browsing the historical tree.
6. Set a realtime date range covering the last hour, wide return format, and an interval no shorter than the sample rate.
7. Read the binding preview. Confirm the value column is populated.
8. Bind the chart series to that dataset. Set the trend's value column to the column name shown in the preview.

Verify the trend against the source data:

• Pick one timestamp and compare the binding preview value against the Named Query value for the same row. They should agree within the aggregation used.
• Step the tag value and watch the step appear on the trend within one polling cycle plus one sample period.
• Widen the range to cover data older than any recent tag edits. Nulls confined to older periods mean the path changed at that time. The current binding is correct.

FAQ