Strange z offset after printing.
-
Also please post your homeall.g file, and tell us which firmware you are using.
-
I am running 1.20 firmware.
; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool on Mon Nov 13 2017 23:47:22 GMT-0600 (Central Standard Time); Relative positioning
G91; Lift Z
G1 Z3 F9000; Course home X or Y
G1 X332 Y318 F2500 S1
; Course home X
G1 X332 S1
; Course home Y
G1 Y318 S1; Move away from the endstops
G1 X-5 Y-5 F2500; Fine home X
G1 X332 F360 S1
; Fine home Y
G1 Y318 S1
; Absolute positioning
G90; Go to middle of bed and home Z
G1 X150 Y150 F9000
G30; Uncomment the following line to lift the nozzle after probing
G1 Z10 F150
; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool on Mon Nov 20 2017 00:03:40 GMT-0500 (Eastern Standard Time); Lift Z relatively to current position
G91
G1 Z5 F6000; Back to absolute positioning
G90; Go to first bed probe point and home the Z axis
G1 X150 Y150 F6000
G30; Uncomment the following lines to lift Z after probing
G91
G1 Z10 F100
G90 -
Do you see any signs of skipping steps on the Z axis? If you run it up and down does it sound smooth and consistent? Any signs of binding? Are you running the Z motors at ~85% rated current?
I'm not familiar with your probe type, so I don't know what to look for to see if it's functioning properly or not.
-
On power up, all settings will be read in from config.g (and or config-overide.g if you use it). So if a power cycle fixes it and homing works fine, then logic would dictate that there is something in the print gcode file that is changing a setting. It might be an idea if you post the first and last 50 or so lines of the gcode file that your are printing - especially the parts that contain your start, and more importantly your end, gcode.
-
I am not getting binding on Z and do not see any skipping. Im fairly certain the probe its self is functioning properly.
Start Script:
T0
M104 S0 ;cancel S3D set temp
G21 ; set units to mm
G90 ; use absolute coordinates
T0 ; select tool 0
M207 S8.5 F4000 T1800 Z0.4 ; setup firmware retractionG92 E0.0 ; reset e count
M220 S100 ; reset speed multiplier
M140 S[bed2_temperature] ; set bed temperature and do not wait
M109 S205 ; set print head temperature and wait
M190 S[bed2_temperature] ; set bed temperature and waitM140 S[bed2_temperature] ; set bed temperature and do not wait
M109 S[extruder0_temperature] ; set print head temperature and wait
M190 S[bed2_temperature] ; set bed temperature and wait
Post processing for FW retraction
{REPLACE "G1 E-1.0000 F6000\n" "G10\n"} ; firmware retract
{REPLACE "G1 E1.0000 F6000\n" "G11\n"} ; firmware unretract
{REPLACE "G1 E1.0000 F1800\n" "G11\n"} ; firmware skirt unretract
Ending script
G91 ;relative positioning
G1 E-5.00 F1000 ;retract 5mm of filament
G1 Z+1.00 X+20.0 Y+20.0 F20000 ;short quick move to disengage from print
G1 Z+10.00 F20000 ;move Z-Axis 10mm away from partG90 ;absolute positioning
G1 X10 Y10 ; move gantry close to home
G91 ; relative positioningG1 E-5.00 F500 ;retract additional filament to prevent oozing
G90 ;absolute positioning
M104 S0 ;turn off hotend
M140 S0 ;turn off heatbed
M106 S0 ; shut off blower
The scripts are not made by me ( they are from a friend that also has a Voron).
-
@lolmodule said in Strange z offset after printing.:
G1 Z+10.00 F20000 ;move Z-Axis 10mm away from part
What happens if you send this command manually? Does it successfully move 10mm?
-
@phaedrux said in Strange z offset after printing.:
@lolmodule said in Strange z offset after printing.:
G1 Z+10.00 F20000 ;move Z-Axis 10mm away from part
What happens if you send this command manually? Does it successfully move 10mm?
Yup. That looks like a very high feed rate for the Z axis. I'd think that may well be the problem.
-
I can't see anything obviously wrong with your files. Two possibilities:
-
This issue might be related to the one that I fixed in firmware 2.0, even though that one was most evident when using mesh bed compensation. So you could try upgrading to firmware 2.0.
-
If the print file is somehow changing the babystepping amount or the tool Z offset, that would cause the problem. So try sending the following commands after a print and check that the results returned are correct:
G31 T5 ; should return trigger height = 2.0
M290 ; should return zero, or whatever babystepping you used
G10 P0 ; should return Z offset = 0 -
-
Ok. I re did my Z0 and my probe trigger height just to make sure everything was ok. Which is why my trigger height is a tad different than before. I printed a calibration cube and put in the commands you suggested @dc42 this is the results:
G10 P0
Tool 0 offsets: X0.00 Y0.00 Z0.00, active/standby temperature(s): 0.0/0.0M290
Baby stepping offset is 0.000mmG31 T5
Threshold 500, trigger height 2.19, offsets X0.0 Y-40.0Everything looks good right?
https://gyazo.com/e708fbecbdc5baf48ebf945f10f2fadf
Notice the commanded position and the readout in the top right.
I tried the suggestion by @Phaedrux and manually entered that move command ( verified Z 0, sent the G1 Z+10.00 F20000, then back to 0 and it was fine.)
I have no idea whats going on. I haven't updated to 2.0 yet but I think it might fix whatever issue I might be having but I will wait to see what you all have to say.
I really do appreciate the time you guys ( even though it may not be much time) put into helping me out.
-
It looks to me that you have some sort of bed compensation in use that is causing a 0.4mm adjustment. Please run M122 and see what the "Bed compensation in use" field reports.
Another possibility is that the GCode file you printed uses a M206 commands to offset the Z axis.
-
No bed compensation: https://gyazo.com/9193b8b3715ef0341789c3e7e04b06f3
Checked the last few files and there are no M206 commands. My start script does have an M207 that has a Z0.4 in it.
M207 S8.5 F4000 T1800 Z0.4 ; setup firmware retraction
Could that be it? like I mention earlier I am not fully up on Gcode so when my friend gave me the scripts for FW retraction I just used them. Is there a reason to have a Z0.4 in the FW retraction?
-
The Z parameter for firmware retraction controls Z hop.
-
Ah ok. I dont know what the issue could be then... Everything appears to be setup right.
-
Might be time to give 2.0 a try.
If that doesn't work, you could try backing up all your existing config files from the /sys folder and then starting fresh with a new config bundle generated by the RepRap configurator. It would likely take some tuning and adjusting to get it working properly for your printer again, as the configurator really provides more of a starting point than a final working config. This would also give you a chance to dig into RepRap firmware and gcode a little more which is really quite powerful once you get into it.
I still suspect some binding or skipped steps occasionally, can you verify what the rated current for your z stepper is and whether you're running it at close to 85% of rated?
-
I thought that the 20,000 mm/min (333mm/sec) for the Z move in the end gcode was way too fast (which it is) but then it'll be limited to 1,000 because that's what is in config.g.
Like Phaedrux, I'm also inclined to think it's binding or skipping steps. You could try lower Z acceleration.
-
It may be that, but like I posted above. I ran that high Accel z move manually and it returned to 0 no problem. ( But that doesn't mean it isn't the cause)
-
@lolmodule Just a theory, but at the end of the print the motor may be hot and may not respond the same.
-
@phaedrux that's possible. I'm running dual leadscrew steppers for my Z so I didn't think it could be that but it's definitely not out of the realm of possibility.
-
I updated to 2.0. printed a calibration cube. removed the print and sent the head to X150 Y150 Z10 ( 10mm above the center of my bed) and this is the result...
https://gyazo.com/384ec6ddfaa195b510a2755408a18a8c
No more strange offset after a print!
Thanks to everyone for all the help and tips!
