LOQ (& other SANS beamlines): Laser measurements

[Tom-Willemsen]

As an instrument scientist on LOQ, I would like to be able to take laser measurements alongside my neutron measurements.

Notes:

• Contact: Steve King
• I am putting this as an IBEX ticket rather than a controls ticket as Steve King believes LOQ is being migrated to IBEX relatively soon.
• Initially the equipment will be used on LOQ, but there are also plans to use it on LARMOR, ZOOM and SANS2D
• Steve King will supply more details on the manufacturer/model next week
  • He has confirmed that it is remotely operable, but was unsure what type of connection it was.
• The Equipment is likely to arrive at ISIS after the summer holidays, with a view to commissioning it on LOQ in autumn/winter 2018
• The equipment will generate a 2-D graph of "counts" as a function of "correlator time".
  • This does not need to be synchronized with the neutron data
  • Steve King suggested that it may need a DAE interface but we may be able to treat it as a standard piece of sample environment

[FreddieAkeroyd]

Top get the data into the NeXus file will need a few changes:

• Arrays are archived in a different table in the archive engine, currently we do not look at this table when we generate the data file
• though NeXus has a mechanism for storing such array log data, we need to check if Mantid is able to read data in such format as it has never needed to in the past.
• we need to check if the archive engine needs a special setup to archive arrays e.g. the XML config files needs to reference the NORD element to setthe array size
• it doesn't sound like data volume is an issue here, but archiving arrays is a way to fill up your database very quickly. It may mean alternative archive solutions are more appropriate in future.

[smk78]

I am attaching 2 documents.

The first (Coherent_OBIS_LX_LS_Operator's_Manual_1184163_RevAG) describes the laser system and its control unit. We will get Items 1, 2, 3, 4, 12 & 13 shown on page 2-1 (pp 61). The control unit has both 9-pin D RS232 and USB interfaces. Remote operation is described in Appendix C starting on page C-1 (pp 277). We will need VI('s) to turn the laser on/off, set the power level, read the interlock status, read the laser operating status, read/set the indicator lights (if not automatic in firmware). To give you a feel for this, the manufacturers control software is described in Section 4 starting at page 4-1 (pp 109).

The second document (LSI Correlator Manual) describes the device that takes the signal recorded by the laser light detector and processes it into something scientifically useful. It comes with its own control and data analysis software. At least initially, I anticipate that we will simply run this software on a laptop sat outside the sample position. But looking ahead we should move to do two things: i) control the correlator from Ibex, and ii) incorporate the correlator output into NeXus files (either those with the SANS data, or ancillary standalone ones?). The correlator control software is described in Chapter 4 from page 12. Graphical examples of the output data are shown in Figures 4.4, 4.5 & 4.6.

I don't have an example of an output file from the correlator software at present, as we don't yet have the correlator! :-)

[smk78]

1st file: Small problem: it's too big to upload! I'll put a copy somewhere you can access.

LSI Correlator Manual.pdf

[kjwoodsISIS]

Manuals are here: \\isis\shares\ISIS_Experimental_Controls\Manuals\LSI Correlator

[Kevin-Woods-Tessella]

From: King, Stephen Sent: 05 November 2018 17:29 To: Woods, Kevin Cc: Akeroyd, Freddie Subject: LOQ: new Laser Scattering Apparatus

Kevin, Freddie,

Some developments…

The Italians are talking about shipping most of the apparatus to us in “2 to 3 weeks” time. Unfortunately (from your perspective) this is unlikely to include the correlator. They have been using a loan one from the company but the one they have ordered may not arrive this year. That doesn’t affect my side of commissioning, but obviously doesn’t help you! My understanding is that the correlator is that in the attached pdf (now in Manuals folder). You will hopefully rejoice in that they provide LabView and Python calling handlers!

I also attach an example of a correlator output file that the student has sent me. This contains two principle data blocks:

1. Search on <Name>Count Trace Ch. A</Name>: the time-dependent intensity of the scattered laser light (though I am unclear as to what the timebase actually is here!), and
2. Search on <Name>Correlation Function</Name> : a 2D array of time (secs) followed by the intensity autocorrelation function (unitless) for each time point.

The correlator appears to come with software to analyse these output files. Big tick. The output file also contains substantial metadata about how the correlator was configured for the measurement. So… what I would be looking for initially is three-fold:

• a way (ie, an Ibex VI or whatever you call them) that permits the configuration of the correlator,
• a way to start/stop the correlator from Ibex,
• a relational way of storing/archiving the output files (and by that I mean a way of associating a correlator output file with the corresponding neutron NeXus files)

In the longer term, it might be desirable to actually feed the raw correlator output into the DAE, but I don’t think we need that right now.

Is this any help?

[Kevin-Woods-Tessella]

From: Akeroyd, Freddie Sent: 05 November 2018 22:15 To: King, Stephen; Woods, Kevin Subject: RE: LOQ: new Laser Scattering Apparatus

Hi Steve,

The array looks to be size 2x277, so that is 277 values of (time,intensity) I guess. I believe there will be multiple instances of this array that will need to be stored in the NeXus file? With a python API, it would be straightforward to create an EPICS IOC using PCASPY. It looks like the data can be accessed directly from python, so storing it in the nexus file as a multidimensional NXlog would be an option.

The data file you enclose looks like a file serialisation of a labview cluster, you mention they have software that can read this format, is this LabVIEW software then? The python API doesn’t look to create files in this format, so we might need to try and reproduce this format if you were planning to use their software. The format though is very labview specific and seems to describes the labview control as well as the data within it. For example the “linear sample time” is not stored as “name, value” but rather the menu where the choice is made is described and then the index of which element in this list is given

<EB>
<Name>Linear Sample Time</Name>
<Choice>0.4 us</Choice>
<Choice>0.8 us</Choice>
<Choice>1.6 us</Choice>
<Choice>3.2 us</Choice>
<Choice>6.4 us</Choice>
<Choice>12.8 us</Choice>
<Choice>25.6 us</Choice>
<Val>3</Val>
</EB>

Because it is based on a description of the object holding the data, I’m not sure what happens if this object structure changes. E.g. if a new choice item was later inserted into the list, do both the writer and reader Vis need to have the same choices (to avoid it just taking the 3rd element of a different list)? If so then you would need two different readers to handle data before and after the change to the choice list. It might be LabVIEW already handles this, I would need to defer to a LabVIEW expert. However if it was possible to have files generated in a format that was less Labview specific I think that would be more flexible for the future.

[kjwoodsISIS]

From: King, Stephen (STFC,RAL,ISIS) Sent: 14 January 2019 10:26 To: Woods, Kevin (Tessella,RAL,ISIS) Cc: Subject: FW: LOQ

... we are expecting the long-awaited Italian DLS to turn up sometime this week!!! There is also a plan hatching that the postdoc will come over w/c Jan 28 for 2-3 weeks.

• Kevin: We have a get-together about the logging from this slated for Fri morning, but as Freddie pointed out this now conflicts with the IDG and I doubt we’ll have the thing powered up by then. So can I suggest we move it into the w/c Jan 28?

Initial meeting scheduled for 1st Feb.

[Alistair-McGann-Tessella]

This initial meeting took place on the 13th Feb.

LOQ has procured an LSI correlator and they are working with their collaborators to understand how it should be operated. From our perspective, it's important to note that the data analysis (autocorrelation of the laser/neutron measurments) is currently performed by the vendor's software, as is the control of the device. We need to investigate what functionality the vendor's python API provides us, which we will be using to control the device.

@Kevin-Woods-Tessella made some notes from the meeting which can be used to guide this investigation:

• [ ] Create simple script to start and stop laser scattering measurements at same time as neutron scattering measurements.
• Vendor’s UI appears to write a single file for multiple measurements (repetitions)
• A single neutron run appears to correspond to multiple correlator repetitions
• [ ] Want to figure how to label repetitions with corresponding neutron run number
• [ ] Should correlation data go into Nexus file (or just be save as an XML file).
• [ ] Is the correlation file written continuously (as data is collected) or at the end of a measurement?
• [ ] Can we change the filename via the API

The investigation will be in a different ticket.

[kjwoodsISIS]

The meeting has taken place. We've documented what we know about the LSi correlator above. Investigation of what we can do with the LSi correlator is covered by #4021. This ticket is now complete.