search

micro-manager / mmCoreAndDevices

Micro-Manager's device control layer, written in C++
38 stars 101 forks source link

TriggerScope DAC Overdrive Transitions #205

Open ieivanov opened 2 years ago

ieivanov commented 2 years ago

@nicost it would be very useful to be able to apply a voltage "overdrive" on each DAC transition using the TriggerScope - for example, go from 1V to 2V through a brief (say 5 ms) pulse at 5V. The reverse should also work, i.e. go from 2V to 1V through a 5 ms transition at 0V. The overdrive transition can be engaged only if the Overdrive-Duration property is larger than 0 ms. In this way, each DAC state would be defined by an overdrive voltage, overdrive duration, and final voltage value.

Could you give us an idea on how easy it may be implement that in the TriggerScopeMM device adapter and maybe give us any pointers on how to do it? Would we need to change the TriggerScope firmware as well? We would also like to be able to go through these overdrive transition during a hardware sequence, i.e. for one pulse received by the TriggerScope, go through the overdrive transition to the final voltage stage. Do you think that would be possible?

Any help would be greatly appreciated. Thanks!

cc: @ talonchandler @ Soorya19Pradeep

AdvancedResearchConsulting commented 2 years ago

I'd probably recommend doing this in firmware, just add the commands to the pcDac function so each time the DAC is changed, the command performs the function. Adding the steps both at the serial command and program step locations in the firmware would accomplish both requests.

nicost commented 2 years ago

This would certainly need to be implemented in the firmware first. Once it is there, adding a property in the device adapter is simple. This is quite analogous to adding delays (see: https://github.com/micro-manager/TriggerScopeMM/issues/5). I discovered that it is not simple to add in the current code (although I believe that it is possible). The main obstacle is to make it performant, i.e. you do not want to have this slow things down. The reason for adding delays dis-appeared, so I never finished that work, but maybe that branch provides some inspiration.

ieivanov commented 2 years ago

Thank you both! I realized that this idea could be extended to a more general sequence of timed states (e.g. V1-t1-V2-t2-V3), which should be more broadly useful.

@nicost it seems like the pulsedTriggers branch doesn't have any commits ahead of the main - maybe you haven't synced your work yet? Could you describe here your targeted approach and the problems you've encountered so far?