CRD plots jumbled

[JustinLangridge]

Several problems with the ringdown magnitudes plot on the UI:

Most of the traces as labelled do not correspond to the right channels. Here is what they look like they are doing:

cell 1 trace: ok cell 2 trace: responding to cell 3 PMT cell 3 trace: responding to cell 4 PMT cell 4 trace: responding to cell 5 PMT cell 5 trace: responding to cell 2 PMT

We have no idea how we could change this.

[lo-co]

I am going to break this out into a couple of issues, starting with the first part being this ticket.

It sounds like this may be a wiring problem to me (i.e a server side problem). We need to check if the PMTs in MAX correspond with the expected signals or if these are jumbled. Can we take a look at this in MAX and test this please?

[lo-co]

Justin, I started to open an issue associated with the right-click menu, but it is not clear to me why you would expect one to be there. What do you need for it? You can select plots via the legend if necessary.

[JustinLangridge]

From previous tests we've done in MAX I almost certain that all PMT signals were coming back on the right channels. Can double check this tomorrow.

Regarding the right-click menu, even if there aren;t other variables to plot should there still be scaling/reset buttons?

[lo-co]

No reset button, but we may want to have a autoscale 1x/autoscale option.

One other thing is that if we can get the data back ok, we can also have fits on/off as well as random trace on/off...

[JustinLangridge]

Can confirm that PMT channel assignments are fine in MAX.

Options to turn fits on and off on plots would be good

[JustinLangridge]

OK Matt, now that problem with the PAS waveform plot jumbling is solved, have just looked at the CRD plots - clearly the issue here is different.

Here is what we have for the order:

Physical cell number : showing up in UI as 1 - 1 (this channel is fine) 2 - 5 3 - 2 4 - 3 5 - 4

[JustinLangridge]

Dave's fixed this now by changing ordering in the get data routine (channels were misasigned). Note that the task labelling is a bit confusing as the split between inputs into the 6132 and 6124 cards is not by wavelength. The correct channel assignments are:

Dry blue: 6124_AI0 Blue gas: 6132_AI0 high RH: 6124_AI1 med RH: 6124_AI2 red dry: 6124_AI3

Matt, are there other downstream impacts of making this change or are we ok? For example, what happens if we try to drive red and blue lasers at different frequencies? Will the acquisition work as they are both input on the same card

[datid]

Changed Get Data on server to order correctly

[lo-co]

It I think this is a little problematic. Let me look into it. I think we will have to entirely decouple the blues and provide output control for the individual blue lasers.