I'm doing project of shadow detection. It uses Xilinx XPS tool to create the embedded system.Once the system created is there any way i can check how many logic gates are produced and how they are configured.
Is there any option to retrive this information in XPS tool..?
There's a report file produced which tells you how many LUTs and Flipflops andthe like are used.
There's not a direct equivalent to actual gates as each LUT would be different depending on its acutal function in the design
Related
Using DDS I know I can print a box and color it in using the the BOX keyword:
A R BOX5 BOX(2.5 0.5 5.1 6.3 0.2 +
A (*COLOR *HIGHLIGHT 3 75)
Is there something similar to create a circle?
According to the DDS Reference: No. I can't find any keywords to directly draw a circle.
My guess is that back in the heyday of high volume impact printers, there was no fast way to print such circles. Note: Impact isn't necessarily the same as dot-matrix printers. Lines were possible with special characters, though. The "language" to steer such a printer was called SCS (SNA Character String).
But you can create a circle as desired with external programs, convert the result to a page segment, using specialized IBM software, and load that via DDS onto a page. See the PAGSEG keyword on the linked documentation for information and caveats. Especially the need to use AFP might pose a serious obstacle. (AFP is — overly simplified and thus not entirely correct — like PCL or PostScript, a page description language. IPDS can be roughly seen as equivalent to PJL.) Ricoh printers sometimes have native IPDS/AFP support. Also, there were some manufacturers for converter boxes, faking an SCS or even IPDS/AFP printer to the host side, and appearing as a PJL/PCL printer data generator to the printer.
The built-in Host Print Transform feature which can be enabled for printer devices converts the spooled output to PCL, so it can be sent to stock printers. The drawback is, it uses local CPU resources which might not be desired. Older releases of the OS might only support SCS with Host Print Transform.
Newer IBM I releases include InfoPrint Server, a java-based background task enabling to convert print jobs on the machine to PDF. I assume this should work with AFP. Not talking about resource usage, though…
Printing on IBM i is a deep rabbit hole in itself. See the accompanying documentation.
I have written a printing application that works well. I can write files, update settings and do most all functionality from one console. But one aspect of the program has eluded me for quite a while: the ability to read the Zebra register/configuration values.
It would be good to periodically be able to read the values on the Zebra and compare them to default known good standards and to be able to reset them if necessary.
Currently, in order to see these values, I need to either use the built-in web page (networked printers only), print a report, or scroll through the printer interface. What I really need to is a method to be able to read these registers values and create a known good setup file.
Has anyone been able to find any SDK or trick to read these values using .NET (C# or vb.Net)?
The application is a windows desktop utility used on my shop floor and I communicate with the printers using either LPT and ethernet interfaces (as applicable).
I would recommend checking out the Zebra Link-OS SDK which has a lot of functionality when it comes to what you can do with Zebra printers. Specifically they have a section titled "Getting all printer settings and their configuration". However the code example they provide will not work unless your printer is a Link-OS enabled printer. If that happens to be the case then great! If not you can use the SGD class within the Zebra.SDK.Printer namespace to use Set-Get-Do commands to retrieve and change information. More information on SGD can be found in this ZPL manual under the SGD Printer Commands section.
I would like to know if the following idea is possible/makes sense?
Create a virtual printer (like "PDF Printer" that any application with printing capabilities can see in the printers list) that doesn't print to paper or file, but simply inserts the document "being printed" in the document management system (DMS) I developed. Imagine from MSWord i choose "MyPrinter" and on "print" my custom forms appear and let the user choose where to save the doc file inside my DMS, letting the user set some parameters (related to my DMS).
So after these "forms" I have all the data needed to insert the file in the DMS.
I am aware this is somehow "in the tricks domain" but it is the only choice to integrate my app with some legacy software (with printing capability) that cannot be repalced.
I'd like to have a comment on this.
Creating a virtual printer is a very technical task. You will have to write a device driver, which is not directly possible with Delphi (even if there are some code in the Net).
There are several components able to do this: they consist in an already developed printer driver, with some general API to be called from other languages, including Delphi.
I found out that EMFPrinterPilot from ColorPilot could be a good start. Your Delphi application may be able to retrieve the Text (for indexing), PDF (for archiving) and even EMF (for display / reprint).
What does a printer driver do? For example, when I open a word document, and use File->Print to print the document: what does the printer driver do? Will it convert the .doc document to PostScript, append some printer commands, and then send to the printer?
Another question is how to intercept the data/command the printer driver send to the printer with software, under windows or *nix.
Simply put, a Windows printer driver is a library which implements a Windows-defined interface of device-independent imaging commands, and another interface of communication to devices like printers. Upon receiving calls from the imaging commands interface, it generates a device-specific print file, and sends it to the communications interface.
In the case of the PostScript printer driver, the driver consists of a shared device-independent part which does most of the conversion of imaging commands to PostScript language code, and a device-dependent part which has the data about the paper sizes and capabilities of a particular printer model. This division, and the fact that the shared part is shared, isn't particularly visible to the user.
These printing related interfaces are not simple. Two places to start learning about them are Introduction to Printing, by the Microsoft Dev Center, and the article Windows Driver Model, at Wikipedia
It is possible to intercept the data and send it elsewhere, either at the imaging commands interface or the communications interface. However, it's not a simple task. It requires learning the printing system and its APIs, as in the references above.
What is a common printer interface today? I've read most of them support PostScript and/or PCL. How should I use PS/PCL from an app code (say, under Win32)?
PostScript and PCL are both open-spec as far as I am aware. The definitive source for PostScript would be the PLRM (PostScript Language Reference Manual). PCL's equivalent can be found at this page.
Most modern multi-function printers for office environments will accept a number of different PDLs. PostScript and PCLXL are the most common, but some others are:
PDF, some printers support rendering PDFs directly.
XPS, Microsoft's XML Paper Specification.
TIFF, a bitmap-only page representation.
Many manufacturers also implement a proprietary PDL. Since PostScript, PDF and XPS can be slow to parse and render, a manufacturer often implements a proprietary PDL that is optimised for the printer's hardware and firmware. A lot of manufacturer-rated page-per-minute counts are only possible if you use their custom PDL driver. This technique is also used by low-end budget printers where the hardware is incapable of interpreting high-level PDLs.
In terms of generating this output, usually you do not need to do so, instead you should go through Windows GDI, or depending on your target OS, GDI+. Your drawing and text-output routines will be handled by a printer driver which in turn will generate output for a specific printer. There are also generic drivers out there (Microsoft includes a generic PostScript printer driver) that can be used to generate output that is not specific to any particular printer.
In Windows, you generally use the GDI and let the printer driver translate it to the actual printer language. This gives you complete device independence.