Ooze Prevention

Just like to start off by saying what great firmware you have developed here. I really like being able to control so many parameters. I have a somewhat basic question (and I hope I am posting in the correct spot):

The question is "Classic Mode" vs. "Fast Mode" for ooze prevention. Classic works great, but tends to leave noticable blobs on complex-curvature models. I understand this may be an adjustment related to the "k" value which I am working on. In fast mode, the complex shapes come out great, but there is noticable ooze between segments of the model. I have played around with many different factors, but am unable to come up with a solution. On simpler shapes, such as a Prusa X Carriage, in fast mode, the holes are not coming out well, with lots of ooze present. On classic mode, the X Carriage comes out near perfect, but obviously a slower overall build time with all the retractions.

Any suggestions? I am using a Lulzbot .5mm nozzle with metric Z axis, 3mm ABS at 230 C, Gen 6, GT2 belts and perfect calibration otherwise. I also use Slic3r 7.2b, and for the small parts am generally printing at 30-40mm/s. For larger parts, prinintng at about 135-150 mm/s. One thought I had is that the ooze tends to be more apparent right after a "fill" section is printed. I am wondering whether the pressure for the fill section naturally spills the ABS over to the next printed segement (and thus forms the unwanted bridge to that part of the print).

Thank you!

Erick

From your description I see you had some problems understanding what the OPS does. It is a replacement for the retraction set in slicer. If the move after a printing move is longer then min-distance, the extruder will retract with the speed set with

#define EXTRUDER_SPEED 18.0

Set the max. extruder feedrate to 60*EXTRUDER_SPEED
No acceleration is used here so values around 15-25 are normal. 18 is the limit of my extruder but this can differ from extruder to extruder.

How far it retracts is set with OPS_RETRACT_DISTANCE. This needs to be enough to stop oozing for the travel time, normally 1.5 to 3mm is needed.
If you use OPS you need to set retraction length in the slicer software to 0.
The classic mode then does the same your slicer would do. If you have comb in Skeinforge activated, you need to set OPS_MIN_DISTANCE to 0 to work correctly in any case.
The real advantage starts with the fast mode. Here you can start your travel move before retraction is finished. For me 50% with 3mm retraction is a good value. This means after 1.5mm is sucked in, the move will start continuing to suck in further 1.5mm. And it tries do unwind the retraction short before it reaches the next printing point. Thats what's gaining the speed. If you have a direct extruder you need to make sure OPS_RETRACT_BACKSLASH is 0 otherwise you will get blobs where printing starts.

The k value you mentioned is the setting for the advance algorithm and has nothing to do with the ops. It adds additional steps during acceleration and reduces steps during deceleration to add the needed additional pressure. It is a quadratic dependency assumed which results in quite a lot steps at 100mm/s for high k-values (40-80). It has some effect but it has it's limits. It doesn't compensate the errors completely, or at least I couln't get it to do so. I'm thinking about some improvements here, but they will need testing to see if they are better.

With the blobs on complex curvature models. This is the most demanding part for the firmware, but the ops has no effect on this. Make sure you use version 0.62 which removed a possible delay causing small blobs. If you already do, make sure you see no BLK messages in your log. If you see a BLK the firmware resp. your board didn't catch up the many short segments you printed in your model. Normally you have a buffer which is filled with 15-16 moves in advance. This gives you some safety and place for the path planner to optimize the path. If you have many very short moves in a row the pre computation of the moves becomes the dominant factor and and your buffer starts to empty causing otherwise unneeded acceleration/deceleration and waits which are indicated by the BLK message. This is handled with these parameter:

/** \brief Number of moves we can cache in advance.

This number of moves can be cached in advance. If you wan't to cache more, increase this. Especially on
many very short moves the cache may go empty. The minimum value is 5.
*/
#define MOVE_CACHE_SIZE 16
/* 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.
*/
#define PATH_PLANNER_CHECK_SEGMENTS 7
/** \brief Low filled cache size. 

If the cache contains less then MOVE_CACHE_LOW segments, the time per segment is limited to LOW_TICKS_PER_MOVE clock cycles.
If a move would be shorter, the feedrate will be reduced. This should prevent buffer underflows. Set this to 0 if you
don't care about empty buffers during print.
*/
#define MOVE_CACHE_LOW 12
/** \brief Cycles per move, if move cache is low. 

This value must be high enough, that the buffer has time to fill up. The problem only occurs at the beginning of a print or
if you are printing many very short segments at high speed. Higher delays here allow higher values in PATH_PLANNER_CHECK_SEGMENTS.
*/
#define LOW_TICKS_PER_MOVE 400000

If you have no sd card you could try these settings:

#define MOVE_CACHE_SIZE 32
#define PATH_PLANNER_CHECK_SEGMENTS 10
#define MOVE_CACHE_LOW 20

These give more safety and also more room for optimization.

---

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!

Thank you for the information. I am still not able to solve this problem though. I suspect it may have something to do with the cache. Maybe there is too much going on with the commands for the infill. When I tried putting in:

#define MOVE_CACHE_SIZE 32
#define PATH_PLANNER_CHECK_SEGMENTS 10
#define MOVE_CACHE_LOW 20

the computer was unable to connect to the Gen6 board. Any ideas?

When you are only with these settings unable to connect your ram usage is too high. Make sure sd card is not compiled. One move cache entry need 111 bytes, so maybe 16 extra = 1776 byte was a but much. The gen6 has only 4096 byte of ram. Try these settings instead:

#define MOVE_CACHE_SIZE 22 
#define PATH_PLANNER_CHECK_SEGMENTS 10 
#define MOVE_CACHE_LOW 16

I noted one thing you said about infill. If your infill is faster then the parameter, then the starting of the perimeter will get more filament at the beginning until the higher pressure from the infill is reduced. If you use my host you can create the second test scenario with 20mm/s and 100mm/s as speeds and you can see it clearly. That is what the advance algorithm tries to compensate. I say try because it gets better but doesn't vanish completely.

---

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!