[OpenSPIM] SPIM with no laser control
Aurelia Honerkamp-Smith
aureliaomega at gmail.com
Mon Oct 7 09:58:00 CDT 2013
Hi,
Doing a manual pixel size calibration before opening the camera has in fact
solved the problem! I'm now able to acquire stacks, with the Thorlabs
shutter acting in place of the laser. Fantastic! Thank you!
I wasn't able to change the platform toolset in the MMCoreJ solution file;
it seems to be something one can only change in the project file. This is
not urgent for me anymore though, so if the general MicroManager upgrade
will solve the build problem then that's great.
Thanks for all your help, I am looking forward very much to starting data
collection!
Aurelia
On Fri, Oct 4, 2013 at 6:21 PM, Luke Stuyvenberg <stuyvenberg at wisc.edu>wrote:
> Hi Aurelia,
>
> The build error isn't exactly a chicken and egg problem, but a matter of
> dependencies: when Micro-Manager is built on VS2010, people without the
> 2010 runtime can't run it. I recently ran into this problem, and assuming
> 2010 was backwards-compatible, changed MM to build in 2008 mode. Hence your
> error; I expect anyone with only VS2010 installed will experience a similar
> issue.
>
> A possible fix is to use VS2010 to open the solution file, right click on
> the MMCoreJ project and click properties, and change the Platform Toolset
> to v100 (I don't recall exactly where the option is; sorry!). You may need
> to change this for other projects as well, but then the build script should
> work.
>
> After next week Thursday I should be able to provide a more permanent fix,
> since Micro-Manager will officially upgrade to VS2010. (The missing files
> that started all this will be packaged with Micro-Manager, so I only need
> to resynchronize our code to get all the benefits.).
>
> Regarding the error you're getting, I truly have no idea. I should point
> out that this is technically progress over the ThorLabs problem; the plugin
> doesn't try to create a pixel size configuration until it verifies the
> setup is correct. When it does try, however, it seems to cause an error in
> the camera device. I can't trace the error yet; if you get the project
> building, you might check the file/line the core log mentions for clues. I
> may be able to help further on Monday.
>
> A possible workaround would be to launch Micro-Manager, create a pixel
> size configuration manually -- as long as it's positive, the plugin
> shouldn't try to create a new one, and so may avoid this issue.
>
> Let me know if you have any questions or if you come up with anything.
> Luke
>
>
> Aurelia Honerkamp-Smith <aureliaomega at gmail.com> wrote:
>
>
> Could you just run the "msys.bat" again? It should have gotten the newest
>> version in the previous run and use that from now on.
>>
>>
> Yes, but how do I run it again, and where can I find it? I tried running
> the installer again, and I tried building Micromanager again from the
> git-bash file in the development environment folder, but I got the same
> error both times.
>
> Please look at the end of said core log. In the line above that
> stacktrace, it suggests that "the user has the camera open already"? Is
> it possible that another uManager instance is still running?
>
> This is pretty strange. This morning I got the same message in the log
> about the camera being open already, but I have made absolutely certain
> that there was not another instance running. I then tried Live view and
> Snap, which both work correctly. After this I tried to open the SPIM plugin
> again, and there is still no response, but I don't get the message about
> the camera being open anymore.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20131007/5ff0886b/attachment-0002.html>
More information about the OpenSPIM
mailing list