Physical change from z-probe to z-switch
-
You don’t need to change the motor leads at all. The rotation direction can be changed in the config.
But the m574 command needs to change from z2 to z1
And the homing moves will need to be negative.
If the motor direction is wrong after that you can change it in the m569 command.
-
@Phaedrux
Changes are done and homing works correctly.
Movements work correctly.From home position:
X & Y moves to minus and Z moves to positive
Axis are X&Y 0-250, Z 0-400However, when I print, the Z-axis doesn't advance to the next level. It just stays at the 1st layer and continues to squish the print until failure.
Here's a couple items I've attempted to print where this happens.
G-Code clearly shows layer changes.config.g
homeall.g
homex.g
homey.g
homez.g
Shape-Box (N)0.6 (L)0.36 (IF)15% (S)80 (T)250°C (F)ASA (T)13m .gcode
Bed Wheel Extension v2 (N)0.6 (L)0.36 (IF)15% (S)80 (T)250°C (F)ASA (T)17m .gcode -
G10 P0 X5 Y5 Z5 ; set tool 0 axis offsetsYou only have a single tool, but it has an offset? Why? Normally if you have a single tool there would be no offset and the nozzle tip would be 0 0 0 and all references would be in relation to that.
@davidewen said in Physical change from z-probe to z-switch:
Z moves to positive
What do you mean by this?
Just to confirm we're on the same page
The z endstop is located at the top of bed movement? As in, where the bed and nozzle touch, the endstop triggers, and the Z position is 0.
Z+ movement should move the nozzle and bed farther apart.
Z- movement should move the nozzle and bed closer together. -
Not sure why there is an offset. I've corrected that.
Regarding Z-axis.
Yes,
Z+ moves the bed away from the nozzle and the End Stop Switch.
Z- moves the bed toward the nozzle and the End Stop Switch. -
The gcode file looks correct for movement and your homing files and config look correct now for using a Z min endstop.
Before printing are you able to home all and then jog the Z axis up and down?
-
@Phaedrux said in Physical change from z-probe to z-switch:
The gcode file looks correct for movement and your homing files and config look correct now for using a Z min endstop.
Before printing are you able to home all and then jog the Z axis up and down?
Yes, all homing sequences work properly and I can move all Axis correctly after homing any/all the sequences.
Tested:
homeall.g
homex.g
homey.g
homez.g -
Alright, now try a print with the offset removed. Unload the filament if you want to try it without a potential mess.
-
@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. -
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/minShould probably remove that. It's setting your Z speeds insanely fast and that may be causing lost steps.
-
@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. -
@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/minShould 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. -
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.
-
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 -
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/maxWhere 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
Z5from 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 coordinatesG1 Z0; move Z to 0G1 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 byM208in 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.
-
@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 -
@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! -
@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.
-
undefined Phaedrux marked this topic as a question
-
undefined Phaedrux has marked this topic as solved
-
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 homedOnce 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.
-
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.
-
Ah. Ok. I'll make that change.
