Enforcing Compatibility
The following page gives essential informations on the preferred toolchain & software to use for the contributions. While we believe that innovation should not be limited by licensing costs of Software, it is important to stick to a predefined standard.
Preferred Toolchain
The table below gives the software that maintainers uses. All modifications shall be compatible, to some extends, with the following tools.
| Category | Software | Notes |
|---|---|---|
| CAD | SolidWorks | use up-to-date version for import compatibility |
| Electronics | LabCenter Proteus | files must be compatible with version 8.4 |
| Optics | OSLO | |
| Documentation | MkDocs | use only plugin Material, Pymdown & minify |
| Code | Visual Studio, GCC | only C/C++ authorized for now |
Alternative Toolchain
In case you wish to contribute but cannot afford a license for one of the preferred tools, you may submit your work using a free alternative.
Usage of alternative tools is restricted to the following conditions - reviewers can open the files easily, - the alternative tool is a well-recognized alternative by the community, - exported files preserve all critical information, - integration into the reference toolchain is demonstrated, - it would not have been easy for you to use the default toolchain.
| Tool | Status | Notes |
|---|---|---|
| FreeCAD |  Allowed | Free, open, reviewable |
| Fusion 360 |  Not-Favored | Widely used but commercial license although a free version exists |
| Creo, CATIA ... |  Strongly discouraged | Review requires costly licenses |
Note that the Maker version of SolidWorks will be treated as an alternative tool, similar to Fusion360, since it is not possible to important the files into the standard/paid SolidWorks version.
Notes on Backward Compatibility
Unless there is no other choice, we ask you not to break backward compatibility, meaning that
- changes do not break existing assemblies or software, especially mechanical CAD to avoid having people required to remachine parts at each release,
- changes do not modify existing alignement and calibration procedures,
- changes do not alter the overall workflow of the instrument such as to keep conceptual integrity,
- changes do not break well-established and documents protocols,
- changes do not break existing unit tests.
Any deviation to these rules must be thoroughly justified when submitting the change and documented with migration guidance. Breaking compatibility without justification will likely get your submission rejected, so be careful when submitting changes.