Skip to end of metadata
Go to start of metadata
Motor Controller Abstraction TODO
- (2010-11-30) Consider creating a HardwareInterface class, and instance of which must be passed through to the LinearStageControllerBasic constructor. The requirement for latter is that the hardware interface should be open and testable.
- Determine how velocitySlow/Fast should be specified in ScanImage - should the user specify this at all? should this just be hard-coded in motorConfig?
- Should change Linear Stage Controller to handle two-step moves in a more symmetric fashion, with the default being either slow or fast, and the other 'special' case has parameters cached, rather than the current situation where 'fast' is the default and 'slow' is special.
- The current bias in the LinearStageControllerBasic class is, ironically, the opposite of what it 'should' be for ScanImage. It is 'slow' moves that are the norm, and long/fast moves that are the exception ('special' case)
- Should consider eliminating moveCompleteHidden() and moveCompleteHook() as separate from moveStartHidden()/Hook(). The moveComplete() operation could/should be just a special case of the moveStart() operation, where moveWaitForFinish() is simply called immediately/automatically.
- Together with last change, an isMovingStrategy property could replace both moveCompleteStrategy and moveCompleteDetectStrategy properties - there are only two cases at the moment - either 1) poll isMoving property, or 2) wait for the asyncReplyReceived event supplied by RS232DeviceBasic (could be generalized to serial-like device interface). The latter makes sense if one wants to trust the Matlab serial port BytesAvailableFcn mechanism.
- Further investigate cause of RS232DeviceBasic error condition - mostly noticed with Scientifica controller - where serial port BytesAvailable appears > 0, but then when read a line or two later, it appears to be 0, causing an error in the fread() call
- Should we try explicitly testing that BytesAvailable > 0, rather than using BytesAvailable in if statement (which should be the same thing, but may be failing sometimes)?
- Identify if pauseTight() is really needed in C-injected callbacks (such as that used ubiquitously in ScanImage now with DAQmx interface). And, if so, determine if this-as it seems to-leads to increased segmentation violations. Hopefully, it will turn out that pause() is a safe command.
Specific Stage Controller Notes/Issues
- Sometimes move appears to simply stall -- the ROE will say 'MOVE IS IN PROGRESS', and be stuck there. Nothing outside of power cycling seems to fix it.
- A small delay is required between the ASCII and binary part of the move commands - probably because MPC200 must 'think' a little once it knows what type of command has been sent.
- Failure to add this delay can cause seg violations when it occurs in ScanImage callback
- Requirement of delay was proven by sending the compound command as single binary write...this would lead to seg violations in ScanImage
- Move commands of < 1um sometimes stall. As if move command is ignored, so terminator is never sent.
- Later this seemed to work, though it's not clear what was done to fix this.
- Interrupt command seems to be a pause, rather than a true interrupt. TO CHECK
- Appears that there is no software reset command - only option to restore operation is to power cycle.
- ROE display only shows position to 1um, although the resolution is better than this
- Position resolution appears to be 0.0625um (or is reported as such, at least) regardless of the velocity used in 'straightLine' mode