(PROJ) Random-access plug-in

The Random-access Plug-in is a semi-temporary project designed to add AOD scanning capabilities (based on Isomet AODs driven using iDDS RF drivers) to the ScanImage application.

FAST LINKS
Bulletin Board  ScanImage Mods  iDDS Programming  iDDS Object Scan Mode Quirks Clock Synchronization
ScanImage Notes Tim Questions

Subversion Info

This plug-in is being developed as a branch on the Svobodalab software repository on Subversion. The branch is located at
https://svn.janelia.org/svobodalab/software/branches/RandScanPlugin

Code Overview

The code for the "plug-in" application consists of 3 primary components:

1. randScan program - a stand-alone program managed by the Program Manager (@progmanager) which controls random-access scan capabilities. This application reads from ScanImage global state variables when available, and works with images "captured" from ScanImage.
2. ScanImage modifications - modifications to the ScanImage codebase to allow for raster scanning capability employing AODs.
3. @idds object - An object which encapsulates the configuration and operation of iDDS physical objects. This object is employed by both the randScan program and the ScanImage

BULLETIN BOARD

ScanImage scan speed properties [SvobodaLab:August 16, 2007 - Vijay Iyer]

Given the standard AI and AO rates of 1.25MHz and 125kHz, and an AOD access time of 15us, we obtain...

For HYBRID/RAMP modes (chirped fast scanning dimension):

For STEP mode (stepped fast scanning dimension):

iDDS Object Sharing [SvobodaLab:April 22, 2007 - Vijay Iyer]

As of Rev87, the @idds object has been made shared between ScanImage and the RandScan plug-in.

As with the @daqmanager channels, Scanimage is presumed to be the master in shared operation, so it must be started first. When the plug-in starts, it only creates an @idds object if it's in stand-alone mode; otherwise, it inherits that from Scanimage. 

Timing Signal Summary [SvobodaLab:April 19, 2007 - Vijay Iyer]

Three timing signals are used in all scan modes: Fast, Slow, Async Trg. The Fast and Slow signals are implemented as D/A timing channels while the Async Trig signal is implemented as an asynchronous DIO line.

In the 4 scan modes, these signals are assigned to the iDDS timing signal inputs as follows

 Note: In the Random Access and Hybrid Raster modes, the Fast and Slow signals are identical.

• From iDDS point of view--there are 3 cases in terms of connectivity (the Random Access and Step Raster modes share the same connectivity)
• Effectively, 3 different outputs map to the total of 4 input signals (X/Y TRG/CLK) in a mode-specific manner
• Could use a single D/A in Hybrid Raster and RA cases, and copy this single signal to the two target iDDS signals
• The Async TRG DIO channel is used exclusively for generating the one-time trigger for iDDS devices operated in looped Image mode. This is generated before the asynchronous and then syncrhonous clock signals are applied.
• Practically, we should use 2 DIO signals--one for the Async Trigger of Image channels, and the other for selecting the iDDS memory bank to use for Image mode operation. This latter channel allows separate banks to be used in Raster and RA scanning, which would speed toggling between the two.

 Raster Scan Mode Status [SvobodaLab:April 3, 2007 - Vijay Iyer]

As of the moment, only the "hybrid" raster scan mode is supported: stepping in the slow dimension, and ramping in the fast dimension.

D/A channel 1 is used for the "slow" CLK, and D/A channel 2 is used for the "fast" TRG

The signals are almost identical, except that the last line (D/A channel 2) does not receive a TRG, so one chirp is skipped. The final line is blanked, so a nominally 256 line image will only have 255 lines, for instance. This serves as the "dummy site" containing the interrupt bit for the Image mode scan in the slow dimension.

Every line, there is a delay at the start of each chirp for the AOD access time. This delay is used for the "pre-scan" time in the fast chirping dimension as well as the blanked time in the slow stepping dimension. 

Image/Chirp Mode Terminations [SvobodaLab:December 3, 2006 - Vijay Iyer]

There is a discrepancy  in the way that iDDS image and chirp mode scans should be terminated between successive triggers.

In Image mode--it is required required to employ a '=T' command between successive triggers (of potentially multi-cycle scans through the Image data). Merely masking the external clock/trigger is not sufficient, as the act of unmasking the clock/trigger lines has the effect of sending one clock cycle, which throws things off by 1.

In Chirp mode--it appears required to employ an '=E' command to mask the external clock/trigger (turn off high bit) rather than an '=T' command. The '=T" command resets the DDS chip and thus compels the  re-creation of the chirp configuration, while the '=E' command can be used to merely mask/unmask the trigger.

To resolve this issue--the idds/stop() function has been made to operate in a mode-dependent way (r50)

XSG Saving Issues [SvobodaLab:November 1, 2006 - Vijay Iyer]

As of the moment, I've opted against implementing file saving for the RandScan plug-in based on the "ExperimentSavingGUI" program.
The main issues I see at the moment:

1. The actual saving is dispatched via xsg_saveData() which is called from the startmanager's _removeExpectedDataSource()._But this function is called in all stop cases - whether or not the acquisition was successful. I would prefer to somehow send a signal that it's OK to save from this program - or provide some sort of flag that this is a dud save.
2. I don't fully understand the distinction between how data sources and sinks are handled...and the ephys program doesn't seem to necessarily do things correctly (both the input and output channels are loaded as expected data sources), so I don't feel like I have a good model to follow.
3. If AutoSave isn't in use, then the header file that's saved at the time a save is ordered might not match the settings that were in use during the actual acquisition, if settings have been changed. This could be solved by caching the header settings.

Also, it would be ideal if an the XSG were better integrated with a modified/improved startmanager/daqmanager model, so that individual programs wouldn't have to call add/removeExpectedDataSource/Sink(). All the sources should automatically be saved in the XSG file by default, though the XSG could be able to exclude particular sources via checkboxes.

Daqmanager object sharing scheme [SvobodaLab:November 1, 2006 - Vijay Iyer]

As of Rev ###, the following @daqmanager scheme has been arrived at
1. Both ScanImage and the Random-Access plug-in have been modified to employ "the" @daqmanager, accessible via the factory method getDaqmanager().

2. Since both ScanImage and the plug-in can name the same physical channels (specifically the AOD and PC control channels) - which @daqmanager objects do not allow - we adopt a master-slave arrangment in our code where Scanimage is the master and the plug-in the slave. This means that Scanimage names the channels without checking, while the plug-in names the channels only after checking that Scanimage hasn't done so already.

3. Scanimage was chose as the master in order to minimize the changes to its codebase.

A consequence of this scheme is that Scanimage must be started before the plug-in for correct shared operation.

In the future, I hope the new @daqmanager architecture is such that such clumsy coding isn't required--different programs should be able to name the same physical channel without preemptively assuming a conflict.

Multiple Chirp Triggering [SvobodaLab:September 20, 2006 - Vijay Iyer]

    As of last week, the long-standing issue of triggering multiple chirps was resolved. It was related to a typo in the Isomet documentation regarding the correct "header" entries to load at scan startup.

    As of this past weekend, I have the augmented ScanImage and the random-access plug-in both running with the upgraded Isomet unit. The AOD control code in each was rewritten around a newly designed @idds class. This class encapsulates the functionality of the IDDS RF drivers from Isomet, and serves to reduce code redundancy. Documentation for this new class is provided here. A key feature of the object is that it readily supports raster scanning in each of the three possible modes — chirps in both dimensions, chirp in the fast dimension while stepping in the slow dimension, and stepping in both dimensions. These have been implemented/tested in Scanimage — with specification in the standard.ini file.

    Here is a summary of the changes that have been, and remain to be, implemented on the Scanimage side to accomodate AOD raster scanning.