Damit nicht immer ihr zwei im Thread diskutiert ...

mhier hat geschrieben:

RF1000 hat geschrieben:tatsächlich ist es weiterhin so, dass Z_OVERRIDE_MAX nur bei G-Code zum Greifen kommt, der nach oben fahren will ... und das kommt beim Drucken ja eher nicht so oft vor.

Standardmäßig fahren die meisten Slicer erstmal von Heizbett weg, bevor sie mit dem Drucken anfangen...

Richtig. Vom Heizbett wegfahren heißt, dass das Bett nach unten fährt, nicht nach oben.

mhier hat geschrieben: RF1000 wrote:
Die Firmware funktioniert nicht nur "irgendwie".

Achso? Dann erlaube mir die Frage, wie viele RF1000-Neulinge auf Anhieb crashfrei und ohne Haftungsprobleme mehr als nur die Beispiele drucken können. Jetzt sag mir nicht, das wäre zu viel verlangt...

Ich würde gerne wissen wieviel 3D-Druck-Neulinge (egal welche Marke) KEINE Probleme mit der Haftung haben...

reini hat geschrieben: RF1000 wrote:
dann stellt die RF.01.31 sicher, dass die Höhe vom ersten Layer automatisch exakt dem entspricht, was der G-Code will.

Dann müsste ich ja nie manuell die Höhe nachjustieren... Stimmt also leider nicht.

mhier,
Wenn du bei Druckbeginn immer die Höhe nachjustierst (nachjustieren musst), hat das nicht zwangsläufig NUR mit dem Abstand Düse/Bett was zu tun. Da können andere Faktoren schuld sein oder zumindest mitspielen (Extrusion Multiplier, Kalibrierung, usw.).

...

reini hat geschrieben:Stichwort: Zuverlässigkeit. Dazu gehört, dass jeder mögliche Workflow funktioniert, dass jedes Verlassen irgendwelcher zulässigen Toleranzbereiche eine klare Fehlermeldung gibt, dass nicht in 1% der Fälle nach dem Homing das Bett plötzlich nach oben fährt, etc. Sorry, aber wenn du behauptest, die Firmware würde zuverlässig funktionieren, weißt du nicht was zuverlässig bedeutet. Sie tut es nicht. Was denkst du, warum ich ständig dabei bin, dir wieder irgendweche Bugs zu berichten? Die sind noch nicht alle gelöst offensichtlich!

mhier,
Könntest du das den Microsoft Leuten auch zukommen lassen. Die dürften einige Mitarbeiter/Programmierer mehr haben, die an Windows arbeiten - es wäre an der Zeit, dass ordentliche Fehlermeldungen kommen.
mjh11

reini,

reini hat geschrieben:....
Wie werden die einzelnen HBS abgespeichert? Mus ich da was drücken, oder Namen vergeben ? Oder geht das Automatisch, ich habe jetzt "Abtasten" einmal durchgeführt, jetzt will ich das nochmal mit meinen ABS Einstellungen machen, gehe ich nun wieder auf Abtasten und bei Erfolg ist das Automatisch die Nr2 ? Später beim Druck welchen GCode brauche ich um z.B. meinen ABS Scan wieder abzurufen?

Siehe hier. Analog für alle 9 möglichen Speicherstellen.

reini hat geschrieben:Oder besser, gibt es eine Art Bedienungsanleitung für die Firmware.

Sieh' mal nach unter GCodes. Da steht 98% von dem was man wissen sollte. In der Datei RF.h der Firmware sind auch viele brauchbare Beispiele der Syntax aufgelistet.


mjh11

rf1k_mjh11 hat geschrieben:Damit nicht immer ihr zwei im Thread diskutiert ...

mhier hat geschrieben:

RF1000 hat geschrieben:tatsächlich ist es weiterhin so, dass Z_OVERRIDE_MAX nur bei G-Code zum Greifen kommt, der nach oben fahren will ... und das kommt beim Drucken ja eher nicht so oft vor.

Standardmäßig fahren die meisten Slicer erstmal von Heizbett weg, bevor sie mit dem Drucken anfangen...

Richtig. Vom Heizbett wegfahren heißt, dass das Bett nach unten fährt, nicht nach oben.

Und danach dann wieder nach oben, sonst kann man ja nicht drucken...

rf1k_mjh11 hat geschrieben:Ich würde gerne wissen wieviel 3D-Druck-Neulinge (egal welche Marke) KEINE Probleme mit der Haftung haben...

Ist halt irgendwie traurig, wenn die Hardware es besser könnte, aber die Firmware nicht hinterher kommt. Es gibt sehr wohl Drucker, die ein deutlich besseres "Plug&Play"-Verhalten haben. Mir war das vorher klar, dass der RF1000 da nicht besonders gut ist, aber so extrem habe ich es nicht erwartet...

rf1k_mjh11 hat geschrieben:Wenn du bei Druckbeginn immer die Höhe nachjustierst (nachjustieren musst), hat das nicht zwangsläufig NUR mit dem Abstand Düse/Bett was zu tun. Da können andere Faktoren schuld sein oder zumindest mitspielen (Extrusion Multiplier, Kalibrierung, usw.).

Weiß ich. Bei mir stimmt aber klar der Abstand nicht. Auch das kann an vielen Faktoren liegen. Der entscheidende Punkt ist aber, dass das unlogische und unerwartete Verhalten bei nahezu allen "corner cases", von denen Conrad meint, im regulären Druck kommen die ja eh nicht vor, dazu führt, dass ich fast nicht debuggen kann...

rf1k_mjh11 hat geschrieben:Könntest du das den Microsoft Leuten auch zukommen lassen. Die dürften einige Mitarbeiter/Programmierer mehr haben, die an Windows arbeiten - es wäre an der Zeit, dass ordentliche Fehlermeldungen kommen.

Micro... wer? Mein Linux gibt mir meistens anständige Fehlermeldungen...

rf1k_mjh11 hat geschrieben:

Vertane Chance

---

Jetzt hätte ich für meinen tausendsten Beitrag was weltbewegendes schreiben sollen - scheiße! Chance vertan!

Herzlichen Glückwunsch zum 1000.!

Hallo zusammen

Wäre die Software durchschaubarer aufgebaut, könnten die User ggf. helfen Neuerungen zu implementieren oder Fehler zu finden.
Ich habe schon C- und Assembler Programme geschrieben, es macht aber keinen Spaß durch den Code zu suchen.
So bleibt die Verantwortung beim großen "C".

Solange die Software noch "Development" ist bleibt die alte drauf!
Vielen Dank für die Sisyphusarbeit den Code zu analysieren und die Fehler zu finden an alle hier im Forum.

Die größten Schäden sind bei mir bis jetzt durch Testen der neusten Software passiert.

Früher am einer 20-Fach CNC Fräsmaschine gearbeitet für mehrere 100000 DM ohne je einen Crash zu haben und hier reicht ein Heatbed-Scan.

Gruß Frank

RFrank,

RFrank hat geschrieben:....
Früher am einer 20-Fach CNC Fräsmaschine gearbeitet für mehrere 100000 DM ohne je einen Crash zu haben und hier reicht ein Heatbed-Scan.

Ich glaube, hier sieht man auch, wieso die Maschine mehrere 100000 DM gekostet hat.

mjh11

RFrank hat geschrieben: Wäre die Software durchschaubarer aufgebaut, könnten die User ggf. helfen Neuerungen zu implementieren oder Fehler zu finden.
Ich habe schon C- und Assembler Programme geschrieben, es macht aber keinen Spaß durch den Code zu suchen.
So bleibt die Verantwortung beim großen "C".

Ich hatte ja bereits mal den Verdacht geäußert, dass dies seitens vom C oder CTC auch garnicht erwünscht ist...

rf1k_mjh11 hat geschrieben:RFrank,

RFrank hat geschrieben:....
Früher am einer 20-Fach CNC Fräsmaschine gearbeitet für mehrere 100000 DM ohne je einen Crash zu haben und hier reicht ein Heatbed-Scan.

Ich glaube, hier sieht man auch, wieso die Maschine mehrere 100000 DM gekostet hat.

mjh11

Das ist nicht der Punkt, es gibt hunterdtausend open source Projekte die es besser können, weil man die Nutzer integriert und die gesammelten Kenntnisse der Community zu nutzen macht, anstatt sich gegen diese abzuschotten, Eigenarbeiten zu erschweren und ein nebulöses Gremium über den weiteren Ausbau entscheiden zu lassen.

Ursprünglich habe ich den RF1000 ja genau deswegen gekauft, weil ich in ihm eine ausbaufähige Plattform gesehen habe. Heute bin ich weit von dem Punkt entfernt ihn nochmal zu kaufen, viel näher stehe ich derzeit am Scheideweg.

Hallo allerseits,

nach monatelanger Abstinenz wegen Umzugs habe ich eben meinen RF1000 hervorgeholt und versucht die neue Firmware
zu compilieren, leider ohne Erfolg. Es kam eine riesenlange Latte mit Fehlermeldungen (Arduino 1.6.9 ist auch
neu installiert worden, Board-Einstellungen natürlich auch korrekt vorgenommen). Er crashed schon in Zeile 114 #define MISO_PIN usw...

Was mache ich falsch?

Danke für jeden Tipp!
Peter

Hallo Peter,


die aktuellen Sourcen müssen mit V 1.6.5 von Arduino kompiliert werden.


mfG
RF1000

Danke für den Tipp. Nun meckert er zwar, dass er wenig Speicher habe, läuft aber durch.
Herzlichen Dank!

Gruß
Peter

P.S.: Ist aber auch doof, dass die Arduino's nicht abwärtskompatibel sind....