Fiery Printer Logs - Is Duplex missing?

[tngcas]

Am I just missing this information? I cannot fathom why the fiery wouldn't record if a job was printed duplex in it's logs but I don't see anyplace for this information.
If it's not there does anyone have any idea WHY fiery would choose to not record this information in the print logs? It seems like a very large oversight.

You can't infer this data from the other fields especially if you're using the fiery imposer to print gangup or doing Unique collate.

 

[pippip]

You can add the filter "Sheets", which you can determine if double sided was used.

 

[tngcas]

You can add the filter "Sheets", which you can determine if double sided was used.

That doesn't help on multi-page documents if you're doing a gangup run. It also doesn't help if you are using the unique collate cut imposition settings. There is no accurate way to "infer" duplex reliably with the options provided.

I just don't understand why this wouldn't be an automatically recorded in the logs. Why omit that information.

 

[chriscozi]

Wellll, maybe it has to do with the fact that Fiery was originally built as a rip to image system by a different company and NOT a digital press front end.
(Cloudy memory of those days discussions about what a 'REAL' rip was and did EFI have it right - and please remember EFI purchased other companies to build their business - they didn't really develop software internally.)
Back then you didn't NEED or HAVE a 'Duplex' option because you were generating a single image per side of plate/film.
And once it got built that code base might still be intact and they don't have the expertise/money to rebuild it?
That doesn't seem reasonable but once you've eliminated everything else . . .
Any old hands here have any clues?
And then EFI spun that all off a year or two ago to it's own company - any clue how they are doing financially?
YMMV
My 2 cents of cogitation and worth about that much.

 

[pippip]

That doesn't help on multi-page documents if you're doing a gangup run. It also doesn't help if you are using the unique collate cut imposition settings. There is no accurate way to "infer" duplex reliably with the options provided.

I just don't understand why this wouldn't be an automatically recorded in the logs. Why omit that information.

It does, divide the total clicks by sheets. If it's the same they're single sided and if it's half then it was double sided.
Yes there are more complex variations but you would be able to infer if double sided was used during the run.
"Sheets" is not the same as "Pages".

The logs are only recording the details of the actual printed job, not the parameters. Technically a job with an odd number of pages is both double and single sided as last pages back is blank.

I don't think it's an oversight on Fiery's part, I think like above it's a parameter that doesn't return a definite value for the log.

 

[chriscozi]

It does, divide the total clicks by sheets. If it's the same they're single sided and if it's half then it was double sided.
Yes there are more complex variations but you would be able to infer if double sided was used during the run.
"Sheets" is not the same as "Pages".

The logs are only recording the details of the actual printed job, not the parameters. Technically a job with an odd number of pages is both double and single sided as last pages back is blank.

I don't think it's an oversight on Fiery's part, I think like above it's a parameter that doesn't return a definite value for the log.

So what you are saying is that all the information to rerun or BILL the job is only available if you do the math yourself?
Instead of the Fiery system LOGGING the settings you selected at print time for YOUR benefit.
Funny thing - they sure do log all the CONSUMABLES and the PAPER SIZE for the billing they give THEIR customers.
Ok. Let's say that is ok.
Are there OTHER settings that are not part of the log per job?
No?
Then Fiery doesn't have the ability, the company doesn't care, or the programmers are simply to lazy to implement a full log. Take your pick.
Yes?
What are the consequences of those other missed settings?
I'll wait right here.

 

[bill kahny]

It is counting clicks not dividing? two sided is 2 clicks 1 sided is one click it doesn't count flipping a 1 sided sheet that can be controlled by the user to exit print up or down. It's defaulted down to keep jobs in print order post fuser anyway. If you use division your final count on odd jobs could be .5 what good is that. when a book has a blank back page it doesn't charge a click so what number do you want to see finished books divided by 2 minus 1? I see this a a keep it simple issue not a reporting issue.
As far as book keeping I watch the clicks for 1 print to check the color click vers black click. very few jobs am I recording start vers ending anyway, the logs take longer to load and sort then the math takes.

 

[tngcas]

I was hoping to use the fiery logs to track when there was an error made on our operators side.
For example if they printed the wrong quantity of a job, accidentally printed double-sided vs single-sided etc.
The problem is that without the duplex logged this becomes very unreliable.

For example:
A 100 page multipage document printed duplex would give you 50 sheets when printed 2-up. Fiery logs will report: 100 clicks and 50 sheets
A 100 page multipage document printed simplex would give you 50 sheets when printed (cut-and-stack) Fiery logs will report: 100 clicks and 50 sheets.
In one case the customer ends up with 2 double-sided copies of their document and in the other the customer ends up with 1 single-sided copy.

I could write another 10 examples of how just tracking doesn't work to track how something was printed accurately without the duplex flag.
This makes it so that you can't really use the fiery logs to backtrack accurately what happened.

Reasoning:
I can understand not using the duplex setting if it was only a setting visible in Fiery Impose. But this information is available on the main fiery screens if you add "2-sided printed" so it feels like the information is available to the main engine outside of "impose". I really see no reasoning for fiery to exclude this information from the fiery print logs. Maybe there is a fiery expert that can explain this.

 

[pippip]

Are you sure of the math on that example you used?

The 100pg simplex cut and stack would only show 50 clicks and 50 sheets, not 100 clicks.

 

[bcr]

It does, divide the total clicks by sheets. If it's the same they're single sided and if it's half then it was double sided.
Yes there are more complex variations but you would be able to infer if double sided was used during the run.
"Sheets" is not the same as "Pages".

The logs are only recording the details of the actual printed job, not the parameters. Technically a job with an odd number of pages is both double and single sided as last pages back is blank.

I don't think it's an oversight on Fiery's part, I think like above it's a parameter that doesn't return a definite value for the log.

and then there are mixed media runs where you may well be using a combination of duplex sections and simplex divider sheets, cover pages, chapters, tabs etc all in one document.

 

[bcr]

Funny thing - they sure do log all the CONSUMABLES and the PAPER SIZE for the billing they give THEIR customers.

err - isn't all that handled by the machine itself and has little or nothing to do with the Fiery?

 

[namelessentity]

If you want to track your operator settings, have them print out a job details page you can keep with the printed output. It's in the "summary" tab of your job details, then the top right button will print all the job details.
The fiery logs just tracks clicks, not settings.

 

[tngcas]

If the fiery log is just for tracking clicks then it literally doesn't need to exist at all since the printer itself tracks clicks.

I don't want another piece of paper that I have to pay for clicks to print and then look at manually and physically review.
I wanted to be able to write a piece of software that could pull the information from the logs and let me automate this information, have a piece of software flag potential issues BEFORE they get to the customer.

Obviously, the operator thinks they did it correctly so they aren't likely to catch their own mistakes.

The one missing setting (duplex vs simplex) had made every attempt (of mine) to create an automated auditing process impossible because there's too many ways for the numbers to come out wrong when the software tries to "infer" whether it printed duplex or not.

If it's possible for them to put it in a "job summary" that is automatically printable (using a digital process) then that means the information is there and should be able to be accessed digitally. There is no reason for them to force us to "print the information" in order to see/access it.

This information should be able to be retrieved digitally. I'm annoyed at fiery for not including it. BUT at least we've answered the question.
It's not there for one of the following reasons:

1. It's either an oversight on Fiery's end to not include it
2. They've built their software into a box where that information isn't available to the logs.
3. The people building these things aren't real world operators, dealing with real world printer-math problems.

Right now, I'm going to go with all three.

Are you sure of the math on that example you used?

The 100pg simplex cut and stack would only show 50 clicks and 50 sheets, not 100 clicks.

You're right. I think I meant the other way. Either way, it doesn't work to infer duplex/simplex programmatically in a reliable way.

 

[pippip]

I've just had a quick look at this -

The "Job Summary" is actually printed using windows, so you can Print to Pdf and save digitally on your system in a matter of seconds but you can't extract the data from this.

I would also note that in the past I've had issues where the job log gets so big it needs to be cleared as was causing issues so be aware of this.

You can automate it in Fiery to export as CSV - Manage the Job Log
You can also export manually as tabbed pdf which may be easier to review.

As mentioned once you have "Sheets" and "Total Clicks" you can clearly see if the job was double sided at a glance for most jobs.
Your automated auditing process should be able to use this info to create an additional field of Duplex.

As I previously suggested the log is a record of the PRECISE job output from the machine and duplex isn't a simple Yes or No Answer for the machine. Odd page count, blank sheets, mixed media etc will not return a Yes or No answer. I agree it could possibly log "Total Number of Duplexed Pages" & "Total Number of Simplex Pages" but this in itself could create more questions than answers when using it to quality control a printed job.

POSSIBLE SOLUTION -

After I wrote above I realised that the problem really comes down to that the JOB LOG is output data where as the JOB SUMMARY is input data which contains the duplex instruction.

So in CWS you can go to your COMPLETED jobs tab and add the field Duplex (displays values - Off, Top-top, Top-bottom).
Unfortunately it's a manual process but you can
File - Export Current View - and save the Completed Job Data as comma seperated txt file.

 

[chriscozi]

err - isn't all that handled by the machine itself and has little or nothing to do with the Fiery?

Yes - the machine or print engine (Xerox, Canon, etc.) 'Handles' it but the INSTRUCTIONS come from the Fiery so to 'HANDLE' any relevant job info that comes from Fiery you need to use Fiery.
Hence the issue.

 

[chriscozi]

Unfortunately it's a manual process

Hence the issue.

 

[pippip]

Hence the issue.

The process of exporting wasn't the initial issue, showing duplex within the data was.

 

[tngcas]

The process of exporting wasn't the initial issue, showing duplex within the data was.

I was able to set an automated daily export of the fiery log very easily.
AI and I were not able to setup a reliable method of inferring the correct quantity/imposition and correct number of prints.
Our team uses a very reliable method of naming the files that go to print. We also know how all of our templates are setup (for imposition) so we were able to infer all the information we needed from the data set EXCEPT for the duplex. That was the only missing piece of information. It's a smidge frustrating to get so close and fail because of one missing piece of info.

Maybe I'll check and see if there is another place to automate the retrieval of that data but my guess is once the 'job' is gone from the fiery the information is gone and you really can't store too many jobs in the "held" or "completed queues" without bogging down the servers too much. We stick to 50 but we frequently process more than that number of individual files on a regular 24 hour day. Maybe I can use the fiery api to send information to a log of my own every time someone hits print. I'll check and see what options there are in the fiery api since using the print logs appears to be a bust for this operation.

I'll check out whether or not the 'current' view screen could be setup on a export as a semi-reliable backhand source of that information that could be combined with the print logs to get a 90% accuracy rate.

 

[tngcas]

Update:
I reached out to our local Fiery guy and he forwarded my request to add duplex to the printer logs. He just got back to me that they are assigning a team to see how this could be implemented.

 

[PricelineNegotiator]

Update:
I reached out to our local Fiery guy and he forwarded my request to add duplex to the printer logs. He just got back to me that they are assigning a team to see how this could be implemented.

Tell your guy to also make it possible to sort Hot Folders in the Hot folders app by alphabetical order!