Proteus, thanks to its powerful syntax, versatility and user-friendliness, is especially useful in fields like Auto-ID, where efficiency, productivity and flexibility are at a premium.

There are many different problems that Proteus can solve - a few examples:

• keyboard wedge: by using the functions for stuffing keys in the keyboard buffer and the interpreter running as a service, in a few minutes the user can connect serial and network devices (see scanner.prt and cb1000.prt), without the need of buying expensive, dedicated and less versatile hardware; it is easy writing new protocols in Proteus, thus replacing existing devices, or modifying how data are acquired, adding preambles, postambles and delays as necessary; many examples are shipped with Proteus, that allow to use the following communication protocols: Datalogic® DTP, Ack-Nak PC32, Sysnet™, Wedge (F64/F67 protocol), Special Protocol, Eavesdrop; serial with or without hardware/software flowcontrol; ActiveSync; file; socket; by using these examples you can connect, among others, the following devices:

1. Datalogic®: F630, F660, F732, F734, F725, 7400, 8600 Kyman™, 9600 Viper®, any Windows® CE/ Pocket PC device; Proteus can replace the keyboard emulators DPS-8000, F64 and F67;
2. Symbol®: CB1000™;
3. all industrial scanners that transmit data using only hardware/software flowcontrol;
4. all Windows CE/Pocket PC devices;
5. all devices capable of downloading data to a file;

• background data acquisition: when running as a service, Proteus can capture data coming from different sources (files, network and serial devices, sockets and named pipes), process and save them or re-transmit acquired data in several ways (see cb1000db.prt);
• intelligent print server: when using dedicated printers (e.g. thermal transfer or direct thermal) for creating labels, the user frequently needs to integrate into his system sequences of instructions in the language of the printer; many times problems arise, because not all the hosts can easily send strings to printers without adding control characters; moreover, every modification to a label layout requires to recompile the programs on the host, which is not trouble-free if many people are using the system at the same time. By writing a Proteus program that acquires a file created by the host, containing only the variable data, it is very easy to send the spool for printing the labels to one or more devices, even with different languages; layout modifications can take place even when the users are working, without interruptions, and is very immediate, being Proteus one of the most versatile languages when dealing with strings (see send.prt, sendlpt.prt);
• console programs: one of the easier and less expensive real-time solutions when using radio terminals is installing a Telnet Server; Proteus allows to quickly write console programs which can be used through a VT client; when comparing this solution to the possible alternatives:

1. developing 16-bit programs, written through vintage Dos compilers (which slow down the server a lot);
2. developing in Visual C++ (which misses a lot of high level functions);

it is clear that Proteus allows to decrease development time and obtain full 32 bit applications that use Microsoft® Data Access Components and all Windows™ features, consuming very little resources (see codqt.prt);

• managing line devices and label-stickers: when writing applications that do not require user interaction, the best way to go is writing a service; in this way, the computer can remain at the login screen (username/password request), while in background the application does what is supposed to do; many problems "in the field" are caused by operators that interfere with the management program; writing a service in Proteus is very easy and does not require specific knowledge of the operating system;
• conversion programs: auto-id devices very often deliver data in different ways, which must be properly formatted before being processed; Proteus allows to write simple conversion procedures that, with very few lines of code, adapt input to what is expected by the system, without using complex or limited languages.

Writing protocols

The programs described below shows several protocols that can be used to obtain keyboard emulation from Datalogic® terminals (and also other devices):

It is easy to create a different protocol using these examples as a starting point, or extend these concepts to similar devices.

The advantage of a similar approach is clear even from a security point of view: data are buffered internally and transmitted in keyboard emulation only when the terminal has trasferred all the data correctly.

This is possible thanks to the huge amount of memory of a PC: a hardware device for keyboard emulation has only a few hundred bytes of memory and so do not store all data received - the main disadvantage is that you cannot distinguish missing data from collected data, when the download fails for any reason (the terminal is lifted from the cradle, cables are moved, bad coupling with the cradle, etc.). This situation can cause delays and duplicated data, that the Proteus approach completely eliminates.

Other useful functionalities that can be obtained by using Proteus are:

• data sorting before wedging;
• merging information (e.g. adding quantities and sending a single item with the calculated total quantity);
• deleting information which are not useful (e.g. date, time, terminal number, etc.).

Moreover, all data sent by Proteus in keyboard emulation can also be saved to a text file or a database, adding a second layer of security. Last, but not least, by eliminating a piece of hardware (the keyboard emulator) you are also eliminating a device that is subject to failure: this ensures continuous operation and decreases total cost of ownership.