RFEM troubleshooting

Setting the connection up is on Connecting RFEM. This page is for when it does not work.

Each state below has its own address, so Dlubal CALC can send you straight to the one that applies: /docs/rfem/troubleshooting#rfem-not-running is the section for that blocker and nothing else.

Restore the connection to RFEM

Open “Restore connection to RFEM” in the RFEM menu. With your consent, CALC checks the Connector, offers an update if needed, synchronizes the key of your signed-in account and verifies RFEM access. Setup or a Windows permission prompt may need your confirmation. RFEM models are not changed. RFEM is started only when you click Start RFEM in this dialog, and it is never closed.

From Connector 2.30.7, a new explicit attempt can also activate a key that was saved but not yet applied to the running connection server. If an active or unresolved operation prevents a safe restart, CALC reports deferred activation. Check the operation, then start Restore connection again.

Setup waits at most ten minutes; connection verification waits at most three minutes. Closing keeps checks running in the background on this page. Stop checking ends further checks, while dispatched actions may continue. Success requires confirmed RFEM access. Earlier model requests are never replayed automatically.

When the installed Connector supports native updates, Check and repair can verify the offered version and start its installer with standard settings. Windows may still ask for UAC confirmation. A missing or older Connector uses the offered download instead. Cancellation and deferred installation have separate outcomes; an unknown outcome does not trigger a second installation attempt.

First: which link of the chain is broken

The RFEM menu and the RFEM row in Settings use the same connection status. Successful MCP initialization alone does not confirm RFEM access; a known API-key rejection appears in both places.

Three programs have to agree, and each one can fail on its own:

First open the RFEM icon in the message bar and read the reported blocker. http://127.0.0.1:8083/rfem-info supplies additional version information. Neither this nor a successful /health response proves RFEM API access. Over the cloud relay, readiness remains unconfirmed until a recent connector status is available.

RFEM is not installed

Blocker: rfem_not_installed

No RFEM 6 installation was found on the machine running the connector.

Install RFEM 6, or pair the connector on the machine that has it. The connector and RFEM have to be on the same machine: the connector talks to RFEM through a local interface, not over the network.

RFEM is not running

Blocker: rfem_not_running

RFEM6.exe is not running. Open RFEM 6 and the state clears by itself, usually within a few seconds. Nothing needs restarting.

In “Restore connection to RFEM”, Start RFEM opens RFEM for you; this happens only on that click. The dialog stays on the RFEM step while RFEM starts and continues with the connection test by itself once RFEM is ready. If RFEM is already starting, the button does not open a second instance.

A dialog in RFEM is blocking it

Blocker: rfem_modal_dialog

Switch to RFEM and close the dialog. If a request had already started, wait for its result and inspect the model before asking again. A chat timeout does not confirm that RFEM has finished working.

RFEM was started but its window never appeared

RFEM can stop during its own start, before the main window opens, because it asks something first: a notice about a new version, an error, or whether to restore a model after an unexpected exit. RFEM is then running, but you may not see it at all; the dialogs can also sit on another monitor.

“Restore connection to RFEM” names this case: it says when RFEM was started and which dialogs are waiting. Show RFEM dialog brings the active dialog to the front. When Windows does not allow that, the dialog flashes in the taskbar instead. CALC never answers, moves or closes an RFEM dialog for you. Once you have answered all of them, the connection test continues by itself while the repair dialog is open.

The component is starting

Blocker: mcp_starting

A start or restart is in flight. This phase is bounded: wait, and it resolves.

First-time setup is still installing

Blocker: mcp_installing

First-time setup downloads and validates the MCP packages, which can take minutes. With MCP 1.0.14 and a matching Connector, those packages live outside RFEM's installation directory. Python and the Dlubal API still come from the running Dlubal program: RFEM, or from Connector 2.30.25 also RSECTION or RSTAB.

Nothing is serving the connection

Blocker: mcp_down

RFEM is running, but no component is answering for it. Restart the connector.

If it comes back, look at the version line in Settings → MCP servers. An outdated component that keeps being adopted from an earlier session is the usual reason a restart helps for a while and then does not.

The component stopped answering

Blocker: mcp_unresponsive

First check in RFEM whether an operation is still running. You can then attempt a controlled Connector restart. With MCP 1.0.14 and a matching Connector, running or unresolved operations prevent the MCP process from being stopped. A restart stays blocked when idle state cannot be confirmed.

With an updated Connector, before a guarded restart, the connector waits up to two seconds for an in-flight request to finish. The existing checks for active RFEM operations still apply afterward. Longer requests or unverified states continue to defer the restart.

RFEM is not listening on its interface port

Blocker: grpc_unreachable

The component is up and RFEM is running, but RFEM is not answering on the port the component uses. Restart RFEM.

This is the one state where restarting RFEM rather than the connector is the right move.

No Dlubal API key

Blocker: api_key_missing

Without a Dlubal API key the component is never started at all. Choose Open connection settings → Manage in profile in the RFEM menu. Automatically managed keys are provided at sign-in and displayed partially masked without an edit field. If your profile offers an input field instead, enter and save your own Dlubal API key there. If no valid key is available, contact Dlubal support.

If you sign in to CALC with Google or Microsoft, CALC can only provide the key when a Dlubal account exists for the same email address. Without one, RFEM, the geo-zone lookup, and file conversion stay unavailable. Create a Dlubal account with the email address you use for CALC, then sign out of CALC and sign in again.

If you already have a Dlubal account but it is not linked to a company, CALC cannot provide the key either. Do not create a second account; contact Dlubal support to complete the account, then sign out of CALC and sign in again.

RFEM rejected your Dlubal API key

Blocker: api_key_rejected

The most common cause is that CALC and RFEM are signed in with different Dlubal accounts, for example a personal account in the browser and a company account in RFEM. Check which account is signed in on both sides. If they differ, sign in to one of them with the other account, then run Restore connection to RFEM.

RFEM rejected the key currently in use. This does not prove that the running connection server already uses the key of your signed-in CALC account. First run guided restore with Connector 2.30.7 or newer. It reconciles the saved and applied keys. The synchronized CALC key takes precedence over an inherited environment value.

If rejection persists after activation succeeds, ask Dlubal support or your administrator to check the key and API permissions of your signed-in account. Repeated reinstalls do not fix missing permissions.

An earlier operation has no confirmed outcome

Blocker: unknown_operation

An earlier RFEM operation was interrupted before its result could be recorded, typically because RFEM or the computer was force-closed while it ran, or because the connection to RFEM could not be closed cleanly afterwards. Until that execution record is resolved, RFEM refuses new model-changing submissions (busy). This is a deliberate safety lock against applying partial changes twice. A possible partial change lives in the RFEM session that ran the operation. Once that session has ended, RFEM reopens the model from its last save, so the record is released automatically: by the MCP server from dlubal-mcp 1.0.16, and by Connector Setup from version 2.30.17 for older servers. Until then the lock also holds back a Connector update, and Setup reports "Setup deferred: An earlier RFEM operation has an unknown outcome" without changing any files.

Reinstalling RFEM or the MCP server, changing ports, and starting a new chat do not clear the record: it is preserved on purpose. Instead:

1. Open the model in RFEM, check for partial changes left by the interrupted run, and save what you keep. Discard results of a calculation that was force-killed.

2. Close RFEM completely and start it again. The record is released once the RFEM session that ran the operation has ended, and the status clears. A released record stays in the journal as failed with a note to re-read the model; it is never run again.

3. If the status remains after that restart, update the Dlubal Connector to version 2.30.17 or later. Its Setup releases such records itself, also in the silent update from CALC.

4. If it still remains, contact Dlubal support with the Connector support report. The report names the execution ID; support resolves the record locally with the MCP server's operator command. It runs with RFEM's bundled Python and the Connector's active private package path (PowerShell, adjust the RFEM path):

   PowerShellCopy

   $active = Get-ChildItem "$env:LOCALAPPDATA\Dlubal\Connector\mcp-runtimes\*\active.json" |
             Sort-Object LastWriteTime -Descending | Select-Object -First 1
   $packages = Join-Path $active.DirectoryName ((Get-Content $active.FullName -Raw | ConvertFrom-Json).current + '\packages')
   & "C:\Program Files\Dlubal\RFEM 6.15\bin\python.exe" -c "import sys,runpy; sys.path.insert(0, sys.argv.pop(1)); runpy.run_module('dlubal_mcp.rfem.execution', run_name='__main__', alter_sys=True)" $packages `
     --state-file "$env:LOCALAPPDATA\DlubalMCP\rfem-executions.sqlite3" `
     --resolve <execution-id> --confirmed-rfem-idle
   

   A plain python -m dlubal_mcp.rfem.execution cannot find the module: RFEM's bundled Python ignores PYTHONPATH. The command sets the record to failed and never re-runs anything.

The Connector port is occupied

If another program such as python.exe occupies port 8083, the Connector can still serve on port 8383. When the fallback is reachable, the actual RFEM status remains the headline and port ownership appears as a secondary hint. Do not stop an unknown Python process solely because of this message.

Everything is up but nothing has run yet

Blocker: not_proven

Successful RFEM access has not yet been proven. First wait briefly for the connector's automatic connection check. There is no need to request another model change for this.

If it stays this way for minutes rather than seconds, check the section above: older connectors reported a refused API key as this warm-up state, which then never cleared.

A request was cancelled or timed out

Cancelling in chat stops the browser from waiting. An RFEM calculation that has already started may continue, and completed model changes remain in place. The connector waits for the running response up to its time limit before executing another request.

Check in RFEM whether the calculation is still running and which changes or results already exist. Do not submit the same script again without checking. An unknown outcome is not resolved by automatically repeating the script. Preventing cancelled relay requests from executing after they were queued requires current connector and relay versions.

When the MCP server supports execution status, the assistant can query the operation by its ID. Further scripts are rejected while it is running. An unresolved operation after a server interruption stays blocked until an operator has inspected RFEM and resolved it. A restart alone does not release it.

With supported versions, the RFEM menu shows the stored operation ID and queries its status after a reload. "Unknown" and "not found" do not authorize a repeat. Clearing browser storage removes the local history, not the server's operation.

Permission or connection

A missing write or Python tool does not automatically mean RFEM is unreachable. MCP 1.0.14 distinguishes read, write and administrator permissions; an operator must also explicitly enable Python execution. Check the permitted capabilities. Pairing again does not expand them.

With supported versions, the RFEM menu offers a support report. It contains bounded connection and state information without keys, model contents or script output. Give support the visible operation ID and describe what you observe in RFEM.

The browser is blocking localhost

Chrome 142 and later ask for permission before a page on calc.dlubal.com may talk to localhost. Denied, the connector looks unreachable while nothing is wrong with it.

Example: the connector is running, http://127.0.0.1:8083/rfem-info answers when you open it directly in a tab, but Dlubal CALC still reports it as not reachable.

Once you have answered the prompt with "Block", Chrome does not ask again. Then:

1. Click the site information icon on the left of the address bar.
2. Allow local network access there. If the entry is missing, open the site settings for calc.dlubal.com and set it to "Allow".
3. Reload the page.

This is a browser permission, not a missing connector. That is why CALC does not offer a connector download in this state: reinstalling does not lift the block, and no amount of restarting will change it.

"Not reachable" that means "not paired"

A connector that is running but not paired with your account refuses the request. Depending on where that refusal surfaces it can read as "not reachable", which sends you looking for a network problem that does not exist.

For a direct browser connection with an explicit missing-pairing message, pair again. An already authenticated cloud relay connection does not require additional local pairing in the browser.

The version says one thing and behaves like another

The connector installs a component and then starts it. Those are two separate things and they can disagree: if a component from an earlier session is still running when the connector starts, the connector adopts it instead of starting a new one. A freshly installed version then sits on disk while the old one keeps serving.

Settings → MCP servers shows both on one line, for example Dlubal-Connector 2.28.8 · MCP 1.0.11. The second number is the one that is running. When they disagree the number turns amber. With MCP 1.0.14 and a matching Connector, updates activate only after idle state is confirmed. Running or unresolved work takes priority. An older component without that check requires an operator to inspect outstanding work and shut it down in a controlled way.

Example: an answer tells you a capability "is not available in your RFEM version", next to a green dot. Usually an outdated component rather than anything to do with RFEM: it never offered the tool the answer tried to use, so the model explained the gap by guessing.

Extended diagnostics

If only extended diagnostics are unavailable, an older Connector version may be the reason. This notice alone does not establish an interrupted RFEM connection. An update enables the additional diagnostics; continue to check the actual RFEM status.

Invalid tool call

This message means the model returned incomplete or invalid arguments. The affected call was not executed. You can retry the request or report the error. Calls completed in earlier steps remain in effect; check them before repeating model changes.

The Connector quits by itself after a few minutes

No Connector process left, nothing in the Windows event log, and after a restart everything works again until it happens once more. The more CALC tabs are open, the sooner. This is a defect in Connector versions up to 2.30.9: the RFEM dialog detection used up a system resource on every status poll, of which a process only has 2000. After that the Connector ended without a message.

The fix is updating to Connector 2.30.10 or newer. CALC offers it in the RFEM menu as soon as the Connector is running again; "Restore connection to RFEM" also installs the current version. Until then the only remedy is restarting the Connector from the Windows Start menu.

The Connector restarts after quitting

Check Windows Connector watchdog under Settings → AI assistant. An enabled watchdog can restart the Connector within ten minutes. From Connector 2.30.2 it is off by default and can be disabled there. Windows login autostart is independent. See Optional Windows watchdog.

The Connector does not start

When a previously detected connector is unreachable, CALC labels the saved version as “last detected”. This does not establish the currently installed version. After an unsuccessful launch, choose “Start Connector and check”. Confirm the browser prompt or open Dlubal Connector from the Windows Start menu, then retry. Choose “Request setup instead” if installation is needed. An unsuccessful launch no longer triggers an automatic reinstall.

While the restore dialog remains open, CALC continues checking for an externally started connector after an unsuccessful launch and resumes automatically when it appears. Closing the dialog or changing accounts ends observation; it is limited to the original ten-minute window. The saved connector version comes only from the connector itself, never from an MCP server version.