Nightly builds

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Nightly builds

Stuurman, Nico
Some of you may have noticed that nightly builds were no longer
updating.  Complicated story, but they should be appearing again
starting tonight.

As usual, I encourage everyone to use 2.0-gamma instead of the stale 1.4
and 2.0-beta: https://valelab4.ucsf.edu/~nstuurman/micro-manager/


Best,


Nico



_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Nightly builds

Karl Bellve-3
On Mon, Mar 11, 2019 at 5:09 PM Stuurman, Nico <[hidden email]> wrote:
>
> Some of you may have noticed that nightly builds were no longer
> updating.  Complicated story, but they should be appearing again
> starting tonight.
>
> As usual, I encourage everyone to use 2.0-gamma instead of the stale 1.4
> and 2.0-beta: https://valelab4.ucsf.edu/~nstuurman/micro-manager/

Where is the source code for Gamma?
Is this it: https://github.com/nicost/micro-manager/tree/G12

--
Kia ora,

Karl Bellvé

Kia ora, a common Kiwi salutation, means to wish somebody life and
health in the Maori language


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Nightly builds

Karl Bellve-3
On Tue, Mar 12, 2019 at 9:07 AM Karl Bellve <[hidden email]> wrote:

>
> On Mon, Mar 11, 2019 at 5:09 PM Stuurman, Nico <[hidden email]> wrote:
> >
> > Some of you may have noticed that nightly builds were no longer
> > updating.  Complicated story, but they should be appearing again
> > starting tonight.
> >
> > As usual, I encourage everyone to use 2.0-gamma instead of the stale 1.4
> > and 2.0-beta: https://valelab4.ucsf.edu/~nstuurman/micro-manager/
>
> Where is the source code for Gamma?
> Is this it: https://github.com/nicost/micro-manager/tree/G12
>

Actually I think it might be this one:
https://github.com/kbellve/micro-manager/tree/ViewerPlusCV

Buried in this: https://valelab4.ucsf.edu/~nstuurman/micro-manager/WhyGamma/

I am a bit confused about the whole situation but it doesn't matter
since I am working on a Device Adapter and I don't think much has
changed even between 1.4 and MM 2.0Beta/Gamma as far as the Device
Adapter API . But, I would rather work from the correct fork so I
don't have to spend thinking about this again. :D

Just a note, I am having a very hard time downloading the windows exe
install. It always stalls at the very end...


--
Kia ora,

Karl Bellvé

Kia ora, a common Kiwi salutation, means to wish somebody life and
health in the Maori language


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Nightly builds

Chon U Chan
Dear Karl:

Since you bring up that you are working on the device adaptor, may I
ask you a question that is partly related to this loop?

I am using the Zeiss CAN29 adapter with a null cable to control my
Zeiss Z1. I need to modify the delay time when an
objective-turret-switching signal is sent, as the default value is too
short. Do you have any hint about where to get started? I am using
MM1.4

Regards,

Chon

On Tue, 12 Mar 2019 at 09:26, Karl Bellve <[hidden email]> wrote:

>
> On Tue, Mar 12, 2019 at 9:07 AM Karl Bellve <[hidden email]> wrote:
> >
> > On Mon, Mar 11, 2019 at 5:09 PM Stuurman, Nico <[hidden email]> wrote:
> > >
> > > Some of you may have noticed that nightly builds were no longer
> > > updating.  Complicated story, but they should be appearing again
> > > starting tonight.
> > >
> > > As usual, I encourage everyone to use 2.0-gamma instead of the stale 1.4
> > > and 2.0-beta: https://valelab4.ucsf.edu/~nstuurman/micro-manager/
> >
> > Where is the source code for Gamma?
> > Is this it: https://github.com/nicost/micro-manager/tree/G12
> >
>
> Actually I think it might be this one:
> https://github.com/kbellve/micro-manager/tree/ViewerPlusCV
>
> Buried in this: https://valelab4.ucsf.edu/~nstuurman/micro-manager/WhyGamma/
>
> I am a bit confused about the whole situation but it doesn't matter
> since I am working on a Device Adapter and I don't think much has
> changed even between 1.4 and MM 2.0Beta/Gamma as far as the Device
> Adapter API . But, I would rather work from the correct fork so I
> don't have to spend thinking about this again. :D
>
> Just a note, I am having a very hard time downloading the windows exe
> install. It always stalls at the very end...
>
>
> --
> Kia ora,
>
> Karl Bellvé
>
> Kia ora, a common Kiwi salutation, means to wish somebody life and
> health in the Maori language
>
>
> _______________________________________________
> micro-manager-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/micro-manager-general


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Nightly builds

nanthony
In reply to this post by Karl Bellve-3
Karl Bellve-3 wrote

> Actually I think it might be this one:
> https://github.com/kbellve/micro-manager/tree/ViewerPlusCV
>
> Buried in this:
> https://valelab4.ucsf.edu/~nstuurman/micro-manager/WhyGamma/
>
> I am a bit confused about the whole situation but it doesn't matter
> since I am working on a Device Adapter and I don't think much has
> changed even between 1.4 and MM 2.0Beta/Gamma as far as the Device
> Adapter API . But, I would rather work from the correct fork so I
> don't have to spend thinking about this again. :D
>
> Just a note, I am having a very hard time downloading the windows exe
> install. It always stalls at the very end...

I would be great if we could A:) move development back to the the official
github repo: https://github.com/micro-manager/micro-manager or B:) put
something in the readme.md directing people to the the correct repository.

The current development fork is very hard to find for newcomers. When people
go to the official repository and see that there hasn't been activity for ~1
year they will likely just assume that the project is dead.

--Nick




--
Sent from: http://micro-manager.3463995.n2.nabble.com/


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Zeiss Can delay times (was Re: Nightly builds)

Karl Bellve-3
In reply to this post by Chon U Chan

On Tue, Mar 12, 2019 at 10:55 AM Chon U Chan <[hidden email]> wrote:

>
> Dear Karl:
>
> Since you bring up that you are working on the device adaptor, may I
> ask you a question that is partly related to this loop?
>
> I am using the Zeiss CAN29 adapter with a null cable to control my
> Zeiss Z1. I need to modify the delay time when an
> objective-turret-switching signal is sent, as the default value is too
> short. Do you have any hint about where to get started? I am using
> MM1.4
>
> Regards,
>

The way you wrote it appears as if the turret is reacting to a signal too quickly?

Or, do you want to wait for turret to finish changing?

Personally, I would just use BSH scripting if possible, or modify the ZeissCan29 code.

I did write a multi-well plate jar, and scripts for a Zeiss long ago: https://micro-manager.org/wiki/Well_Plate_Plugin

In that example script, I do use:

 mmc.waitForDevice(zstage);
// add an extra second...
mmc.sleep(1000);
// add an extra second...
mmc.sleep(1000);



--
Kia ora,

Karl Bellvé

Kia ora, a common Kiwi salutation, means to wish somebody life and health in the Maori language


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Zeiss Can delay times (was Re: Nightly builds)

Chon U Chan
Dear Karl:

Thanks for your reply. The microscope takes longer than the delay
prescribed in ZeissCan29 code to switch turret. Therefore, the next
step in MMC kicks in too early. Since this is a generic issue
associated with hardware parameters, I would prefer to fix it as a
bug.

I have tried to find the ZeissCan29 code to work on, but not able to
locate it. If you could point me in the right direction (which
file/folder), I won't mind spending looking into it.

A bit more details:

The Zeiss Z1 observer microscope has a sequence of action to rotate
the turret: it retracts, rotates, and approach again at the same focal
depth. In MMC, the next step following the turret-switching command,
either light-switching or camera-trigger, would stop the Z1 motion
immediately. If the delay is not sufficient, it would result in a
wrong focal plane.

Best Regards,

Chon

On Tue, Mar 12, 2019 at 1:15 PM Karl Bellve <[hidden email]> wrote:

>
>
> On Tue, Mar 12, 2019 at 10:55 AM Chon U Chan <[hidden email]> wrote:
> >
> > Dear Karl:
> >
> > Since you bring up that you are working on the device adaptor, may I
> > ask you a question that is partly related to this loop?
> >
> > I am using the Zeiss CAN29 adapter with a null cable to control my
> > Zeiss Z1. I need to modify the delay time when an
> > objective-turret-switching signal is sent, as the default value is too
> > short. Do you have any hint about where to get started? I am using
> > MM1.4
> >
> > Regards,
> >
>
> The way you wrote it appears as if the turret is reacting to a signal too quickly?
>
> Or, do you want to wait for turret to finish changing?
>
> Personally, I would just use BSH scripting if possible, or modify the ZeissCan29 code.
>
> I did write a multi-well plate jar, and scripts for a Zeiss long ago: https://micro-manager.org/wiki/Well_Plate_Plugin
>
> In that example script, I do use:
>
>  mmc.waitForDevice(zstage);
> // add an extra second...
> mmc.sleep(1000);
> // add an extra second...
> mmc.sleep(1000);
>
>
>
>
> --
> Kia ora,
>
> Karl Bellvé
>
> Kia ora, a common Kiwi salutation, means to wish somebody life and health in the Maori language
> _______________________________________________
> micro-manager-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/micro-manager-general


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Zeiss Can delay times (was Re: Nightly builds)

Karl Bellve-3

On Tue, Mar 12, 2019 at 1:31 PM Chan, Chon U <[hidden email]> wrote:
Dear Karl:

Thanks for your reply. The microscope takes longer than the delay
prescribed in ZeissCan29 code to switch turret. Therefore, the next
step in MMC kicks in too early. Since this is a generic issue
associated with hardware parameters, I would prefer to fix it as a
bug.

I have tried to find the ZeissCan29 code to work on, but not able to
locate it. If you could point me in the right direction (which
file/folder), I won't mind spending looking into it.

You want to look at the ZeissCan29.cpp code, specifically the Turret::OnState(), which I think calls ZeissDevice::SetPosition()


I know it says micromanager2, but it is actually the 1.4 code.
 

A bit more details:

The Zeiss Z1 observer microscope has a sequence of action to rotate
the turret: it retracts, rotates, and approach again at the same focal
depth. In MMC, the next step following the turret-switching command,
either light-switching or camera-trigger, would stop the Z1 motion
immediately. If the delay is not sufficient, it would result in a
wrong focal plane.

Best Regards,

Chon



--
Kia ora,

Karl Bellvé

Kia ora, a common Kiwi salutation, means to wish somebody life and health in the Maori language


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Nightly builds

Stuurman, Nico
In reply to this post by nanthony
On 3/12/19 9:26 AM, nanthony wrote:

> Karl Bellve-3 wrote
>> Actually I think it might be this one:
>> https://protect2.fireeye.com/url?k=4cc9801a-1089ed4c-4cc9a707-0cc47adb57f0-42219cf5501002f0&u=https://github.com/kbellve/micro-manager/tree/ViewerPlusCV
>>
>> Buried in this:
>> https://valelab4.ucsf.edu/~nstuurman/micro-manager/WhyGamma/
>>
>> I am a bit confused about the whole situation but it doesn't matter
>> since I am working on a Device Adapter and I don't think much has
>> changed even between 1.4 and MM 2.0Beta/Gamma as far as the Device
>> Adapter API . But, I would rather work from the correct fork so I
>> don't have to spend thinking about this again. :D

For device adapter development, please use the 1.4 subversion
repository.  That is the master "branch" for the Core and Device
Adapters.  All other MM versions update those parts from the subversion
repository.

>> Just a note, I am having a very hard time downloading the windows exe
>> install. It always stalls at the very end...
> I would be great if we could A:) move development back to the the official
> github repo: https://protect2.fireeye.com/url?k=9ece1dab-c28e70fd-9ece3ab6-0cc47adb57f0-826ec4a6bbcb6bad&u=https://github.com/micro-manager/micro-manager or B:) put
> something in the readme.md directing people to the the correct repository.
>
> The current development fork is very hard to find for newcomers. When people
> go to the official repository and see that there hasn't been activity for ~1
> year they will likely just assume that the project is dead.

Problem is that only Mark has write access to the micro-manager
repository on github...

All I can do is update the micro-manager website.  Still waiting for
this whole situation to clear up...

Best,


Nico



_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Zeiss Can delay times (was Re: Nightly builds)

Stuurman, Nico
In reply to this post by Chon U Chan
Hi Chon,

> Thanks for your reply. The microscope takes longer than the delay
> prescribed in ZeissCan29 code to switch turret. Therefore, the next
> step in MMC kicks in too early. Since this is a generic issue
> associated with hardware parameters, I would prefer to fix it as a
> bug.
>
> I have tried to find the ZeissCan29 code to work on, but not able to
> locate it. If you could point me in the right direction (which
> file/folder), I won't mind spending looking into it.
>
> A bit more details:
>
> The Zeiss Z1 observer microscope has a sequence of action to rotate
> the turret: it retracts, rotates, and approach again at the same focal
> depth. In MMC, the next step following the turret-switching command,
> either light-switching or camera-trigger, would stop the Z1 motion
> immediately. If the delay is not sufficient, it would result in a
> wrong focal plane.

Usually, the CAN29 code is pretty good at signalling when a device is no
longer busy.  However, it is possible that the actions take longer than
the "system timeout" that you specify in your configuration.  Look for
the Core -  TimeoutMs property in the Device Property Browser and set it
to a higher value than what you have (default is 5000 ms).  Then add
that property to your System - Startup configuration.


Best,


Nico



_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general