VersaWorks – Job Save Function

I see many users leave jobs in their queues as a way to save jobs for future use. While it is a good idea to save each project at least a few days after completing – gumming up the queues as a storage technique can slow VersaWorks from loading. I have also seen VersaWorks get bogged down and require re-initialization to correct. Under this situation – your queue will get wiped out (as well as printer & queue settings!) The Job Save fuction is a better long term solution and even has a way to increase workflow speeds.

Job Save is one of those functions that has 3 ways to access it: Menu-Job-Save OR Right Click on the job – Save OR the down arrow icon at the bottom of the queue window. Everyone has their own preference! This feature has three flavors to choose from in the dropdown menu. The first two are files that get loaded just like normal design files – the third is a very specialized use file.

RVW Job File (*.rvw): The first is a RVW Job File (*.rvw). This file choice will save all the settings that have been applied to the job in the queue settings as a seperate file. In order to reload the job into the queue at a later time – this file is loaded into the queue and the original file is then loaded with all the saved settings. In VersaWorks 5 this can cause a problem – if the original file has been moved – the program will report an error and not load. While this was corrected in VersaWorks Dual and VersaWorks 6 – by allowing the user to look for the original file – I suggest a “best practice.” When this file is saved – save it in the same folder as the original file. In this way – if the file is ever moved – the *.rvw file will be moved with it and the RVW5 problem is avoided. [Best Practices for managing files will be addressed in a future post]

RVW Job + Source File (*.rvw): The next choice in the list avoids the problem with lost original files by embedding the original file in the *.rvw file. This option has the advantage of making sure if the original file has been modified – the old version is used for output. That can be a disadvantage as well – if the design has been altered or lost – you will not be able to correct the original design. Obviously, this file option can become a large file and double storage useage for this job. NOTE: Those of you using FlexiSign and having the software send temporary files over to VersaWorks should use this feature – because the EPS or PDF file in VersaWorks is deleted once the queue is cleared.

PRT File (*prt): The last option – PRT File (*.prt) – I refer to as a “data dump.” This will create a *.prt file that is sent directly to the printer through the Menu-Printer-Send Native File menu. This workflow allows no opportunity to do anything with the settings and simply dumps the already RIPed data directly to the printer. Why would a user choose this option? If RIP times are large and there is a contract for repeated output – this can save a great deal of time. As an example – think of a contract for 10 box trucks – two sides – once every two months. RIPing the file takes over an hour due to the large or complicated file. Saving all that RIPed data in the queue can slow down your VersaWorks for almost a year. Creating a *.prt file will just dump the data to the printer and free up space in the queues. I have yet to test this theory: Using *prt files for Print/Lam/Cut workflows where printing and cutting is done seperatly. I can’t see why two files could be made and dumped through the Send Native File menu. I also cannot really see an advantage to doing it this way unless it is repeated so much that a quick approach is worth it.

All but the first option will need RIP data in order to save. If for some reason the job has not been RIPed – ripping will be done before saving. This issue is often not a problem because in most cases the file has been processed already, but keep this in mind.