You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: