GEM: Commission Oscillating Radial Collimator

[AdrianPotter]

The control for the GEM Oscillating Radial Collimator has been completed as part of ticket #2409. However, there are number of open questions about the device and how it is used that cannot be derived from the spec or the VI.

The purpose of this ticket is to use the existing control program and make any subsequent changes to make sure the program behaves as expected by the instrument scientists using the real device.

For commissioning purposes, the GEM ORC is currently on COM26 according to the VI

Termination character ☑

The termination character listed in the VI is A. That's quite odd. It's been left as \r\n in the protocol file. This should be updated depending on what the hardware actually needs

Utility time ☑

The utility time in the VI is width/2*(width+backlash). That seems wrong since it gives a maximal utility time of 50%. The implication from the soft spec is that it should be width/(width + 2*backlash) which is what I've set the IOC to. Is this expected? At the least, the instrument scientists should be aware of the change

rq response string ☑

The device emulator replaces the intermediate characters in the rq command response string with .s. Neither the soft or original spec agree with the response format as in the VI. We've gone with the VI as the authority on what the response would be but it would be good to know the actual response format rather than having large chunks of unidentified characters

rq response format ☑

The soft spec says the offset contains 3 digits, and the acceleration contains 4. In the VI it is the other way around. I've programmed the IOC like the VI but, as above, the actual format should be clarified

Request settings ☑ (Asked users, no objection)

I've removed the "Request settings" button. The previous mechanism contained a 5s scan of the device parameters with this button available as a backup. The IOC does a 1s scan so I suspect this button is now unnecessary. Is that assertion correct? Is the scan rate appropriate? Can the device handle the higher polling frequency?

ORCNUM.txt ☑

In the VI, it generates a binary file called ORCNUM.txt containing some IOC settings. It seems to be to do with saving the value of the auto re-initialisation interval. I think we get round the need for that by autosaving the value but it'd be good to know whether that's true.

---

Acceptance criteria

• The above questions have been answered
• The device has been controlled from IBEX
• The instrument scientists have confirmed that they are happy with the OPI and the behaviour of the device

As part of the above testing, the following use cases should be tested:

• Take the device from an idle state and start it oscillating
• From an oscillating state, stop the device and start it again
• From an oscillating state, make sure that the initialization required LED comes on when expected
• Set an auto-re-initialisation interval such that the re-initialisation sequence is correctly triggered.

[KathrynBaker]

The termination character is in Hex, so is just a Line Feed. Utility time – I’d go with the code that they look at and use over the spec, or check with them now rather than having to change it later. At the very least make sure there is a comment in the db where this is done, as the support call could have us chasing our tails if we’ve forgotten about this. The autosave should remove the need for ORCNUM.txt, that is certainly correct.

[AdrianPotter]

Thanks Kathryn. I have made the following changes to the PRs for #2409:

• Changed line endings to line feed
• I've left the backlash as is but made sure there is a comment in the DB. I'd normally side on the VI but in this case there is a strong case that the original arithmetic is wrong
• Good news for ORCNUM, I'll just leave it as autosave. No change

[DominicOram]

The ORC is currently not on the beamline as it is inside the sample tank, which has been taken off for the upgrade. The plan is for the ORC to be back on the beamline early February. We would then need to have it commissioned before the end of February.

[DominicOram]

ORC is now in beamline, waiting for it to be connected up.

[DominicOram]

The ORC controller has been powered up and reconnected. The motors themselves have not been connected yet. It worth testing whilst it's in this state?

[AdrianPotter]

@DominicOram I suspect we could get the remaining answers in this state. When can we go down?

[DominicOram]

The ORC can be accessed remotely in this state using the MOXA (130.246.53.47 port 6). It will be connected to physical motors later this week/ early next week.

[AdrianPotter]

@DominicOram Any word on whether the ORC is up yet?

[AdrianPotter]

• The RQ format from the VI is correct so I've left it as it is
• The RQ command pads the response with spaces. That's important for the protocol as the %s format converter is for non-whitespace characters

[AdrianPotter]

Following on from testing on GEM, the following changes are required:

• On startup the ID record should not have an OOPT field. On reflection the added complexity isn't useful so leave the ID on a slow scan
• The ORC ID is very long so doesn't currently fit on the OPI
• The starting status on the "Initialisation status" is "Initialisation routine not yet run" which is ambiguous if the "Initialised since powerup" LED is on. The message should clarify
• Reading the status doesn't work because of the whitespace, the format converter should be changed to %#s
• Similarly in the initialisers for the sets, %*s should be %*#s
• The calculation of utility ratio, period and frequency doesn't match the VI. The DB says there is a difference but the actual difference doesn't match the stated difference
• Setting setpoints doesn't work
  • The response strings are all "OK" rather than "xxok" where "xx" is the command
  • The length of the set for speed is 3 characters, not 2
  • The length of the set for acceleration is 4 characters, not 2
• The button "Restore defauts" is misspelled

[AdrianPotter]

Unassigned @DominicOram. Not that he wasn't involved in getting the instrument set up, but the code changes are independent of that work so he can review if available.

[AdrianPotter]

Placed as review priority so we can make a release build for GEM