one axis is slower than the others in delta printer

[mj996]

Hello everybody,I have a problem with my delta printer and I would be very grateful if you help me
to solve it.
I'm using Arduino due + RADDS with Repetier firmware.
The problem started when the Z stepper motor only moved in one direction.I've tried loads of methods non of them helped me to solve that.
I checked all of the endstops.They worked fine.
I checked the stepper drivers ,all of them had the same voltage 0.7 v .
and finally I found out that the problem was with the dir pin on the board
So I decided to use E1 socket for Z axis stepper motor.I change it in my firmware and i plugged the stepper cable and the driver into E1.when I swapped the Z axis with E1,the Z carriage moved correctly up and down but the speed of that carriage is lower than the others now.so the things that I did :

• If i command the printer after homing to lower the Z for 30 mm what i observe is 15mm distance from Z carriage to Z endstop but for the others it's 30 mm(correct)..
  I thought that maybe the steps per mm is wrong but it was right.
  200 stp/rev , 1/16 micro stepping , 2mm belt pitch , 20 pulley tooth
  I set steps per mm on 80 for X,Y and Z.

• I checked the deep switches under the RADDS board and All of the were set on 1/16 (MS1=H , MS2=H , MS3=L).

• I swapped the driver of E1 with Y but the problem was still on z axis.

• When I put the Z axis stepper cable and it's driver back in Z socket there was no sign of speed problem(it's speed was like the other axes)but I can't use it because of the defect dir pin .

• I adjusted the belt tension and the X and Y axes worked fine and accurate but for Z axis we've got problem yet.

[repetier]

Apparently the driver is using a different microstep setting. Check the MS1, MS2, MS3 pins on the socket if they mirror the switch settings. Maybe one of the switches is not 100% in position and still gives wrong signal. Just test voltage agains GND and compare it with Z socket. 5V over usb is enough for the test.

[mj996]

Apparently the driver is using a different microstep setting. Check the MS1, MS2, MS3 pins on the socket if they mirror the switch settings. Maybe one of the switches is not 100% in position and still gives wrong signal. Just test voltage agains GND and compare it with Z socket. 5V over usb is enough for the test.

Thanks.You made my day.There's another thing now.When I home the printer and command to lower the Z for 10 mm The carriages move 80mm downward and this will just happen for the first command after homing.
should I open another issue for it?
I noticed that when I press home button in the Host my last Max z height number will appear
but when the carriages hit the endstops my new Max Z height will appear in the Host.So when i command to lower the Z for 10mm it will lower the Z 10 mm from my last Max Z height number.I commanded M502 , M500 but nothing changed.

[repetier]

That is no bug I think. Check in host what you have set as z position for homing. My guess is that it is 70 less then what you really have. So it sends lower Z coordinates to printer and hence the move is longer then expected since firmware knows where it was. Here M502/M500 does not help since it is the host having wrong coordinates. It does not know correct homing position and does not read returned coordinates in all cases.

[mj996]

That is no bug I think. Check in host what you have set as z position for homing. My guess is that it is 70 less then what you really have. So it sends lower Z coordinates to printer and hence the move is longer then expected since firmware knows where it was. Here M502/M500 does not help since it is the host having wrong coordinates. It does not know correct homing position and does not read returned coordinates in all cases.

Sorry for the delay.I checked that and you were right the Z home position was different in the host.Now I don't have that Homing problem but still when I press home button the Host (manual control part) shows number of Z 1mm less than what i set it to be.
I checked the printer setting in the host the Z home position was ok.There's another thing in those settings called printable height. I set that 1 mm less than Z home position.Can this cause the problem?
So when I command g1 z0 the distance between the nozzle and the bed is more than what I expected and if I home the printer again and command g1 z0 one more time the distance between the nozzle and the bed is different from last time.

Regards

[repetier]

Do you mean Print Area Height - that is a limit for positions in z direction. So that can be limiting it.
On the other side as soon as you send explizit Z coodinate like G1 Z0 host takes that position same as firmware and firmware will do it correctly even if host had different value before. Host is just showing what it thinks you are at but relevant for moves is what firmware says.

[mj996]

Do you mean Print Area Height - that is a limit for positions in z direction. So that can be limiting it.
On the other side as soon as you send explizit Z coodinate like G1 Z0 host takes that position same as firmware and firmware will do it correctly even if host had different value before. Host is just showing what it thinks you are at but relevant for moves is what firmware says.

Yes I mean the Print area height or Printable height in the host .I can't understand why I get different distances from the bed( G1 Z0) each time I home the printer !!
Another thing that seems unusual is the weird sound from Z stepper motor when I turn off the printer

[repetier]

Yes G1 Z0 should always move to same height at same xy position. If you had autoleveling active there are some ways to get different results if you home to z max which I think you do, right? When homing z max you need to move back from z endstop at the end so you can correct z over xy without hitting endstop - otherwise z would not adjust leading to wrong z.
But sequence
G28
G1 Z0
should always lead to exactly same position and height. If not the end stop is triggering at different positions or z moves loose steps (which you should be able to hear).

When you power off printer there is no power to make sound, so not sure what I should think about the weird sound problem. Also it would not start a move so why should it make any sounds.

[mj996]

Yes G1 Z0 should always move to same height at same xy position. If you had autoleveling active there are some ways to get different results if you home to z max which I think you do, right? When homing z max you need to move back from z endstop at the end so you can correct z over xy without hitting endstop - otherwise z would not adjust leading to wrong z.
But sequence
G28
G1 Z0
should always lead to exactly same position and height. If not the end stop is triggering at different positions or z moves loose steps (which you should be able to hear).

When you power off printer there is no power to make sound, so not sure what I should think about the weird sound problem. Also it would not start a move so why should it make any sounds.

Yes I home to Z max.I set the Endstop distance after homing 5mm for all x,y,z axis in the firmware.
I can hear some knock sounds from y stepper motor which I can sense it's vibration on the tower.So if we consider this as loosing steps here are things that I checked :

• same voltages on the stepper drivers(x,y,z).
• same belt tensions
  and here are the current speed settings for all x,y,z :
• Max. travel speed 300 mm/s
• Homing speed 100 mm/s
• Travel acceleration 3000 mm/s^2
• Print acceleration 1000 mm/s^2

by the weird sound from steppers when powering it off I mean right at the moment I press power button on my printer I hear that (fisss) sound and I also can see some little movements on the belt of Z axes at that moment.

[repetier]

Loosing steps is normally a high pitched sound. Knocking sound is more if you go back a step due to being held by some force. Can also be overheating driver then you hear it going off and on.

Dispowering sounds like no error. When motors loose power the can not hold microstep position and that can be heard sometimes.

[mj996]

Loosing steps is normally a high pitched sound. Knocking sound is more if you go back a step due to being held by some force. Can also be overheating driver then you hear it going off and on.

Dispowering sounds like no error. When motors loose power the can not hold microstep position and that can be heard sometimes.

The sound is like a car crossing some rumble stripes on the road . There's fan for cooling the stepper drivers so I don't think that's an overheating issue and I can't see any obvious backward movements in pulleys and carriages.

[mj996]

Loosing steps is normally a high pitched sound. Knocking sound is more if you go back a step due to being held by some force. Can also be overheating driver then you hear it going off and on.

Dispowering sounds like no error. When motors loose power the can not hold microstep position and that can be heard sometimes.

what issues can cause the carriages to go back a step?If they are held by some force ,which force can cause this?belts?
Are there any items to check to find the problem?

[repetier]

Normally only if you move behind physical possible position. Then you hit something. E.g. endstop reachend and move toward endstop without endstop check. But that is so loud you know that it is that.

[mj996]

Normally only if you move behind physical possible position. Then you hit something. E.g. endstop reachend and move toward endstop without endstop check. But that is so loud you know that it is that.

ok I'm sure that the carriages don't hit anything (including endstop) .Can this happen because of the speed or acceleration?
current travel speed : 300 mm/s
I lowered the speed in firmware but the actual speed of printer didn't change ! (I changed EEPROM and Host setting to match the firmware too)

[repetier]

It can also be jerk too high - in that case you loose steps and with some luck it starts moving or it keeps staying. That is at start/end. Max speed is an issue mid move if you start loosing steps there.

[mj996]

So here is what I observed.I lowered the speed by the command G1 Z0 F3000 and I didn't hear shock or knock sounds anymore!

[repetier]

50mm/s is not really fast for a delta. At which point do you hear the sound exactly? During full move/start/end? And why only Y axis.
G28
G1 Z0 F6000

moves all axis equally so they should also sound all the same.

[mj996]

50mm/s is not really fast for a delta. At which point do you hear the sound exactly? During full move/start/end? And why only Y axis.
G28
G1 Z0 F6000

moves all axis equally so they should also sound all the same.

I can't say this exactly but I tried
G28
G1 Z0 F6000
for 5 times and most of the times I hear the sound when the carriages are close to their endpoint (z=0) and when they are going up for homing I can hear another one at the middle of the way.
And it's just for Y carriage.I don't know why !

Thanks for all these helps.I'm so glad for your support.

[mj996]

Here is my log in the host :

15:20:51.066 : Info:Watchdog Reset
15:20:51.066 : Free RAM:80316
15:20:51.066 : Autoretract:0
15:20:51.066 : X:0.00 Y:0.00 Z:0.000 E:0.0000
15:20:51.066 : SelectExtruder:0
15:20:51.070 : Error:Format error
15:20:54.870 : Warning: Seems like we missed a ok, got a wait - continue sending.
15:20:54.874 : Error:expected line 1 got 11
15:20:54.875 : Resend:1
15:20:54.892 : FIRMWARE_NAME:Repetier_0.92.9 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Delta EXTRUDER_COUNT:1 REPETIER_PROTOCOL:3
15:20:54.895 : Printed filament:0.59m Printing time:0 days 0 hours 12 min
15:20:54.895 : PrinterMode:FFF
15:20:54.899 : X:0.00 Y:0.00 Z:0.000 E:0.0000
15:20:54.899 : DebugLevel:6
15:20:54.900 : SelectExtruder:0
15:20:54.912 : Error:Wrong checksum
15:20:54.913 : Resend:11
15:20:54.918 : skip 12
15:20:54.918 : skip 13
15:20:54.918 : skip 14
15:20:54.918 : skip 15
15:20:54.925 : DebugLevel:6
15:20:54.928 : SelectExtruder:0
15:21:03.802 : SelectExtruder:0
15:21:03.802 : X:0.00 Y:0.00 Z:616.200 E:0.0000
15:21:37.077 : SelectExtruder:0
15:21:37.082 : X:0.00 Y:0.00 Z:616.200 E:0.0000
15:24:41.530 : Reduced visual quality for better framerates and to protect print quality.
15:24:41.530 : You can disable this in Config->Preferences->Basic Settings->Behaviour.

[repetier]

Any reason you start with such an old firmware version? 1.0.4dev is what I would start with. Or even V2 firmware (only available on github). Could really need a tester for new V2 on delta and delta code is working already also I still need to calibrate my delta. But that is the printer type benefitting most of new V2 system and it has already RADDS support. Only thing is no config tool - you need to write 2 config files instead, but with sample configs this is not that difficult if you have some programming background.

[mj996]

Oh sorry we accidentally switched to that version on our last edit of settings in firmware.Now we're runnig 1.0.4 dev but our problem is still there.
I changed the driver but the problem is still on Y axis and there's another problem now. When I home the printer all of the carriages start going up but Y carriage stops in the middle of the way !!

[repetier]

Please try using the E2 socket for Y axis. Maybe there is a bad contact also it sound quite repeatable where things happen. And switch X and Y stepper driver so it is new socket with working driver.

Was the Y speed different? If it has double microsteps it might not reach the top. Otherwise only reason to stop is the y axis gets triggered. That can also be a problem for normal moves if you have ALWAYS_CHECK_ENDSTOPS enabled. Please make sure it is disabled. Maybe it is just crosstalk from endstop blocking a short segment on y axis.

[mj996]

Ok I swapped Y with E2 and now there's no sign of knocking or any other sounds anymore.So what's wrong with my Y socket?

PS : I also disabled ALWAYS_CHECK_ENDSTOPS in firmware and for now that problem is gone.

[repetier]

Great so it is hardware related. Either socket since swap helped or endstop related as you changed that as well. You can remove one of them if you want to know which one was real cause.

[mj996]

Great so it is hardware related. Either socket since swap helped or endstop related as you changed that as well. You can remove one of them if you want to know which one was real cause.

I tested the always check endstops option and the problem was not that. It was with the Y socket.So does it mean that Y socket is defected? Can I use the Y socket anymore?
And there is one more problem,When I command the printer to go to a specified coordinates (G1 X-140 Y-84 Z25), it will go there but after that the printer doesn't do any more commands ,no matter It's home command or other specified coordinates.
and Sometimes when I disconnect the printer and connect it again and command G28,the printer first goes to the coordinates that I commanded last time(G1 X-140 Y-84 Z25) and after that it will go to home position!!

[repetier]

I tested the always check endstops option and the problem was not that. It was with the Y socket.So does it mean that Y socket is defected? Can I use the Y socket anymore?
I would avoid it if possible. If you need the socket use it for extrusion - there it is not as bad as for motion to miss a few steps. It's strange from the repeatablility, but can't say why it makes a difference. As you see the algorithms are working correct. So maybe it has a bad soldering with connection to another pin causing the problems. Would explain repeatablity.

Regarding commands - check the host log with ack/commands enabled. That sounds like communication stack is broken and after reconnect it sends the missend motion.

[mj996]

I tested the always check endstops option and the problem was not that. It was with the Y socket.So does it mean that Y socket is defected? Can I use the Y socket anymore?
I would avoid it if possible. If you need the socket use it for extrusion - there it is not as bad as for motion to miss a few steps. It's strange from the repeatablility, but can't say why it makes a difference. As you see the algorithms are working correct. So maybe it has a bad soldering with connection to another pin causing the problems. Would explain repeatablity.

Regarding commands - check the host log with ack/commands enabled. That sounds like communication stack is broken and after reconnect it sends the missend motion.

The ack/commands was disabled so I enable it.Now we can say that the problem is almost gone but not completely.
G1 X-140 Y-84 Z25
printer moves
G1 X140 Y-84 Z25
printer moves
G1 X0 Y84 Z25
printer moves
Now we want to return to our start point So
G1 X-140 Y-84 Z25
printer doesn't move and here is what we see in the log

12:28:00.577 : Error:B hit floor
12:28:00.593 : Warning:Invalid delta coordinate - move ignored x:-8885 y:-5128 z:2000
12:28:00.593 : Warning:in queueDeltaMove to calculateDeltaSubSegments returns error.
12:28:00.593 : Warning:executeGCode / queueDeltaMove returns error
12:28:01.562 : Reduced visual quality for better framerates and to protect print quality.
12:28:01.562 : You can disable this in Config->Preferences->Basic Settings->Behaviour.
12:28:01.578 : wait
12:28:01.640 : T:-22.05 /0 B:5.85 /0 B@:0 @:0
12:28:02.578 : wait

And When We command G1 X0 Y0 z25 , first the printer wants to go to (G1 X-140 Y-84 Z25) coordinates that we commanded last time and after that it wants to run current command(G1 X0 Y0 z25).

[repetier]

.. hit floor comes if one of the slider is closer then DELTA_FLOOR_SAFETY_MARGIN_MM to the floor. This sounds like you are going very close to the physical limits of the delta. Maybe even an area where you should not be. When one of the arms need to be nearly vertical that is a very bad position. Due to angle it needs to move much faster then the others and that can easily be too much. That is also where the sliders are closest to bottom.

[mj996]

Ok I think we're in the hardest level of calibrating a delta which we should have the same distance from nozzle to bed in different spots of the bed.

So I started it by computing the appropriate Z height when we are at the center of the bed and Z=0 So the gap between the nozzle and the bed should be as the thickness of a paper (0.1mm with a bit dragging on the paper).I set it and till here everything was ok.

I understood that I have a concave surface because when I homed the printer and commanded (G1 X-140 Y-84 Z0) to move the nozzle toward X Tower ,the distance between the nozzle and the bed was about 60mm !! I think that's a huge error and something is wrong here because if I want to continue with these situation it means that I should lower my endstop too much.(~60 mm).
I even tried that and I lowered the endstop but that was a mess because when I homed the printer,the effector was too much close to the edge.I don't know what's the problem?

( As far as I know the standard way of calibrating a delta is that we should have the correct Z height in the middle and then set the gap between the nozzle and the bed in different spots and after all of these when we come back to the center position we may face another distance from nozzle to bed ,from the one that we had first time and we finally should fix this by changing the DELTA SMOOTH ROD OFFSET which is MAX DELTA RADIOUS in repetier firmware.Did I miss something?)

[repetier]

Ok that explains a lot. The convex/concave motion when moving away from xy 0,0 means the ratio DELTA_DIAGONAL_ROD and PRINTER_RADIUS is way off. DELTA_DIAGONAL_ROD is distance of the rotation points connecting slider with carrier. PRINTER_RADIUS is the horzontal distance of these 2 points when carrier is at 0,0 and hence much smaller then DELTA_DIAGONAL_ROD. While it is easy to measure diagonal it is hard to exactly measure PRINTER_RADIUS but it should be possible within a few mm so you do not get 60mm error.

Use escher delta calibration with 6 factors to calibrate the delta parameter further.

[mj996]

Ok that explains a lot. The convex/concave motion when moving away from xy 0,0 means the ratio DELTA_DIAGONAL_ROD and PRINTER_RADIUS is way off. DELTA_DIAGONAL_ROD is distance of the rotation points connecting slider with carrier. PRINTER_RADIUS is the horzontal distance of these 2 points when carrier is at 0,0 and hence much smaller then DELTA_DIAGONAL_ROD. While it is easy to measure diagonal it is hard to exactly measure PRINTER_RADIUS but it should be possible within a few mm so you do not get 60mm error.

Use escher delta calibration with 6 factors to calibrate the delta parameter further.

Thanks alot I'm working on it.
Since this morning I receive ''no start signal detected '' in repetier host log and I think that's a common issue among the users cause I found so many issues with this title.
and here are the things which I tried :

• I changed the baud rate to other numbers but that didn't work.
• I set the PORT and TRANSFER PROTOCOL to Autoselect or autodetect and no change in result.
• I tried to upload firmware with new EEPROM set and that didn't work niether.(I get Done uploading message each time I try in Arduino IDE)
• I tried both native and programming micro usb ports on due and non of them changed anything I still get '' no start signal detected '' ( I tried to send M114 and M115 commands with both ports but I got '' 1 command waiting '' notification )

[mj996]

These are 2 different operations.
G32 S2 corrects bed rotation against your delta in case it is not 100% perpendicular to the z axis of your delta.

The eeprom values correct geometric imprecisions of delta geometry that lead to the head moving up/down where it should move as a flat plane.

So eeprom is to make the swings on the bed disappear, but for the overall rotation correction you use G32 S2.
Hope you understand the difference.

I know what are you talking about.
The problem is that when I don't use auto leveling at all ( I disappointed from the whole auto leveling process and put it away and decided to calibrate manually)and I leveled the bed just by changing ROD RADIUS , TOWER ANGLES , Z-HEIGHT and ENDSTOPS OFFSETS in eeprom , The bed shouldn't go out of level each time I turn off and turn on the printer but it does.

PS : I used EEPROM editor in the host to change the values last night for manual calibrating and I didn't use M502 or M500 at all this morning.

[mj996]

Even now when I adjust the Z height with a paper in the center and turn the printer off I feel different tension on the paper next time I turn on the printer and bring the nozzle to Z0

[repetier]

G28
G1 Z0

should always feel the same. If not the homing of z differs a bit meaning the z endstops react differently.

What are your steps per mm? Homing can always vary 1-2 steps with high resolution even more. Question is what this is in mm and means in your case. 2 steps with 80steps per mm are 0,025mm - should not make so much difference but you can easily test going up/down 0,01mm a few times and see how much the paper force changes by this.

One big difference might be if nozzle/bed are hot or not. With ooze it feels also different every time. And hot extruder/bed can change shape a bit, e.g. extend the nozzle or warp a bed. So also compare under same conditions.

[mj996]

What are your steps per mm?

My steps per mm is 160.
so there should be about 0.0125 mm difference after each homing,but today there was 0.25 mm difference from last night.and I leveled the bed when the bed and nozzle were cold and it was also fine when the bed and nozzle were hot,so i believe it isn't a deforming problem.

If not the homing of z differs a bit meaning the z endstops react differently.

So after each homing there should be a difference,but it just changes when I turn the printer off not after each homing.

[repetier]

When it works without power off the precision should be ok.

The only thing you loose with power off are settings from G32 without S2. So if you did not run this between power cycles I see no reason why that should differ. But also not that changing eeprom values requires rehoming to see the result!

[mj996]

When it works without power off the precision should be ok.

The only thing you loose with power off are settings from G32 without S2. So if you did not run this between power cycles I see no reason why that should differ. But also not that changing eeprom values requires rehoming to see the result!

That's really strange to me either.The point is that if it was only a bit difference in Z-height I must have a higher or lower Z0 over all parts of the bed and then I could fix this just by adjusting the Z height but it's not just that.After each power cycle I have diffderent heights in different parts of the bed and It's like I haven't level the bed before at all and I should start adjusting all of the values (e.g ROD RADIUS , TOWER ANGLES ) again from beginning !

[mj996]

Sometimes when I connect to the host I see a message which says something like your Jerk is too low , changed the value to ........( I don't remember the number ).Can this jerk thing be the cause of the problem?
My Jerk settings in config file :
#define MAX_JERK 5
#define MAX_ZJERK 0.3

My current jerk setting in eeprom editor (Host) :
Max.jerk : 12.211 mm/s

[repetier]

You need MAX_JERK 12.3 as minimum value. The message just tells you it was modified compared to your value. Setting it to 12.3 will make the message disappear.

What is your value for ENDSTOP_Z_BACK_ON_HOME? It should be something like 20 or higher to get you away from end stops at the beginning.

Also set ALWAYS_CHECK_ENDSTOPS 0 so no crosstalk to end stops stops move in between.

These can sometimes cause unexpected positions, so better be safe as long as you do not know what is causing the problem. But what you describe happens when homing position at top differs. In that case the bed orientation also differs. But why should it differ after a reset when you do not change anything in between.

[mj996]

You need MAX_JERK 12.3 as minimum value. The message just tells you it was modified compared to your value. Setting it to 12.3 will make the message disappear.

What is your value for ENDSTOP_Z_BACK_ON_HOME? It should be something like 20 or higher to get you away from end stops at the beginning.

Also set ALWAYS_CHECK_ENDSTOPS 0 so no crosstalk to end stops stops move in between.

These can sometimes cause unexpected positions, so better be safe as long as you do not know what is causing the problem. But what you describe happens when homing position at top differs. In that case the bed orientation also differs. But why should it differ after a reset when you do not change anything in between.

Update :
I found out there are two problems in my printer :
1- The ''different Z-heights after each power cycle'' problem was actually a heating problem.
I read your suggestions carefully and found out each time that I want to level the bed it should be in the same bed temperature conditions .If I level the bed when it's cold I'll have different results for printing when the bed is hot.

2- My bed gets so hot and the temperature that the thermistor read is too low compared to actual temperature of the bed So for each print the bed goes near 80 degrees but the thermistor says it's 50 degrees.So this too much heat makes some changes in aluminum bed shape and when I turn the printer off the bed gets cold and it deforms again.

Another issue :
I watched your delta printer Auto leveling video .You bring your sliders down and put a rod between them and the bottom and with m132 s1 you set the correct offsets.
I have a question about this part : In my case I already have some offsets for endstops from the time I manually calibrated the printer to reach to Nice geometry parameters.So now if I want to do it like your video should I set the current offsets to ZERO and then command m321 s1?
Maybe I couldn't have a nice autoleveling before because I always used to ignore this part of your video or I did it wrong('endstop offset calibration part' , m321 s1)

PS : I changed my probe with a pressure sesnor and now I have 0.3mm difference between highest and lowest point of the bed.I tried G32 S2 for a couple of times but I couldn't get lower than 0.3mm difference.

[mj996]

hello

You need MAX_JERK 12.3 as minimum value. The message just tells you it was modified compared to your value. Setting it to 12.3 will make the message disappear.

What is your value for ENDSTOP_Z_BACK_ON_HOME? It should be something like 20 or higher to get you away from end stops at the beginning.

Also set ALWAYS_CHECK_ENDSTOPS 0 so no crosstalk to end stops stops move in between.

These can sometimes cause unexpected positions, so better be safe as long as you do not know what is causing the problem. But what you describe happens when homing position at top differs. In that case the bed orientation also differs. But why should it differ after a reset when you do not change anything in between.

Hello again
There's a problem with the speed of printing.
when I try to print an object in vase mode there is no matter what I define the speed (any of outer/inner perimeter ,skin or print speed) the printer prints that single layer of vase with a super slow speed and the point is that the speed of first layer and infill is ok (matches to what I define for them in slicer) and just when it comes to printing the walls (single layer of vase) it prints too slow and it doesn't match to what I define for it in slicer and finally my nozzle clogs because of the super slow movement of the nozzle.

The things I tried :

• Tried different slicers with different speed values but all of them had the same problem.
• Put the CURA speed mode on fast(on Repetier host) but it just changed the infill and first layer speeds and the speed of printing the walls was like the last time (too slow)
• Designed a 30x30x30 mm cube (with a 2x2x2 cube like hole inside)and print it.It was just like printing the vases.Normal infill and first layer speeds but super slow wall speed.
• Checked the feedrate and speed multiply in host and LCD.(both of them were 100)
• Tried to print a solid cube and it was just fine.All of the speeds were ok.

Totally the printer prints solid objects with normal speeds and the problem is just with printing objects that are in a shape of a Vase.

[repetier]

Not really a firmware problem. The problem is i think the layer time. In filament cooling definition you can define minimum layer time and simple vase mode can be much faster. To solve it slicer then reduces the print speed to one turn is the minimum layer time.
See generated gcode which speed is defined there and I guess you see it is a lower speed then what you wanted. So it is just the slicer telling to move slower.

[mj996]

Not really a firmware problem. The problem is i think the layer time. In filament cooling definition you can define minimum layer time and simple vase mode can be much faster. To solve it slicer then reduces the print speed to one turn is the minimum layer time.
See generated gcode which speed is defined there and I guess you see it is a lower speed then what you wanted. So it is just the slicer telling to move slower.

You were right.
I lowered layer time value is slicer and the the speed problem is gone but I still have problem in printing small objects.
I want to print a 5mm diameter cylinder (with 3 mm dia hole inside).When it came to print the skin of cylinder,nozzle jammed and it was just moving in the air.
I tried to lower all of the speed values to 20mm/s but it didn't solve anything!
That much speed reduction just lowered the print time for 2 seconds !I don't know is it normal !

PS : There's no matter if I put the layer time on the default value(5) or lower it and put the fan on the highest output rate.In both cases the the nozzle clogs.

[AbsoluteCatalyst]

I haven't gone through this entire thread, but for your last post:

That sounds like a common problem people run into with extremely small sized gcode extrusion amounts. Do you have relative extrusion enabled in your slicer settings by any chance? If you do, turn it off and try printing again.

Your extruder might just not be extruding/moving at all if your gcode file has very tiny E values like "G1 E0.000000023 F100" etc.
At a 5mm print, I can see that happening to a 1.8 degree stepper extruder @ 16-microsteps; especially if you have relative extrusion amounts on.

[RAyWB]

another possibility for clogging is too high retract distance .
Had this issue with e3d V6 plagiate and PLA filament especially on thin layers and small nozzles(<0.4).
for me a retract distance of maximum 5mm works on 1m Bowden setup (guess you have bowden on a delta)

and i also fully agree with AbsoluteCatalyst

[mj996]

That sounds like a common problem people run into with extremely small sized gcode extrusion amounts. Do you have relative extrusion enabled in your slicer settings by any chance? If you do, turn it off and try printing again.

Thanks for the reply.
There's no such a thing called''relative extrusion'' in the slicer i use (I'm using cura engine in repetier host).

Your extruder might just not be extruding/moving at all if your gcode file has very tiny E values like "G1 E0.000000023 F100" etc.

I checked the G-code file ,the smallest extrusion value is >0.01

[AbsoluteCatalyst]

Then it may most likely be as RAyWB suggested. Retraction might be a little too high for those small dimensions

[mj996]

Had this issue with e3d V6 plagiate and PLA filament especially on thin layers and small nozzles(<0.4).

Thanks for the reply RAyWB.
I'm using E3D V6 and 0.4 nozzle.
The thing that I'm trying to print is like a 3mm dia spacer.I don't see any retraction in printing such a thing.

for me a retract distance of maximum 5mm works on 1m Bowden setup (guess you have bowden on a delta)

My retraction distance value is 4 mm for a 60-70 cm bowden tube

[mj996]

Then it may most likely be as RAyWB suggested. Retraction might be a little too high for those small dimensions

Thanks by the way.
I'll try to print the thing with 2 copies beside it.Maybe giving a time to layers to cool down will fix the problem and I think I should consider the retraction distance for this case.The 4 mm value is a bit high for it.

[RAyWB]

on my main printer i changed to the lite Version of V6 . it´s easy to swap by changing heatbreak only.
in this version the ptfe liner goes down to the nozzle so theres no chance for clogging.
from my experience it does the trick and there is not that critical retraction distance.
(works for 1.75mm filament only)

[mj996]

on my main printer i changed to the lite Version of V6 . it´s easy to swap by changing heatbreak only.
in this version the ptfe liner goes down to the nozzle so theres no chance for clogging.
from my experience it does the trick and there is not that critical retraction distance.
(works for 1.75mm filament only)

Ok,I'll give it a try.
But I think to print such tiny objects I should do some changes somewhere in slicer.
Today I printed a test cube. There were some uniform horizontal lines on the walls of the cube.

https://imgur.com/5u6Yf3n

Is it a kind of over extrusion?
My extrusion multiplier value is 100.

The other thing is that when I slice something with Prusa slicer it will print the first layer just fine even better than cura engine (with same first layer height, layer height, speed of first layer values) but the problem with this slicer is that when it comes to print the second layer the nozzle clogs after printing few lines.
I read in some threads that it can be the fans or the speed issue.
I turned off the cooling fans and also Played with the speed values but the problem was still there.

[RAyWB]

on a cartesian system i would guess on a loose belt , pulley or coupler... but as I´m not familiar with deltas i have to pass.
sorry

[mj996]

on a cartesian system i would guess on a loose belt , pulley or coupler... but as I´m not familiar with deltas i have to pass.
sorry

So you think that it's a mechanical problem?
Is there a possibility that it comes from the temperature?

[RAyWB]

as said , on a cartesian system i would guess on mechanical issues as it seems to be repeated.
don´t think it depends on temperature

[mj996]

Not really a firmware problem. The problem is i think the layer time. In filament cooling definition you can define minimum layer time and simple vase mode can be much faster. To solve it slicer then reduces the print speed to one turn is the minimum layer time.
See generated gcode which speed is defined there and I guess you see it is a lower speed then what you wanted. So it is just the slicer telling to move slower.

Hi,
I'm using SD card as EEPROM on RADDS.I always use eeprom configuration on repetier host to change the values.Anyway I wanted to pick a file from my sd card so I removed the card from board , picked my file and then re-inserted the card into the board (while the printer was off) but when I turned on the printer my EEPROM settings were gone !!!! The shown values on eeprom configuration (repetier host) were those which I uploaded from Arduino IDE some months ago !!!
Does that mean that I lost my settings?? :((

[repetier]

If you have no backup of the eeprom file they yes they are gone.

[mj996]

If you have no backup of the eeprom file they yes they are gone.

A binary file called EEPROM is available on that SD CARD.Isn't it a backup?

[repetier]

No that is the last written EEPROM file. That is what you should backup if you made many changes. But you can also use the eeprom backup solution in repetier-server to save it and restore from there.

[mj996]

OK I'm a bit confused now.

that is the last written EEPROM file

Does the last written EEPROM include my last edit in eeprom configuration (repetier host)?
Or it just includes the last values which I upload from ARDUINO IDE ?

Sorry if I'm asking dump questions.

[AbsoluteCatalyst]

The eeprom file updates whenever you change eeprom configuration on repetier host or repetier server. (Or M500 commands)
It's usually always up to date.

Your Arduino IDE settings are considered the default/factory eeprom settings.
If you had no eeprom file in the sdcard, one is created directly from these settings.
If your eeprom.bin file is corrupt, it'll also revert to these stock settings.

It seems your eeprom.bin was reset for whatever reason
Try running a M501 command to import the .bin you currently have in the sdcard now to see if it still has your previous settings, unlikely though.

[mj996]

The eeprom file updates whenever you change eeprom configuration on repetier host or repetier server. (Or M500 commands)
It's usually always up to date.

Your Arduino IDE settings are considered the default/factory eeprom settings.
If you had no eeprom file in the sdcard, one is created directly from these settings.
If your eeprom.bin file is corrupt, it'll also revert to these stock settings.

It seems your eeprom.bin was reset for whatever reason
Try running a M501 command to import the .bin you currently have in the sdcard now to see if it still has your previous settings, unlikely though.

The eeprom file updates whenever you change eeprom configuration on repetier host or repetier server. (Or M500 commands)
It's usually always up to date.

Your Arduino IDE settings are considered the default/factory eeprom settings.
If you had no eeprom file in the sdcard, one is created directly from these settings.
If your eeprom.bin file is corrupt, it'll also revert to these stock settings.

It seems your eeprom.bin was reset for whatever reason
Try running a M501 command to import the .bin you currently have in the sdcard now to see if it still has your previous settings, unlikely though.

Thanks Moses.
I got it.
It seems like the current eeprom.bin is corrupted and M501 doesn't make any difference.
At least now I know that I should export my EEPROM settings to be able to back it up later!!