Ignition 7.0.6 is the version identified as restoring the Script Playground; searching for the old FPMI menu path in an earlier Ignition Designer will not make the missing tool appear. Until that version is available, use a controlled script-testing method rather than repeatedly searching menus or running unbounded code in Designer.
Stop searching the old FPMI menu path
The FPMI Designer exposed the feature at Tools > Advanced > Script Playground. The feature did not carry into the initial Ignition Designer, so the old location is not a reliable way to find it there.
- Retrying the old menu path: it fails because the Playground was absent from that Ignition release, not because the menu is hidden in the same location.
- Waiting for the previously mentioned 7.1 target: a later update identified 7.0.6 as the release containing the feature. Use the specific release information available for the installation rather than relying on the earlier tentative timeline.
- Running a suspected infinite loop to test recovery: it can lock the Designer UI and force process termination. It does not provide a safe way to evaluate normal script behavior.
First identify the installed Ignition version. If it predates 7.0.6, treat the Playground as unavailable in that installation. If it is 7.0.6 or later and the tool is still missing, record the exact version and Designer behavior before changing the installation or escalating.
Use the version boundary to choose a path
The available release statements establish a useful historical decision point: 7.0.6 was called out as including the Playground, while an earlier comment had projected 7.1. Do not interpret that earlier forecast as the final availability target.
- Read the Ignition version from the installed product rather than inferring it from the Designer’s appearance.
- For a version earlier than 7.0.6, stop looking for the Playground in the FPMI menu location and use an available supported scripting workflow.
- For 7.0.6, check whether the Script Playground is present in that installation. If it is not, capture the version and steps that reproduce the absence.
- For a later release, confirm the feature’s availability against that installation’s documentation or official support instead of assuming menu placement is unchanged.
This distinction prevents a tooling issue from turning into an unnecessary reinstall or an unsafe production experiment. It also keeps release-specific behavior separate from the scripting risks that apply regardless of where code is entered.
Keep interactive script tests bounded
The Playground was intended for interactive command execution, but a script that never yields or exits can monopolize the execution context. The example while 1: pass continuously evaluates a loop without useful work or a pause. When run in Designer, the reported failure mode is a locked Designer that may require termination through Task Manager.
Gateway-side scripts run in their own threads, so the failure mode differs in where the blockage occurs: an infinite loop ties up that script’s thread and can drive CPU use very high, potentially pegging one core on a multi-core system. A gateway-side loop should not be treated as harmless merely because it does not run in the Designer UI.
- Test small, bounded expressions before executing longer code.
- Do not test an intentional infinite loop in Designer or on a production Gateway.
- Before running code that repeats, verify that its exit condition can become true and that its work does not create an unbounded CPU load.
Preserve work and avoid relying on unsafe recovery
Interactive behavior can affect the editing workflow as well as execution. The reported Playground cleared its script buffer after successful execution, which made iterative edits inconvenient. A shell-style up-arrow history was also reported to work, but that behavior should not be treated as a substitute for saving important code outside a transient command buffer.
Keep a working copy of any script you need to revise, then paste or enter only the intended test into the interactive tool. If a command is still running and the interface is unresponsive, do not assume the Playground provides a reliable stop button: a request for a termination control was raised, but no such control was confirmed. Avoid repeated launches or other actions that could add load while the Designer or Gateway is already saturated.
Verify the restore without stressing the Gateway
After confirming the correct release, verify availability with a harmless, bounded command and confirm that the Designer remains responsive after execution. For Gateway-side scripts, check CPU use and whether the script thread completes its work; a continuously pegged core or a script that fails to exit indicates that the test is not bounded.
Do not use a deliberately endless loop as a verification step. If the Playground clears the buffer after a successful run, retain the source separately before testing so that a successful execution does not erase the only working copy.
Script Playground questions engineers ask
Can I find the Script Playground under Tools > Advanced in Ignition Designer?
That was the FPMI Designer location. The feature did not carry into the initial Ignition Designer; 7.0.6 was identified as the release that included it.
Does Ignition 7.0.6 include the Script Playground?
Yes, 7.0.6 was specifically identified as including the Playground. Check the installed version before troubleshooting its menu availability.
Can a while loop lock up the Ignition Designer?
Yes. An endless loop such as while 1: pass can lock Designer and may require terminating the process. Do not run unbounded test code in the UI.
Does an endless Gateway script lock up the whole Gateway?
Gateway scripts run in their own threads, so the loop ties up its thread and can drive CPU use very high, including pegging a core. Stop testing if CPU remains saturated or the script does not finish; capture the product version and execution context, then contact official Ignition support for installation-specific guidance.