Posts made by izeman

I'm trying to track down the issue, by calling G28, G32, M40[12] etc in all different combinations, and it seems there is something wrong with M40[12].

The probe is not attached, and I call M401. It picks up the probe, Z-Probe shows 0 in the webfrontend, but still the scripts spits out:

M401
Error probe not attached - aborting

after it has picked up the probe, and z-Probe clearly IS ZERO.

This is my deployprobe.g

; The deploy command for Z when using a dockable probe
M564 H0 S0
if sensors.probes[0].value[0] != 0
    var originX = {move.axes[0].userPosition} ; Store the X position before grabbing the probe.
    var originY = {move.axes[1].userPosition} ; Store the Y position before grabbing the probe.
    G1 X6.500 Y193.000 F999999 ; Move tool in front of dock
    G1 X6.500 Y243.000  F999999 ; Move tool in position where probe is mounted
    G1 X6.500 Y193.000 F999999 ; Move tool in front of dock
    if var.originX > 6.500 || var.originY > 193.000  ; Move the toolhead back to the position we came from
        G1 X{var.originX} Y{var.originY} F999999
        M400
if sensors.probes[0].value[0] != 0
    abort "Error probe not attached - aborting"

Do I maybe need some delay in the script?

EDIT: If I remove these the last two lines from the script (the ones checking for senors.probe.value unequal 0, then everything works.

@dc42 said in Issue with Klicky probe and independant z-Axis:

@izeman said in Issue with Klicky probe and independant z-Axis:

And then it will start by picking up the probe by M401, NOTE/REMEMBER that during the whole macro, until it's put back manually by M402 again?!

Yes, that's how it should work. RRF maintains a count how many times the probe was asked to be deployed, either explicitly by M401 or implicitly by G30. When it is asked to retract the probe it decrements that count, and only does the retraction if the count has reached zero.

Tested it now back home. As you said: it SHOULD work that way. Unfortunately it doesn't. Calling G32 with the Klicky already attached it does work.

Calling it with Klicky DETACHED (the default situation), then it DEPLOYS the probe, and stops with the message

G32
Error probe not attached - aborting

Even though it IS ATTACHED when it send that message.

It seems RRF does NOT know all the time if the probe is attached?! Does it RESET the attached/detached state by itself if it detaches the probe by itself? Or do I always need to have M401 be followed by M402?

@DIY-O-Sphere said in Issue with Klicky probe and independant z-Axis:

@izeman
https://forum.duet3d.com/topic/33529/euclid-probe-unnecessary-docking

Thanks @DIY-O-Sphere. So this says that, if my bed.g should look like this, and it will work?

M401 ; deploy probe
M561 ; cancels any bed-plane fitting
G28 ; home
 while true
    G30 P0 X20 Y135 Z-99999 ; probe near a leadscrew, half way along Y axis
    G30 P1 X235 Y135 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors
    if abs(move.calibration.initial.deviation) < 0.01 || iterations > 3
        break
M402 ; retract probe

And then it will start by picking up the probe by M401, NOTE/REMEMBER that during the whole macro, until it's put back manually by M402 again?!

I post this here for documentation issues, as I hate forum posts that have been solved, but the OP forgot to post the final solution

I got my klicky probe working. It picks up fine and retracts it after use.
I can do a homing, it homes X, Y, then goes to the middle of the bed, goes to the pickup location of the Klicky, picks it up, moved back to the middle of the bed, then probes Z, goes to Klicky retract position, retracts it, and then moves in the front of the Klicky pickup position and waits there.

BUT if I want to use it for independent Z-axis, i does homing first (G28), then DROPS off/RETRACTS the Klicky, picks it up again, and then stops. This RETRACT seems to confuse the following G30 command with error: "Error probe not attached - aborting", where as it already is attached again, but maybe too late.

Anything I can do about it? Like stopping G28 from retracting the probe after it's done probing Z in the middle of the bed?

G28 ; home
; while true
    G30 P0 X20 Y135 Z-99999 ; probe near a leadscrew, half way along Y axis
    G30 P1 X235 Y135 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors
    if abs(move.calibration.initial.deviation) < 0.01 || iterations > 3
        break

M584 X0 Y1 Z2:4 E3          ; set drive mapping Dual Z-Axis
M671 X-40:290 Y135:135 S4   ;Set the Z motor relative locations

Manually running the two G30 command from the console works fine.

Two ways to deal with it.

• Change the M208 settings so the max values correspond to the actual physical position when the endstop sensor is triggered

• Use G92 to adjust the logical X and/or Y position so the position at the center is correct. Put the G92 in the homing file of X and/or Y with the values needed to obtain the correct center position. One way to do this is have a G1 command at the end of the homing file with the value needed to move to the center and then have a G92 command with 0 as its value to set the logical position to 0, thus matching the physical position. For example in homeX.g you might have: G90 G1 Xnnn G92 X0

Two issues with that:

So instead of saying I can move 250/250 I tell the printer it can only move 250-10/250-15? It's not easy to find the "real" 0/0 when you're homing at some random 250/250 (which in reality could be 248/251 or something else) and then re-iterate from there where your real "0/0" is. Isn't it?

When I use G92 to move the working coordinates I have the issue that it can't pick up the klicky probe after homing again as it's location has change then ...

@DIY-O-Sphere said in Please help understanding coordinated (bed, nozzle, ABl, ....):

@izeman
Please note:
The homing files have to be adapted as well.
Otherwise the print head will move in the wrong direction during the homing process

Yeah. Just noted that It seems to work now. I guess ... Just running a full ABL with 20mm grid.

I just seems that my 0/0 now is like 10mm to the left and 15mm to the front of the print bed. Looks good. But when I move to the center of the bed 117/117 it moves to that number away from the real 0/0 (movement maximum) and not to the real center which should be 117+10/117+15.

@OwenD WORKS GREAT now!! Thanks a lot!!!

@fcwilt said in Please help understanding coordinated (bed, nozzle, ABl, ....):

Ok. So my endswitches are in the back right corner. So all HIGH/MAX. So basically I can check what total movement I can have in X&Y and set this like:

M208 X0:total movement Y0:total movement

and then use G10 for axis offset to set the nozzle to the front left corner for 0/0?

No need for G10 assuming your M574 specifies that endstop sensors are at the high end of each axis.

With back/right being Xmax/Ymax then front/left will be Xmin/Ymin.

Frederick

I'm totally GAGA. There must be some knot in my brain. Sorry to act that stupidly.

I now updated my config to move 0/0 to left/front. Bed is 235/235. The head can move 250 in both directions. What would I set my config to?

@izeman
Did you set some tool's offset?
Bercause You have to consider those, too, for the coordinates.

But basically the movement is considered from (0, 0), then it can go to negative coordinates; so, let's say (20, 20), is 20mm X and 20mm Y from where you set your (0, 0)

No tool's offset yet. I just try to get the axis/bed configured correctly first. At least that was what I was hoping for. I now have tool homed at 250/250, but can't move away from there, as moving the head to 0-249 makes it go to 250+. Direction of the axes is reversed. Even though they home correctly.

@Mr-Yod said in Please help understanding coordinated (bed, nozzle, ABl, ....):

@dc42
Aren't those just rotated axis?

If you rotate the image 180° you'll get the axis that are normally used.
Now, if I think about mirroring the image along X and then do the same along Y I'll get the same as rotating it 180°.

I think you are correct. If you change ONE axis from front/back or left/right then it get's mirrored. If you change both it get rotated.

@fcwilt said in Please help understanding coordinated (bed, nozzle, ABl, ....):

@izeman said in Please help understanding coordinated (bed, nozzle, ABl, ....):

@fcwilt tbh this makes it even more confusing. And what I miss in all documention I‘ve seen is the reference system.

All good! Not your fault that I'm confused. I just got issues when it comes to this kind of things. I'm better in other things

Ok. So my endswitches are in the back right corner. So all HIGH/MAX. So basically I can check what total movement I can have in X&Y and set this like:

M208 X0:total movement Y0:total movement

and then use G10 for axis offset to set the nozzle to the front left corner for 0/0?

@fcwilt tbh this makes it even more confusing. And what I miss in all documention I‘ve seen is the reference system.

My head can always move to the endswitches. So in your case that would mean i have to use 0/0 as minimum. But that can’t be true.

@dc42 I now try to follow your advise and move 0/0 to front/left, which is pretty hard as I need to change a LOT of parameters. First one is "homing positions"

; Axis Limits
M208 X235 Y235 Z200 S0 ; set axis maxima and high homing switch positions (adjust to suit your machine)
M208 X-10 Y5 Z-0.5 S1   ; set axis minima and low homing switch positions (adjust to make X=0 and Y=0 the edges of the bed)

Would that be correct? I can't see anywhere in the manual if the first line specifies the absolute bed size, or if it relates to actual 0/0 which is offset from the corner (5mm in Y and 10mm in X in my case). Or asked the other way round: In the first line I DO SET the physical size of the bed, no matter where it lies in the coordinate system. Correct?

EDIT: Reading more on the topic I get more confused, but it seems I was WRONG. M208 uses TOTAL PHYSICAL movement for the first parameter and the second then defines where the BED's left front corner is located - in relation to the physical 0/0. This correct?

@dc42 If I didn’t care about that: That's default for all Ender5 as I heard. So if we keep it as it is (and as it was for the carthesian Ender5 before I converted to CoreXY), what would be the next steps? Thanks!

EDIT: afaik the parts are not mirrored but rotated 180 degrees. Right?

This is a picture of my setup. 0/0 is back right (Ender5 CoreXY setup on a DuetWifi). Bed is 235x235. Probe is a Klicky located 30mm from the nozzle to the back.

I just can't understand what I need to set coordinates for abl, etc ...

Probe trigger values: (it this correct? Is the Y offset measured in a way, that you take the nozzle as 0/0 and calculate from there? So -30 in Y?)

G31 P500 X0 Y-30 Z12 

My dual z-setup look that way:

M671 X-70:240 Y115:155 S4

Is that measured from bed zero, or from 0/0? Do I need to take Y-30 offset into consideration?

Grid setup for ABL is completely off. The nozzle can reach ALL positions within the bed. The probe can reach all position with an offset of 5mm to the inside.

Can someone please help me set this up?

Thanks!!!

Just in case someone else is looking for a deployprobe.g and retractprobe.g for a klicky probe, and got the same issues as I got. Just use the tool to determine the values, or do it manually, and c&p it into those two files:

; The deploy command for Z when using a dockable probe" 
; Let's create the probe loading code file for dockable probes

if sensors.probes[0].value[0] != 0
    var originX = {move.axes[0].userPosition} ; Store the X position before grabbing the probe.
    var originY = {move.axes[1].userPosition} ; Store the Y position before grabbing the probe.
    G1 X238.6 Y55 F999999 ; Move tool in front of dock
    G1 X238.6 Y25 F999999 ; Move tool in position where probe is mounted
    G1 X238.6 Y55 F999999 ; Move tool in front of dock
    if var.originX > 238.6 || var.originY > 55 ; Move the toolhead back to the position we came from
       G1 X{var.originX} Y{var.originY} F999999
    M400
if sensors.probes[0].value[0] != 0
    abort ""Error probe not attached - aborting""

; The retract command for Z when using a dockable probe
; Let's create the docking code file for dockable probes

if sensors.probes[0].value[0] != 1000
    G90
    G1 X238.6 Y55 F999999 ; Move tool in front of dock
    M400
    G1 X238.6 Y25 F999999 ; Move tool in position where probe is mounted
    G1 X188.6 Y25 F999999 ; Move tool to detach probe
    G1 X238.6 Y55 F999999 ; Move tool in front of dock
    M400
if sensors.probes[0].value[0] != 1000
    abort ""Error probe not docked - aborting""

I now just went to the code, and I guess I could see what it's meant to do, and basically it's not needed to be run as a macro. I can just determine the positions per hand, and then c&p the to be generated code (the last two blocks) into the .g files. I will try that.

@OwenD Thanks for your tremendous effort, but the problem still exists.

@OwenD I will check the file with another editor. Thanks!

But for the error in macro line 270: There is no daemon.g anywhere on the SD-card, and I'm not printing anything. I'm just calling the macro to generate deployprobe.g and retractprobe.g.
This must be some internal file that's called?!

Got all the tabs removed now, and RRF doesn't complain anymore. Now everything runs fine, and in the end it throws this error:

M292
Error: in file macro line 490 column 7: meta command: expected string expression

Same error, different location ... If I knew where to search for it ...

Reconfigured the probe now - seems it was wrong somehow.

Now I get:

M292
Error: in file macro line 270 column 7: meta command: expected string expression