More XSG Saving Issues (2007 03/01)
As of r75, the XSG savign capability was successfully added to the RandScan plug-in.
But this still faces the issue mentioned on 11/01/06 -- that it saves after all stops, regardless of success. Also, Tim mentioned last week that the XSG doesn't gracefully handle the case where auto-save is disabled: it saves the header at the time of the save, rather than buffering configuration info from the time the data was actually collected. So the header saved along with the data might not match the experimental configuration. But somehow, he's reluctant to buffer config info.
So, let's leave out XSG functionality--effective Rev 76.
Image/Chirp Mode Terminations (2006 12/03)
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 (2006 11/01)
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:
- 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.
- 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.
Daqmanager object sharing scheme (2006 10/31)
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 (2006 09/20)
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 @iddsclass. 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.