Hallo zero K,
danke für deine Antwort.

Natürlich kann nur Derjenige eine Auskunft geben, wo meine genannten Bedingungen erfüllt.
Das Forum hier ist groß und ich vermute, der Fehler bezieht sich rein auf Simplify 3D,
vermutlich ist es sogar egal welcher Drucker mit S3D betrieben wird.
Nur muss dieser halt mit S3d direkt über USB betrieben werden.

Die Lösung mit dem Raspberry Pi ist sicher nicht schlecht.
Auf Live Preview Tracking in der Slicervorschau, möchte ich jedoch nicht verzichten müssen.

Der einzige Wermutstropfen ist, wenn ich einen Doppelklick auf den Button Verbinden/Trennen mache,
verhält sich S3D, als hätte ich den Not Aus gedrückt und zwar ohne Verzögerung!

Mit dieser Erkenntnis traue ich mich wenigsten S3D in der aktuellen Version weiter zu betreiben.

Eine Industrieanlage ohne Not Stopp, wird in der Regel sofort stillgelegt.

LG AtlonXP

Ich habe mit Simplify noch nichts gemacht, aber bei Repetier-Host gibts mehrere Notstopp-Strategien. Will das hier mal notiert haben. Evtl. kannst du, AtlonXP, dasselbe Verhalten wie beim neuen Simplify auch reproduzieren, wenn du hier "Nur Notstopp senden" auswählst.

Repetier war nicht untätig, was das Problem mit der Abarbeitung der Warteschleife angeht:
https://github.com/repetier/Repetier-Fi ... 716cf86e13
Dieser Commit zeigt, dass alle reinkommenden Daten vorausgewertet werden können, sodass ein M112 bearbeitet werden kann obwohl die Warteschleife für Befehle aktuell voll ist.

Ich habe das aber doch nicht in den Mod reingebaut, weil es Ram kostet und eigentlich ist bei mir in einem Notfall der Reset-Knopf zuständig. Wenn ich merke, die Achse fährt an die Wand (Manuelle Bewegung ohne Homing) so ist entweder schon alles vorbei bis ich es begriffen habe oder ich habe den Notknopf erwischt.
Maus packen, Tabs wechseln und den Knopf finden geht garnicht

Selbst den Notknopf brauche ich eigentlich nur zum Entwickeln oder um den Drucker abzuschalten.

Die beste Lösung dafür wäre rausfinden was Simplify3D anders/falsch macht und dann bei denen ins Forum posten. Oder den Support kontaktieren.

LG

Guten Morgen,

Gestern ist mir beim Z-Offsetscan ein Problem aufgefallen,
Und zwar habe ich die Einstellschraube zu wenig nach unten gestellt und bin somit auf das limit 0,80 gekommen.

Dabei bleibt der scan einfach stehen und ich wollte manuell die z-achse herunter fahren doch nach einen ruck hinunter kam ein ruck nach oben das die Düse schon leicht das heatbed gebogen hat. Dann blieb der Drucker stehen mit der Meldung Z min Limit oder so.

Ich hab die 1.43.20.

Lg nikibalboa

Hallo nikibalboa,
deine Angabe 0,8 mm sollten das nicht -0,8 mm sein?
Wenn ich mich recht entsinne, du fräst auch mit deinem RF?
Könnte da noch etwas mit reingespielt haben.
Zwei Z Endschalterbetrieb?
Ist der Drucker vielleicht im Fräsmodus gestanden?

Ich habe den Verdacht, der Drucker wollte den Z Endschalter frei fahren.
Vielleicht in die falsche Richtung, das tut er dann aber ganz langsam,
das Motorgeräusch hört sich auch etwas anders an.

Ich hoffe, Nibbels hat nach Beantwortung meiner Fragen es etwas leichter zu suchen.
Ich benutze die gleiche FW Version.

Hier noch eine Info an Nibbels:
Meine Endschalter Hysterese ist bei mir zurückgestellt in der FW.

LG AtlonXP

Sorry genau - 0,8, nein mein Drucker war nicht im Fräs Betrieb und meine Z-Schalter sind single und nicht circuit geschalten. Ich hab einfach meine z-achse etwas geschrumpft. Im circuit Betrieb gibts einige Probleme.

Der Motor ist nicht langsam gefahren sondern hat einen schnellen Sprung ins minus gemacht.

Ohne hotend könnte man das Verhalten reproduzieren.

Lg nikibalboa

nikibalboa hat geschrieben:Guten Morgen,

Gestern ist mir beim Z-Offsetscan ein Problem aufgefallen,
Und zwar habe ich die Einstellschraube zu wenig nach unten gestellt und bin somit auf das limit 0,80 gekommen.

Dabei bleibt der scan einfach stehen und ich wollte manuell die z-achse herunter fahren doch nach einen ruck hinunter kam ein ruck nach oben das die Düse schon leicht das heatbed gebogen hat. Dann blieb der Drucker stehen mit der Meldung Z min Limit oder so.

Ich hab die 1.43.20.

Lg nikibalboa

Ich schaus mir zeitnah an.
Auf die Idee, dass jemand mit dem Positionsmenü spielen könnte kam ich bisher nicht.
Es kann gut sein, dass du ins Direct-Stepping gerutscht bist und über das zweite Koordinatensystem das Minus-Limit umgangen hast. Ist aber nur ein erster Verdacht. Dürfte aber eigentlich auch nicht vorkommen.
-> Positionsmenü/Z-Buttons während einem Scan muss verboten sein.
-> Der Z-Offset-Scan und auch jeder andere Scan muss bei überschreiten der Grenze sofort sauber abbrechen.

EDIT: Ja, also dass ich für Z-Steps über Button/Menü die GCode und Direct-Koordinaten frage ist in meiner aktuellen Experimental-Development Version schon seit ein paar Versionen rausgeflogen. Bleibt noch, dass wir das Positionsmenü generell während aller Scans verbieten müssen.

AtlonXP hat geschrieben: Hier noch eine Info an Nibbels:
Meine Endschalter Hysterese ist bei mir zurückgestellt in der FW.

LG AtlonXP

Das heißt, der Matrix-Scan funktioniert nun mit den Patches zuverlässiger?

Nibbels hat geschrieben: Das heißt, der Matrix-Scan funktioniert nun mit den Patches zuverlässiger?

Nun ich mache das nicht jeden Tag.

Bis jetzt kann ich nichts mehr an dem Scann beanstanden.
Das Freifahren macht er so wie ich es eingestellt habe (0,3 mm).
Eine Wiederholung habe ich nicht mehr bemerkt, ich war aber nicht die ganze Zeit anwesend.
Meine Endschalter Hysterese ist auf 0,1 mm eingestellt.
Scheint alles zu funzen.

LG AtlonXP

@Nibbels,
baue bitte zum Output Befehl unbedingt noch (davor) M3000 in unsere FW mit ein.

Wenn man so wie ich mit -8,0 mm im Keller den Druck beginnt, herrscht Kollisionsgefahr
bei Output Objekt, wenn das Druckteil eine kritische Druckhöhe erreicht.

Konkret Z Fahrweg max. 190 mm ist bei mir in der FW definiert.
Erster Layer beginnt bei Z -8,0 mm im Keller.

Die kritische Höhe beginnt bei Druckteilen grösser als 182 mm, weil die Z Kompensation noch eingeschaltet ist!
Im Moment schalte ich diese im Endscript vor Output Objekt ab.

LG AtlonXP

AtlonXP hat geschrieben:@Nibbels,
baue bitte zum Output Befehl unbedingt noch (davor) M3000 in unsere FW mit ein.

Wenn man so wie ich mit -8,0 mm im Keller den Druck beginnt, herrscht Kollisionsgefahr
bei Output Objekt, wenn das Druckteil eine kritische Druckhöhe erreicht.

Konkret Z Fahrweg max. 190 mm ist bei mir in der FW definiert.
Erster Layer beginnt bei Z -8,0 mm im Keller.

Die kritische Höhe beginnt bei Druckteilen grösser als 182 mm, weil die Z Kompensation noch eingeschaltet ist!
Im Moment schalte ich diese im Endscript vor Output Objekt ab.

LG AtlonXP

Da muss ich noch prüfen, ob das am Ende mit meinem ganzen neuen Soft-Endstop-System nicht doch auf exakt dasselbe rauskommt.
Ich hab seit Sylvester extrem viel umgebaut und richtig radikal ausgemistet.
Das ist auch der Grund, warum ich nun alles so genau neu testen muss.

Zum Problem von nikibalboa:
Ab der 1.43.40
https://github.com/Nibbels/Repetier-Fir ... log.txt#L9
(Aktuell leider noch nicht zu empfehlen, obwohl sie druckt und ich im Moment keine Fehler kenne)
... ist der Fehler raus. Da waren zwei Stellen an denen geprüft wurde. Eine hat den Scan nicht richtig abgebrochen.

Ab der Version haben wir für alle Scan-Typen die abbrechen eine Display-Meldung eingebaut,
die genau sagt, warum abgebrochen wurde.
https://github.com/Nibbels/Repetier-Fir ... .cpp#L3589
Das ist unter Umständen extrem praktisch, weil der Drucker für manche Fehler die Lösung direkt ins Display posten kann. Wer mit dem Fehler hier im Forum ankommt hat es einfacher als mit dem Titel "HBS bricht ab"

LG

Guten Abend

Unsere Stable und Development auf https://github.com/RF1000community/Repetier-Firmware ist in Version 1.43.20.
Ich habe jetzt eine ganze Weile groß umgebaut. Einige von euch haben sich darum schon von meinem eigenen Github https://github.com/Nibbels/Repetier-Firmware eine Version größer .20 gezogen.

Diese Höher-1.43.20.Mod-Experimentierer will ich gerne auf mindestens 1.43.68 updaten lassen. Ich drucke aktuell fleißig und teste alles mögliche, aber wenn ich noch weitere eventuell übrige Fehler eliminieren kann, weil mir diese jemand zeigt, dann ist das super.

Vorsicht Fräsen:
Alle die fräsen wollen, sollten sicherheitshalber noch eine Version 1.43.20 nutzen. Testen sehr sehr gerne, aber bitte nicht annehmen, dass alle Fräs-Funktionen ordnungsgemäß funktionieren müssen. Es wurde zu viel verändert, um das ohne Testing zu empfehlen. Wenn mir allerdings jemand genau sagen kann, dass mit Version 1.43.68+ dieses oder jenes nicht mehr funktioniert, hilft mir das.
Was ich für Fräser bisher eingebaut habe ist eine Geschwindigkeits-Anzeige im Menü 3. Der Rest steht noch aus. Es fehlt z.B. noch, dass man beim im Fräs-Modus mit den Extrudiertasten die Geschwindigkeit ändern kann. Das ist fest im Plan.

Etwas vorsicht bei Dualdruck.
Dual-Druck konnte ich bisher nicht testen - nur den Extruderwechsel.

Changelog: https://github.com/Nibbels/Repetier-Fir ... ngelog.txt
Vorläufiger Pull-Request mit DIff: https://github.com/RF1000community/Repe ... /188/files

LG