Hallo,
Um den Düsenoffset zum Sensor zu bestimmen möchte ich die Z-Achse ins Minus fahren können.
Wo ist denn das blockiert?
Der Trick der hier irgendwo steht, Z-home ausführen, dann g92 Z+10 und dann runterfahren geht definitv nicht. Die Achse rührt sich kein µ ins Minus.
Mit Babysteps runterfahren geht zwar, aber mit M114 gibts keine aktuelle Position. Man müßte mitzählen, was mir zu primitiv, mühsam und überhaupt nicht state of the art ist.
Notfalls könnte man ja irgendwo in der software eingreifen, und da auch gleich den Homing-routinen vernünftige Algorithmen verpassen.
Ich frag hier nur mal, weil sicher jemand weiß wo das steht.
Gruß und danke.

---

PrusaI3 Bausatz
Repetierhost 0.95F Ramps1.4 gepimpt

[marlinfw.org]
[marlinfw.org]

Herzl. Grüße

Danke,

aber geht alles nicht !
hab repetier 0.95 FW !

Ich will definitv runterfahren und angezeigt kriegen z-0,1.. z -0,2 ...
und nicht durch irgendwelche M oder G code manipulationen rumtricksen müssen.
d.h. die wahre z-position muß sich ins Minus fahren lassen.

Dann könnte man noch nen MCODE XXX erfinden, der den gefundenen Wert gleich ins Z_PROBE_HEIGHT schreibt.
Kern dürfte driver.h sein,


Hab da schon mal das hier rausgenommen:

void gotoPosition(float newPos)
{
bool up = true;
/* Kill 0-Limit
if(newPos < 0)
newPos = 0;
*/
if(newPos > maxDistance)
newPos = maxDistance;
enable();


Reicht aber nicht fährt nicht ins Minus

Irgendwo wird newPos vorher schon abgefangen
muß noch suchen....

Status ist somit der:

Bei Position X/Y 0/0 steht der Sensor im Leeren.
Ich hab den Abstand der Düse zum Triggerpunkt des Sensors ausgetüftelt und bei Z_PROBE_HEIGHT eingetragen. Alle Versuche den Düsenoffset irgendwoanders einzutragen werden ignoriert,

Beim Homing fährt er brav die Sensoroffsets in X und Y an fährt dann aber (wenn vorher schon gehomt war) nicht weit genug hoch, um den Sensor aus dem Schaltbereich zu fahren.
D.h.das homing ist dann für ihn erledigt, in Wirklichkeit aber üngültig. Offensichtlich fährt er nur den Z_PROBE_HEIGHT - Wert hoch.
Z_HOME_PRERAISE_Distance führt er zwar aus, aber fährt sofort wieder runter bevor er die Sensor Position anfährt

D.h. ich müßte den von mit ausgemessenen Düsenoffset irgendwo anders eintragen, und für Z_PROBE_HEIGHT einen Wert setzen, der den Sensor sicher aus dem Schaltbereich hebt.
Nur fährt er ja blöderweise genau diesen Wert nach dem Nullen runter, was also ein Crash gibt.

Bin momentan zu dumm dafür

gruß

1-mal bearbeitet. Zuletzt am 31.07.18 05:17.

... du kannst meist in der Firmware die Referenzposition "irgendwo" definieren - wenn er die Z-Referenzposition anfährt, hat er dann z.B. statt Z=0 eben Z= -50mm -- dann fährt er bei G0 X0 Y0 Z0 also 50mm nach Oben und kann von da aus (auch bei aktiven Softlimits) in Z bis auf -50mm runterfahren ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

... du kannst auch jederzeit z.B. mit "G92 Z-30" die aktuelle Z-Koordinate auf -30mm setzen - dann geht das auch mal schnell auszutesten

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Genau das geht nicht
Um runterzufahren müßte ich g92 z+3 machen.
setzt er auch ,aber kann trotzdem nicht runterfahren, weil die wahre z-Position 0 ist.
Schon probiert? Bei mir gehts nicht !

kann es sein, dass deine Z-Probe aktiviert ist und sich die Achse deshalb nicht bewegt?

---

Drucker: 3D-Cube Eigenentwicklung, Ender3

Quote
netsnake
Beim Homing fährt er brav die Sensoroffsets in X und Y an fährt dann aber (wenn vorher schon gehomt war) nicht weit genug hoch, um den Sensor aus dem Schaltbereich zu fahren.
D.h.das homing ist dann für ihn erledigt, in Wirklichkeit aber üngültig. Offensichtlich fährt er nur den Z_PROBE_HEIGHT - Wert hoch

Das ist doch nicht so,
#define ENDSTOP_Z_BACK_MOVE 5 war auf 2 gesetzt, er fährt diesen Wert (jetzt "5") vor dem Homing an.
Soweit alles gut. Die ganze PRERAISE-Fummelei hab ich weg gemacht.
Geht jetzt einigermaßen. Bed-Autoleveling brauch ich sowieso nicht, das Bett muß mechanisch stimmen, alles andere ist Unfug.

von mir aus thread schließen,auf die "in Minus fahren Problematik" gibts hier wohl keine Lösung. Muß mal bei Repetier anfragen,falls es mal möglich sein sollte nach gefühlten 120 captcha Bildern einen Account zu machen.

Danke und schöne Grüße

Hi netsnake,
es geht generell nicht über die vorgegebenen Referenzpunkte zu fahren, weder ins Plus noch ins Minus, das geht bei keiner Maschine.

Einfaches Beispiel eine Maschine hat eine Max-Position von 2000, beim überspielen der Software, oder Programmierfehler, wie auch immer,
steht da dann 20000, dann möchte ich nicht in der Nähe einer großen Werzeugmaschine stehen.

Man kann den Z-Versatz nur über den G-Code ändern (vor dem Homing), oder wie in meinem Fall, am Drucker selbst verstellen.
Damit kann man auch den 0-Punkt für Z (den Z-Versatz) ermitteln.

Es ist halt für dich keine befriedigende Lösung, aber es ist so.

Wenn du eine Lösung hast (Repetier), kannst du sie ja Posten.

---

Gruß,
Michael

Acrylic I3 / Arduino Mega 2560 R3 / RAMPS 1.4 / 12864 LCD mit Wlan-SD Karte / TMC2100 / MK8 m. Bowden / 5mm DDP (PEI) / Tr8x4 / Mosfet 30A / Marlin-1.1.8 / Repetier-Host. / PrusaSlicer-2.3.0
In Planung, Ultimaker-Kinematic mit Kugellagern und 30X30 Profilen
LCD mit Wlan-SD Karte -- Mein I3 u. leise Y-Achse mit Mittelmotor

Hallo der Befehl G1 S1 Z-1 sollte es erlauben ins Minus zu fahren, dabei werden Softwarelimits nicht beachtet. Danach wieder ein G1 S0 senden.

1-mal bearbeitet. Zuletzt am 01.08.18 02:36.

---

Drucker: 3D-Cube Eigenentwicklung, Ender3

@printey, das ist allgemein nicht richtig.

Ich hab hier z.B. eine programmierbare Endstufe von Nanotec. Diese unterscheidet zwischen Endstop und Referenzpunkt. Der Referenzpunkt kann dort immer überfahren werden. Dient aber auch zum Einstellen der Nullposition.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.