X axis travel issue.

First off, I absolutely love the repetier firmware and host, it has transformed my printer into a wonderfull machine!

But, I do have one issue left.
Sometimes the X drive skips steps when going towards 0, se the attached image.
The travel speed is the same as the infill speed and I have two different profiles, normal and high speed. And the result is the same with both.
Before switching to repetier I was running marlin and never had any issues like this.
The X motor current is adjusted propperly, the pololu drivers has heatsinks and a fan.
And the only time there is an issue is when the printer does a travel move for the next print segment and always towards 0.

I have tried lower the speeds, the issue becomes less frequent but still present.
I have tried raising the motor current, no difference.
I have tried lowering the motor current, no difference.

Anyone have any idéas where to start with this??

/Johan

Just noticed that I get "BLK 10", "BLK 11", "BLK 12" on the output when this happens.
From the source, main window row 1534 this seams to be related to step calculation, with a comment "should't happen".. :-)
Well, it seams that it is happening.

I,m running firmware 0.71 downloaded from the homepage.
Just saw that there is a 0.73 in the git but the changelog does not mention anything that looks related to this issue.

My hardware is a Maga 1280 with Ramps 1.4 and pololu drivers.

/J

From Repetier fw documentation:

Quote

PATH_PLANNER_CHECK_SEGMENTS (default 10)
Sets how many line segments can the path planner use for path optimization. The maximum possible value is MOVE_CACHE_SIZE-2. Higher values need more computation time, which can cause blocking for many short subsequent moves. If this happens you will see BLK messages in your log and then you now the value is to high for your printer settings. If you set the value too low, you will get unneeded acceleration/deceleration sequences.

Solved.

First I changed the PATH_PLANNER_CHECK_SEGMENTS to 9 from 12 (the 0.71 has 12 as default).
This removed the BLK but the X issue remained.

Then I found this post: [github.com]
Changed STEP_DOUBLER_FREQUENCY to 15000 and DOUBLE_STEP_DELAY to 2.
Still no change.

The I checked the setting for endstop checking during print, this was active.
I have already tested my mechanical endstops and they work just fine.
But, I disabled the endstop checking and the problem is gone!
My best guess is that the Arduino mega board I have (chinees knockoff) probably has a different layout or are just simply poor quality on the pcb making the input pick up noice from the machine or something else. Another possible reason is the IDC connectors supplied with my machine, these are very simple and low quality, there might be an issue with these at low currents and vibration.

Thanx for the help anyway.

To me this sounds like oyur x-endstop may give false signals due to cross talk. Make sure you have

// You can disable endstop checking for print moves. This is needed, if you get sometimes
// false signals from your endstops. If your endstops don't give false signals, you
// can set it on for safety.
#define ALWAYS_CHECK_ENDSTOPS false

That way cross talk has no influence during a print.

The other possible reason could indeed be related to the blk problem. This means, that a line segment is blocked by the path planner while the stepper interrupt wanted to start working on it. Normally this does not happen, because the current and next segment are not touched. Which means you have many small segments in a row, which is the only way how this can happen. If this is your problem you should upgrade to the developer version. There the path planner is completely rewritten and should not have this problems. You see sometime a BLK 3 there for single moves, which can be ignored.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!