Beamtime_october

[dylanmcreynolds]

This PR includes changes that were made to get things working in the October 2025 XPS beamtime.

Changes include:

1. Global renaming of settings.xps to settings.xps_operator for clarity

2. Renaming of arroyo imports to arroyopy to keep up with api change in arroyopy package.

3. Fix of a nasty off-by-one error calculcating how many frames go into a shot

4. Change to the constructor for XPSWSResultPublisher to be more consistent with other places that we pass websocket information.

5. Removal o the TiledPublisher from the processor_cli.py module. Should this be configurable? Undone? The latent space explorer now writes results inlcuding the full shot heat map. Should we depcrecate TiledPublisher?

[xiaoyachong]

Hi Dylan,

This PR looks good to me! I just noticed a couple of minor issues:

1. test_redis.py and test_listener.py are failing the unit tests.
2. Should we consider using TiledPublisher in xps_operator and disabling it in lse_operator, while sending the tiled_url in the WebSocket message?

You outlined three possible ways to bridge the gap between xps_operator and lse_operator last week:

• In XPS: create a ZMQ frame publisher.
• In LSE (current approach): implement a WebSocket listener that consumes the messages produced by the XPS code.
• In XPS: publish the frames to Tiled, and in LSE: read them from Tiled as they arrive.

Would you like me to create a new PR for option 3?
Also, should we move the WebSocket listener to ArroyoSAS?

[xiaoyachong]

One note about shot_num: I noticed that it starts from 1 instead of 0 during beamtime. It works well — just a note for awareness.

Shall we add tiled_url for shot_mean in the websocket message?

[dylanmcreynolds]

Yeas, I like the tiled_url for shot_mean, but we'll need to reconstitute the TiledPublisher here to do that.

[dylanmcreynolds]

I'm not sure about TiledPublisher. It's getting a little complicated to keep all of these things separate. How would it know where in tiled to publish in a way that coordinates with other things that LSE is writing into tiled? Maybe we need to talk in front of a white board?

[dylanmcreynolds]

You outlined three possible ways to bridge the gap between xps_operator and lse_operator last week:

In XPS: create a ZMQ frame publisher.
In LSE (current approach): implement a WebSocket listener that consumes the messages produced by the XPS code.
In XPS: publish the frames to Tiled, and in LSE: read them from Tiled as they arrive.

I like the last one the best. In a near future world, Tiled is a perfect place for this, especially with the websockets code that it now has. We haven't yet played with tiled websockets here at the ALS, but maybe it's time!

[xiaoyachong]

You outlined three possible ways to bridge the gap between xps_operator and lse_operator last week:

In XPS: create a ZMQ frame publisher. In LSE (current approach): implement a WebSocket listener that consumes the messages produced by the XPS code. In XPS: publish the frames to Tiled, and in LSE: read them from Tiled as they arrive.

I like the last one the best. In a near future world, Tiled is a perfect place for this, especially with the websockets code that it now has. We haven't yet played with tiled websockets here at the ALS, but maybe it's time!

Sounds good. It seems we could also use tiled_websocket for XPS, as we already use it for the SMI beamtime.

[xiaoyachong]

I'm not sure about TiledPublisher. It's getting a little complicated to keep all of these things separate. How would it know where in tiled to publish in a way that coordinates with other things that LSE is writing into tiled? Maybe we need to talk in front of a white board?

Sure, let’s discuss it later.