Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EMMA: Fermi Chopper #2397

Closed
kjwoodsISIS opened this issue Jun 7, 2017 · 11 comments
Closed

EMMA: Fermi Chopper #2397

kjwoodsISIS opened this issue Jun 7, 2017 · 11 comments

Comments

@kjwoodsISIS
Copy link
Contributor

kjwoodsISIS commented Jun 7, 2017

As scientist or technician using EMMA, I want a controller & GUI for the Fermi Chopper, so that I can change the settings of the Fermi Chopper.

Acceptance Criteria

  1. The GUI must display the current speed, phase & window.
  2. I can use the GUI to change the current speed, phase & window settings.
  3. I can use a script to query the current speed, phase & window settings.
  4. I can use a script to change the current speed, phase & window settings.

Notes

  1. The Fermi Chopper on EMMA is controlled via an SKF MB350PC (G3) controller, which uses a Modbus over serial (RS485) communications protocol.
    1. The disk choppers on IMAT are also SKF choppers (G5 models). It might be possible to adapt the IOC created for IMAT for use on EMMA. See Update build manual for GUI #886 and Add new SKF chopper files #1737.
    2. Until recently, LET used to use an SKF MB350PC (G3) controller. The IOC & GUI could be based on the corresponding SECI VI.
  2. See EMMA Instrument Details for additional information.
@kjwoodsISIS kjwoodsISIS mentioned this issue Jun 7, 2017
17 tasks
@kjwoodsISIS
Copy link
Contributor Author

Note from David Keymer:

In principle, a fermi and disc chopper behave in the same way – they’re still spinning lumps of metal
in the end – so they have the same operator parameters (frequency, phase, window, etc) that we
would set remotely.

However, it all depends on how clever the controller is as to how much logic, if any, is required in
the IOC/VI. From memory, the VI for the G3 is very basic (apart from the MODBUS protocol) and
only reads and writes values, leaving the controller to deal with everything else (as it should do of
course). So with any luck, an IOC for a G3 would also only have to have the same basic functionality.

@KathrynBaker
Copy link
Member

Notes from the VI:

Assumption: This is the Mirrortron-SKF MB350PC chopper used previously on LET.

There is no logic in the VI other than the interpretation and building of command packets and responses, but this is specific.

Number of Nodes: 108
Cyclomatic complexity: 15
Screen Shot:
image

The nominal values are read from a file on startup, file is not human readable.
Also on startup there is some initialisation relating to the parking information.
There is a very specific command packet builder and interpreter, this will need to be reproduced.
The status displays are interpreted from a byte array.
When the values are changed they are written to the file that is loaded on startup (autosave should cover this).
There are about 30 commands programmed in the LabVIEW VI that builds the command packet.
May need to be wary of the serial connection along 485, ensuring the pin allocations and expected behaviours.
Including emulator and test suite this may be >5 points.

@kjwoodsISIS kjwoodsISIS added the 8 label Oct 26, 2017
@kjwoodsISIS
Copy link
Contributor Author

kjwoodsISIS commented Oct 26, 2017

Check that this is the right VI - ask @davidkeymer

@Tom-Willemsen
Copy link
Contributor

I had a chat with @davidkeymer - Apparently Mike Brind and Paul Chorley are the people most likely to know exactly what this chopper is. I will drop them an email.

@Tom-Willemsen
Copy link
Contributor

Requires #2768

@Tom-Willemsen
Copy link
Contributor

#2768 is now complete and I have contacted Jeff to see if there's a convenient time to retest this against the hardware on emma.

@Tom-Willemsen
Copy link
Contributor

Went down to emma this morning - basic comms appear to be working. Didn't try moving anything but the readbacks were updating with the same numbers as LabVIEW.

Device needed an extra sleep before sending a serial break - I hacked this into asyn on the beamline but it needs a sensible fix doing.

@Tom-Willemsen
Copy link
Contributor

List of PRs you need to review this ticket:
EPICS top: https://github.com/ISISComputingGroup/EPICS/pull/107
IOC: ISISComputingGroup/EPICS-ioc#195
Support module: ISISComputingGroup/EPICS-SKFMB350#1
Emulator: ISISComputingGroup/EPICS-DeviceEmulator#44
Tests: ISISComputingGroup/EPICS-IOC_Test_Framework#35
GUI: ISISComputingGroup/ibex_gui#589
Streamdevice: ISISComputingGroup/EPICS-StreamDevice#3
Asyn: ISISComputingGroup/EPICS-asyn#6

Note, to talk to the real device you will need to rebuild both streamdevice and asyn with the above changes. To talk to the emulator you don't need to rebuild asyn but still need the streamdevice changes.

@John-Holt-Tessella
Copy link
Contributor

Awesome to have so few problems in such a complicated IOC.

@kjwoodsISIS
Copy link
Contributor Author

@Tom-Willemsen - is this ticket ready for a final review and completion? (we are about to migrate EMMA, after all).

@Tom-Willemsen
Copy link
Contributor

@kjwoodsISIS yes I've done the suggested reworks, just requires review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants