Vesuvio: Eurotherm needs to be able to read pressure

[Tom-Willemsen]

Giovanni came in and said he wants to use a eurotherm to read data from a pressure sensor.

1. Find out if this is already possible (with a different calibration file?).
2. If it's not possible, figure out what modifications to the IOC are necessary to make this possible.
3. Consult with the instrument scientists what the use cases for this are to figure out the functionality needed.

[GDH-ISIS]

Old analog pressure reading. Electronics have a box that will convert pressure to mV. No calibration currently. It will have to calibrated manually. Required today. Plugging in Eurotherm now. I'm about to go down to check. I have a feeling they will be happy to log mV for the moment i.e. Calibration = None

[GDH-ISIS]

Electronics contact : Jamie Nutter

[GDH-ISIS]

Eurotherm hardware connected. Connected it to EUROTHERM_02 IOC. Communication established. Created Block called Sample_Pressure. This reads and is operational. Using no calibration file currently. Recording mV reading on Eurotherm. This may be sufficient. Created component Eurotherm DRUCK as it is not a permanent item on the beam line.

[GDH-ISIS]

Not sure how to hook up a synoptic view or device screen to the Eurotherm so that they can select a calibration file (if one is sent to me). Will ask for help.

[GDH-ISIS]

OK, I think I have a synoptic up and live so that the calibration can be changed. Will now wait to see whether we get a calibration.

[GDH-ISIS]

Unit that was supposed to output an anolog voltage for the Eurotherm to read does not have the appropriate AO card in it. Sample environment group are now looking into another transducer. They will forward the necessary calibration when they can. The configuration name and synoptic name will need to be changed.

[AdrianPotter]

1. Open the synoptics perspective

2. Click on the Eurotherm

3. Enter the name of the calibration file in the appropriate text box

Does that answer the question?

[GDH-ISIS]

Thank you Adrian.

[KathrynBaker]

Not something to worry about in this ticket, but at the moment the calibration would be forced into temp sensors for ease, otherwise it won’t be found. The calibration directory should be alterable, but I at least will get confused if we start having pressure calibrations in the temp sensors. I believe it should be macro settings to use a different directory in those situations, so not difficult, but I don’t think we have a directory for ‘random’ calibrations.

[GDH-ISIS]

I have put something together that looks as though it might be sufficient to run. The adhoc calibration is attached. I have placed the calibration file in c\Instrument\Settings\config\common\temp_sensors on ndxvesuvio. Using IBEX, I changed the calibration to VesPres.txt and it looks as though it has taken the calibration change.

I can confirm that the calibration took ok.

VesPres.txt

[GDH-ISIS]

Items to consider : 1) How to cope with random calibrations? I'm am not convinced this is a long term calibration. 2) Rename configuration on IBEX - clean up 3) Rename synoptic on IBEX - clean up

[KathrynBaker]

I’d like to add:

4. Have somewhere that isn’t temp sensors for these calibrations
5. Ensure that it is easy to alter the calibration directory to use

[ChrisM-S]

May be worth dropping the level of temp sensors folder down a level and having a

C:\Instrument\Settings\config\common#calibrations#\temp_sensors

This would allow other calibrations to be added, as well as obvious physical parameters, are there calibrations for motion kit and jaws which would be better kept somewhere common like this? The other question from me would be is there a location for information about the calibration file (e.g. what units/formula used). I’m guessing it could be put in with the pull request for the change – so when an “extension” is made like happened with the PT100, this information would naturally be traceable from the modified file.

[KathrynBaker]

EVERYTHING at that common level is already a calibration. The ramps are a specific type of calibration, the barndoors are the ones for the Muon barndoors, the magnets will be used by Danfysiks when we have any calibrated magnets. What we actually want is a “misc” folder at the same level, which is not necessarily stored in a Git repo like the rest of it. Adding in an extra layer increases the length of the file name causing other problems for the records in the end. Typically there is no equation for a calibration it is just observed results as a lookup table.

[kjwoodsISIS]

As you can see for the screenshots above, the folders used to store calibration & ramp files are hardcoded in the OPI. That's because we don't have an easy way for the user (using the client) to select files on the server. So I think that having different directories for "temporary" calibration files is not really practical. I think we have to store any "temporary" calibration files alongside the "permanent" calibration files.

What might be possible is to give the "temporary" calibration files obvious names. Gareth has used the name VesPres.txt, which seems fine to me. Perhaps, we could go one step further and name it something like tmpVesPress.txt. That way it is obvious that it is temporary and can be removed later. However, I do notice that Gareth chose a name that fits the 8+3 file naming convention. Was that deliberate? Is there a limitation on how we can name these files? Would long name break something else?

To answer Chris's question about storing units & the calibration formula: the obvious place to store that information (metadata) is in the file itself. That way it can never get separated from the data. It could be stored in a comment block at the top of the file. However, I do realise that this would break the LabVIEW code that has to use the same calibration files, so making this change to the format of the calibration files will have to wait. In the meantime, I would suggest that the best place to store calibration file metadata is in the check-in comments in the repository used to store the master copies of the files. You could also use the check-in comments to note that the file is "temporary".

[FreddieAkeroyd]

I am assuming that this is really "hardcoded in the IOC" rather than the OPI? We have a mechanism for allowing users to choose files that we currently use for the DAE for wiring tables - is it possible to adapt this to work on an OPI?

[kjwoodsISIS]

Yes, "hardcoded in the IOC" is what I meant - it just didn't come out that way ... :-)

[John-Holt-Tessella]

It is indeed in the IOC and could easily have a macro set for it (see "C:\Instrument\Apps\EPICS\ioc\master\EUROTHRM\iocBoot\iocEUROTHRM-IOC-01\st-common.cmd")

epicsEnvSet "CALIB_BASE_DIR" "C:/Instrument/Settings/config/common"
epicsEnvSet "SENS_DIR" "temp_sensors"

The units could also be set as a macro and then the whole thing would be part of the configuration.

If this is needed long term then we should develop the above to make it work. If not we should leave it locally on the machine and every deploy we should ask whether it is needed. It is already part of deployment to update the configuration folder.

[John-Holt-Tessella]

See #2134 and #2133. To resolve this ticket simply leave where it is and we will ask whether this file can be deleted each release (make a note on the IBEX page if not already done under the instrument)

[AdrianPotter]

Unassigned ticket should not be in progress. John, as the latest comment and not being at stand up, you've been nominated as the assignee. Please could you finish the ticket, move back to ready, or reassign as appropriate.

[John-Holt-Tessella]

Vesuvio change has been noted.