OpenFlexure Delta Stage v1

Today we are launching the Delta Stage v1!

https://openflexure.org/projects/deltastage/

The Delta stage has been refined and is now a fully functional microscope. Thanks to everyone who has given their feedback on the previous designs.

Improvements include:

  • Refined body design, requiring less plastic, a shorter print time and leaving more space around the optics module.

  • The optics module is now specially designed for the Delta Stage, so that the camera is correctly oriented for the stage geometry.

  • The base now has better ventilation and SD card access hole.

  • Reflection illumination is now supported and the reflection illumination module is more stable.

  • Illumination using an LED grid is now available (experimental stage).

  • The documentation is now complete and has a Bill of Materials.

  • There are now logos on the main body!

  • 35mm petri dish holder adapter for the stage.

  • The Delta Stage can now be controlled using the familiar OpenFlexure software (requires server version>2.7).

All the components are compatible with the previous version, so if you just want to change the main body, it’ll work fine with all your other existing components.

Hope you find these improvements useful, as always if you have feedback, you can write an issue or use the forum.

10 Likes

:openflexure: Fantastic news! :openflexure: Thanks for all your hard work Samuel!

2 Likes

Hi Samuel, I just found the openflexure website, and want to print one of the microscopes. Since the Delta stage is a microscope it seems, is that one the preferred one to build? It seems to have some advantages over the actual microscope.

Maybe a small table showing the advantages and disadvantages of each? Let me know if that is possible.

Fantastic idea, we should get on that.

My summary would be the “standard” microscope is much more tried and tested, more compact, easier to understand the mechanics, can be operated by hand. The benefit of the delta stage is the optics are in a fixed position which allows you to mount more and heavier optics, or to even couple in external optics.

1 Like

Thanks, I looked up a bit more. I want to be able to do both transmission and reflected light microscopy, so I should go with the delta stage at the moment.

Been looking forward to this. However, when I tried to render, this error occured
image
This also happen with a fresh clone. Openscad is 2021.1, 64-bit.

P/S: A local company saw my modified version and now interested having them OEM-ed. Is it allowed with the current licence? If yes, what can I change and what must be kept?

Did this error come from compiling the Delta Stage?

Currently we only use Openscad 2019, and so I recommend you try using that. I believe there were several changes in Openscad 2021, but we haven’t tested the code using that newer version yet.

@r.w.bowman will be able to help you wrt the licence.

Regarding licensing, our intent is that all the OpenFlexure designs are released under the CERN Open Hardware License (v1.2, but with the intention that we will upgrade to 2.0). The license text sets out in detail what you must, may, and may not do:
https://spdx.org/licenses/CERN-OHL-1.2.html

In summary, if a company wants to produce and sell a modified design, they are permitted to by the license, so long as they:

  • Release the modified design under the same license
  • Acknowledge the source of the original design
  • Do not claim endorsement by the original designers

We’re discussing exactly how we’d like to manage the process of people producing OpenFlexure designs and derivatives. I think if a company wants to produce them as, or as part of, its own products, that’s great - it’s probably best if they use their own product name and branding, but it really helps the OpenFlexure project if they acknowledge the source of the design (and is required by the license). Our funders really like hearing stories of the “impact” the project has on the real world!

I’m not totally sure what you mean by OEM-ed, but I hope I answered the question. I’m very happy to talk further with either you or the local company, here or in private - I appreciate companies don’t always want all their product information on an open forum, but we are very keen to engage with potential manufacturers and it really helps us to keep track of how the designs get used.

1 Like

The “valid_dict” assertion is concerning, that should not happen and it indicates something is broken. It should also be picked up by the build server; I assume you mean it happens with a fresh clone of the master branch. Are you able to figure out what called the valid_dict function? What file are you compiling?

valid_dict I think is only used in the microscope, so this probably means that the Delta Stage is using master from the microscope? Likely it is using a function that has now been updated to use a params dictionary.

How is the microscope repo handled in the Delta stage? It should be linked to a fixed version especially with the changes that are happening to master.

The Delta stage doesn’t use master but does use two fixed versions of the microscope repo. That’s why I suspect that it either has not come from compiling the Delta Stage, or it is being compiled using 2021 which I haven’t tested on those two fixed versions from the microscope repo.

It has to use two versions of the main microscope repo because of the ongoing changes:

  • The sub-repo is fixed at d4b73bbb as the Delta Stage uses some utilities from before the big changes were made.
  • It checks out a later version 4dfc357e in the CI as some of the smaller parts (optics module, LED array holder etc) had to be merged during the big changes.

Once the big changes have been completed and tagged on the microscope repo I will:

  1. Move the sub-repo to that tagged version and update the functions of the delta stage that use the utilities.
  2. Update the repo to use a params dictionary like the microscope is moving towards.
  3. Update the CI so it doesn’t check out to a new version for those new parts, but compiles the parts from the sub-repo.

Thanks @samuelmcdermott. Perhaps this is what happens if instead of checking out submodules you just download the master from openflexure microscope?

Are there step by step instructions on how to compile locally? I have never really played with git submodules, I am sure many others have not too?

Yes, it could be they downloaded the openflexure-microscope master separately, but it’s not necessary.

There are instructions in the repo for command line git and sub-modules, and VSCode deals with them automagically. In essence it’s just a repo (fixed at a certain version) inside a repo. You can change version and branch of the sub-module, but there’s not really any need until we move it up to the next tag. I’ll add some more detail to that effect.

I suppose it depends on whether people are Git cloning or just downloading the repo.

@Hades_Corps Can you confirm whether you used Git Submodule or if you downloaded the projects separately?

That’s true, if you just download the repo then it won’t include the submodule. I should make that clearer.

I have to download projects separately. With remote and recursive submodule, git still only download latest though. Could be just my setup, I don’t have enough experience with git.

Build scripts work just fine with all versions of Openscad. It’s just the live render that’s broken.

I use a Pi 4 8GB running Ubuntu Mate 20.10 64-bit.

OEM by itself is not well-defined. It’s simply: Company A wants to have a certain product but lacks means to manufacture it; so they contract B to make it with A’s branding.

In my case the company is in petcare bussiness. Since they are not engineers, I will provide complete microscopes, continuous upgrade packages, service packages, and guarantees. We are both new startups and believe in open access to knowledge, hence, no problem with release the source at all. My goal is to keep modifying to minimum, just package it better so they can be use in vet offices.

By live render do you mean opening the .scad file in OpenSCAD and looking at a render produced in the OpenSCAD editor? The build scripts work OpenSCAD from the command line, and inject some variable values using the D switch. This is the only way in which some parts of the structure can be built correctly.
The way in which variables are passed around in the microscope code is being cleaned up which will make live renders work better in the future, but for now the reliable builds come from the build scripts.

Edit: You can of course use the build script commands to do single item builds locally from the command line. Not as quick as the live render, but quicker than waiting for the build script to go through. For some reason my OpenSCAD will not work from the command line, probably a Windows issue of some kind :frowning:.

It’s a known issue that the delta stage cannot be rendered using the GUI and so currently can only be rendered using the command line. I believe that is due to the convexity of the way the model is put together, but it’s something I try to improve everytime I make changes to the model.

Unfortunately, it is not intuitive how to download the project and have everything work rather rather clone it, so I will make the instructions to do that clearer in the readme. I have made an issue for this.