Skip to main content
Found a bug or design problem? Reporting issues helps improve OSSM for everyone. This guide explains where to submit issues and how to write reports that maintainers can act on quickly.

​
Where to report

  • GitHub (open source design and code)
    • Use the OSSM GitHub repository issues for:
      • Software bugs — firmware crashes, unexpected behavior, or code errors
      • Hardware design issues — CAD model problems, printed part fit, mechanical interference
      • Documentation errors — incorrect instructions, missing information, broken links
      • Feature requests — ideas for improvements to hardware, firmware, or UX
    • Repository issues: https://github.com/KinkyMakers/OSSM-hardware/issues
If you purchased parts or a pre-built assembly from Research and Desire, use support for order issues, shipping questions, missing items, or product defects. These are not GitHub issues.
Contact support (typical reply within 1 business day).
Security or safety vulnerabilities: do not post publicly. Contact support and include “Security report” in the subject. Provide a minimal, reproducible description and affected versions.
If your problem is with the Wireless Remote (RADR) pairing or behavior, review the RADR Quick Start first.

​
Submit a high‑quality issue

1

Search existing issues

Check whether the problem is already reported. If you find a match, add your details (device/firmware versions, logs, photos) as a comment instead of opening a duplicate.
2

Gather the right information

Collect these details before you file:
  • For software/firmware
    • Exact firmware version and board revision
    • Steps to reproduce (numbered, minimal)
    • What you expected vs. what actually happened
    • Any on-screen or serial error messages
    • Whether you control OSSM via wired remote or wireless remote
    • If you recently updated, note how you flashed it: see Flashing your OSSM
  • For hardware/mechanical
    • Clear photos or short video showing the issue
    • Specific part names and version (e.g., printed part STL name, rev)
    • Measurements (calipers), materials, printer settings (nozzle, layer height, infill, filament)
    • Assembly or wiring references if relevant (e.g., Motor Wiring)
  • For all issues
    • Environment details: OSSM hardware version, power supply, peripherals
    • Links to any related discussions or prior issues
3

Create a minimal reproduction (if applicable)

Reduce the problem to the smallest set of steps or configuration that triggers it. Attach sample configs, short pattern files, or gcode-like snippets as needed. This helps maintainers reproduce and fix the issue faster.
4

Open a new issue on GitHub

Go to https://github.com/KinkyMakers/OSSM-hardware/issues/new and include:
  • A clear, descriptive title
  • Numbered steps to reproduce
  • Expected vs. actual behavior
  • Environment and version details
  • Screenshots, photos, logs, or short videos
Paste error messages verbatim and attach files rather than pasting large blobs inline. Redact personal data.
5

Follow up and verify the fix

Subscribe to your issue and respond to maintainer questions. When a fix or workaround is provided, test it and confirm the outcome. Close the issue when resolved.
You should have an issue number and notifications enabled. If you contacted support, check for a confirmation email within 1 business day.

​
Copy‑paste issue templates

### Summary
Brief description of the problem in one or two sentences.

### Environment
- OSSM board revision: 
- Firmware version: 
- Control method: (wired remote | wireless remote)
- Power: (24V PSU | USB‑C PD + adapter)

### Steps to reproduce
1. 
2. 
3. 

### Expected result

### Actual result

### Logs / screenshots

​
Try these first (common fixes)

Re‑flash the device using the web flasher and verify the version shown during flashing. Guide: Flashing your OSSM
Check wiring order and terminations for the Gold Motor. Guide: Motor Wiring
Walk through the quick start and reconnection steps: RADR Quick Start
Include version numbers everywhere: printed part revision, board revision, and firmware version. This is the single most common blocker for quick triage.
Need help deciding whether something belongs in GitHub or support? If money changed hands (orders, shipments, defects, warranty), contact support. If it’s about the open source design, CAD, firmware, or docs, open a GitHub issue.