Print to PDF on a Anritsu MS46122B

[Bcolby26]

Hi,

I'm attempting to automate an existing testing process on a Anritsu MS46122B VNA, unfortunately this involves using the print to PDF function to generate PDFs directly from the VNA software.

I am able to print the PDF however it calls up the Save Print output as window and prompts the user for a file name and location for every file. 

Is there a way to automate the location and file name of this window?

Any help or ideas would be appreciated,

Thanks!

[cstorey]

It would help to know the details of how you are sending commands to the instrument.  But in general VNAs use SCPI commands like..

:MMEM:STOR:IMAG 'C:\directory\filename.png'

So you probably just need to provide a full valid filename to the SCPI command to avoid the dialog box.

Hope that helps,

Craig

[Bcolby26]

I'm currently using the HCOP SCPI Commands to set the headers and print the file, Its the only way to generate pdfs straight from the VNA that I could find

[cstorey]

Hmm... don't see a PDF option in a manual for HCOP.  Do you have a reference for that command to store PDFs?  Perhaps just add a filename?  There could also be options to suppress dialods.  Post all the SCPI commands?

You can use :MMEM:STOR:IMAG 'C:\directory\filename.png' to save a screen capture.  That will not call up a dialogue.

I no longer have an Anritsu so can't debug.

Craig

[Bcolby26]

Thanks for the reply, Craig

I'm using the HCOP with Windows Print to PDF as the default printer, unfortunately I can't use a screen capture because I can't change the format that we are currently using. the resulting data sheet is below.

So sending the HCOP command to the VNA pops up with the "Save print as Dialog box" that prompts the user for a file location and name. 

[rolfk]

Print to PDF is notorious for requiring a dialog to specify the file location. The reason is simple. Print to PDF is in most cases implemented as printer driver. There are many such printer drivers out there, although I think it is a dying business as Windows comes nowadays with a standard PDF printer driver, so why would someone want to install yet another PDF printer driver? As the Windows printer API does not support passing a file name from the application to the printer driver (what for? a printer doesn't have a file storage anyways) this is not easily implementable by an application.

In the long ago past you had some PDF printer drivers that were free for standard operation and had a paid version that supported additional features such as specifying an actual file location through a special API, a registry key or some other such custom interface. I haven't automated PDF printing for a long time other than by using the Carya Toolkit to create PDF files directly from LabVIEW, so not sure about the current market for PDF printer drivers. There used to be several based on Ghostscript, the software used under Unix/Linux for anything Postscript related. But the Windows printer driver for that was troublesome: creating Windows compilations of software originally developed for Unix is always a bit tricky, licensing was murky and most providers of such solutions tried to earn a buck for their efforts, except that it is hard to get people to pay for something like that.

In the end it results in a situation where many half baked solutions exist, but none that is really completely useful, has a clear license and doesn't cost an arm and a leg. And since the printer driver interface does not provide a means to specify a file name, the way this is done is always solution specific, which is not a good starting point to integrate it into a software like HCOP even if you can script that system.