Hi Eddy,
I added it to GitHub, along with a README that explains some basics:
https://github.com/mp49/motorHome
I normally configure it via the included CSS screen. There’s one screen that dynamically changes depending on which home method type is used, as the options presented are slightly different in each case (and
the options are autosaved). It also needs to be instantiated in the same IOC as the motor record.
This is used (or an earlier variation of it) on several hundred motors at the SNS and HFIR facilities. Since it only uses the motor record interface, it works across controller types.
Cheers,
Matt
From: Blomley, Edmund (IBPT) <edmund.blomley at kit.edu>
Sent: Wednesday, January 28, 2026 11:53 AM
To: Pearson, Matthew <pearsonmr at ornl.gov>; EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] AW: OmsAsyn Maxnet Homing
Hey Matt, Yes, some database for a soft-zero and/or soft-homing logic would be great! Cheers Eddy ________________________________ Von: Pearson,
Matthew <pearsonmr@ ornl. gov>
Gesendet: Mittwoch, 28. Januar 2026 16: 42: 58
An: Blomley, Edmund
Hey Matt,
Yes, some database for a soft-zero and/or soft-homing logic would be great!
Cheers
Eddy
________________________________
Von: Pearson, Matthew <pearsonmr at ornl.gov>
Gesendet: Mittwoch, 28. Januar 2026 16:42:58
An: Blomley, Edmund (IBPT); EPICS Tech Talk
Betreff: RE: OmsAsyn Maxnet Homing
Hi Eddy,
The implemented homing procedure [1] of the EPICS module does not seem to work, probably because there is no home switch. There are only limit switches.
That’s fairly common I think. Most controllers won’t support homing to a limit switch, probably because it confuses the function of the switch and the home position would change depending on how fast you move onto the switch.
The homing procedure should be:
1. Move into lower limit switch
2. Define this position as 0 (at least) in the EPICS motor coordinates.
For homing on a limit switch, the homing procedure is ideally:
1. Move onto the switch (possibly also widen the software limits)
2. Move off the switch some predefined distance (eg. 2mm)
3. Change the speed to a predefined homing speed (normally a slower speed)
4. Move back onto the switch
5. Define zero
6. Change speed back to what it was before, and set the software limits back to what they were
7. Optionally move to a pre-defined post-home position
We tried to figure out a solution based on the command reference [2], but were not that successful.
This is our current connection and init command:
omsMAXnetConfig("MCONTROL0", 5, "MAXNET0", 20, 200, "AZ;LTL;LMH;ABL;PSO;AT;LTL;LMH;ABL;PSO;AU;LTL;LMH;ABL;PSO;“).
As a workaround, the student using the setup developed a Python script using the motor record to do:
1. Read out and store .HLM and .LLM
2. Depending on .DIR trigger either .HOMF or .HOMR
3. Wait until .LLS is active
4. Store .RBV
5. Switch to calibration mode via .SET=1
6. Set .VAL to 0
7. Restore .HLM and .LLM from 1.
8. .SET=0
You might have to set DVAL directly and not VAL in order to initiate the LOAD_POS in the driver. Also it’s better to work in dial coordinates if you’re setting the controller position. You might also want to ensure that the user offset (OFF) is frozen (by setting FOFF).
I don’t know the OMS controllers, but is it possible setting HOMF or HOMR starts the controller home function, but it never completes? Or, is perhaps cancelled when it hits a limit switch?
So the question is, if there is a better approach by either directly using Maxnet controller commands or with the motor record itself (is there a „Zero“ command?)
Simply setting the user offset (OFF) can ‘zero’ the motor. However if you really want to home on the controller and define the controller position as zero, then it could either be done via a script as above, or in database logic. I have some database logic to do this (as well as supporting screens) if you’re interested.
Cheers,
Matt