Have had someone such a problem?

DBSDBS

3 days ago I printed normally. All looked OK except THIS problem, bet prints were good enough for me. 

Without changing almost anything, I noticed that the print have a problem - it shifts on the bottom part by "Y" axis.

Yesterday I made 3 tests. The object for print was 20 x 20 x 20 mm "cube"  with 2 mm thick shell and missing TOP / BOTTOM side.

The first try was sliced with Cura Engine. 

The result was: THIS

After than I decided to scale X Y to 10 mm and leave the Z as is - the object! Again sliced with Cura Engine. 

The result was the smallest object in front - HERE.

At the last I decided to change the slicer - I tried with Slic3r. And the result is THIS one in front.. 

The pictures are not good enough, but trough a magnified glass I can see that the first 2-3 layers are OK. Than the shifting begins and continues 15-16 layers. After than the print is absolutely vertical - OK. And the "effect" occurs on the all 3 prints no matter of size of the object and the slicer !!!

The first think was that the pulley of Y motor is not tightened enough, BUT the motor arrived with the pulley heavyset on the axis. There is no way to tighten it more. 

I tried to tighten the belt too with heaviest springs - without result.

I think that the problem is not mechanical or electrical, because nothing was changed from before and because if it IS, the shifting have to occurs on different layers. 

Have had someone such a problem?
PIC1;PIC2;PIC3;PIC4;PIC5;PIC6;PIC7

 

Repetier

You are the only one who can see images on your google drive!

DBSDBS

oooooops sorry.. I'll move them.

ALL LINKS WORKS NOW !!!

DBSDBS

Use THIS link... and orange arrows on the top of the page.

DBSDBS

Thous are the GCODE files...

10x10x20_Slic3r , 10x10x20_Cura , 20x20x20_Cura

DBSDBS

What I did today:

Re flashed firmware.

Checked tightening of the pulley - PERFECT.

Checked symmetry of the pulleys and the belt - almost perfect.   

Checked many times for possible step loosing - the motor do NOT loose steps.

Checked current for the motor driver -  VREF = 1.57 V, that have to mean: 3.925 A  - the absolute max for this driver ( ±2 A)

The driver temperature is 27-30°C, the motors temperature is 28 - 31°C.

Max speed for this axis is limited to 90 mm/s .

Tried new print with other layer high and variable feed rate:

Even on 50% of the feed rate the printer shift layers at the SAME Place (layers) as yesterday !!!

When the "problem" layers were passed and the printer started to print correctly, I tested with 150% feed rate - perfect layers without shifting, without step loosing.

So, the last that I'll check tomorrow will Uninstall and Re install the host and all settings. 

May be have to test with another host - I'll think.

DBSDBS

Hi again,

After 4 hours serious work, the problem still exists....

I re-made the firmware and re-flashed the arduino mega again, but situation is the same.

You can see HERE the result     I think that the shifting is from 0 to ~ 5 mm (on Z) and after that all is OK.

It is seen from the pictures that the problem is NOT mechanical nor from the motor driver.

Meanwhile I have installed the versions: 1.50 and 1.52 of the Repetier Host - nothing changed.

 Tomorrow I'll connect one notebook as a management PC and will report.

Repetier

I really can not say what it is. It is so consistent that I do not think that it is a endstop or a loose pulley. That would give different results in different positions. On the other side I can not think of a influence that only exists  in the first 5mm. I also do not think it is host related since it only sends gcode and that happens since you printed. I also guess the preview in host does not show this so it is also not a wrong slicer result.

I had a similar issue with an other user. He used a cnc toshiba stepper driver with optical decoupling. There he had the problem that the direction change was too fast for the drivers so on direction change he sometimes got a step in the wrong direction. On average it equals quite well the error but it managed to get a step added in wrong direction for each layer depending on next layer staring direction relative to old direction. He solved it by increasing the direction delay variable. Do you also have some non standard stepper drivers which may need longer timings?

DBSDBS

Thank's for the reply,

The drivers are A4988 and all was OK until 4-5 days ago. Thous are very usual drivers. I do not remember any changes on the system between good and bad  prints. Further more, I printed second time the same part as the day before, and noticed this shifting.

Now I'll change the PC with host, and will see is there will be a difference.

But before that, I'll change the driver for Y axis...

DBSDBS

So,

Bran NEW and FRESH installed Windows 7 Ultimate 64 bit, + Arduino IDE 1.6.3 + Repetier Host 1.5.2 + New slicers + NEW interface (USB) cable.... Again from 0 to 5 mm shifting and after than OK.

Before that CHANGED Driver for this axis (Y) - without changes

The last that can be problematic is the Arduino Mega 2560... Unfortunately the new one purchased is on the way.

Meanwhile I'll search for the way to do real (total) reset of the board. May be I have to burn a new Bootloader...

Repetier

Bootloader can not have an influence. It does not run while printing.

You could use the Extruder 2 slot for y axis to test if it is the position on RAMPS.

You are right that driver is very usual. STEPPER_HIGH_DELAY 1 is maybe worth a test since it increases timing a bit, but normally not needed.

DBSDBS

The idea for burning Bootloader is to "RESET" generally the Arduino Mega board. And when I flash the firmware, to be sure that all is really new.

I set all Vref's of all drivers. Now they are max 10% more than by motors specs. This didn't help me.

After that I exchanged the extr 2 (my second Z motor) with Y motor and changed the number of pins responding for them in pins.h but they have to be described on somewhere else, because the movement was "strange" but not desired.

That's why I had returned all in place and will wait for the another (new) Mega 2560.

DBSDBS

I changed everything in my setup, except mechanical components (because they are the same as before the problem). i.e.:

- PC (from Desctop to Notebook) + the host software (different versions of Repetier Host - from v.1.06 to v.1.53)

- USB cable

- Arduino Mega 2560 + few times new firmware (Repetier 0.92.3)

- RAMPS 1.4

- Y driver (A4988)

In addition I made some changes in my firmware too, especially STEPPER_HIGH_DELAY 1 (from "0")

I checked many times the current from the drivers and theirs (and motor's) temperatures. They are as follow:

Axis - Driver - Motor

"Y"  - 32.7°C  - 31.5°C

"X"  - 28.0°C  - 32.4°C

"Z1" - 35.5°C - 34.7°C

"Z2" - 28.5°C - 32.4°C

"E"  - 28.0°C - 31.8°C

All temperatures were measured with digital infrared thermometer and the ambient temperature was 27.2°C. 

The Vref of the "Y" axis was 0.8V but the motor has left some steps. That's why I raised the Vref to 1.00 V and now it works smoothly. The temperatures quoted above are with Vref = 1.00 V.  !!!  Before the problem, Vref was even more high - 1.52 V, and I had NO any problems for more than a year !!!

The last, that can be changed is the firmware type. 

Thank's to all

Repetier

Glad you found it. Such a small issue causing so much problems.

DBSDBS

Unfortunately I didn't found the problem. 

The last that I can change is the firmware. But still do not decide which one to test.

Repetier

> That's why I raised the Vref to 1.00 V and now it works smoothly.

sounded like a success. You could try Marlin as a counter test.

If it is always Y did you test also reducing jerk to a lower value. Bed is heavy so starting with higher speeds can sometimes loose steps.

DBSDBS

Hi Repetier,

After many tries and many spend hours, the final conclusion is that the problem is IN my Repetier's Firmware, because with Marlin 1.1, the printer prints vertically at all.

BUT because I have other issues with Marlin, and in fact I like more Repetier's Firmware, I would like to ask you to take a look in my Configuration.h for some troubles that can cause such a problem. 

Is it possible the problem to be in some other file (not exactly in cinfiguration.h) ???

Thank you in advance!

DBSDBS

Is it possible this line to be a problem ones?

#define ALLOW_QUADSTEPPING  1

DBSDBS

So, I'm not sure what for exactly is:  

#define ALLOW_QUADSTEPPING 

but when it is "0" all is OK. All the time the problem was in this parameter. It was "1" and I'm not sure why I had changed it.

If @Repetier accepts ideas for improving the quality of it's Software and Firmware, my proposal is to explain the functions / parameters. Because when he write them, he knows very well what for are they, but no one user is "in he's head".

Thank's again for the really good software and firmware! I love them!

Cheers

Repetier

It is described here:

http://www.repetier.com/documentation/repetier-firmware/rf-installation/

Section stepper timings

It executes 4 steps in a row if needed so you can reach higher frequencies. Till now it did not cause any problems, except that it executes 4 steps in a row so it might that motor/driver can not follow as fast as it executes. Therefore you can set Delay between double/quad steps to higher values to slow down speedup. Quad stepping only starts when speed is > 2 * double stepper frequency. Until then it stays unused. Since printing is slow I think your travel moves are fast enough to require that speed and then it looses a step from time to time.