Physical change from z-probe to z-switch

Phaedrux

Alright, now try a print with the offset removed. Unload the filament if you want to try it without a potential mess.

davidewen

@Phaedrux said in Physical change from z-probe to z-switch:

Alright, now try a print with the offset removed. Unload the filament if you want to try it without a potential mess.

Test printed Shape-Box (N)0.6 (L)0.36 (IF)15% (S)80 (T)250°C (F)ASA (T)13m .gcode a few times.

Found out that layer changes start at layer 10.
Z-Axis will not move prior to layer 10 even with Babystepping.

Phaedrux

What height does layer 10 correspond with?

I also notice that your slicer start gcode is setting speed variables.

M201 X5000 Y5000 Z2500 E5000 ; sets maximum accelerations, mm/sec^2
M203 X120000 Y120000 Z60000 E9600 ; sets maximum feedrates, mm / min
M204 P2500 T1500 ; sets acceleration (P, T), mm/sec^2
M566 X960.00 Y960.00 Z1920.00 E600.00 ; sets the jerk limits, mm/min

Should probably remove that. It's setting your Z speeds insanely fast and that may be causing lost steps.

davidewen

@Phaedrux said in Physical change from z-probe to z-switch:

What height does layer 10 correspond with?

As far as I know, nothing.
I just noticed in the Web Control that at layer 10 the Z-Axis starts to move.

davidewen

@Phaedrux said in Physical change from z-probe to z-switch:

What height does layer 10 correspond with?

I also notice that your slicer start gcode is setting speed variables.
M201 X5000 Y5000 Z2500 E5000 ; sets maximum accelerations, mm/sec^2
M203 X120000 Y120000 Z60000 E9600 ; sets maximum feedrates, mm / min
M204 P2500 T1500 ; sets acceleration (P, T), mm/sec^2
M566 X960.00 Y960.00 Z1920.00 E600.00 ; sets the jerk limits, mm/min
Should probably remove that. It's setting your Z speeds insanely fast and that may be causing lost steps.

Ok. Removed those in the slicer.
Re-sliced and sent to printer.
Still no Z movement until layer 10.

davidewen

@Phaedrux

Update.
After a few more attempts, slicing other files etc.
I have discovered that the Z-Axis will not move even with Baby Stepping until somewhere around 1.3 - 1.5 mm.
It's difficult to tell exactly where as I'm attempting to hit the Baby Step button and watch the Z-Axis at the same time while it's printing.

I'm guessing there must be a setting somewhere that is causing this behavior.

davidewen

@Phaedrux

I think I figured it out.
I believe it had something to do with the RRF Config and the tool offsets that you mentioned earlier.

I re-ran the RRF config tool, corrected the tool offset and now it seems to be working.

I will confirm tomorrow morning when I come back to the office.

Cheers,
David

infiniteloop

@davidewen

I'm guessing there must be a setting somewhere that is causing this behavior.

What about this in your config:

M208 X0:262.10 Y0:260.20 Z-1:400			 ; set axis min/max

Where is Z-1? Below your bed's surface?

Then, your Z offset:

G10 P0 X5 Y5 Z5                              ; set tool 0 axis offsets

@Phaedrux already pointed you at this - did you remove Z5 from your config?

Then, this is in your homez.g as well as in homeall.g:

G92 Z-0.4           ; set Z position to axis minimum (you may want to adjust this)

Why -0.4?

In my understanding, your Z axis is limited to a minimum coordinate of around 1-2 mm (notably not above the bed, but in its coordinate system), so that an absolute move to Z0 is clipped to that.

I have discovered that the Z-Axis will not move even with Baby Stepping until somewhere around 1.3 - 1.5 mm.

Yeah, that's your "10th layer" where Z begins to move. To verify, you can try these steps:

home your axes
execute the following commands from the console:
G90 ; set XYZ to absolute coordinates
G1 Z0 ; move Z to 0
G1 Z0.6 ; Z should move up 0.6 mm - but I think it doesn't …

You can increment the Z value until you detect a movement - then, you have an idea where to look at: There must be a limitation on the lowest coordinate Z can reach, either imposed by

an "unrelated" relative move (perhaps M83?) or
some offset you somewhere define for Z or
a re-definition of the Z-origin

I'm not sure I covered all possibilities, but you should look at the issues I listed above. In addition, I miss M564 (or did I overlook that?): To home your axes (to endstops or by Z-probe), the limits imposed by M208 in your config.g must be temporarily removed.

For each of the GCodes which might affect Z, please refer to the GCode dictionary and spell every single argument, one by one, so that you get a detailed knowledge of what is happening.

davidewen

@infiniteloop said in Physical change from z-probe to z-switch:

Why -0.4?

So that I can baby step down if needed.

G10 P0 X5 Y5 Z5 ; set tool 0 axis offsets

I made the change to G10 P0 X0 Y0 Z0 in config.g, but it did not fix the issue. When I made the change in RRF Config, it did correct the issue. I would think the config.g would do it, but maybe there is an override in the config.json?

Now that the corrected config.json and config.g files are present in my System Directory, the Z-Axis is working as it should.

I'm finishing up a test cylinder and it is printing just as it should be.

I would consider this issue closed.

Thanks for all the help. Each time I have to trouble shoot something like this, I learn a bit more about the Duet system and coding in general.

Cheers,
David

infiniteloop

@davidewen said in Physical change from z-probe to z-switch:

I would consider this issue closed.

Glad you solved that.

When I made the change in RRF Config, it did correct the issue. I would think the config.g would do it, but maybe there is an override in the config.json?

Not as far as I know. The .json is just used with the config tool, not during runtime. However, there is an "override" mechanism in RRF: see M500 and M501. But in the config.g from one of your above posts, that's not implemented. So I still have no precise idea what was the real cause of your Z-axis shift. 5 mm from G10 (in your previous config.g) account for more than 10 layers. Nevertheless, your success counts!

Phaedrux

@davidewen said in Physical change from z-probe to z-switch:

So that I can baby step down if needed.

If that's what you're after than the Z axis minima is where you want to set a small negative value, which you have.

Normally when you do a homing move it will set the position to the axis minima. When you use G92 to force a position, it should at least be accurate to the actual bed position. So you should use the actual distance between the bed and the nozzle instead of -0.4. You'll still be able to baby step lower than 0 if your Z axis minima is slightly negative.

davidewen

@Phaedrux

Not sure what I'm doing wrong, but I have another issue.

I've completed a number of prints with everything working fine.
Prints complete, bed moves to near max of 400.

Now I can not home. The Z will only lift about 5 mm, then stop and I get an error
G28 Z
Error: G0/G1: insufficient axes homed

Once that happens, I can not home Z with homeall or homeZ.

This happened once before. Not sure what I did to fix it. I just messed with the homeall.g and homez.g files.

Current files are what were working until this morning.

I'm attaching a short video and a screen shot as well as config files.

homez.g
homeall.g

Home Z edit.mp4

Phaedrux

G1 X125 Y125 F9000			; move probe to center of bed allowing for probe XY offsets and XY axis min/max settings
G1 H1 Z-25 F1200			; move to Z end stop and stop there (first pass)
G1 Z10 F1200				; move down a few mm
G1 H1 Z-25 F360				; move to Z end stop and stop there (second pass)

If the bed is at the bottom, you'd need to move more than 25mm to get back to the switch. Your homing moves need to be at least as long as the axis to ensure a homing move will be long enough to hit the switch even if it's at the far end of the axis.

davidewen

@Phaedrux

Ah. Ok. I'll make that change.