Closed JustinLangridge closed 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:
eCRDS::Find Discontinuity
). In the default case we look for:
max
and min
is greater than 100TRUE
(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:
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.
Need to look at this when the lasers are enabled to test anything.
I think this is OK now
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.