blobs. why delay after retract/restart

Dear all

I am a newbie here. I built an ormerod 2 during the christmas recess. I am quite happy with its performance but I have an issue with blobs.
Each time the printer has to move to a new location or a new layer a retract/restart happens. That is fine of course. But after retract and then the restart (the G1 commands with only E) the printer waits a few seconds before it does the next command. This gives very ugly bobs on my printed structures. I am not shure whether the it is the 'retract' or 'restart' move of the filament that gives the blob. I should make as test structure for that. However i am sure that it is due to the retract/restart. If I disable retraction completely the blobs are gone but I get of course onwanted little threads between the position. Can somebody tell me why the printer is delaying after each retract/restart (two delays. it delays after each G1 Ex) command. I don't find a setting to kill it. It is also annoying because it considerably slows down the printing.
I use the firmware from the official reprap repository. (RepRapFirmware-078c-18-09-2014. That was on my duet when it came and is what the site says is most recent?)

kind regards,

wim

Hi wim, welcome to the forum!

I don't see any delay after retract/restart. Are you printing from SD card, or over USB or the web? If you print directly over USB or over the web, sometimes the data rate can't keep up with the printer. So it's best to print from SD card.

You are using the latest official firmware, however a lot of users are using either my firmware fork or zpl's. You can find a list of difference in my fork compared to the official firmware at [github.com]. The binaries are at [github.com] (use the 0.78za version). If you switch to using my fork, you will need to update the web interface files and subdirectories in /www on the SD card, but not the config or homing files in /sys

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dear dc42

thanks!
i am printing from SD so that is not the issue. It is also far to systematic related to the retract/restart
I will try with your firmware but need some (weekend ?) time.

I will keep you posted.

kind regards,

wim

Can you post a gcode file that shows this problem? I'm wondering whether the problem is in the gcode rather than the firmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dear

take the whistle.g from de gcodes directory on the SD card e.g. See also fragment below
All my files have it. I also made i file that just retracts /moves /restarts/moves/ retracts /moves /.... 10 times.
The delay is also there.

problem fragment
(..)
G1 F1800.000 E-4.00000 ; it will wait after this
G1 Z0.240 F3600.000
G1 X100.357 Y87.431 F3600.000
G1 E4.00000 F1800.000; it will wait again after this
(..)

Using absolute extrusion coordinates does make a difference.

kind regards,

wim

Quote
wdehaene
dear

take the whistle.g from de gcodes directory on the SD card e.g. See also fragment below
All my files have it. I also made i file that just retracts /moves /restarts/moves/ retracts /moves /.... 10 times.
The delay is also there.

problem fragment
(..)
G1 F1800.000 E-4.00000 ; it will wait after this
G1 Z0.240 F3600.000
G1 X100.357 Y87.431 F3600.000
G1 E4.00000 F1800.000; it will wait again after this
(..)

Using absolute extrusion coordinates does make a difference.

kind regards,

wim

I'm puzzled! I have never seen that issue, and I would be surprised if there is a bug in 0.78c that causes it. I suggest:

1. Post that test file you mentioned, so we have something concrete to test with.

2. Make sure that debugging is turned off (M111 S0).

3. Try setting axis compensation and bed compensation to zero. There is a bug in 0.78c (fixed in my fork) that only manifests itself when axis compensation is enabled - although AFAIK it doesn't affect extruder moves.

4. Also try with my firmware or zpl's.

Are you using the USB interface or the web interface?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dear

i tried the stuff you said
- interface (usb or ethernet) does not matter
- M111 S0 does not change anything

How do i switch of axes compensation?

I updated to your firmware. The testfile (see attachment 'testE.g', I also include my sys files) still delays in the place i indicate in the file. there was some inaccuracy in my previous description: the unwanted delay is only after the restart, not after the 'negative' retract in this file. The test is: boot the machine. home all axes. print testE.g. Right before this post i did it without usb connection. i repeated after sending an M111 S0

Your firmware/interface tempts me to go for a second extruder but first this ...

Having it on both firmwares suggest another cause. But what?. Or its a common firmware issue.

Thanks for all the help

regards

wim

Maybe post your config.g file in case it is something in that. Is the delay perhaps just the time it takes to move the extruder? i.e. Is the extruder gear stationary during part of the delay, or is it moving all the time? Retract cycles do cause a delay because they take time to execute, but it should be fairly brief. Maybe you have a very slow max. extrusion speed set somewhere?

Dave

I was going to suggest that. If the speed of the extruder is set too slow you could have that effect.

dear dave

I'll do some more experimenting. If I can find some time post a movie about the behaviour.
(the extruder is stationary during the delay. It moves fast during retract/restart). The config.g is with my other sys files in the zip file i posted before. The test file is there also under gcodes.

thanks for the inspiration. Your firmware is anyhow a very nice upgrade. The webserver actually fully works!

regards,

wim

dear dave

on the link below you find a little movie showing the issue: watch the extruder gear move in two directions and then comes the delay ...
[homes.esat.kuleuven.be]

regards

wim

Try changing your config.g to the following (I have removed lines that I do not believe are necessary or might have an effect on what you are experiencing). If that does not change anything, try removing all the lines that deal with compensation (starting M556 or M557) and also for testing purposes power up with the bed and X axis near zero and enter "G92 X0 Y0 Z0" instead of doing any homing before running your test file.

;M110
M111 S0
M550 PMy RepRapPro Ormerod 2
M551 Preprap
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED
M552 P192.168.1.14
M553 P255.255.255.0
M554 P192.168.1.1
M555 P2
G21
G90
M83
M906 X800 Y1000 Z800 E800
M569 P0 S0
M92 E420
;M558 P2
G31 Z2.2 P546
M557 P0 X50 Y0
M557 P1 X50 Y180
M557 P2 X215 Y180
M557 P3 X215 Y0
M556 S78 X0.25 Y-0.05 Z0.05
;M201 X500 Y500 Z15 E500
M203 X15000 Y15000 Z100 E3600
;M566 X1200 Y1200 Z30 E1
M563 P1 D0 H1
;G10 P1 S-273 R-273
;M110

Dave

Edited 2 time(s). Last edit at 01/11/2015 10:03AM by dmould.

I just tried your testE.g file on my Ormerod, which is running experimental 0.80c-delta-dc42 firmware. There are no delays, however it moves much more slowly than in your video. This is because the feedrate in your test file is set to 300mm/min, whereas the default minimum feedrate in 0.78 series firmware is 900mm/sec AFAIR (except in some of my 0.78 versions in which it is reduced to 600). My 0.80 series does not have minimum feedrates.

I'm wondering whether trying to use a feedrate lower than the minimum has anything to do with the problem - although I am not aware of any such issue. Can you try your testE.g file with the feedrate for all the XY moves changed to 1000?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Dave
the M566 line.
You are terrific. The delay is gone now. It was the M566 line! If I throw it in manually the problem reappears. I did the 'E1' because the original file had such a large minimum speed that I had some calibration issues.

You removed the M558 P2 line. Don't I have to throw it in again. If not my proximity Z probe is not operational? If I do it manually the delay problem does not reappear.I also noticed that the range of that sensor is totally different. It needs to be much closer to the bed before it reports something. I can recalibrate but it seems strange to me. Is this an effect of the new firmware?


Thanks a lot!!

Wim

Dear all

a little update: throwing in the M566 P2 line before homeing, bed levelling, ... Solved the issue mentioned in previous post.
Thanks Dave and all the other people who replied for helping out. I hope I can be of any help one day too but that will take a lot of 3D fun first

regards,

wim

Quote
wdehaene
Dave
the M566 line.
You are terrific. The delay is gone now. It was the M566 line! If I throw it in manually the problem reappears. I did the 'E1' because the original file had such a large minimum speed that I had some calibration issues.

You removed the M558 P2 line. Don't I have to throw it in again. If not my proximity Z probe is not operational? If I do it manually the delay problem does not reappear.I also noticed that the range of that sensor is totally different. It needs to be much closer to the bed before it reports something. I can recalibrate but it seems strange to me. Is this an effect of the new firmware?


Thanks a lot!!

Wim

Yes - my suggestion was only for the purpose of seeing if it fixed the issue and if so you could find the exact line that caused it - as you have done. Then put back the lines that are not a problem (though I see no purpose in having the M110 commands).

Dave