Skip to content

Conversation

@tlambert03
Copy link
Contributor

This PR introduces a (somewhat hidden) new feature: the ability to query the "last set" stage positions (i.e. the last known command sent from the core to a stage device). The use case arises during an MDA (when we can relatively safely assume that only the core, and not, say, a joystick, is controlling the stage), and we want to at least have the option to avoid sending a command to a device if we suspect that it is unnecessary. The new API here would now be:

  std::string xyStageDevice = core.getXYStageDevice();
  Configuration cache = core.getSystemStateCache();
  if (cache.isPropertyIncluded(xyStageDevice,MM::g_Keyword_LastSetPositionX)) {
      std::string lastSetPositionX = cache.getSetting(xyStageDevice, MM::g_Keyword_LastSetPositionX);
  }

that's a bit hard to discover (perhaps rightly so), but could be carefully used by applications if desired.

obvious caveats that should be heeded when using this:

  • these values are never guaranteed to be an accurate reflection of the current state of the stage. Simply the last value we (the core) knew about
  • these values are never guaranteed to be present (and I explicitly clear them whenever setRelativePosition is used, to reflect the fact that we know they are stale... and we don't try to be smarter about updating them).

questions

  • during calls to CMMCore::setOrigin, I set the lastPosition to "0" ... is that a correct interpretation of the semantics of that command?
  • consider using lastKnownPosition, and also update the cache anytime we call Stage->GetPosition?
  • should I do anything for pStage->SetAdapterOrigin?

- Introduced g_Keyword_LastSetPosition, g_Keyword_LastSetPositionX, and g_Keyword_LastSetPositionY to MMDeviceConstants.h.
- These keywords will facilitate tracking of the last set positions for devices.
@marktsuchida
Copy link
Member

  • during calls to CMMCore::setOrigin, I set the lastPosition to "0" ... is that a correct interpretation of the semantics of that command?

I believe so.

  • consider using lastKnownPosition, and also update the cache anytime we call Stage->GetPosition?

I think that would be nice. We might be able to utilize change notifications as well in the future (by either living with the jump forward & back after setting the position, or coming up with a way to query whether a stage is going to issue notifications).

  • should I do anything for pStage->SetAdapterOrigin?

Probably best to clear the cache.

One other thing: it's generally best to avoid holding two locks at the same time (because if the order of acquisition ever differs, it will dead lock). So when the function is already acquiring the device adapter lock (mm::DeviceModuleLockGuard), that section should be put it its own scope ({}) that ends before you acquire the cache lock. (Happy to add a commit for that if you like.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants