Beiträge von kmg

Zitat von HobbyProgrammer

das was Du da schreibst klingt als ob der Cife ein nicht funktionierendes Müllprojekt ist.

Nein, ist es nicht ! Ich hatte nur aus Deinen Antworten den Eindruck gewonnen, das du das Gefühl hast, einen Kampf gegen Windmühlen zu führen, weil an allen Ecken immer wieder neue Probleme auftauchen. Deswegen der Hinweis sich ev. einmal auf die Kernfunktion zu konzentrieren und 'neu zu sortieren', um so den Blick wieder frei zu bekommen für die weitere Arbeit. Aber ein "Schrottprojekt" ist es in keinem Fall, da misverstehen wir uns wohl eher beide ! Wenn etwas einfach nicht so will wie es soll, reicht es oft, den gewählten Ansatz leicht zu varieren, um den Karren wieder flott zu bekommen. Das zu sagen war meine Intension, mehr nicht und eine harte Kritik wie im obigen Zitat vermutet wird, schon garnicht. Das würde ich mir schon aus Respekt vor deiner bisher geleisteten Arbeit nicht erlauben. Ich hoffe damit alles wieder ins Lot gebracht zu haben.

Wenn ich Deine Antworten so lese... Mein Rat wäre, kompliziertes vorerst beiseite zu lassen. Ich finde es schon einen großen Gewinn in die images oder mehrere gleichzeitig reinsehen zu können ohne dafür einen Emulator für's CPM-System benutzen zu müssen. Meist möchte man doch nur unkompliziert Files aus dem Image heraus bzw. hinein bekommen oder sich vergewissern was im Image für Files sind. Da das ohne den PC ohnehin nicht geht, kann das auch über einen Ordner für den Export/Import auf dem PC erfolgen und von dort dann zu einem anderen Image. Ich gebe zu, dass das etwas altbacken und umständlich klingt/ist, dafür hat man aber fürs erste ein zuverlässiges Konzept und hat ganz nebenbei auch ein aufbauendes Erfolgserlebnis. Steht das alles, kann es an Kompfortfunktionen wie Drag&Drop oder anderes gehen. Das Verify bzw. Repair von Images würde ich grundsätzlich herauslassen, denn bei dem Formate-Wildwuchs in der CPM-Welt verfranzt man sich nur, bzw. wie soll die korrekte Verify/Reparatur überprüft werden ? Das sollte dem jeweiligen CPM und seinen Hilfsprogrammen überlassen bleiben. Ein Explorer muß das nicht können !

Muß es z. Zt. unbedingt schon Drag/Drop in beide Richtungen sein ? Reicht da nicht als solide Grundfunktion Import/Export für Files vorerst aus ?

Ein per Drag u. Drop eingefügte Datei (PC -> Image) wird anscheinend nicht ins Image eingefügt. Zumindest ist es bei mir für die Joyce so. In CPMBox kann ich die Datei hinterher nicht finden.

Ein Check Image mit Repair bedeutet, dass das Image anschließend defekt ist und CPMBox es als nicht lesbar bemeckert (das üblich Wiederholen/Abbrechen/Ignorieren Lied des BIOS). Ich habe jetzt nicht die vorhergehenden Beiträge alle gelesen, kann also sein, das diese Tatsache bereits bekannt ist.

Hier finden sich Wordstar3.00 & 3.01 Manuals wie Files:

URL: https://winworldpc.com/product/wordstar/300

Ev. ist das gesuchte dabei.

Danke für die Erklärungen. Ich habe da noch eine andere Sache, die nicht so funktioniert wie erwartet. Mit dem Parameter -I<file> sollen auftretende Fehlermeldungen in eine Datei umleitbar sein. Das ist ganz praktisch, würde es denn auch so funktionieren. In meinem Fall wird die Datei angelegt, sie ist aber trotz auftretende Fehlermeldungen stets 0kB lang (?). Als behelf lasse ich alle Ausgaben auf der TTY-Schnittstelle parallel ausgeben und zeichne das was da kommt mit dem Terminalprogramm auf dem Laptop auf. So hat man's auch, aber es wird dafür leider ein 2ter Rechner benötigt. Irgendwie suboptimal. Womöglich ebenfalls eine Eigenart des neuen HTC oder denke ich nur nicht genug um die Ecke (Stichwort PIPEMGR.COM) ?

Mit welchen Aufruf-Parametern für den Hi-Tech-C Compiler hast Du Deine Beispiele übersetzt ? Bei mir werden die Binaries ca. 14k groß. Das sieht mir danach aus, als wenn ein haufen ungenutztes Zeug mit dazu gelinkt wird, Im Handbuch konnte ich nichts finden, was das abstellen würde. Meine HTC-Version stammt von Github => agn453

RunCPM legt auf dem RPi Pico ein beachtliches Tempo vor ! Bei mir schafft das compilerte CalcPi immerhin noch 77sec. für 100 Stellen (bei 25MHz).

Ich habe einmal spasseshalber versucht, VOKABELN.BAS mit SBASIC zu kompilieren. Der Compiler beschwert sich vehement über fehlende Module in der LIBRARY.BAS - siehe nachfolgendes Listing:

04:06 M0:WORK>sbasic vokabeln    
       tm
S-BASIC Compiler Version 5.4b 

0001:00 COMMENT
0002:01     VOKABEL.BAS
0003:01     SBASIC Beispiel Vokabel Trainer
0004:01     LIBRARY.BAS Anpassung
0005:01     Kurt Pieper, Germany
0006:01     Update   : 08.02.2023
0007:01     Revision : 10.02.2023
0008:01 END
0009:00 ON ERROR GOTO 940
0010:00 BASED ERROR.CODE = INTEGER
0011:00 $INCLUDE LIBRARY CLS
0012*01 rem  Clears Kaypro screen
0013*01 procedure cls
0014*02     print #0; chr(26);
0015*02 end cls
0016*01 $end.module
0017:00 $INCLUDE LIBRARY CLREOS
MODULE NOT FOUND

LIBRARY NRM$
$$$$$$$$$$$$$$$ Un-defined operand
0225:99 $INCLUDE LIBRARY CURSOR

ZPM3 Error On O0:  Invalid Drive
Function = 15  File = LIBRARY.S
04:07 M0:WORK>

Das angemahnte Modul CLREOS ist nicht in der LIBRARY.BAS enthalten. Alles andere ordne ich unter Folgefehler ein. Das ZPM3 am Schluß einen Zugriff auf Laufwerk O0: ausbremsen muß (bei mir gibt's nur A,B,C und M) ist merkwürdig genug (was will der Compiler von Laufwerk O0: ?). Vielleicht sind dererlei Merkwürdigkeiten der Grund, das sich SBASIC nicht so recht durchgesetzt hat. Bedauerlich, ich finde SBASIC gut, nur man braucht ein dickes Fell und Sitzfleisch will man SBASIC nutzen

Super, ich danke Dir.

Zitat von guidol

Denn ohne dies Verzeichnis gibt es kein Laufwerk A: fuer RunCPM und es kommt zum BDOS Error (meist kommt man mit 1-2 mal ENTER da raus - aber wenn schon Laufwerk A: fehlt kann er dahin nicht zurueckspringen)

Du hast recht, da war ich zu schnell oder zu blauäugig. Ich habe ohne weiter darüber nachzudenken angenommen, da alles im .exe drin steckt. Spätestens bei der nachfolgenden Aktion hätte mir auffallen müssen, das da was übersehen wurde 8^) - nämlich, das im älteren Archiv deutlich mehr Dateien enthalten sind (warum wohl).

Wo jetzt aber die ganzen Dateien auf A0: hinverschwunden sind (bis auf die, die über DIR angezeigt werden), verstehe ich trotzdem (z. Zt. nicht). Auf Laufwerk A: wird ja zugegriffen, sonst gäb's die ausgegebenen Dateien nicht. Nach USER 1 und DIR müßte INFO.TXT kommen, tut's aber nicht.

Zitat von guidol

Zeig doch mal das Ergebis eine "uname -a" von Deinem Buster

$ uname -a

Linux refracta9 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) i686 GNU/Linux

Zitat von guidol

Wieviel Bit hat denn Dein debian Buster bzw. wieviel Bit vertraegt Dein Wine?

wine ist 32-bit

Zitat von guidol

Allerdings wuerde es wohl am meisten Sinn machen, RunCPM unter debian selbst zu kompilieren, dann umgehst Du den Overhead von Wine

Das wäre eine interessante Option. Am wine-Overhead störe ich mich da weniger, da das CPM eh' in einer Emulation läuft (die dann i.d.R. ohnehin deutlich schneller ist wie das Original).

Zitat von guidol

Ich koennte evtl. eine Art Kurzanleitung (oder mein Shell--Script zur Verfuegung stellen).

Das wäre optimal, als Nicht-Informatiker habe ich da keine guten Erfahrungen gemacht, wenn es um das Zusammenstellen von Entwicklungsumgebungen geht. Da habe ich meistens Schiffbruch erlitten, weil man im Thema nicht so drin steckt.

Dein Starter-Paket von RunCPM hat mich dazu veranlaßt, es auch einmal zu versuchen - unter wine auf meinem Linux System :o)

Als erstes habe ich mich am Starter-Paket 'RunCPM_v6_0_Win_09102022.zip' versucht, weil es das letzte aktuelle ist. Das geht mit eines BDOS Fehlermeldung schief:

Das üblich 'A' zum Abbrechen hilft nicht, aus der Nummer ist so nicht heraus zu kommen. Da half es nur, RunCPM über den Taskmanager direkt zu töten.

Manchmal hilft der Blick zurück, also habe ich das vorletzte Starter-Paket versucht: 'RunCPM_Win_v6_0_Starterpack_GL20221011.zip'. Das war ein Volltreffer - läuft unter wine soweit :

Ein kurzer MBASIC Testlauf mit dem Einzeiler '10 for i%=100 to 500:? I%;:next' wird anstandslos abgearbeitet. Der Compilerwechsel hat anscheinend Auswirkungen auf die Lauffähigkeit unter wine, soweit ich das als Nur-Anwender feststellen kann. Mein Linux-System ist ein schon etwas betagteres Debian-Buster. Ev. läuft das unter Debian-11 besser. Ein Upgrade habe ich aber nicht vor.

Zu Deinem Layout - 2-lagig mit Massefläche auf der Bestückungsseite:

Durch die horizontal verlaufenden Leiterbahnen kommt es zu undefiniert langen Wegen vom VCC-Pin zum Masse-Pin. Das gilt ganz besonders für die speicher-Chips und den Prozessor. Hier wäre es günstiger gewesen, die Massefläche auf die Lötseite zu legen. Das dürfte vermutlich der Hauptverursache für die Betriebsprobleme sein. Es ist generell keine gute Idee, das Layout NICHT mit dem Verlegen der VCC und GND Leitungen zu beginnen. Wenn der 10uF so deutlich erkennbare Auswirkungen zum Besseren zeigt, deutet das auf eine zu hochohmige Versorgungszuführung vo Netzteil hin. Der 10uF puffert die durch die Schaltvorgänge erzeugten 'langsamen' Stromsptzen und glättet somit VCC. Das müßte eigentlich mit dem Scope auch deutlich zu sehen sein. Deine Feststellung "Also liegt es tatsächlich an der Spannungsversorgung" ist wohl zutreffend. Kontrolliere aber trotzdem, ob nicht immer noch Spannungseinbrüche auf VCC auftreten, die gößer wie 0.3V sind (den 10uF ev. erhöhen auf z.B. 47uF parallel 100nF). Versuch mal auf der jetzigen Leiterplatte das GND-Ende eines jeden 100nF Stütz-C's mit einem Draht (0.5mm Durchmesser) direkt zum GND-Pin des IC's zu verbinden. Das sollte die Stützwirkung weiter verbessern, da der GND-Pfad des Stütz-C's kürzer und definierter wird. Du kannst auch versuchen, einen zusätzlichen bedrahteten 100nF zwischen VCC und GND Pin zu löten (besonders bei den RAM-Chips). Erhöhe doch auch mal die +5V auf +5.2V. Das liegt noch in der Spec. Verbessert sich dadurch ev. der Betrieb, wenn ja, sind immer noch zu viele Störungen auf der VCC.

4-lagen PCB:

Generell wie schon angeklungen die beste Lösung, da so die Impedanz der Versorgung für steile Stromspitzen am geringsten ist. Die so gebildete Kapazität des Plattenkondensators ist jedoch nicht sehr groß, die notwendigen 100nF Stütz-C's ersetzt das auf keinen Fall. Ich erinnere da mal an die 500pF Drehkos in den alten Röhrenradios. In der Größenordnung dürfte sich der erzielte Wert bewegen (wenn überhaupt).

Testbetrieb:

Laß die CPU in einer Schleife immer auf die selbe Adresse die selben Daten schreiben/lesen. Das erzeugt eine quasi-statischen Betrieb und Fehler/Störungen lassen sich leichter untersuchen und zuordnen. In Deinen Logiganalyzer-Plots ist viel zu viel auf einmal zu sehen. Teste auch, ob alles ok ist, wenn sich viel Bits auf einmal von '1' auf '0' und umgekehrt ändern. Diese Situationen erzeugen starke Stromspitzen auf der Versorgung. Auch dann muß alles stabil funktionieren. Derartigen Fälle können zu später schwer auffindbaren Fehlern führen.

Lichte doch noch mal Dein Layout/Bestückung hier ab. In kiCAD kann man sehr schön Ober- u. Unterseite gleichzeitig plotten lassen, sonst diskutieren wir hier über ungelege Eier. Bevor Du ein neues Layout anfängst, muß (!) klar sein, wo die Probleme liegen, andernfalls geht unnötigt Geld durch Neustarts drauf. Nachträglich aufgelötete Stütz-C's auf Prototype-Boards sind die Regel, Anpassungen bei den Versorgungsleitungen etc. ebenfalls. Ein 2-Kanalscope ist für die Fehlersuche ausreichend, allerdings sollte es 100MHz Bandbreite in Deinem Fall haben und am Besten auf einem Kanal 1Gs/s schaffen, ansonsten siehst Du bei 'längeren' Aufzeichnungen (~100us/DIV) nicht genug. Will heißen, beim Rein-Zoomen sind zu wenige Samples an der Darstellung beteiligt. Der Tastkopf sollte >250MHz Bandbreite aufweisen, ansonsten geht von der Y-Bandbreite zu viel verloren. Aus meiner Sicht ist Hopfen-und-Malz noch nicht verloren. Dann wären da noch Screenshots von dem was Du mißt. Ohne diese Bilder ist eine tiefergehende Beurteilung Deines Problems kaum zu schaffen...

Wenn Du die MMU auf einem Experimentierboard aufbaus, zuerst die VCC und GND Leitungen verlegen. Die 100nF Stütz-C's an den VCC-Pins gegen Masse für jedes IC nicht vergessen (absolut wihtig). Die Versorgung muß frei von Störungen sein, also keine Peaks oder Einbrüche, ansonsten kannst Du jeden Schaltungsaufbau wegen nicht nachvolziehbarer Fehlfunktionen vergessen. Falls Du mit dem Tastkopf ran gehst und bei den Flanken klingeln bzw. große Über-/Unterschwinger mißt, der Masseklipp am Tastkopf ist eine Induktivität undbekannt dafür, das Messsignal in dieser Form zu verfälschen. Sehr gute Messergebnisse erhälst Du, wenn die Signalmasse zum Messen per kurzen Draht vom Massering an der Tastkopfspitze abgenommen wird (die Signalmasse möglichst immer am Ort des zu messenden Signal abnehmen ! Auf dem Steckbrett besonders wichtig). Das ist etwas frickelig, vermeidet aber besagte Probleme. Sollten bestimmte Signal wegen langer Signalleitung auf der Platine dennoch Probleme machen, kann auch ein Widerstand (27R...47R) direkt am Signal-Ausgang in Serie zur Leitung als Dämpfung der Leitungsinduktivität/kapazität Wunder wirken. Derartige Dämpfungswiderstände helfen auch, solltest Du die MMU-Platine auf's Steckbrett stecken, um den erweiterten Rechneraufbau zu testen. Die Steckbretter haben leider eine relativ hohe Kontaktinduktivität gepaart mit ~5pF Schaltkapazität (meine Erfahrung). Das macht die Bretter nicht unbrauchbar, man muß es nur berücksichtigen, dann geht es meistens.

Zitat von Diddl

Naja es geht ja nicht um den RAM für das System selbst.

Was ich meine ist der MMU RAM.

Das gesagte gilt für das RAM der MMU genauso, Die zu bevorzugende Richtung ist natürlich so schnell wie möglich.

Sicher gehen die auch, der CPU-Takt muß dann nur niedriger gewählt werden, damit die RAM's nicht überfahren werden. Beim 6809 NitOS9 CocoDEV-Rechner von Coco-Daddy kommt ein 512k 10ns SRAM zum Einsatz, was wiederum 25MHz CPU-Takt ermöglicht. Sind die SRAM's langsamer, wie Deine 20ns Typen, liegt der max. mögliche Takt vielleicht bei 16MHz. Aber selbst das bedeutet immer noch ein beachtlich schnelles System - also kein Grund zur Sorge. Man sollte nur nicht unbedingt mischen, denn der langsamste bestimmt den 'Takt'.

Es gibt bei kiCAD im Schaltplan-Editor unter DATEI -> plotten im dann auf-poppenden Fenster die Möglichkeit den Schaltplan in diversen Formaten zu plotten. Das pdf wird im Stammverzeichnis des Projektes abgelegt. Geht schnell und unkompliziert für einzelne Schaltpläne oder alle des Projektes. Hat auch den Vorteil, wenn es Problme mit Symbolen gibt, im pdf nachsehen zu können (unabhängig von kiCAD), wie der Originalzustand sein soll.

Ich hab' mal bei utsource nach dem MC6829 gesucht und ... nichts gefunden, auch eBay glänzt durch Unkenntnis. Der Chip ist bekanntermaßen nicht zu bekommen, womit Du leider der einzige bist, der am Ende das Projekt realisiert. Gibt es da wirklich keinen anderen Weg ?

Ich bin vor ein paar Tagen auf ein Projekt namens 'UniFlex' gestoßen. Dort kommt auch ein 6309 zum Einsatz und die Hardware besitzt ebenfalls bezüglich MMU und Betriebssicherheit einige sehr bemerkenswerte Eigenschaften. Man braucht für ein Grundsystem 4 Eurokarten und einen 19"-Einschubgehäuse. Letzteres setzt die Einstiegskosten leider schon recht hoch an. Eventuell läßt sich aus den Schaltplänen Honig saugen und ein Ersatz für den MC6829 basteln.

Btw., sind das nicht eigentlich Plagiate, da von einem 3D-Drucker gefertigt und nicht original APPLE ?

Zitat von Shadow-aSc

oops - das hab ich übersehen kmg : bist du mit der von mir gewählten Überschrift auch zufrieden?

Bin mit der Antwort etwas spät, war mit einem anderen Projekt beschäftigt: Ja, Deine Wahl geht auch in Ordnung. Ist ja beim gleichen Thema.

Zitat von funkenzupfer

Ausserdem habe die meisten unserer Geräte doch ein H-Kennzeichen

Wenn es nur darum geht ein Anschaungsobjekt mit so original wie möglich gehaltenen Erweiterungen auszustellen, hast Du allemal recht. Ich finde es auch immer wieder spannend zu sehen, was damals für'n Aufwand betrieben wurde, um die Rechner mit Must-Have-Features aufzubohren. Da sind aber Überlegungen wie anfangs zu lesen 'Jetzt steht noch die Frage an, TTL-Grab oder CPLD. Da bin ich mir noch nicht schluessig' nicht erlaubt. Das klingt doch eher wie 'Retro' oder 'Vintage' ?. CPLD wäre dann Retro, TTL-Grab gleich Vintage. Dr. Google liefert einen Erklärungsansatz:

"Echt Vintage oder nur Retro-Stil? ... “ Im Klartext: Vintage ist tatsächlich alt, Retro ist neu, lehnt sich aber an alte Designs an."

Ich empfehle die Münze zu werfen

Zitat von Toast_r

Das TTL-Zeug gibt es seit Jahrzehnten, und ich schätze, daß es das auch nach ein paar weiteren Jahrzenten noch geben wird.

Fragwürig, wo doch immer mehr auf Energieeffizienz geachtet wird. TTL-Gräber saugen auch als LS erhebliche Leistung auf.

Zitat von funkenzupfer

Wenn ich mir die Lagerhaltung bei reichelt & Co anschaue, wird die Beschaffbarkeit von 74LSxx auch immer duenner bis zu null.

Kann ich nur bestätigen. Zum Teil muß man sich aus diversen Quellen bedienen um an alles zu kommen, das Treibt die Projektkosten wegen der jedesmal anfallenden Versands unangenehm in die Höhe. Bei Kauf in China sind es außerdem die erheblichen Wartezeiten.

Zitat von funkenzupfer

Jetzt steht noch die Frage an, TTL-Grab oder CPLD.

TTL-Grab ist zu statisch - denke dabei auch an den Entwicklungsaufwand - auch wenn sich die Grafikkarte auf einem Steckbrett aufbauen läßt. Ich tendiere mittlerweile zum Löten by Editor weil ich mir dann dieses ganze Geraffel mit Lökolben und der notwendigen Stellfläche als 'Dauerexponat' sparen kann. Den Mehraufwand durch ISE oder Quartus nehme ich da gern in kauf - ein Labtop ist schneller zusammengeklappt und weggeräumt wie wie das hantieren mit dem Testaufbau samt Scope und Meßgeräte bis endlich alles steht und läuft. Ich sehe auch für den Nachbau(er) beim CPLD ganz klar die meisten Vorteile: Da weniger Bauteile, weniger Fehlermöglichkeiten, von Problemen bei der TTL-Bauteilbeschaffung einmal ganz abgesehen.

Zitat von csdragon

Dafür hat man ja im Drucker verschiedene Profile...

Daran muß ich mich wohl erst noch gewöhnen, ist aber sicherlich der richtigere Weg.

Zitat von csdragon

Also mit der pulverbeschichteten Platte war das Ablösen so was von leicht...

Ich hatte ganz zu Anfang einen Haltewinkel gedruckt, der war in Z-Richtung 12mm hoch und auch sonst recht massiv. Soweit ich mit noch erinnere, ging der deutlich besser vom Druckbett zu lösen. Gleiches gilt für ein 5cm hohe Pyramide. Sobald die Teile einfach nur dünn sind (besagte 2mm), hilft verbiegen des Bleches nicht viel, da das Druckgut dem einfach folgt und sich nicht wie gwünscht ablöst. Das ist dann das typische Beispiel, bei dem dann nichts geht wie erwartet.

Zitat von Shadow-aSc

sollte man solche Infos nicht eher im 3D-Bereich zur Verfügung stellen,

Diesen Weckruf sollte man vielleicht erhören. Was als kurze Zwischenfrage gedacht war verselbständigt sich so langsam zusehens... Ich bin auch fürs verschieben. Titelvorschlag: "Haften eure Ausdrucke auch so fest..."

Sieht genau so rauh wie die meinige aus. Mir kommen Zweifel, was meinen Probedruck auf der Pulverplatte betrifft. Ich werde den noch einmal wiederholen, dann aber mit etwas größerem Testobjekt, um mehr Oberfläche zu haben. Der erste war merkwürdigerweise ca. 1/10tel dicker wie er hätte sein dürfen und paßte deshalb nicht in die Nut. Kleinkram, soetwas kann man schließlich vorhalten. Aber davon unabhängig werde ich mir im nächsten Monat die satinierte bestellen und die auch testen.

Zitat von zitruskeks

Gibt von Prusa jetzt aber auch eine satin-rauhe, das könnte was für dich sein.

muß ich mir ansehen. Gerade bei Frontplatten ist eine leicht rauhe Oberfläche mitunter angenehmer, die Lichtreflektion ist defuser und man sieht dann (hoffentlich) die kleinen Ungenauigkeiten im Druck nicht so. Mußte Ich gerade heute erfahren, als ich nach dem Grund für Resonanzen der Druckplatte suchte, wenn der Druckkopf in der nähe der oberen Plattenkante druckte. Den leichten Druck mit dem Finger, um zu testen ob was lose ist, kann man jetzt in einer geringfügig anderen Lichtreflektion sehen.

Zitat von csdragon

Bin ich nicht wirklich Fan davon.

Hate ich heute vor dem oben erwähnten Druck getestet. Die 85°C der Druckbetttemperatur haben das Crepp leicht schrumpfen lassen und die Kanten stelten sich auf. Beim Überfahren ist der Druckkopf leicht hängen geblieben. Die Druckspur ist dann an der Stelle abgerissen. Ich konnte schlimmeres gerade noch verhindern. Für ein beheiztes Druckbett ist es sicherlich ein No-Go, auf kaltem Bett (vom CADET) ist es eine gute Lösung (mit PLA). Isopropanol ist nur zum entfetten gut, ansonsten unveränderter Klebekrampf. Es bleiben noch Spuke und Spüli

Dr. Google hat mir heute auch noch offenbart, das es sogar ein Profile für den Mini+ für CURA gibt. Das Howto wie man das Profil installiert muß ich allerdings noch abarbeiten. Auf dem CADET konnte mich Cura durchaus überzeugen, aber für den ist sie schließlich auf den Leib konfiguriert.

Zitat von zitruskeks

Ich hab noch eine 3rd-party Strukturplatte

Von welchem Verein ist die ?, Würde ich gern mal ein Auge drauf werfen, alternative Quellen sind immer Hilfreich. Taugt die was, die magnetische Haftung auf dem Druckschlitten muß gewährleistet sein, sonst ist es nicht zu gebrauchen.

Dieses Trennschicht-Problem zw. Druckplatte u. Druckgut hat was von Allchemie und Kaffeesatz... Der Tipp mit der Spucke ist aus dem täglichen Leben. Es soll ja haften aber auch nicht zu bodenständig sein. Ich habe hier noch 2 Rollen blaues Malercrepp liegen, mich nur noch nicht getraut es auf ein Druckbett zu kleben, welches dann auf 90°C aufgeheizt wird. Laut Datenblatt ist es dafür nicht geeignet - hat das trotzdem schon mal jemand versucht ? Was macht da ev. der Klebefilm auf dem Druckbett ? Bei einem unbeheiztem Druckbett war die Haftung auf dem Crepp gut und das Druckgut einfach davon zu trennen. Insgeheim gehe ich davon aus, das mindestens ein Druckbett versauen wird, bevor sich 'Erfahrung' einstellt. Das glatte Druckbett zeigt schon erste Verschleißspuren wie Kratzer und kleine Lunker, dort wo das PetG zu fest haftete.

Das Thema Support-Struktur und die siche ergebende unschöne Oberfläche des Druckguts ist wohl nur konstruktiv zu lösen, indem da wo es zu sehen ist eine Art Blendplatte etc. drübergeklebt wird, sofern sich das Teil nicht so gestallten/zerlegen läßt, das supportbedürftige Überhänge vermieden werden. 3D-Druck erfordert schon ein beachtliches Toolset: Slicer, 2D/3D-CAD-Software, Reinigungsmittel/Trennmittel und einen guten Kleber für die vielen Einzelteile. Jedenfalls werde ich das mal so in mein persönliches Pflichtenheft übernehmen. Danke für die Anregungen und Kommentare.

@zitruskeks

Danke für die sehr hilfreichen Hinweise. Meine eigentlich guten Erfahrungen mit Überhängen und Support sind dem CADET von MONOPRICE und CURA-4.8 geschuldet. Nur der kann kein PetG und die ganzen Druckeinstellungen nach CURA zu übertragen habe ich noch nicht versucht (wenn's überhaupt sinnvoll geht).

@csdragon

Die Erfahrung habe ich auch gemacht. Die Haftung ist exzellent, einen 2mm dicken Ausdruck habe ich mir deswegen schon durchgebrochen. Aber Wasser und etwas Seife (Spüli ?) habe ich noch nicht versucht, werd's ausprobieren. Zum Ablösen nehm ich statt Skalpel lieber ein Schweizer Taschenmesser, ist nicht so scharf. Meine Finger sind mir auch wichtig. Mit der pulverbeschichteten Druckplatte habe ich nur einmal etwas gedruckt, die resultierende Oberfläche war doch recht rauh. Mit welcher Platte druckt Prusa eigentlich seine Teile für die Drucker aus ? Deren Oberflächenstruktur hatte ich mit der pulverbeschichteten in Verbindung gebracht.

Moin,

zum Thema Support habe ich da mal eine Frage. Verwendest Du PetG Filament von Prusa und wenn ja, wie gut ist bei Deinen Ausdrucken der Support vom eigentlichen Druckobjekt lösbar ? Wenn ich mit meinem Mini+ etwas mit PetG u. Support ausdrucke, ist es jedesmal ein heiden Krampf die Support-Strukturen zu entfernen. Eine weitere Frage: Wie sieht die Oberfläche des Druckobjektes aus, die auf den Suport-Strukturen gedruckt wurde ? Bei mir ist es keine geschlossene Oberfläche sondern es sind Filamentfäden, die erst in der nächsten Druckschicht eine geschlossene Fläche bilden. In den Druckeinstellungen konnte ich hierzu nichts verbesserndes finden, um das zu ändern. Der GCode wird mit dem PrusaSlicer 2.30 (Linux) erstellt.

Die Bohrung nicht als Presspassung auszulegen ist sicherlich richtig und wichtig, denn Klebungen haben ein sehr großes Problem mit Kräften, die rechtwinklig zur Klebefläche auf die Klebefläche einwirken. Auch wenn es nicht ganz original ist, könnte es hälfen, einen Art Ringschelle an den Enden zu installieren (wie eine Überwurfmuter), welche die Kräfte beim Drehen aufnimmt und so an dieser Stelle die beiden Hälften zusammenhält und am spalten hindert. Auf die schnelle kann ich leider keine Zeichnung oder ähnliches zur Verdeutlichung anbieten - aber mit etwas Kopfkino sollte es gehen...