to clarify my confusion about the motion range:
Look at this slide, the visible area is about 10x10mm:
However, when scanning, it seems like a limited, circular area, and even has a skipped tile below the central area and various edges missing:
So I wonder, what the motion range actually is, and why the scan is incomplete in some areas…
Scanned with basically default values (45k steps).
Yes, thanks again @zeus . I have the same experience that it almost works, but there are occasional missing locations (or lines of locations) and also edges that get missed.
The scan planner object the underlies the current implementation of the scanner keeps in memory the locations it has visited and what was the result of attempting to image that location. This data needs to be saved to disk for debug purposes, we have a visualization for this data that works for unit tests, we need to adapt it for real scans so we can identify and correct these issues
Can i install this pre-release using sudo ofm upgrade --pre?
I would love that sort of thing to work. But as it is a totally different underlying OS image we don’t have the resources to make that sort of upgrade path reliable. So I am afraid it is a case of burning a new SD card. Sorry 
As v3 doesn’t have all the release tooling built up yet, nor is the underlying OS configuration stable enough, I think alpha2 (coming very soon) will actually also need a new SD card image even if you have alpha1.
We hope to release alpha2 next week. With some pretty nice upgrades. 
Is there a place where i can read what each option on the Slide Scan tab do?
Im having difficult to make an functional scan with an 40x objective, it always loses focus and doesnt get it back, so the image becomes all out of focus.
Im guessing it may have to do with the autofocus range, or stack dz, but i dont find what those options mean.
Autofocus range is the number of steps in an autofocus. and stack dz is the number of steps between images in a z-stack (though this functionality isn’t exposed in this version).
Are you using background detect. This helps a lot, as if there is no sample for a while it will really walk away.
If it cannot find the sample autofocus can repeat and walk away. Alpha2 should have a more robust focus algorithm. There has been some delays to releasing it due to unexpected issues with the camera, and some upstream dependencies.
It will be soon though!
Sorry for the delay! We have had some unexpected difficulties getting this out. Lots of work is happening though, and it should be soon.
We have made a second alpha release of the v3 microscope server. You can find the SD card image here.
A huge amount of work has gone into this release, some highlights are:
I would like to highlight that, while the vast majority of the code you will see in the Git history is from me and @JohemianKnapsody, this has really been a team effort. There has been so much testing, reviewing, and discussing that has made this a better release for everyone.
Specifically, I would like to highlight the contributions of @bprobert. She reviewed the vast majority of code for the release. Her feedback has improved quality and legibility immeasurably.
We’re really excited to get Alpha 2 out to everyone. Please test it and let us know what you think.
It’s still an alpha release, not fully tested or feature complete, but we hope it gives a taste of how things are moving.
We’re sorry to break with the no-release-Friday convention. We wanted to get this out before Maintain-A-Thon next week. During Maintain-A-Thon, we’ll be adding tests and documentation that will hopefully make Alpha 3 even closer to a stable release.
Thank you for developing the Alpha 2 version. I installed it right away and will be testing it next week. My first impression was very positive. I also appreciate that you are pushing the project forward. This is truly an important and meaningful endeavor. The work you are doing is of immeasurable value.
I am testing it right now! My first attempt - the trusty fixed slide with stained wheat corn (it is so beautiful). So far is it working flawlessly! Stitching the image, z-stacking - what a gift. I will try it on a soil sample right after - might be a bit more challenging 
but I am sure I will find the right setting!
This will save so much time. You guys are amazing, I don’t know how to thank you for this, honestly!
Update: for soil samples, for now, I found it easier switching off the background detection, but overall the improvement of the experience is breathtaking! I have now updated both my OFMs to the v3 server. The stitching works flawlessly even on the challenging soil sample images.
Hello, I tried the alpha version from October 13, but I wanted to ask if the automatic focus stacking feature has been removed. I ran both Stack and Scan, but the images weren’t automatically merged. When I download the ZIP file, I only get the individual images, not the complete stacked sheet. I also can’t find that option in Slide Scan. Maybe I’m just missing something, but I wanted to ask.
We’re excited to use this new version, but after flashing the SD card image and restarting the microscope, our server no longer starts up. Instead, we are stuck in the rasbpian prompt. Any suggestions for what to try? Is this a sign our sangaboard (v 0.5) needs updating?
Autocalibrate should laways be run without a sample. But still it should not be going green like that! I am not sure what is up there. I will have a think of what logging we cna do to see what is going on.
We need to make it clearer what is happening in the interface. We send the number you select to the camera, and the camera sets the nearest value that the hardware supports. We have no control over this.
hmm. If the Sangaboard needs updating you should still get a server, but with a message saying that the Sangaboard cannot load? The current server image of v3 can only be connected to over the network, there is no UI on the pi. Are you connecting from a septate computer? We will try to build a GUI version soon.
If you are on the microscope you can run ofm status in the terminal to check the server has started, and check ofm log to see if there is any logging information
Ah, thank you! We didn’t know the GUI wasn’t available for this version. It looks to be working smoothly now.
Alright, now that we can access our v3 alpha server, the image looks great, the slide moves around just fine (though the motors are quite hot) -however, we are getting an insurmountable error at the Camera to Stage Mapping step: “The residuals of fit were too large”
line 138, in fit_backlash raise MappingError(“The fit didn’t look successful! The residuals of fit were too large.”) camera_stage_mapping.exceptions.MappingError: The fit didn’t look successful! The residuals of fit were too large.
Camera stage mapper should ask you to replace the sample so it has something to focus on. What it doesn’t yet do is provide an interface for you to focus to get a clear image. (@chish has added this today!!)
Workaround
Camera stage is needed for double click to move, and for scanning as it les us calibrate motor steps to the distance an image moves.
Hi there again,
my wife recently build an upright hi-res version with v3-server (build-report coming soon, because it looks awesome) and we have the strange problem, that while doing a slide scan, the increments of movement per image in x and y is only 1 to ~25 steps.
I also noticed, that the overlap value seem to be per default autopopulated with numbers following the localized numbering-scheme when using openflexure-connect (for me in germany the decimal-”point” is actually a comma, so the default value for the overlap is “0,45” instead of “0.45” for me). However, changing it to “0.45” (or whatever value) does not change anything. This happens on openflexure-connect 4 and 5 (linux, x86_64, appimage-prebuild), so most likely has nothing to do with the client. Also because the steps are so minimal, there is a significant amount of stitching-errors as a result of that (see screenshot).
Not really sure what to do about that, I can only assume, that it has something to do with the microscope beeing upright, because I already build a “regular” highres-version on v7-parts with server-v3-alpha, that works just fine (even though i only tested the alpha-1 with this yet). Because the XY-configuration is identical for the regular and upright version, I assume this issue has something to do specifically with the alpha-2 build. Has anyone else experienced this issue yet also?
Hardware-Configuration:
This is super weird. Does movement work ok in both directions if you just try to navigate normally in the view panel?
Especially important: does it centre well when you double click? Because if not it may be a camera stage apping issue.
Can you download a copy of the log file straight after completing a scan and share it?
The axis directions change relative to the camera on the upright (v7.0.0-beta4) compared to the standard inverted configuration. I don’t think that this would confuse the scanning, but it might?
I had similar problem. Changing x and y motors worked for me.
