Navigator DFE for 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 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 DFE.
There is a 6gb buffer in the printer. There is a buffer of variable size which uses available RAM in the DFE computer.
So, looking at these 5 controls again with that in mind:
1. StreamOnStart - affects DFE buffer behavior
2. The Duraflex Spooler page pool. - sets DFE 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 DFE 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 DFE buffer settings
StreamOnStart
Stream On Start bypasses the DFE 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 DFE-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.
With StreamOnStart, the DFE buffer will still be used once the printer side buffer is full. When the printer side buffer fills up and the RIP has processed pages available they will go to the DFE buffer. StreamOnStart uses the DFE buffer as an overflow but not as a hedge against data underrun.
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 DFE buffering is enabled.
If you set to StreamOnStart=1 then it is on and DFE buffering prior to start of print is disabled. The buffer is used only for overflow in this case.
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 and is backed by the OS paging file. 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 more important.
Setting this number from between 1gb and 16gb is a good 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.
Setting this to a very large size can be useful in some situations. e.g. where there is a large distance between the front and back stage print heads.
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 is checked. It could just be called “Print my jobs”. Because turning it off stops you from printing anything until you turn it back on.
This one is a bit of a special case.
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). That is normally what is desired.
If unchecked, the job will not be started and will sit on the press (printer buffer) 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%. Which is 3000mb or 3gb. 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. The buffer is a built up ‘head of steam’ to try and get ahead of any 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 caused by 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 below for some ideas about changing this value.
Example use cases
Example case 1. We 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 is challenging to render (RIP) and 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 DFE buffering.
When you noticed the problem you had Print Buffer Start Trigger at 50% (default) and StreamOnStart on (default).
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). Then the press will pause printing while the buffer fills back up to the start trigger of 50% full. You have a leeway of about 53 pages until you reach the underrun pause trigger. When you eat through that 53 page tolerance and the DFE notices you are running out of data, it pauses the press.
So let's try to avoid pausing so much.
Set your Print Buffer Start Trigger higher and set the DFE 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 some extra start up time, the press will pause less.
Example case 2. We do 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.
First of all, how would you recognize this situation? Big pauses in between jobs while the printer does cleaning and maintenance.
When you noticed your small jobs often fail to chain you had 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 (DFE 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:
StreamOnStart=1
Page Pool 1024mb
Start Trigger 50%
Underrun Trigger 15%
We won't try to fill the DFE 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 fill the DFE-side buffer prior to starting the printer.
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%