Connect > Excel RTD

Troubleshooting Excel RTD¶

This page covers the common reasons a cell does not show a live value, in the order worth checking, and how to read ami_rtd.log. The log, in the same directory as the DLL, records the connection, login, and subscription lifecycle and is the single best diagnostic.

A cell stays `0` and never updates¶

A cell that has been entered but has never received a value holds the number 0, not an Excel error, so a cell stuck at 0 is the usual symptom of every cause below. Work down this list; each step rules out one cause:

The component is not registered. Confirm AmiRtd.Server exists under HKCU\Software\Classes in Registry Editor. If it is missing, re-run the installer, or regsvr32 ami_rtd_server.dll from the installation directory, as a normal user.
The config is in the wrong place or points at the wrong host. ami_rtd_config.json must sit in the same directory as the DLL, and its host and port must reach a running Center. Restart Excel after editing it, because the config is read when the component starts.
The client is not authorized on the Center. A secure Center rejects an untrusted client at the TLS handshake. See The connection is rejected at the handshake.
The row cannot be identified. If the connection and subscription succeed and rows arrive but every cell stays 0, the table needs a keys entry naming its identity column. See Identifying rows.
The cluster or topic is wrong. Confirm the cluster name matches a name in the config and the topic is table.object_id.field, with at least two dots. A topic with too few dots, and a topic naming a table that does not exist, both leave the cell at 0 while the log reports success.
The Center is not publishing to that table. Confirm rows are actually changing on the Center for the table and row the topic names. A field that has not changed since the subscription opened stays at 0, and rewriting it with the value it already holds does not count as a change.
The cell is no longer an RTD formula. Typing a value over a live cell replaces the formula with that literal and ends the subscription, leaving a cell that looks like its live neighbours. Check the formula bar rather than the displayed value: a cell still subscribed reads =RTD(...). Restoring the formula does not restore the value; the cell returns to 0 and waits for its field to change.

The tool reports success but no value arrives¶

The console driver prints [OK] for its startup and COM steps, and Excel loads the component, before any network connection is confirmed. None of these mean a socket reached the Center.

Treat a driver [OK] line or a loaded cell as "the component started", not "it connected".
Read ami_rtd.log for the real result: it records whether the connection, any login, and the subscription succeeded.

A run blocks for a long time with no error¶

If the driver prints its startup lines and then waits with no further output, and no value arrives, the cause is at the connection rather than the topic. The component does not report a failed or pending connection in its console output.

Two different causes produce this symptom and the same No Ami server available at <host> line in ami_rtd.log: a host or port that does not reach the Center, and a client the Center rejected at the TLS handshake. The log does not distinguish them. Confirm the host and port first, and if they are right, treat it as an authorization failure and see The connection is rejected at the handshake.

The connection is rejected at the handshake¶

A secure Center enforces mutual TLS and rejects a client whose certificate is not in its allow-list. This failure does not surface in Excel; the cell simply never updates.

To confirm and fix:

ami_rtd.log does not name this cause. It records No Ami server available at <host>, the same line a wrong or unreachable host produces, with no mention of TLS, the certificate, or the allow-list.
Confirm it with a direct TLS probe, using the openssl.exe bundled in the installation directory:
1
openssl.exe s_client -connect <host>:<port> -cert keys/client.crt.pem -key keys/client.key.pem -brief
An unauthorized client is refused with tls alert certificate unknown (alert 46). Presenting no certificate at all is refused with tls alert bad certificate (alert 42). Once the key is authorized and the Center has restarted, the same probe reports CONNECTION ESTABLISHED.
Authorize the client: append the ssh-rsa line from keys/client.pub to the file named by the Center's ami.center.ssl.authorized.clients.file property, default keys/3forge.auth, then restart the Center. See Authorizing the client on the Center.

A gateway connects but sends nothing¶

A query gateway with an authenticator refuses a subscriber that has not logged in, but it accepts the connection and the subscription first, so every cell stays 0 as if the table were empty. Set username and password on the cluster for a gateway. Do not set them against a plain Center: a Center has no route for a login request, so it returns an exception and destroys the subscription, and ami_rtd.log shows only Server returned an exception (Type::Throwable). The log also prints a logged in line on the no-credential path where no login was sent, so it cannot be used to confirm authentication either way.

`regsvr32` fails during install¶

The usual cause is a missing or blocked runtime DLL. Confirm the bundled OpenSSL and MSVC runtime DLLs are present next to ami_rtd_server.dll. If the installer was downloaded, unblock it (right-click, Properties, Unblock) before running.

The subscription succeeds but no value appears¶

If ami_rtd.log shows the connection and subscription succeeding and the Center is publishing, but no value ever arrives, every cell on the table sits at 0, and the console driver prints nothing, the client cannot match arriving rows to the topic. Add a keys entry naming the column that identifies the table's rows, then re-run:

"keys": [
  { "table": "<table>", "key": "<id-column>" }
]

Once the entry is in place, ami_rtd.log prints a row identified line for each row, and values begin to arrive. Add a keys entry whenever values do not surface, rather than assuming the table's index is enough. See Identifying rows.

A sheet stops updating with no error¶

Cells that were live and have stopped changing may have lost the connection to the Center. Nothing in the sheet reports this: every cell keeps the last value it received, with no error, no blank cell, and no staleness indicator, so a frozen sheet and a live one look the same.

Confirm it in ami_rtd.log, which records a disconnected line for the cluster. The component reconnects on its own once the Center is reachable again, and the log records the reconnection and the new subscriptions.

A reconnected sheet can still show values that no longer exist

Reconnecting restores the subscription, not the data. Each cell keeps its stale value until the field it watches next changes on the Center, and a table whose rows were lost, as happens on a Center restart where no PersistEngine is configured, has nothing to send. The sheet then shows values for rows that no longer exist, over a healthy connection and with a clean log. After any Center outage, confirm one known value against the Center before trusting the sheet.

Reading `ami_rtd.log`¶

The log is append-only and lives in the installation directory. It carries the connection lifecycle, the login result where a gateway is used, and subscription and error messages. When a cell does not behave as expected, match its cluster and topic to the log lines written when the cell was entered, and use those to place the failure at the connection, the login, the subscription, or row identity.