...
- Some properties are known in advance and will not change at run-time: {
positionUnits
}} orvelocityUnits
, for example. These properties are implemented as regular (non-Dependent) properties, and are given default values directly in the properties block. In some cases, it may make sense to allow these properties to be optionally constructor-initialized, eg if their value depends on a firmware version which can vary from device to device. For the MP285, thepositionUnits
falls into this "set-it-and-forget-it" category. - Some properties change at runtime, and involve read-only queries to the hardware. An example is
positionAbsoluteRaw
. These properties are implemented as Dependent properties, with get-methods that send the appropriate query commands to the hardware. - Some properties not only change at runtime, but can be set to new values, as well as queried. An example of such a property is
velocity
, implemented as a Dependent property with both a set-method and a get-method. The set-method sends the appropriate set-command (and value-to-be-set) to the hardware to set the value on the device.
...
- In some cases, a property "does not apply" to a device.
accelerationRaw
, for example, does not apply to the MP285. To make MP285 a concrete class,accelerationRaw
must be defined somewhere in a properties block; however, for the MP285, the this property doesn't do anything (its get-method always returns NaN, and there is no set-method). Your
...
- LSC subclass may similarly "omit" inapplicable properties. Note however that
...
- ScanImage
...
- will expect certain properties to be
...
- present and working. See #Minimal LSC Implementation for ScanImage below.
- The MP285 has two "resolutionModes", 'fine' and 'coarse'. Each mode has its own velocity setting, so that the
resolutionMode
is queried when setting/getting thevelocity
property. The details related toresolutionMode
are specific to MP285 and may not apply to your device; however they do illustrate the general pattern of having more than one mode.
...
The LSC interface includes more than is absolutely required by ScanImage, because it was designed with the idea that it would provide a stage controller interface that would to be generally useful, independent of any single application.
That said, you are probably reading this page because you are a ScanImage user with a custom stage. At the moment, ScanImage requires the following properties and methods of LSC to be implemented/functional:
Properties
nonblockingMoveCompletedDetectionStrategy
isMoving
(get only)positionAbsoluteRaw
(get only)positionDeviceUnits
(get only)resolution (get only)
Methods
moveStartHook
...
getResolutionBestHook
(This method has a default implementation in LSC, but if the default method doesn't apply to your device then you should provide an override.)
Testing
When your subclass is complete, it is critical to test its operation with real hardware in a "safe" setting before live use. Implementing an LSC subclass involves a fair amount of complexity and some amount of testing/debugging time will likely be necessary to ensure reliable operation. Using an LSC without proper testing could lead to wild stage moves and damage to your rig.