Community Mod RFx000 Firmware :: Neue Stable (Stand 1.42.03 / 28.07.2018)

[AtlonXP]

Danke Nibbels für die neue FW, das sieht interessant aus.

Was gibts noch?

Ich hoffe, dass uns nicht irgendwann die Systemzeit im Drucker ausgeht.

LG AtlonXP

[Nibbels]

Guten Abend,

Ein wichtiges Wort zu den Versionen 01.42.17.Mod bis inklusive 01.42.21.Mod.
Mit Version 1.42.17 hatte sich ein kritischer Bug eingeschlichen, als ich einen anderen eliminiert hatte. Dabei gings um das "Heater Decoupled Test", der unter manchen Umständen nicht funktionieren könnte.
Man sollte alle diese Drucker auf mindestens Version 1.42.22 upgraden.

LG

[AtlonXP]

Hallo zusammen,

hier eine Störmeldung:

In der Betriebsart USB auf Drucker fährt der Drucker bei einem Software Not Aus einfach weiter.
Die USB Verbindung wird von S3D unterbrochen doch der Drucker fährt noch seinen Puffer leer.

Es handelt sich hier um die FW 1.42.22

Ich kann diese FW Version nicht weiter empfehlen.
Kann jemand diese Störung bestätigen?

LG AtlonXP

[Nibbels]

Wenn das so ist, dann ist das schon länger so.
Kannst du rausfinden, ob wirklich M112 als Reset benutzt wird?
Das müsstest du in den logs sehen.

M112 müsste eigentlich den Drucker ausserhalb der Reihe in eine While(1) Schleife schicken. Dann greift der Watchdog.

Das ist zumindest Sollverhalten.
Bin nicht daheim, meine Tests können also dauern.

LG

[zero K]

Guten Morgen AthlonXP

Im Moment bin ich mir nicht ganz sicher, was Du meinst ...

Stop-Befehle (M112) oder auch die Buttons im GUI über Software begehen einen vergleichsweise langen Weg.
Hier müsste wohl nach jedem Gcode eine Abfrage stattfinden, ob ein Stop-Befehl anliegt.
Ich glaube, parallel ohne den Druckprozess zu behindern, das kann der kleine Rechner nicht.

In sofern kann ich Deine Beobachtung bestätigen.

Die RFs die auch als Zerspaner umgerüstet werden können haben einen echten Notaus-Schalter.
Beim RF2000 v2 funktioniert der sehr gut.
Die Zahnriemen-Achsen sind sofort entspannt aber eine Hand in der Z-Achse könnte im worst case an der Flucht gehindert werden.

Oh ich habe sehr lange getextet.
Nibbels ist online . der erfasst das viel besser ....

Gruß zero K

[AtlonXP]

Guten Morgen zero K,

Stop-Befehle (M112) oder auch die Buttons im GUI über Software begehen einen vergleichsweise langen Weg.
Hier müsste wohl nach jedem Gcode eine Abfrage stattfinden, ob ein Stop-Befehl anliegt.
Ich glaube, parallel ohne den Druckprozess zu behindern, das kann der kleine Rechner nicht.

Vermutlich ist es der M112 Befehl, ich weiß es nicht.
Auf jeden Fall ging der Drucker sofort in den Reset.
Das funktionierte die ganze Zeit auch in unserer MOD FW.
Ich bin es nicht anders gewohnt.

Ob der Drucker den letzten (aktuellen) Fahrbefehl zu Ende führt und dann erst in den Reset ging,
da bin ich mir nicht sicher. (Ich glaube aber, der ging sofort in den Reset).
Der RF1000 hat ansonsten keinen Not Aus und ich schätze viele benutzen deshalb diesen auf der Sliceroberfläche.

Wir können es uns nicht leisten in dieser Sicherheitsfunktion schlechter zu sein wie in der originalen FW.
Mir scheint auch ein Verbindungsaufbau der USB Leitung hakelt nun auch,
der Drucker geht 2 x in Reset bis die Verbindung endlich steht.

Kurz um: Ich schätze Nibbels hat da eine Drahtbrücke vergessen in der Software.

LG AtlonXP

[zero K]

Nun wollte ich es wissen ....

Also, ich habe gerade mal den Druckkopf veranlasst mehrfach schnell von 0 bis 170 bis 0 zu fahren.
Der M112 über die Komandozeile im GUI des Repetierservers funktionierte erwartungsgemäß sehr verzögert.

Der "Notstop" im Dropdownmenü funktionierte sofort.
Vielleicht auch altersbedingt konnte ich keine Verzögerung feststellen.
Der Drucker wurde sofort wieder neu gestartet, sichtbar an der Bootsequenz im Display.
Nach einem Homing war er dann auch sofort wieder einsatzbereit.


Da könnte man direkt mal schauen, ob die Erfinder des Repetierservers dafür erreichbar sind, einen Notausbutton etwas exponierter oder besser auf jeder Seite anzubringen.

Gruß zero K

[Nibbels]

Klar, das machen wir möglich!

Ich teste normalerweise M112 nie im laufenden Betrieb, nur mein eigenes universelles Stopprint.

Es ist halt auch so: Die daten landen im puffer. Und erst, wenn ein platz in der Warteschleife frei wird wird von dort weitergelesen.

In Echtzeit wird ein Reset nur klappen, wenn man an der COM der DTR(?) einmal runterzieht.

Lg

[zero K]

Na ja -aus der Laborpraxis und wegen unserer Kiddies, die glänzende Augen so groß wie Untertassen bekommen wenn sich etwas bewegt und ein Teil Gestalt gewinnt, achte ich etwas auf Gefährdung und Sicherheit.

Daher ist es mir auch völlig unverständlich, dass Conrad die großen RFs mit den Gefahren des Z-Antriebes so lange ohne Eingriffsicherung lassen kann.
Die Katalogangabe "für Industrie" ist da sehr bedenklich, denn nach Maschinenrichtline kann das Gerät im gewerblichen Umfeld kaum zugelassen werden.

[AtlonXP]

So Leute, da ist noch was anderes!

Ich hatte in meiner Kritik nicht erwähnt dass ich auch ein Update von S3D auf Version 4.0.1 gemacht habe.
Der Wurm steckt hier in S3D!

Um Klarheit zu schaffen, wenn ich in diesem Bild den Emergency Stop Button drücke,
dann reagiert der Drucker nicht wie in der S3D Version 4.0.0

Das Reset Signal wird laut Log. als M112 an den Drucker geschickt und wird leider erst verzögert verarbeitet!
Der Drucker bleibt danach, wie auf dem Bild so stehen.
Anschließend muss man die USB Verbindung nochmals von Hand dazu betätigen, damit diese sich wieder aufbaut.

Bild:

S3D.png

Wenn ich aber in der Konsole M112 von Hand verschicke, dann reagiert der Drucker so wie ich es gewohnt bin.
Die Verbindung wird dabei dann auch automatisch wieder aufgebaut.
Danach Nibbels Idiotenknopf und der Drucker kann ohne Homing von Hand frei gefahren werden.
So bin ich es gewohnt.

Im Druckbetrieb habe ich den sofortigen Halt noch nicht getestet,
aber da der Drucker sofort in den Reset geht, müßte alles dort in Ordung sein.

Oh man, wenn ich wo hinlange, dann ist dort nur Scheiße!

LG AtlonXP