search

msr-consulting / exscalabar_server

Repository for the EXSCALABAR server.
http://www.msrconsults.com/ukmet-gh/exscalabar
0 stars 1 forks source link

filter and speaker cycling #170

Closed JustinLangridge closed 7 years ago

JustinLangridge commented 7 years ago

This looks to be almost working as we need, but someremaining issues:

lo-co commented 7 years ago

When cycles are connected, the speaker is only firing when we move the filter valves from sampling -> filter positions and not when they move back from filter -> sampling. Can the speaker be made to fire automatically for every time the filter valves change position?

I thought the intention would be to run the speaker cycles as originally intended but (for instance, have the speaker on 20 s even if the filter length was 60 s). Wouldn't this be what you wanted? It seems to me you can't get a background if the speaker is on speaker the entire time the filter is on. Now, this gets to another point (also called out below). It seems to me that the speaker is not actually cycling when the two cycles are connected - only the speaker turning on and never off. Is this a correct assessment?

The timing seems a bit off. When we set the speaker to fire for 5s without the cycles connected then it sa=tays on for 5s as expected. However, when we do the same with the cycles connected then the speaker stays on for closer to 7s? Why and can this be changed?

Don't know why this is happening but likely connected to the issues above and below.

When operating in auto mode (cycles not connected) the speaker light in the 'speaker controls' UI control comes on and off to tell the user what the speaker state is. When the cycles are connected, it does not do this. Can this be changed so that this indicator shows the speaker state when operating with cycles connected?

Is the indicator not working or is the speaker not actually cycling back? This is what I worried about that I brought up in the last issue. To be honest, I can't off the top of my head remember how exactly we populate that indicator, but maybe this is the issue?

JustinLangridge commented 7 years ago

When cycles are connected, the speaker is only firing when we move the filter valves from sampling -> filter positions and not when they move back from filter -> sampling. Can the speaker be made to fire automatically for every time the filter valves change position?

I thought the intention would be to run the speaker cycles as originally intended but (for instance, have the speaker on 20 s even if the filter length was 60 s). Wouldn't this be what you wanted? It seems to me you can't get a background if the speaker is on speaker the entire time the filter is on. Now, this gets to another point (also called out below). It seems to me that the speaker is not actually cycling when the two cycles are connected - only the speaker turning on and never off. Is this a correct assessment?

You are right that we want the speaker to fire only for the initial part of the filter cycle (e.g. for 20s even if the filter length is 60s). Currently we can do this. The problem is that I’d also like it to fire for 20s when we come off the filter, which it doesn’t currently do. The speaker is cycling, however the UI indicator is not cycling which is maybe why it looks like it gets stuck on the on position.

The timing seems a bit off. When we set the speaker to fire for 5s without the cycles connected then it sa=tays on for 5s as expected. However, when we do the same with the cycles connected then the speaker stays on for closer to 7s? Why and can this be changed?

Don't know why this is happening but likely connected to the issues above and below.

When operating in auto mode (cycles not connected) the speaker light in the 'speaker controls' UI control comes on and off to tell the user what the speaker state is. When the cycles are connected, it does not do this. Can this be changed so that this indicator shows the speaker state when operating with cycles connected?

Is the indicator not working or is the speaker not actually cycling back? This is what I worried about that I brought up in the last issue. To be honest, I can't off the top of my head remember how exactly we populate that indicator, but maybe this is the issue?

So the speaker is cycling, it is just the indicator that is not working when we have the cycles connected. When just the speaker cycle is running un-connected then the indicator does work.

lo-co commented 7 years ago

So, just a quick diagram to detail how this works (the speaker cycle and filter must be connected AND the speaker must be set to cycle - this has changed as it also used to be required that the filter being set to TRUE or on).

  1. A message is fired to change the filter position. This message can originate from the UI OR from the server (if the filter is set to cycle).
  2. The message Change Filter State is fired.
  3. In this message, we check for the above conditions laid out and if the condition to change the speaker on filter state change is valid, the message Speaker MSG is loaded.
  4. Speaker MSG sends the message to the PAS actor ePAS Library::Change Speaker Switch MSG.
  5. ePAS Library:: Change Speaker Switch MSG sends the command ePAS LIbrary::Change Speaker State to the PAS instrument class. It is in this message that the CVT is updated.
  6. ePAS LIbrary::Change Speaker State is handled by the ePAS object changing the speaker state down on the FPGA.

Now, the reason the speaker is not updated on the speaker cycle (and it really should never be as it is currently coded) is that the CVT is updated one level up. I will go ahead and fix this now.

lo-co commented 7 years ago

In PAS Library::PAS::Rcv Cmd use the ExtCom queue to send back the information required for updating the CVT when the speaker is automatically cycled.

datid commented 7 years ago

Just tested this, it is all working - thank you