ACHTUNG Gehäusedrucker: issue im MainCase von Januar bis heute

Ich habs mal global gepinned, das sollte jetzt überall oben auftauchen.

Danke. Dann Schaun wir mal.

Hi,

Oha das war knapp ich wollte gerade 15+X Gehäuse bestellen.

Danke für die Info, dann warte ich erstmal.

Schöne Grüße
Peter

@thomaso du hattest schon einen Testdruck gestartet - Wenn der für die Platine passt sagst du hier noch mal bescheid?

1 „Gefällt mir“


Sieht erstmal gut aus, aber das pcb berührt den sensor. Ich würds zur sicherheit nochmal komplett einbauen. Melde mich dann wieder.




Das Board geht rein und lässt sich verschrauben. Allerdings berührt es tatsächlich den Ultraschallsensor. Auf der anderen Seite beim USB-C Port ist dagegen etwas Luft. Man bekommt das Ladekabel aber trotzdem rein bis zum „Klick“. Theoretisch dürfte es noch 1mm in Richtung USB-Öffnung wandern, dafür ist aber die Schraubensäule direkt neben dem USB-C im Weg.

1 „Gefällt mir“

Also ich kann den Sensor ohne großen Aufwand etwas nach vorn schieben.

Ja das könnte die Situation verbessern. War das Lademodul früher auch nicht in die Öffnung eingeschoben?

Das Lademodul war früher eingeschoben. Allerdings hat das je nach einlegewinkel, Geschick des einlegenden und Qualität des Ladereglerboards dazu geführt dass man beim Einlegen den USB-C-Buchsenteil abgerissen hat. Ich hab deshalb 3-4 USB Boards entlöten dürfen…

@thomaso Wie im element besprochen: das leicht verlängerte Case ist jetzt verfügbar. Sagst du Bescheid wenn das board passt? Sobald die Platine da ist kann ich das auch selbst machen, derzeit hab ich nur 0.03.10 / 0.03.11.

1 „Gefällt mir“

Hi,

Kurze Frage, die zwei Öffnungen für die Befestigungsplatte, bleibt eine davon jetzt immer offen?

Ich finde es ja gut dass man dann 2 Varianten anbietet.

Aber haben wir einen Deckel, Schrauben Muttern usw. vorgesehen?

Für mich wäre das eine neue Variante. Das macht es gerade schwierig eine Sammelbestellung durchzuführen.

Dass das neue Gehäuse auch noch kürzer würde, habe ich erst gesehen als ich diese übereinanderlegte.

Das mit den nicht verschlossenen Durchbruch, macht es nicht sehr Spritzwasserfreundlich.

Eine bitte noch, können wir in den Namen wieder die Versionsbezeichnung / Revision einführen. Dann ist erkenntlich ob die Varianten zusammen passen.

Schöne Grüße
Peter

1 „Gefällt mir“

Das ist alles hier dokumentiert:

Du kannst ein Gehäuse mit nur einem Port generieren oder eine Abdeckung drucken. Für die Abdeckung brauchst du natürlich je 4 schrauben und Muttern.

Wenn du keine Lust hast die Leute, denen du Gehäuse druckst, zu fragen was sie wollen solltest du beide ports drin lassen und die Abdeckung mitsenden. So können auch diejenigen, die keinen Platz unterm Sattel haben, (größtenteils Frauen) den obs nutzen. Übrigens solltest du auch Anfragen, welche Halterung benötigt wird, aus gleichen Grund.

Jap, das macht die Sammelbestellung etwas komplexer, aber halt auch inklusiver. Das ist es wert.

1 „Gefällt mir“

Die Idee ist gut, aber die Stücklisten passen nicht dazu.
Die Bauanleitung passt nicht dazu.

GitHub Anweisung welche Bauteile zu drucken sind fehlt die Abdeckung. Wird nicht erwähnt bei der Standard Variante.

Das Attachment cover ist immer notwendig.
Könnt ihr es daher in den Ordner MainCase verschieben?

Kann jemand eine neue Stückliste anlegen. Das ist eine neue Variante, es frustriert alle wenn am Ende Bausätze zusammengestellt werden welche Inkonsistenz sind.

Wie soll ich diesen Änderungen noch folgen können?

Mach gern diese Änderungen. Danke.

Prinzipiell gilt: alle Inhalte sind Angebote, wenn du sie annehmen möchtest ist das mindeste, dass du mitdenkst. Wenn dir ein Fehler auffällt, ist es nett, wenn du ihm behebst. Nur imm Forum meckern ist auf Dauer nervigz dann hören Leute am Ende auf freiwillig Dinge zu verbessern.

@PDR, @opatut, ich habe die Änderungen schnell noch dem ohnehin schon wartenden Pull Request zum Gehäusedruck hinzugefügt. @PDR ich finde es super, dass du Sammelbestellung machst - Ich kann mir vorstellen, dass es da ganz schön unangenehm ist, wenn solche Probleme auftauchen. Ich denke aber dass wir wenn das aktuelle Gehäuse noch mal mit der 0.03.12er platine erfolgreich gebaut wurde erstmal keine edit: Feature-Gehäuseänderungen mehr direkt in main machen, ich habe einen beta branch angelegt, in dem wir dann forschen können, und dann vielleicht alle 6-12 Monate mit Vorlauf ein „Feature“-update von main und der Doku einleigen. Besonders die Teilelisten im Blick zu halten ist bei den Gehäuseänderungen ziemlich schwierig.

1 „Gefällt mir“

Heute abend baue ich alles mal zusammen, aber es kann schon sein, dass wir die nächsten Wochen noch ein paar Verbesserungsrunden drehen, z.B. ich sehe alle Stellen, die mit größeren Düsen noch verbessert werden können und spiele das nach und nach ein, wenn ich Zeit finde. Andere werden anderes finden. Eine Empfehlung für ein Gehäuse gerade ist schwierig. Die Fusion-Modelle, die ich in Inventor noch angepasst habe, haben schon irgendwie funktioniert, aber das OpenSCAD-Design ist so viel besser, modularer, und behebt die Schwachstellen, die mit dem Dateichaos proprietärer Formate keiner mehr angehen konnte.

1 „Gefällt mir“

@thomaso: Usability-fixes sehe ich durchaus auch unterjährig in main - aber nur mit dem besprochenen Prozess: mindestens ein OBS mit der neusten Platine ist zusammengebaut und gefahren. Was wir nicht mehr ändern sollten sind Dinge die die Teileliste verändern.

Wir könnten auch ein mehrbranchiges konzept fahren, bei dem es auf der Webseite einen beta-Bereich gibt, den man schon mitpflegt während man größere Featureänderungen am Gehäuse macht. Usability-fixes gehen dann in main und den betabranch. Und wenn beta nach main gemerged wird, bekommt es die doku vom vormaligen betabranch.

3 „Gefällt mir“

Ich würde stattdessen git tags vorschlagen, dann können wir Release ZIPs bauen (automatisch mit Github actions) und müssen die STLs auch nicht mehr im Repo pflegen. Das erfüllt @PDR’s Wunsch nach Versionsbezeichnungen, ohne Dateinamenchaos einzuführen, und wer sich selbst seine STLs baut aus den Quelldateien weiß, dass er:sie vorsichtig sein muss und alles nachgeprüft werden sollte, bevor z. B. große Bestellungen rausgehen.

Wenn wir tags mit Versionsnummern haben können wir auch eine Kompatibiltätstabelle pflegen (PCB ← → Gehäuse, etc.).

Das einzige was dafür fehlt ist halt die Automatisierung, siehe https://github.com/openbikesensor/OpenBikeSensor3dPrintableCase/issues/27

Die Dokumentation kann dann auch auf eine spezifische Version verweisen und kann nicht „outdated“ werden, bzw. wer den Verweis updated muss eben auch den Inhalt anpassen. Die Dokumentation kann dann hinterher sein hinter dem „aktuellen Stand“, aber eben nicht abweichen von ihrem referenzierten Stand.

Wie genau der Release Cycle aussieht ist mir gleich. Aber wenn wir künftige Fehler noch besser verhindern wollen, dann sollten einfach noch mehr Menschen testen. Meinem Aufruf dazu waren leider nur sehr wenige gefolgt. Wie kriegen wir das besser hin, dass nicht erst zwei Monate später auffällt, wenn etwas nicht stimmt?

Was wir nicht mehr ändern sollten sind Dinge die die Teileliste verändern.

Dem stimme ich nur bedingt zu. Ich finde es nach wie vor zumutbar, vor der Sammelbestellung zu prüfen, wie viele Schrauben/Muttern nötig sind. Dafür sollten wir evtl diese Teile nicht in die Bausatz-Liste bei der PCB-Version pflegen, sondern parallel zu den Gehäusebauteilen. Dann kann jede:r, der:die eine Sammelbestellung von Gehäuseteilen plant, sich zusammenrechnen, welches Bauteil welche Befestigungsteile benötigt. So würde z. B. beim „AttachmentCover“ stehen, dass 4x Mutter und 4x M3x8 nötig sind, um dieses anzubringen. Wer diese Teile nicht druckt, rechnet sie auch nicht rein.

Damit würden Schrauben und Muttern eben einfach zum Gehäusebausatz gehören und nicht zum Elektronikbausatz. Ich denke, das könnte viel Verwirrung vereinfachen, insbesondere wenn Leute, die größere Mengen 3D-Druck organisieren, ihren „Kund:innen“ ein gewisses Maß an customization bieten (Alternative Halterungen, Top/Back rider Varation, …).

2 „Gefällt mir“

Ich bin heute vormittag mit einem Sensor OpenSCAD-Gehäuse gefahren. Die Teile passen also zusammen. Nur der „GPS“-Schriftzug wird von der Schraube überdeckt, sondt konnte ich nichts feststellen. Mein Display-Gehäuse war noch ein altes.

Hattest du das case selber gerendert mit openscad? Evtl. Fehlt dir die opensans? Im github überlappen die nicht:

2 „Gefällt mir“