lo-co
commented
7 years ago I am not sure what the best way to go about this is. When triggering fails, it is usually due to the CRDS loop not completing as it should...but even this should not be an issue.
That being said, it was and apparently still is. So, if you take a look at eCRDS::Get Data (found under Instrument->CRDS->eCRDS Library->eCRDS in the project), you will see some currently very kludgey code. This code needs to be cleaned up as it was an after thought, but it operates as it should:
- We retrieve data from both of the high speed data acquisition cards.
- Run through the channels on each card and check to see if there is a discontinuity in the data (this occurs in the VI
eCRDS::Find Discontinuity). In the default case we look for:- an 80% jump in the value from one sampling point to another
- AND the difference between the
maxandminis greater than 100
- If these two values are
TRUE(the latter threshold prevents us from triggering on noise when the lasers are not firing), we restart the AI on the card in question.
This code was ported over from the Open Path CRD where we are acquiring on an FPGA and there is a possibility of this occurring regularly. We haven't seemed to need it on the AOP and to be honest, it is not clear why this is happening here (but, strange things sometimes happen even in DAQ when we try to implement this triggering). Now, I have some thoughts:
- When one card is reset, we probably need to reset both. Resetting the AI resets all of the triggering.
- We need to make sure that we are not triggering this functionality on noise, so it would be a good idea to document when this is happening.
- With regards to the previous point - I have seen this reset functionality get stuck, so is there anyway we can reproduce the conditions that caused this?
- Low probability, but make sure that the core instrument loop for the CRDS is not overrunning it's execution time (1 s).
Once again, if you all change anything here, make sure you document it well here. This is core functionality that has been robust thus far and we need to make sure that we don't upset things too much.
datid
So the fix we have in there seems to work most of the time, but we had several problems during the test flight where the CRDS triggering was never settling down and thus we had to do a full restart in order to acquire data.
It would be good to make this more robust if we can. Matt, can you give an overview of what we are doing currently? If you can tell us enough to enable us to play with optimising the fix ourselves then we can get on with this.