Z offet issue

[fredini]

I am having a frequent Z offset issue where the machine jumps out of alignment. Is anyone else having this issue?

The other strange thing that occasionally happens when I kill a print is that I will send a G28 command to home the machine again and only the Y axis will move upward. I have to quickly disconnect or power off the Rostock or it will grind away if the arm moves too far as only the one axis is moving upward. When I disconnect and manually push the arms upward and hit g28 its usually fine but sometimes I need to home it twice in a row as the x arm does not move on the first try.

Does this seem as though some wiring in the board connectors is loose? I'm starting to suspect this may be the issue.

Examples:
[img]http://farm9.staticflickr.com/8360/8375571858_a08b356bcf.jpg[/img]
[img]http://farm9.staticflickr.com/8499/8373997254_5b46c4bb47.jpg[/img]
[img]http://farm9.staticflickr.com/8464/8372926355_5b737cbd7e.jpg[/img]

[Polygonhell]

Something is skipping if you're seeing that.
Could be bad wiring, could be drivers overheating, could be too much mechanical resistance, or could be a set screw worked loose. Looking at which axis is moving towards or away from will give you a starting point for debugging it.

[fredini]

Seems to be moving away from the Z axis, so I guess I should look at that one? Although the print with the legs also has a shift away from X, I think.

[barnett]

I had that offset problem happen to me twice. Not sure if chewed belts was the culprit but I haven't seen this since I replaced two of my belts.

If you move the carriages to the endstops, you can inspect the belt ridges. I think even a small amount of grinding can chew them up. My X belt was just hanging by a thread.

I have not (yet) had a G28 command fail on me.

[fredini]

Two things I did seem to have fixed things:
1) I discovered that the Z belt had loosened up- just a little, but apparently enough to make it skip.
2) I also had purchased a proper crimping tool and redid the connections to the rambo board with new 4 pin connectors.
After I tightened it up some it seemed to be printing fine. A 6 hour and then a 10 hour print later, I have some nice prints and no Z offset issues.

However, at the end of the second print I still had the issue where the machine homed weird at the end of the last layer the x and y axis' both stopped moving. My gcode has a G28 command in it to home the all 3 axis at the end of the print, but what happened was that only the Y axis moved upward- the X and Z axis both just stayed put as soon as the top layer finished. I had to quickly disconnect in Repetier to avoid it grinding. Then after I reconnected, still only the Y axis would respond the the G28 command. I then disconnected and powered off the printer, even removed the USB cable from the laptop and reconnected in Repetier. At that point the machine homed normally and all was back to usual.

My end Gcode contains:
M104 S0 ; turn off temperature
M140 S0 ; turn off bed
G28 ; home all axes
M84 ; disable motors

Its weird that this keeps happening. Everything seems connected to the Rambo board and my connections are good. Could this be a software issue? Anyone else getting this issue?

[Polygonhell]

I'd lose the M84 in the GCode.
In general M codes don't wait for GCodes, so it's possible that there is some weird interaction wher the M84 disables the motors immediately as the home starts.

To be more explicit.
All the GCodes are queued into a planning buffer, and execute later, when a move is requested then the motors are enabled. MCodes instantaneously change the state of the machine, and don't wait for queued moves to happen. So for example

G1 X0 F100
G1 X70 F100
M106 S255

In this case the fan will turn on before the moves finish, on a none delta machine probably as the first move starts and I suspect the M84 is doing the same, exactly why the Y axis continues I don't know.

[fredini]

Thx, I'll try that and let you know if it works.

[barnett]

This may have nothing to do with your issue, but every time a print run completes for me, my machine drives about +125 in X. This is not in the gcode. So I f I do G28 at the end of a run, then the carriages are all at the top and this unwanted +125 in X will cause grinding since nothing can move up.

instead of G28, I add G1 X0 Y0 Z200 F2500 at the end of the gcode so it will have clearance for this unwanted +125 to happen without grinding. A better solution would be to find out why this is happening in the first place (firmware?), but I've been too busy printing junk for the kids (& me).

[Highcooley]

This may have nothing to do with your issue, but every time a print run completes for me, my machine drives about +125 in X. This is not in the gcode. So I f I do G28 at the end of a run, then the carriages are all at the top and this unwanted +125 in X will cause grinding since nothing can move up.

instead of G28, I add G1 X0 Y0 Z200 F2500 at the end of the gcode so it will have clearance for this unwanted +125 to happen without grinding. A better solution would be to find out why this is happening in the first place (firmware?), but I've been too busy printing junk for the kids (& me).

I had the same issue and it was caused by the park position feature of Repetier Host. Uncheck "got to park position after job" and set the park position to values which won't cause grinding or any collisions (e.g. with the finished print). I set mine to X0 Y0 Z350.

[barnett]

I'm not at the printer, but I have my laptop here and I see that the "Dump Area Position" was x=135 Y=0 Z=0 and "Go to Dispose after job/job kill" was checked.

Clearly that was my problem. I changed the position and unchecked that box, so I suspect you solved my problem.

Thanks Highcooley!