Loosing steps X axis

Well, since you don't mention any problem with the Y and Z axis I assume that your PC meets the basic requirements to run LinuxCNC, e.g. the jitter is not too bad. Has this setup ever worked before?

From personal experience I would look for mechanical problems with the X axis. With the motor removed make sure that both ends of the spindle are centered at the same time. Also with the carriage at the X center make sure the spindle ends move equally up and down, with the spindle nut as pivot. On my machine the spindle was too low. I had to removed the carriage, loosen the lower roller bolts and tighten while pushing them downwards. It is also mandatory to loosen the screws for the X profile, drive the carriage to one end and tighten the screws, then proceed to the opposite side. This procedure is also described in the manual.

I am not a LinuxCNC expert and looking at your files I can't see a problem, but the files seem to be manually modified. Maybe it is a good idea to restart from scratch and check one axis at the time.

Here are some stepconf screenshots from my Stepcraft 300 installation. I use a Dell GX620 with a Pentium 4 w/ hyper-threading disabled (another GX620 with Pentium Duo didn't work at all). My jitter is about 25000, but it works fine.

Wilhelm

Try to turn your model 90 degree and print again. I think you will now loosing steps in y-axis. I don't think that you have a problem with your x-axis. If you zoom in your model you can see a lot of unusual peaks, so check your construction. Otherwise check your stlfile with netfabb.

I would like to explain my "measuring" procedure:
1. make mark on the base plate
2. point nozzle to that point and "touch off "
3. let it print ( without feeding plastic )
4. go to XYZ ( 0,0,0)
5. measure offset - there I see nozzle is cca -1mm on X axis

OpaHoppenstedt: thank you for ideas:

1. Jitter is not that bad +- 13000ns ( latency test was running for 20 minutes , and max jitter was 13003ns - so I set it to 15000ns
Anyway - I don't have issues with Y axis for sure ( Z - I haven't measure yet ) - so it seems to be only X axis related problem.

2. Loosen the screws for the X profile - I'll try this procedure

3. Spindle in the middle - it seems to be centred

eon16:

1. I've checked that model with netfabb ( I always do ) and I don't see that "spikes" in my gcode viewer ( pleasant 3d)

I've recently discovered this GCODE online viewer http://gcode.ws and there is also not anything weird

2. I'll try to rotate that model

Before 3D print, I was using few months step craft only for milling low profile milling objects and I didn't notice any problem with X axis.

I'm suspecting that ZIGZAG infill can cause that problem ( very sort and intensive movements - bud with that 12mm/s2 low acceleration I would expect that can't be problem )

Thank you guys for your time - I'll try to make some testes based on your suggestions.

Michal

1. I've loosen X portal's screws on both ends as directed by "OpaHoppenstedt"
2. The force needed to move X position is much less then 5N for sure - I think there is no mechanical problem with X axis
3. I've rotated 3D model 90C around Z axis
4. Checked model in netfabb ( basic version ) - no errors
5. Generated GCODE ( with slic3r )
6. Changed LINUXCNC settings to -> speed 30mm/s , accel 120 mm/s2
7. printed => the same result - X axis is cca 1mm to the left , Y seems to be ok

Result is +- the same no matter if acceleration is 12mm/s2 or 120mm/s2

Maybe LINUX CNC bug ?

I'm going to exchange X / Y axis in LINUX CNC and see what will happen

Attaching also STL file

Hi Michal,

last night I try to print your file (without filament), but the result I realy don't understand!

1. run, 0 degree - lost steps X 712 / Y 682 / Z 0
2. run, 90 degree - lost steps X -1408 / Y -1 / Z 0
3. run, 180 degree - lost steps X -704 / Y 663 / Z 0
4. run, 270 degree - lost steps X 528 / Y 10 / Z -1
5. run, 270 degree - lost steps X 24 / Y 10 / Z 0

Between each run I print out my good and my bad reference object, so I know, my SC is running fine.

The results of run 1 and 3 make sense but I have no idea what happend at 2/4 and 5.

Better you forget this file!!!

I did a new slice of your stl-file, without Support material

RESULT: lost steps X 0 / Y 0 / Z -1

So I think, there is a Problem with the slicer and not with your SC!

Hallo Wolf,

thank you for your effort.

1. How can you count lost steps ? With some kind of external step counter ?
2. I've exchanged X,Y axis in LINUX CNC config ( so signal to X was send to Y and vice versa )
Result - Y axis no problem, X axis + cca 1 mm
3. As you observed - removing support from that part => no lost steps

Is it so that there are some movements o X axis that X axis motor can't handle , but stronger Y axis motor can ?
[ X axis motor - 1.4A , Y axis 1.8A ]

But then I don't understand that even with very low speed and acceleration ( I was also testing accel 12mm/s2 ) the result was same
and with so low accel and speed ( where torque is high ) still the same problem with lost steps.

If there is problem with LinuxCNC with planning trajectory or with latecny then I would expect that also Y axis should have lost steps but that didn't happen.

Hallo Wolf,
one more question - what settings did you use for test print ( speed / acceleration ) achieving 0 lost steps ?

Hi Michal,

in WinPCNC you have a very helpful function called "Position test" where you can check after each run if you have lost steps.

While printing, I don't use the machine parameters, I only use the Parameters in gcode created by slic3r. Only the acceleration is from the machine in WinPCNC called ramp, here 200 ms.

Print Settings Slic3r:

I don't think that the stronger Motor is the reason for less lost steps. In Y you have more tolerances and more mass to move, so Y will be the critical axis at first. Normaly you have to find the same result on the other axis if you turn your printfile 90 degree.
At the Moment I have no idea what is the reason for the problem when using Support material. Also I don't understand the difference between run 4 and 5. If I test my bad reference file (no Support material), I always have the same result +/- 5 steps.
If the slicer is buggy with Support material you have to find the same result each time. But here we have a coincidence...

I've generated GCODE in CURA software - at high speed (30mm/s) X axis lost steps ( cca 1mm ). Then I rotated gcode 90 and Y has lost steps. Then I have modified speeds to your's and it seems there are no visible lost steps.

I do understand that with higher speeds torque decreasing so one have to find some "gold" point ( speed / acceleration ).
What I don't understand is how can "bad" gcode cause lost steps even with very low speed and acceleration ( I was testing "bad" gcode with support at cca 10mm/s and 12mm/s2 - that's i think very low acceleration ).

Is there gcode sequence ( I was looking for it but haven't found ) that has the worst impact on stepper motors and that way one can simulate worst situation for stepper motors and tune speed and acceleration, so that there will be not any other situation where system will lose steps ?
Maybe it depends also if there is full step or half step at some point of running gcode - half steps as I know has 15% lower torque

perhaps we are searching in the wrong direction and the problem is not caused by the print speed. You reduce the print Speed and the result is the same. Now I suppose that the Problem might be the travel speed - 20 mm/s could be to much moving Printer head

Torque / speed graphs

I 'll try first determine maximum speed:
1. setup low acceleration
2. let machine drive long distance at max speed
3. if lost steps , lower speed and repeat test

Then the same for acceleration - I'll set max. speed where there was no lost steps

In attached Torque graph files one can see that there is a point where motors start to lose torque
600rpm seems to be critical - as I know for step craft 1 rotation = 2 mm => 1200mm/min => 20mm/s , so I think maximal speed
will be around 20mm/s.