RE: power off/on ioc recovery

["Pearson, Matthew via Tech-talk" <tech-talk@aps.anl.gov>]

Hi Alex,

 

  Findings:

 

  1. system() command registration: You're correct - system() is NOT registered in our galil.dbd file, which explains why it wasn't working. I confirmed this by grepping the dbd file.

  2. RSTM field: My motor record does NOT have the RSTM field (caget XF:19IDC-ES{Tbl:1-Ax:HU}Mtr.RSTM returns "not found"). We're using Galil-3-0/3-6 with an older motor record version (pre-R6-11).

  3. Autosave configuration: Confirmed we're saving DVAL (in galil_positions.req) correctly.

 

R6-11 is fairly old now, and there’s been a number of bug fixes and improvements over the years. So it’ll be worth upgrading at some point.

 

RSTM was added in R7-3. It can be useful if you need to define autosave behavior on a per-motor basis.

 

  Solution Implemented:

 

  Following your suggestion, I implemented the bash wrapper approach:

  - Renamed original st.cmd → st_ioc.cmd

  - Created new st.cmd as a bash script that:

    a. Runs python3 generate_restore.py to auto-generate the restoration script

    b. Executes st_ioc.cmd to start the IOC

 

Sounds good!

 

  The position restoration now uses SET mode after iocInit() to update the controller position without motor movement. This approach works reliably after controller power cycles, whereas pass0 restore alone

  failed (controller position overwrote the restored DVAL during initialization).

 

I’m still not sure why, but it could be the issue that affected several motor record releases, where the autosave restore behavior was changed (fixed by RSTM).

 

  Testing Results:

  - ✅ Controller power cycle → positions correctly restored via SET mode

  - ✅ No motor movement during restoration

  - ✅ Both VAL and RBV updated correctly

 

  Question:

  Is there any concern with using SET mode + hardcoded values (auto-generated from autosave file) versus relying on pass0 restore with RSTM=2? The bash wrapper automation works well, but I'm curious if upgrading

  to a newer motor record with RSTM support would be beneficial for other reasons.  However, I do not have permission or authorization to upgrade.

 

It’s perfectly fine to rely on SET mode. But you might see minor issues. There will be a small amount of time after IOC init where the position is zero and before the position restore (using SET) has taken place. So that could produce an error/alarm if, for example, zero is outside the software limits. And you may archive zero momentarily before the correct position is restored, messing up the archive history. Since the pass0 autosave restore happens before IOC init, those problems wouldn’t manifest.

 

Cheers,

Matt

 

---

From: Pearson, Matthew <pearsonmr@ornl.gov>
Sent: Friday, December 19, 2025 11:35 AM
To: Tran, Phi Dung <ptran1@bnl.gov>; Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>
Subject: RE: power off/on ioc recovery

 

Hi, For the system command, there is documentation on it here: https: //docs. epics-controls. org/en/latest/appdevguide/IOCShell. html that explains you need to add the function registration to the database definition file. Was that done? For your

Hi,

 

For the system command, there is documentation on it here:

https://docs.epics-controls.org/en/latest/appdevguide/IOCShell.html

that explains you need to add the function registration to the database definition file. Was that done?

 

For your work-around, it could be automated by instead of executing the IOC st.cmd file directly to start the IOC, execute a bash script that first runs the Python program, and then the IOC st.cmd.

 

However, autosave should be working for the position restore. Can you us which version of the motor record you’re using? And does it have the RSTM field? The RSTM field was added in order to improve the options regarding position restore:

 

(0:"Never", 1:"Always", 2:"NearZero", 3:"Conditional")

 

RSTM=2 is the default, and that reproduces the old behavior of restoring the position only if the controller position is zero (+/-MRES). So, make sure RSTM is not being set to 0.

 

There may be a version of the motor support module where the autosave restore method was changed, and before RSTM was added.  

 

For some controllers and drivers you may need a short sleep (1s) after loading the driver and before executing the autosave functions and iocInit.

 

Also make sure you’re autosaving DVAL and not VAL.

 

Cheers,

Matt

 

From: Tech-talk <tech-talk-bounces@aps.anl.gov> On Behalf Of Tran, Phi Dung via Tech-talk
Sent: Friday, December 19, 2025 10:30 AM
To: Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>
Subject: [EXTERNAL] power off/on ioc recovery

 

Hello, I'm trying to run a Python script from within my IOC startup script (st. cmd) to auto-generate a configuration file before iocInit(). However, I'm finding that the system() command is not available in my EPICS build. Background - Motor

Hello,

 

  I'm trying to run a Python script from within my IOC startup script (st.cmd) to auto-generate a configuration file before iocInit(). However, I'm finding that the system() command is not available in my EPICS build.

 

  Background - Motor Position Restoration Problem:

 

  I need to restore motor positions after a Galil motor controller power cycle. I discovered that:

 

  - Pass0 restore alone works when only restarting the IOC (controller stays powered on)

  - Pass0 restore fails when the controller is power cycled - the controller resets to 0, and motor record initialization overwrites the restored VAL field with the controller's position (0)

 

  My Solution:

  I use SET mode after iocInit() to restore positions without motor movement. To avoid hardcoded values, I wrote a Python script (generate_restore.py) that reads the latest autosave file and generates the restoration script with

  current saved values.

 

  What I'm trying to do:

  Run this Python script automatically during IOC startup (before iocInit) to ensure the restoration script always has the latest saved positions.

 

  What I've tried:

  system("cd /path/to/script && /usr/bin/python3 generate_restore.py")

 

  Error received:

  st.cmd line X: Command system not found.

 

  Also tried:

  - shell "command" - Command not found

  - ! command - Command not found

  - iocshCmd and iocshRun - Only execute EPICS commands, not shell commands

 

  Environment:

  - EPICS Base: R7.0.5

  - OS: Red Hat Enterprise Linux 8.10

  - IOC built from Galil motor driver (Galil-3-0/3-6)

 

  Questions:

  1. Is there a way to execute shell commands from within st.cmd in EPICS 7.0.5?

  2. Is system() command availability dependent on build configuration or compile-time options?

  3. Are there alternative approaches to run external scripts during IOC initialization?

  4. Is there a better approach to handle motor position restoration after controller power cycle?

 

  Current workaround:

  Running python3 generate_restore.py && ./st.cmd manually before each IOC start, but I'd prefer an automated solution.

 

  Any suggestions would be greatly appreciated!

 

  Thanks,

Alex