Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving performance of multi-site experiments #823

Open
juliomateoslangerak opened this issue Sep 5, 2022 · 0 comments
Open

Improving performance of multi-site experiments #823

juliomateoslangerak opened this issue Sep 5, 2022 · 0 comments

Comments

@juliomateoslangerak
Copy link
Contributor

We are currently running a classic z-stack over multiple sites and I would like to improve the performance to be able to capture more stacks per cycle.

There is a significant delay between one site and the next one. Some 10sec. The computer is old and we are going to replace it soon, but I'd like to anticipate cause I have the feeling that it is not only this.

I believe there a number of things could be worked on on the multi-site experiment:

  • For every position, there are a number of things that are 'unnecessarily' being recalculated, like the whole actions table. Could we wrap the calculation of the table in a function that could be cached? Would it be possible to split out the z positioner actions generation so that only that part is recalculated?
  • The movement time to the next position seems slow, while the stage it self is moving in 150msec. I believe there might be some time lost waiting for the stage to answer and also the x and y movements are sequential...
  • Saving images also seems slow. Is there something might help in that front?

Another alternative is to setup a single-site experiment doing the multiple sites. I believe that might provide more flexibility to optimize some of these things. Eg. with the NI-fpga executor, when I start the execution I can specify at which position of the table to start. It is possible to pre-compute the z-stack for the different positions and have no overhead in loading a new table for every position (as long as memory is not an issue).

This might not be necessary or not so pressing with a new PC. As soon as the PC is replaced I'm planning to run some timing tests to see which points might require more attention.

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

No branches or pull requests

1 participant