Dynamic Input Tray Selection

OL Connect Professional Designer
1

I have created Connect documents which print to PostScript printers without any issues.
There is requirement to print each document type to specific printers and from specific trays on these printers.

The data file will have fields for the printer and the tray to use.

So for instance:

Classified documents will print on printer 10.10.10.10 from Tray 4
Statements on 10.10.10.09 from tray 1
Payslips on 10.10.10.05 from tray 7
etc…

But obviously, this information could change depending on the availability of the printers and the data files will always include the printer and the tray information.

How can I configure dynamic input tray selection in Connect?

2

Hi Ssime,

You are going to have to create multiple output resets for the printers involved here in order for this to work especially as if you have multiple types of printers they may require different tray instructions. Unfortunetaley you can’t select output presets based on variable in create output preset.

As such what you’d have to do is extract form the data what printer and tray combination you need and then run through the print content and job preset as normal then use a logic tree to select the appropriate output preset.

However if this is system is close to being an ad hoc or on demand print system where users can send work to be printed on any of the systems printers, I’d suggest having a look at whether an OL Connect Send can work better for you in this circumstance

Hope this helps

Alex Banahene

3

Do you realise that you are asking us to create hundreds of output presets?!!! wow!

We have 4 different print rooms located in 4 different cities with a total of 71 (and counting) printers. Each printer could have between 5 and 15 trays.
So if I underdand correctly I have to create about 500 output presets, one for each tray of each of the printer and have 500+ different branches in my process. Is that right?

We halso can’t have a print job spending time checking whether it should go to this branch or the next. It would take ages before it actually finds the correct printer and tray! In some cases, the job needs to be printed in less than 10 seconds as the customer will be waiting at the till for their invoices.

We are taking jobs from a variety of customers and shops via various FTP Input\ LPD or Winqueue accounts.
We need to be able to automatically route the job to the right printer and select the correct tray. The printer and the tray information is always in the data.

There must be a much better and more efficient solution to what you are suggesting.

4

One way could be to always output a PDF and in Workflow, extract the IP and tray into variables.

Then, based on the value of the tray variable, dynamically build PJL command to be added in front of the PDF file (actually inside of it).

In Workflow, you can dynamically redirect a job to an IP address by using the Printer queue Output plugin.

Of course, all of this is based on the premises that all of your printer can natively print PDF (without going through a driver) and respond to PJL command.

5

Hi Ssime,

I don’t think Alex meant that you would have to create an output preset per printer. But you probably do not need to have an output preset per printer type. Perhaps an output preset per printer with a certain configuration. For instance, Printer type X with 5 trays, and Printer type X with 15 trays.
You would then want to have tray mapping in that output preset for all the paper types that you want to use on that printer.

For printers that have a generic way to select trays (IPDS, PCL, generic PostScript, and a some specific printer definitions), that would mean that you create entries in the tray mapping table of the output preset. In case of PostScript printers for which you have a PPD, you can create a printer definition from the PPD, and use “Dynamic PPD mode”.

To control this from the data, you would look at setting up media types in the templates that you use for Content Creation. If you have a template per (group of) document types, you often just configure it directly in the template’s Media and Sections. For the media, it’s best to choose good names, and also set the Media type in the Characteristics. If you use “Media 1” in every template, but it actually refers to a different paper type, then that’s probably going to make things difficult. It may make sense to also explicitly set the color and weight attributes in the Media’s characteristics, but often the size and the type are enough.

It’s also possible to use scripting to choose the media type for a section. If you are using a generic template for all/most of your output, then that’s probably a more effective way to get it done. In any case, you would be explicitly configuring the every Media that can be used by a certain template.

All of the above is the most generic approach that will also work for jobs where you have to be able to switch trays on a page by page basis within a document.

This will allow you to get the print job with the right tray selection. You can use Connect Workflow to send the job to right printer based on the data.

If you can print the stationery with the job, instead of using preprinted paper, you may be able to reduce the number of trays (and perhaps printers) that you need. Connect has different ways that you can add stationery as a background. One of them is in the Media of the template, and is called “virtual stationery”. Every output preset has a checkbox that will cause that stationery to be printed with the job.

I hope this helps you move forward.

1 Like
6

Thank you to all for your responses.

All printers are PostScript with sevaral different brands (Sharp, KM, Canon, Lexmark, Epson, …ect) and each brand with several different models between them.

So basically what you are saying is that I should create an output preset per model and configure the tray selection for all the trays available in that model.

So I still end up with a minimum of about 35 output presets. The problem here is that if a customer normally prints to printer A from Tray 7 using output preset 1 which has a maximum of 8 trays as per its PPD and that printer A isn’t available on a given day, they are asked to redirect their job to a backup printer. Now backup printers are usually smaller printers with up to 5 trays. Tray 7 isn’t available on most backup printers. This requires staff intervention to change the process so they can print from one of the tray 1-5 on the backup printers.

It is still not a fully dynamic and automated solution where we want to minimise downtime as much as possible.

The real solution for us would be to make Tray fields dynamic fields through job metadata or workflow jobinfo or event new runtime parameters.

7

Well, can you check my solution?
Does all your printers respond to PJL commands?
Does all your printers are capable on natively print PDF?

If that is the case, as long as the info for which printer to use and which tray to call are in the data, then you will be able to build your PJL dynamically.

Of course, that will require some scripting in Workflow.

8

In response to the backup printer situation, you could also use SNMP conditions to dynamically check the printers in use. If they take down Printer A and now have a backup printer in place, the workflow can detect this and re-route to the printer that’s up. In doing this, you call the appropriate Output preset for the backup printer at that location.

It does sound like you’d have a lot of preliminary setup to do to put this all in place, but I can see how once set up it would be relatively hands off. You’d only need to touch it when hardware changes.

9

Following up on hamelj’s suggestion, if that’s actually an option, then it’s very likely possible to create a custom printer definition to handle this. But you then first need to know if the printers support PJL.

With respect to handling different brands and types of PostScript printers: the problem here is that printer manufacturers are not even trying to standardize. PostScript has a generic way of doing tray selection, but many printer manufacturers choose to not use that.

What may be a good approach to get started on the printer definitions, is to give our “Generic PS Level 3 Multi Trays” printer definition a try. If a bunch of your printer types support that, you can use it for those, and save a lot of time and effort.

With the suggested setup that maps paper types in the template to trays on the printer, you would not need staff intervention, other than a way to reroute to that other printer. The output preset for that printer will then map the paper type to the right tray on that printer.
What might help you a bit more, is to have a field for paper type in your data, instead of the field for trays. But that’s mostly cosmetic: currently the combo (printer x, tray 7) already means something like “payment slips” to you, except it doesn’t say so explicitly in the data.

As mentioned before, perhaps printing the stationery can reduce the number of trays you need in general. But that usually requires color printers, and of course doesn’t take care of different sizes, weights, colors, coatings, etc. of your paper.