PDA

View Full Version : DC252 embedded Fiery and Nexus



Nikola
09-08-2010, 06:53 AM
A customer has problems with Hotfolders, which are installed on a Windows Server and PDF files from several clients are submitted into these Hotfolders from Nexus-SW. Hotfolders might be running fine for several days :), but from time to time the client jobs don't arrive there anymore and the Hotfolders need to be deactivated and then activated again.
Any hints or tipps, what might be causing this effect? :confused:

manyfaces
09-08-2010, 10:11 AM
My understanding is that HotFolders are not intended to be shared over the network. This may explain why your jobs stop arriving into the HotFolders.

Now, if your jobs arrive in the HotFolder okay and then just don't transfer to the Fiery...

adam1991
09-09-2010, 03:44 AM
Hotfolders absolutely are intended to be shared over the network. That's their entire purpose in life.

Otherwise, there's no reason for hotfolders to exist. The operator would instead use virtual printers or simply pull-down presets within the job ticket on the Fiery itself.

manyfaces
09-09-2010, 10:14 AM
Hotfolders absolutely are intended to be shared over the network. That's their entire purpose in life.

As someone who is used to a production-level environment, I completely agree with this point of view. I'm used to HotFolders being on my RIP and being shared out through the network.

However, my previous statement is based on how EFI is distributing the software rather than my past experiences with non-EFI software.

EFI distributes HotFolders as client software to be installed, as a package, with CWS on each client computer. I don't understand why Hotfolders would be distributed this way if EFI's intention was for them to be used in a single, centralized location.

markdyck
09-09-2010, 10:43 AM
A customer has problems with Hotfolders, which are installed on a Windows Server and PDF files from several clients are submitted into these Hotfolders from Nexus-SW. Hotfolders might be running fine for several days :), but from time to time the client jobs don't arrive there anymore and the Hotfolders need to be deactivated and then activated again.
Any hints or tipps, what might be causing this effect? :confused:

When you state "Windows Server" is this a computer separate from the RIP? Because if it's the RIP itself, there are known issues with the current version (and a few versions back) so much that it's not supposed to be run directly on the RIP.

If you're running it on a completely different station (be it server or client computer), you should ensure you're running the most recent version of HF and that the computer has all updates applied. Shy of that, you could always implement a scheduled reboot during off hours BEFORE things started not working. That way you would have the illusion of seemless operation. Just a couple ideas anyhow...

adam1991
09-09-2010, 11:41 AM
As someone who is used to a production-level environment, I completely agree with this point of view. I'm used to HotFolders being on my RIP and being shared out through the network.

However, my previous statement is based on how EFI is distributing the software rather than my past experiences with non-EFI software.

EFI distributes HotFolders as client software to be installed, as a package, with CWS on each client computer. I don't understand why Hotfolders would be distributed this way if EFI's intention was for them to be used in a single, centralized location.

Ummmm, well, it's not quite that way. I do agree, EFI could better explain the whole thing.

The fact that they install the hotfolder util on the Fiery itself is a little weird IMNSHO, but it does make it easy for the operator to start using them right away.

But the hotfolder utility is not installed as a package with CWS per se. Rather, it's installed using their Master Installer, and the default is that every item is checked in the Master Installer install screen. That's a problem, too; nothing should be checked by default, and the user should have to take action to tell the Master Installer what to install. Again, this is IMNSHO.

So yeah, EFI needs to get their stuff together in that regard. On the other hand, if that's all confusing to the print shop, they have bigger problems...

The biggest reason NOT to use them on the Fiery itself is the same reason not to do anything permanent on the Fiery itself: it's a RIP, for God's sake, not a server!

So I tell anyone who asks about hotfolders that they have to install the utility on another computer somewhere, something that's backed up by the network administrator. Share those folders out. Should something happen, the backup will be restored by the network admin and all will be well. But if something happens to the Fiery and the tech wipes it clean, you're on your own. And--here's the biggest problem--you can't back up the hotfolder configuration information.

That, of course, is my biggest complaint with EFI products. I need a one button "back up my entire configuration in a reliable way, and allow me to put it back after the scrape load" solution. I don't think they're there yet, and I don't think they ever will be there.

Hence my stand: ignore that they put hotfolder utility on the Fiery itself, and uncheck it when installing CWS onto a client workstation.

BTW, note that it's not part of the CWS5 installer--which means it's not by definition intended to be part of a CWS installation. It's just a choice in the Master Installer.

thistlegorm
09-09-2010, 01:15 PM
Hi All,

Just to add to the mix - I think that the term "Hotfolder" & the EFI package "Hotfolder Console" might have got a little mixed up.

As we all know if a queue / virtual printer is set up on a RIP with all the attributes wanted for that particular queue, if that is then enabled as a hotfolder it can either be dragged from the RIP to the client workstation as a shortcut or have a drive mapped to that hotfolder - then print ready format jobs can be copied / moved onto that directory & the RIP processes & prints etc..

However EFI hotfolder console does far more than this hence why it is an independent package, which contrary to previous posts can be installed as a seperate entity, you do not have to install CWS.

When you load HF Console you will see it load Harmony Impose etc - the reason being when you open the package you create the hotfolder & define it on the client, so obviously you need to have the Fiery functionality on the client within the hotfolder - you then point it to a Fiery server & the "queue/printer" you wish the job to come out from. When you dig down through console you will see specific filtering - as an example I'll use the office filter. If you wanted to create a hotfolder which you could drag & drop loads of .doc(x) files to, you would need to have MS Office loaded. If this hotfolder was set up on the RIP - then it would need to have MS office loaded in order for that particular hotfolder to work..?

Most (read - all) places I goto wont purchase MS office for this so it makes sense for this to happen on the client where the job originates does it not.. this is just one example.. there are lots more.

Getting back to Nikola's initial post, assuming you have the hotfolders console loaded on a server - I have witnessed where the console loses conection with the Fiery, you generally get an exclamation mark on the hotfolder, if you open the hotfolder & look in either the MOVE or FAILED directory you can normally see your PDF however it hasn't smb'd across to the Fiery.

Within Console there is a log you can look in that might give you an insight as to what has happened. In my instance you had to close console & restart before the hotfolder started working again, when I looked in the log it said "invalid file format", the fix was to upgrade HF Console to the same as had just been loaded on the Fiery. Which leads me to my last point (hooray...). Has this workflow been working for a period of time & then stopped ? or is this a new workflow - my reason for asking is that there a few EFI patches that do a lot more than what it states, a recent one for me was an actual Hotfolder upgrade which unbeknown to us also changed something in Impose - which if we hadn't checked would have had us coming back the following day.

Suffice to say if it has been working for a long time & this has just happened I would suspect either a patch in auto update which has changed the equilibrium or something on your server has changed.

Since your Nexus Software outputs a pdf might it not be better to just set up a script that lprs the file to a virtual printer on the Fiery - on our production presses where the output is from PReS in ps they just create a batch file which lpr's to the right queue..

Cheers

Kev

Greta_C
09-14-2010, 12:34 PM
@Adam
In answer to some of your comments:

"And--here's the biggest problem--you can't back up the hotfolder configuration information."
A: You can backup the Hot Folder configuration easily in Hot Folders 3.0 or higher. It's in the Hot Folder file menu > backup and restore. Hot Folders 3 supports the DC252 rips too.

"I need a one button "back up my entire configuration in a reliable way, and allow me to put it back after the scrape load" solution"
A: The Fiery Clone Tool will do this, for Fiery servers (not embedded Fierys at this point).

We designed Hot Folders so the application can either be running on the Fiery (and folders shared out from there), or installed on a client computer.

The benefit of running it on a client PC is that you are not taking up resources on the Fiery, and you can use filters like the MS Office filter which requires Office installed.

@Nikola
For the problem listed initially in this thread, I would recommend trying Hot Folders 3 if you are installing on a client computer. We fixed a load of stability issues with this release.
It's available here: http://services.efi.com/support/drivers/download2.asp?oem=efi&sys=FieryApplicationPackage&ver=3b

Let me know if any further questions/comments.

Regards,
Greta.

adam1991
09-14-2010, 05:02 PM
"I need a one button "back up my entire configuration in a reliable way, and allow me to put it back after the scrape load" solution"
A: The Fiery Clone Tool will do this, for Fiery servers (not embedded Fierys at this point).

No, the Fiery clone tool backs up the entire FIERY.

I want to scrape load, to get rid of crud or whatever, and put a configuration back--and only the configuration.

I'd like to take a snapshot of the configuration in any moment of time, scrape load, and then restore that configuration to the fresh load.

Greta_C
09-16-2010, 01:01 PM
I want to scrape load, to get rid of crud or whatever, and put a configuration back--and only the configuration.
.

The backup and restore feature backs up just the configuration, not the whole Fiery. It basically takes everything setup in the configure tool, plus virtual printers, paper catalog settings, users & groups, & job log. It also captures any edits to the default spot colors (note: this info is correct for System 8R2, Sys9 and Sys9R2).

You can find backup and restore in either the configure tool, or in Command Workstation > Device Center > General > Tools.

adam1991
09-17-2010, 02:09 PM
Does the backup config tool work now?

Time was, it just plain didn't.