Resolving LabVIEW RT 8.20 Timed Loop Restart Crashes

The RT target stops responding after Stop Timed Loop.vi is used and the stopped Timed Loop is started again. Network ping can fail, the hard-disk activity LED can remain idle, and a directly connected monitor can end with Bad state at RTScheduler.cpp:3577. Treat this as a scheduler restart fault in LabVIEW/LabVIEW RT 8.20, not as a routine application timeout.

Rule out the usual wrong fixes

Do not start by repairing an R: drive, changing the LabVIEW RT installation from C:, or adding an R: volume. The displayed path, R:\Europa\TimedLoopScheduler\RTScheduler.cpp:3577, identifies a scheduler source file used to build the runtime. It does not describe a required drive on the deployed controller.

Do not treat a priority change as the primary repair either. LabVIEW 8.20 can report a separate configuration error when the Timed Loop priority is too high, but that configuration problem is distinct from the stop-and-restart crash. Likewise, waiting for ping or disk activity does not recover a target whose scheduler has entered the bad state.

Quick fix	Why it fails	Use instead
Create or repair R:	The path is an internal build path.	Trace the Timed Loop lifecycle.
Change priority blindly	Priority configuration is a separate fault path.	Validate priority independently.
Wait for network recovery	The target may no longer service ping.	Recover the target, then reproduce under control.

Check: Proceed only after confirming that the final monitor text points to RTScheduler.cpp:3577 or that the hang follows the same stop-and-restart sequence.

Capture the failure before changing the application

Record the last monitor output before power-cycling or rebooting the target. Observed examples include:

Bad state [103481600L10700]: R:\Europa\TimedLoopScheduler\RTScheduler.cpp:3577
Bad state [111883072L12052]: R:\Europa\TimedLoopScheduler\RTScheduler.cpp:3577
Bad state [80532928L12052]: R:\Europa\TimedLoopScheduler\RTScheduler.cpp:3577
Bad state [84268800L24472]: R:\Europa\TimedLoopScheduler\RTScheduler.cpp:3577

The bracketed values vary, so match the stable parts: Bad state, TimedLoopScheduler, and line 3577. A debug file may contain no additional entry. Retrieve it through the normal target-management or file-transfer route if available, but do not delay recovery when it is empty.

Separate total target loss from an unresponsive user interface. Test ping from another machine and watch local storage activity. Failed ping, no disk activity, and the scheduler message together justify treating the controller as hung. Apply the site's approved recovery procedure; do not repeatedly cycle power if doing so can leave actuators or test equipment in an unsafe state.

Check: Save the monitor text and note whether ping failed, then confirm that the target returns to normal communication after the approved recovery action.

Prove that restart triggers the bad state

The critical transition is not merely stopping a Timed Loop. Stopping it can complete normally; attempting to restart that aborted or stopped loop can place the LabVIEW 8.20 Timed Loop scheduler in the bad state. That distinction explains why the failure appears intermittent in a large application: only execution paths that stop and later restart the same scheduled activity expose it.

1. Create a small test VI containing the minimum Timed Loop and its existing stop control path.
2. Run the loop and invoke Stop Timed Loop.vi.
3. Leave the loop stopped. Observe whether LabVIEW remains responsive.
4. Invoke the application's restart path for that loop.
5. Repeat the sequence while monitoring the Windows development system or the RT target.

The fault was reproducible in a simple VI on LabVIEW 8.20 for Windows as well as in LabVIEW RT 8.20. That makes the Windows reproduction useful for isolating scheduler behavior without repeatedly taking the controller offline.

Check: Establish two results: stop without restart remains responsive, while stop followed by restart reproduces the hang or scheduler bad state.

Remove the stopped-loop restart path

Restore production by preventing the application from restarting a Timed Loop after Stop Timed Loop.vi has stopped it. The lowest-risk workaround is to keep the scheduled loop alive and gate the process work inside it. When the machine requests a pause, transition the application logic to an idle state while leaving the Timed Loop lifecycle intact.

1. Locate every call to Stop Timed Loop.vi and every state, event, or command that starts the associated operation again.
2. Replace the stop-for-pause behavior with an application state such as run, idle, or shutdown. Use the existing project conventions rather than adding an unrelated scheduler layer.
3. In the idle state, suppress equipment commands and process calculations that must not run, but allow the Timed Loop to continue executing its controlled state path.
4. Reserve final loop termination for application shutdown, where no restart of that stopped instance follows.
5. If the design cannot keep the loop alive, end the owning execution cleanly and start a fresh application execution after recovery instead of re-entering the stopped loop.

For a migrated application that ran under LabVIEW 8.0 and fails under 8.20, a controlled return to the previously qualified 8.0 deployment is another recovery option while the lifecycle change is tested. Match the complete qualified application and runtime combination; do not mix deployment artifacts casually.

Check: Exercise pause, idle, resume, and shutdown while confirming that no execution path restarts a loop previously stopped by Stop Timed Loop.vi.

Validate Timed Loop priority separately

A priority set too high can produce a Timed Loop configuration error in LabVIEW 8.20. Diagnose that message on its own merits. Read the configured priority from the VI and compare it with the application's scheduling design; no valid numeric ceiling is provided here, so take the permitted range from the installed LabVIEW documentation and the target configuration.

Symptom	Decision
Immediate configuration error when the loop starts	Inspect the Timed Loop priority and configuration.
Loop stops normally, then the system hangs on restart	Remove the stopped-loop restart path.
Bad state at RTScheduler.cpp:3577	Preserve diagnostics and treat it as the reported scheduler fault.

Do not lower priority until the error disappears and call that proof of repair. A priority edit can hide a configuration fault while leaving the restart sequence available.

Check: Start the loop without a priority-configuration error, then verify separately that the application never restarts a stopped Timed Loop.

Run the complete production sequence

1. Cold-start the RT target and deploy the corrected application.
2. Run every operating state that normally activates the Timed Loop.
3. Command idle or pause, then resume repeatedly through the real operator and control interfaces.
4. Run the normal shutdown path and confirm that terminated loops are not restarted.
5. Watch the local monitor, network communication, and application health indicators throughout the test.
6. After the test, inspect the target diagnostics for another Bad state entry and document the LabVIEW version used.

A passing test keeps the target responsive to ping, shows normal application state changes, and produces no TimedLoopScheduler bad-state message. Also confirm that idle-state gating does not leave stale actuator commands or unintentionally continue process work.

Check: Release the change only after the full stop-equivalent, resume, and shutdown sequence passes on the intended LabVIEW/LabVIEW RT 8.20 system.

FAQ