Open michaelb1886 opened 5 years ago
Thank you very much for your input, @michaelb1886. The way scanning is currently realized using NI cards is indeed not the optimal solution. This has already been discussed and is on our agenda for omniscan. In principle it should not matter HOW exactly the hardware module is performing the scan as long as it complies with the interface to the controlling logic module. The problem is that the current scanner logic is explicitly handling hardware specific implementation details which is going against the qudi idea of abstracted hardware.
What is affected by this bug?
The reason X series NI cards with 4 counters are required is because the clock outputs for scanning and counting are finite in length - requiring two counters.
When does this occur?
For any NIDAQ counting or scanning operation.
Where on the platform does it happen?
How do we replicate the issue?
Expected behavior (i.e. solution)
Change the clock outputs to be continuous, and make the analog output, and counter input that depend on the clock timing have finite timing. This allows all M series cards to be used. I was going to rewrite the nidaq hardware file as such, but I soon learnt that the number of counters was too tied the confocal logic to make the effort worth the pay-off.
Other Comments
I understnad this is probably not a major priority, but if the the moniscan project is a major rethink of the confocal scanning behaviour then this would be a good time to implement what I think is an obviously good idea.
Here is an example from the Stuttgart code that uses 2 counters for all scanning/counting - it works well.