Hej David,
some late response  I had to finish my code and testing first.
My challange was: A driver opens some "handles" on a PLC system.
when the IOC exits, these handles should be closed -
otherwise we risk to run out of handles in the PLC, or other resources
are bound, I don't know.

EPICS base 7 (I thnink >7.0.3 ?) have an extended initHook.
The initHook itself is a C-function, and the latest base
has a new value called "initHookAtShutdown".

I used that to call a cleanup function:
Go through a list of all handles and close them.

That seems to be working fine - when I enter "exit" on the IOC-shell,
the hook is executed and cleanup/closing the handles works.

In your case that should work, too.
No, the code is not related to a PV/Record as such.
But the driver keeps a local copy of things that must be cleaned up.
Does this sounds good ?
Are there better ideas ?
BR
/Torsten



On 2026-08-18 21:42, Dudley, David via Tech-talk wrote:

OK, masters of the EPICS universe….

Got a unique inquiry for you.   Probably something rarely used.

Running an IOC on the latest EPICS 7.

Have a situation where I need to process a PV when the IOC exits.

I have some PVs that control the power to a device that I’m testing. When I want to replace the device (this is for a testing rig), I’d like to turn off the power to the device in the process of exiting the IOC (I don’t want to keep the interface powered up while unplugging and plugging equipment).

I implemented 2 PVs that have the power on command, and the power off command.  In the Power On command I set PINI=RUN, however all I could do on the Power Off command was to set PINI=Pause.   I can successfully control the power on/off  with the iocRun and iocPause commands.  iocRun occurs when the ioc Starts running, so that has the desired effect of powering up the interface.  But iocPause only processes on the iocPause command as far as I can tell.  I may have to compromise on that, as an exit command is not a pause.  I would have though it would possibly cause a pause/exit sequence, but no.

John Priller told me I would probably need to write some ‘C’ code to attach to the at-exit point (which I can do), but thought I’d ask the mailing list if there is a more standardized method to do this in the current release of EPICS.

Later-

David

Alternative: Hardware Extraction (Cloning) If you have access to another working machine with an identical V1 MDrive motor:

• Microcontroller Readout: Desolder or hook up an in-system programmer (ISP/JTAG) to the onboard microcontroller on the motor's control board. If lock bits were not set by IMS during production, you can dump the full EEPROM/Flash image directly to a .hex file to re-flash the bricked drive.

Hi Alex,
I’ve been using RTEMS 6 and 7 with my VMEbus targets for some time now. I’ve set the tick rate to 1000 there.
In epics-base, under configure/os/, you can find these settings:

CONFIG.Common.RTEMS-beatnik:OP_SYS_CFLAGS += -DCONFIGURE_MICROSECONDS_PER_TICK00

HTH,
Heinz

------------------------------------------------------------------------------
Fritz-Haber-Institut  | Phone: (+49 30) 8413-4270
Heinz Junkes          | VC: https://zoom.fhi.berlin/junkes
Faradayweg 4-6        | Visitors: Hittorfstrasse 29 (Bld S (Slough House) )
D - 14195 Berlin
------------------------------------------------------------------------------
“Sorry I’m a bit late, had a terrible time…
All sort of things cropping up at the last moment. Uh, how are we for time?”
—Zarquon's address to Milliways

> On 28. Aug 2026, at 16:48, Wells, Alex (DLSLtd,RAL,TEC) via Tech-talk <tech-talk at aps.anl.gov> wrote:
>
> Hi TechTalk,
>
> I'm having some difficulties when migrating from VxWorks to RTEMS around how timeouts seem to be handled for very short periods.
>
> Under VxWorks, I set a clock speed of 1000, i.e. 1kHz. I then had some events that had a timeout of 10 "ticks", so a wall time of 10ms. This event was triggered when the associated hardware finishes its read/write cycle - it would send an interrupt, and in the handler I signal the waited-on event. Interrupts were also often turned off, to save CPU time, so the events would just timeout but this caused no issues as the hardware read/write would complete inside the 10ms.
>
> Under RTEMS, I have a different clock speed of 100Hz. I set the same timeout of 10ms (0.01s). I also have interrupts disabled so that the Event will never be signalled. I see different behaviour - some of my reads/writes now report errors, as though they are attempting to execute too fast and not actually waiting the 10ms for the hardware to act.
>
> This seems to be backed up by using EPICS' nanosecond timing functions. Using "epicsTimeGetCurrent" before and after the "epicsEventWaitWithTimeout" function, and then calling "epicsTimeDiffInNS" gives a mean and median duration of ~5ms between the before and after times. I suspect this means the EPICS Event Wait function is not actually waiting at all.
>
> Is this somehow to do with the fact I'm trying to wait for exactly one tick? Or is there some other explanation for why my wait time is not being reached?
>
> Thank you for any help,
> Alex Wells
>
>
>
>
>
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom.

Attachment: smime.p7s
Description: S/MIME cryptographic signature