redo the i18 add

[stan-dot]

Fixes #709

Instructions to reviewer on how to test:

1. Run Dodal connect i18
2. Confirm devices connect

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.63%. Comparing base (84e49b5) to head (718ae2d).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1030      +/-   ##
==========================================
+ Coverage   97.60%   97.63%   +0.03%     
==========================================
  Files         154      159       +5     
  Lines        6468     6564      +96     
==========================================
+ Hits         6313     6409      +96     
  Misses        155      155              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[DiamondJoseph]

must

Suggested change

	set_mock_value(table.x.user_readback, 1.23)
	set_mock_value(table.y.user_readback, 4.56)

[DiamondJoseph]

Should: 0 is the default value for a float signal, so this shouldn't be required.

Suggested change

	# Mock the initial values of the x and y signals
	set_mock_value(kbmirror.x, 0.0)
	set_mock_value(kbmirror.y, 0.0)

[DiamondJoseph]

Suggested change

	"alarm_severity": 0,
	"timestamp": ANY,
	"value": 0.0,
	},
	"table-z": {"alarm_severity": 0, "timestamp": ANY, "value": 0.0},
	}
	"value": 0.0,
	"timestamp": ANY,
	"alarm_severity": 0,
	},
	"table-z": {
	"value": 0.0,
	"timestamp": ANY,
	"alarm_severity": 0,
	},
	}

nit: consistency with above

[DiamondJoseph]

nit: make this consistent.

[stan-dot]

what do you mean?

[callumforrester]

Make the formatting of "table-z" the same as the formatting of "table-theta"

[stan-dot]

it would seem that the set_mock_value is indeed required, the tests are failing now

https://github.com/DiamondLightSource/dodal/actions/runs/13013408223/job/36296490106?pr=1030

[DiamondJoseph]

it would seem that the set_mock_value is indeed required, the tests are failing now

dodal/tests/devices/unit_tests/test_shutter.py

Line 20 in 5c82bbd

def propagate_status(value: ZebraShutterState, *args, **kwargs):

You want something like this callback_on_mock_put that ensure the _RBV signal gets updated when you set the write half.

[stan-dot]

    def propagate_status(value: TablePosition, *args, **kwargs):
        set_mock_value(table.x.user_readback, value.x)
        set_mock_value(table.y.user_readback, value.y)
        set_mock_value(table.z.user_readback, value.z)
        set_mock_value(table.theta.user_readback, value.theta)

    callback_on_mock_put(table, propagate_status)
    return table

okay but its per-signal basis so do I need to make 4 of those? set_mock_value is quite low-granular

[DiamondJoseph]

okay but its per-signal basis so do I need to make 4 of those? set_mock_value is quite low-granular

#1031
Might be worth getting this nailed down.

[stan-dot]

Might be worth getting this nailed down.

what do you mean by that?

[callumforrester]

@stan-dot resolving #1031 would dictate whether or not we keep the set methods you've added to your devices. As far as I can see they are there to make setting the positions of a group of sub-motors into an atomic operation.

This PR is already long-standing and I do not think we need to resolve #1031 to everyone's satisfaction in order to get it merged. The discussion in there is trending towards a consensus:

• set is most useful if it has an obvious meaning, where a device is associated with a singular, scalar value (e.g. a motor).
• It is sometimes useful to streamline an operation that a user does a lot
• Occasionally there are specific requirements for making "setting" a device into an atomic operation.
  This is also roughly consistent with how dodal is today, or at least its direction of travel.

As far as I can see there's no concrete use case for atomicity for any of these devices, I don't think that it streamlines the operation from the user point of view since

yield from mv(mirror, XYPosition(1.0, 2.0))

Is the same as

yield from mv(mirror.x, 1.0, mirror.y, 2.0)

The other possibility is that you think the first example is neater/more readable. I won't comment on that except to say that it's usually more important to be consistent with the rest of the codebase than to write exactly what makes the most sense to you, since a future developer will read a broad swathe of code in dodal and will find it easiest to read consistent code.

So in summary I think the quickest path to getting this merged is either removing the set methods or justifying them against the criteria above.

[callumforrester]

LGTM :)

.