Duraflex has 2 buffers with some choices.

This level of choice exists to accommodate different types of printer usage.

Basically the options boil down to "do you want a lot of buffering or do you want to start the press as soon as possible?"


I will enumerate the options.

1. StreamOnStart

2. The Duraflex Spooler page pool.

3. Auto-Start on IDLE

4. Print Buffer Start Trigger

5. Print Buffer Underrun Trigger


It is important to understand that there are two buffers in the system.

One in the printer and one in the RIP.

There is a 6gb buffer in the printer.  There is a buffer of variable size which uses available RAM in the RIP computer.


So, looking at these 5 controls again with that in mind:

1. StreamOnStart - disables RIP buffer

2. The Duraflex Spooler page pool. - sets RIP buffer size

3. Auto-Start on IDLE - affects printer buffer usage

4. Print Buffer Start Trigger - affects printer buffer usage 

5. Print Buffer Underrun Trigger - affects printer buffer usage 

There are 2 controls for the RIP side buffer and 3 controls for the printer side buffer.  These buffers are on either side of a 10gb ethernet connection.


First I will explain each of the five options. 

Then I will describe three example use cases and how to configure the buffers for each case.


The RIP buffer settings


StreamOnStart 

Stream On Start bypasses the RIP buffer to start the printer as soon as possible, rather than delaying start to build up a buffer of ripped jobs.

If you want to fill the RIP-side buffer with data before printing, then turn this off.  

If you want the printer to start printing as soon as possible after a page is available, then turn it on.


You control it by editing the file at  %AppData%\Roaming\Xitron\Duraflex\DuraflexSpooler.ini  


If you set to StreamOnStart=0 or if the line is missing entirely, then StreamOnStart is off and RIP buffering is enabled.

If you set to StreamOnStart=1 then it is on and RIP buffering is disabled.



The Duraflex Spooler page pool

This setting, available in the spooler window behind the Configure button is where you set the page pool size.


It's set to 2gb in the example above.  It uses RAM.  So be mindful of how much RAM is in your computer.  You'll want 8gb reserved for the rendering engine and the OS.  Or more.  If you set your system with Stream on start on (=1) then this setting becomes less important. You could set it low in that case. (1024mg)  If you set stream on start off (=0) then this number becomes important.  

Setting this number from between 1gb and 16gb seems like the outer range.  Depending on available RAM.  I'm thinking here of a computer with 32gb of RAM.  You could certainly find a computer with more RAM than that and then use a larger buffer.



The printer buffer settings

The next three are all set in the server under Navigator Server/Configure Device



Auto-start on IDLE.
The default state for this item is checked. It could just be called “Print the jobs”. Because turning it off stops you from printing anything until you turn it back on.
If checked, the software will automatically start the print process when a job is submitted to the press (subject to the print buffer start trigger).
If unchecked, the job will not be started and will sit on the press waiting to be printed. This can help you to queue up jobs to the press before starting.   It might become very important to you if you are trying to chain together very small jobs (e.g. multiple 1 page jobs that you want to print without gaps or without mid-job servicing)  If so, look at this. 


Print Buffer Start Trigger (%)

This is a trigger that decides when to start printing (as long as Auto-start on IDLE is checked)


The default value for this item is 50%.  This is 3000mb.  The press buffer is 6gb.  

There are two conditions for this trigger.  


Percent of buffer filled 

OR

an entire job is buffered.


That is to say:

The software will wait until the specified trigger percentage of the press’s print buffer is full of job data before starting the print cycle.

OR

If all of the job’s data is sent to the press, then the job will start the print cycle regardless of buffer percentage used.


Why increase this buffer? While the software renders the pages of the job very rapidly and the network transfer to the press is also rapid, occasionally network and rendering issues may cause pages to be send to press at below optimal levels.
The software will wait until the specified trigger percentage of the press’s print buffer is full of job data before starting the print cycle, in order to build up a ‘head of steam’ to try and minimise any issues caused by network or rendering issues which could result in a data underrun* and a failed job output.
 If all of the job’s data is sent to the press before this level is reached, then the job will start the print cycle anyway.  If the entire job is in the buffer, then it cannot underrun.


*a data underrun is when the printer has used up all of the data in its buffer and there is nothing left to print but the job has not completed yet.  Usually networking issues or RIP speed problems.  

This brings us to the next trigger.


Print Buffer Underrun Trigger (%)

It's a "pause" trigger.  As a companion to the Print Buffer Start Trigger, this value is used to prevent the press running out of data when printing very complex jobs that take a long time to render, by pausing the job if the buffer level falls below the specified level, and then waiting for the buffer to refill above the Start Trigger or for all of the job’s data to be in the press’s print buffer.

This trigger will not activate if, when the buffer falls below the specified level, all of the job’s data is in the press’s print buffer.  This is because, if the entire job is in the buffer, then it cannot underrun and the job will complete normally.


The default value for this item is 15%. This is a good value.  The press’s buffer is 6000MB and a CMYK US Letter page is about 80MB, so 15% equates to about 11 pages. The pause process usually requires about 5 pages to complete, so 15% includes a safety margin.


To explain this last comment:  If you hit pause, we stop sending data to the printer.  The printer does not usually pause immediately.  It takes a few seconds until it will stop, cap the heads, and wait.  If your printer buffer only held 2 pages at the time you hit the pause button, you could get a data underrun error. 


Could you go smaller than 15%?  Sure, if you need to.  Maybe down to 10%.  But experience shows that once you get below 10% you are in danger of having data underrun errors cancel your job and stop the press. Read the use cases for some ideas about changing this value.




Example use cases


Example case 1.  I focus on medium to long run jobs of high graphic complexity and the RIP isn't keeping up.

I mean "medium to long run" in the context of digital print!  Let's imagine run lengths of 5000 pieces, #10 envelope or labels at 10x4.25", full variable data, each page different.

If the designer went wild with transparency, vector nodes, image resolution or some other design choice that threatens to cause data underruns, what could you do?

First of all, how would you recognize this situation?  Lots of pausing.  If the RIP is having trouble processing a job at the speed of the press or faster, then you will notice the printer pause while we catch up.  This is the Print Buffer Underrun Trigger in action.  That underrun protection trigger is doing its part to prevent an error from stopping the job entirely.  Once in a while this is fine.  But if it's happening a lot you have a few options.  

1. talk to the designer or the prepress department and get a better handle on input file design

2. slow down the press 

3. change the RIP settings regarding buffering.


Imagine you had Print Buffer Start Trigger at 50% (default) and StreamOnStart on.  

You can buffer 75 labels or envelopes.  If the RIP is slightly too slow, you'll run through that buffer and eventually reach the underrun trigger of 15% (22 pages).  You have a leeway of only about 53 pages until you reach the underrun pause trigger.  When you eat through that 53 page tolerance and the RIP notices you are running out of steam, it pauses the press.


So let's try to avoid pausing so much. 

Set your Print Buffer Start Trigger higher and set the RIP spooler buffer way up high. Turn StreamOnStart off. Maybe choke the underrun pause trigger back.  Get as much buffer usage as possible.


So:

StreamOnStart=0

page pool of 12gb.

Print Buffer Start Trigger 100%

underrun trigger 10%


Now we will take a few more minutes to start the press while we fill these buffers, but then we'll have 450 pages buffered up.  This gives us a bigger head of steam and a better chance to make it through.  We'll have over 8 times more leeway (435 pages buffered before the underrun trigger instead of 53 pages) so, at the expense of a little extra start up time, the press should pause a lot less.


Example case 2.  I run very short run jobs with job chaining.

See a definition of job chaining and some more use cases here.

With smaller jobs, the time taken to build up several pages in the RIP buffer can cause the job chain to break because the printer sees not enough pages have been transferred to the printer in time for the chain.  

Imagine you have StreamOnStart set off (=0), Print Buffer Start Trigger at 50% and Page Pool at 4gb. You are running 5 jobs in a row that you want chained but they do not chain. 

The run lengths are 5 pages, 25 pages, 80 pages, 100 pages, 50 pages.

The printer decides to chain as long as it sees 8 pages in the buffer. 

What happens in the configuration you have here is that we buffer up the first job (5 pages) and then send it on to the printer, which buffers it up all the way.  It prints as soon as it's all the way in.  We are ripping the 25 page job and filling the page pool (RIP buffer), but before we get 8 of the pages into the printer buffer, it is done printing and the chain is broken.


So, there are a couple of things to do here.  

1. Try to start your jobs with the biggest page count up front, instead of the smallest. Give us some time.  That might actually fix it.

2. Turn on StreamOnStart (which avoids using the page pool buffer and sends directly to the printer buffer.


So, new settings are 

StreamOnStart=1

Page Pool 1024mb

Start Trigger 50%

Underrun Trigger 15%


We won't try to fill a RIP buffer before filling the printer buffer and your jobs should flow through.  In this case, if you still don't chain you may have hardware issues (network not fast enough, computer not fast enough).


Example case 3.  Everything is going great for me!

Here I will explicitly say what we recommend if your hardware is fast, your jobs are well designed, and you want the system to work as best as it can.

It turns out it's the same settings as use case 2.


If your computer is fast, your network connection to the printer is reliable, the RIP isn't having any trouble with your files, then you don't need as much buffering.

So you'll start printing faster if you don't use the RIP-side buffer.  

You'll also reserve more of your RAM for the RIP and screening engine.


StreamOnStart=1

Page Pool at 1024mb

Print Buffer Start Trigger at 50%

Underrun pause Trigger at 15%