File Manager Won’T Release Read File

Yes - in ARC, the same script instance that opened the file should be the one that closes it.

What you’re seeing usually means one of these is happening:

• the file is still being held open by the original script instance
• the script exited or was interrupted before the close executed
• there are multiple script runs (even if you only intended one)
• a file read is still active in the background because the open/read/close sequence didn’t fully complete

Important ARC behavior

ARC’s file read handle is tied to the running script context. So if FileReadOpen() is called in one script run, FileReadClose() should be called in that same run.

If you try to close it from a different script, or from a later run that doesn’t own that handle, ARC may not release it the way you expect.

What I’d recommend

1) Keep open/read/close in one script only

Your init script should look more like this pattern:

$path = "c:\robot\offsets.txt"

FileReadOpen($path)

:loop
$line = FileReadLine()
if ($line = EOF)
  goto(done)
endif

# parse $line here
goto(loop)

:done
FileReadClose($path)

If your ARC version supports FileReadClose($path), prefer passing the filename explicitly so there’s no ambiguity.

2) Avoid leaving the script via errors or interrupts

If the script can terminate early, the close may not run. A common pattern is to make sure the close happens in a guaranteed cleanup section.

3) Don’t mix read and append at the same time

If the init script may still be active when your Python script tries to append, you’ll get exactly the lock behavior you described.

A safe pattern is:

• load calibration
• close file
• set a global flag like $calibrationLoaded = true
• only allow append after that flag is set and the init script has fully ended

4) If possible, read the file all at once instead

If the file is small, using a full read instead of line-by-line open/read can reduce lock problems. For example, the file skills and scripts in ARC are more reliable when they don’t leave a handle open longer than necessary.

About your Python append

If your Python is running inside ARC, the file lock can still come from ARC’s file manager if another script has it open. The fact that disconnecting/reconnecting clears it strongly suggests the handle is still being retained by ARC, not Windows.

Also, in ARC Python, I’d normally suggest using ARC file commands consistently rather than mixing ARC file reads with native Python file I/O if the same file is involved.

Best practice

For reliability:

• use one dedicated init script to read offsets
• make sure it opens, reads, and closes in one execution
• only append after that script has finished
• consider storing calibration in a separate file from runtime logging if both are active often

A couple of questions

1. Are you using the File Manager robot skill, or are these FileReadOpen/FileReadLine/FileReadClose calls inside the Script skill?
2. Is your init script definitely ending, or is it running as a startup/background loop?
3. Would you like me to convert your init script into a safer ARC JavaScript or Python version that reads the file, closes it cleanly, and then writes updates without lock conflicts?

If you want, I can show you a robust ARC Python version that reads the calibration file, parses it, and safely appends later.