Communicate with Serial COM Port Fiscal Printer devices
Run DOS applications in Windows.
Brought to you by:
emendelson,
josschaars
Jos,
Thank you for this great software.
I am not being able to communicate through the serial COM ports with vDOS. I searched and read a lot of post regarding the subject on this discussion forums and realized there is a problem on this area and that you made several attempts to make it work but haven’t got real devices to test and test people have been keen to participate first but finally desisted. I hope you keep interest (and energies) on this subject and be able to give it another try. I think I have a workaround for the lack of a device to test, I get back to this near the end of this post but please let me do an introduction before...
As a software developer with 25+ year in activity I still have many DOS based transaction processing/management software (invoicing, stock, cash, credits, etc.) deployed on several small and medium companies, which for some reasons cannot be migrated on modern languages in the short term. These companies still have 32-bit Windows or virtual PCs in some cases. There is a massive need to renew most hardware and they are coming with 64 bits Windows. I am looking a way to extend for some time these applications but would like to avoid the hassle of installing virtual PCs on each, for the all known caveats and license issues. These applications are mostly written in Clarion Database Developer 3 and compiled in Protected Mode. DosBox hangs up the moment it tries to run the program, no screen display, I suspect it has some conflicts with the protected mode it uses, because if I made a test program with Static mode it works but that is limited to small programs. Then I found vDos, so far I tested it, it worked great, on networks and both with the internal database drivers and with Btrieve. The problem is when they need to communicate with Fiscal Printers, and all Point of Sales need to.
Fiscal Printers are devices governed by their strict internal rules and logical states. The printer part of them is hidden to the PC application. They are connected to the PC with a serial connection and have a strict communication protocol, frame based, with start and end delimiters, sequence number and checksums, with established timings. They follow a master – slave relationship between PC software and them. They receive commands, process them and send responses back to the pc. For example, PC software sends “Open receipt” command with customer data, Fiscal printer checks its internal state and the data received and if it is all right starts printing receipt header and send response to PC software that the command was successful, so it can start sending Product Items’ commands. If there is some problem, e.g. there was already a Receipt opened, it would response with an error (always sending the response framed with start and end delimiters, sequence number and checksum). They have storage memory for the operations and are like black boxes and has numbered seals. There is a formal legal procedure to start using it called initialization, where the owners’ fiscal data is firmly saved. Prior to this initialization there is a period of time that can be used to test them and the software.
To give an idea of how many cases like this could exist, consider in Argentina, every business has to provide legal receipts for their sales, and has the following options for that:
-Fiscal printers
-Electronic receipts (web based)
-Manual receipts (handwritten)
-Exceptionally: printed receipts with common printers (few types of business allowed)
Fiscal Printers are used in other countries as well, as you can see on the site referred on following link. Here the most known brands are Epson and Hasar. Each of whom created the 2 mainstream communication’s protocols.
Manufacturers usually provide documentation and some tools. Hasar for instance, has a portable command line tool, PRUF.EXE (DOS 16 bits and WPRUF.EXE - 32 bits) to test and issue commands to their fiscal printers.
There is a Fiscal Printers Emulator, build by a 3rdparty which can be installed on a PC and listen to commands and answer simulating being a real device, showing on screen the packets received an additional information. It can be attached to a real serial port, which would require 2 pcs and a null-modem cable between them, and also to a virtual serial port transparently paired with a virtual serial port to use by the invoicing software. It has a 15-day trial version (9.5MB).
I’ve tested with real serial ports and USB-to-SERIAL converters, with real devices on 64 bits Windows with these results:
-WPRUF from CMD worked
-PRUF from DOSBOX worked
-PRUF from vDOS didn’t work
The same results arrived connecting to the Fiscal Emulator through the virtual serial port instead of the real Fiscal Printer.
Follow these steps if you would like to reproduce:
This is the Emulator’s product page (has screenshots of the main and general settings window)
http://www.impresoras-fiscales.com/emulador.htm
Translated:
https://translate.google.com/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=http%3A%2F%2Fwww.impresoras-fiscales.com%2Femulador.htm&edit-text=&act=url
Click on item 3 Descargas (downloads) or directly on the following link I extracted from there:
http://drivers.impresoras-fiscales.com/apps/Emulador53_std_setup.exe
(1) Download and Setup. Open “Emulador Fiscal”. Click on pulldown “Emulador Fiscal” / “Configuración general” or COM name of the windows’ status area (bottom right) change “Marca y Modelo” (Brand and Model) to a HASAR one e.g. the first “HASAR SMH/P-615F” and under “Crear Puerto COM Virtual”, change it to True, this will create an “ELTIMA Virtual Serial Port” to use with the command line tool. Finally click on the Play icon to start listening on the port created.
PRUF tool
http://grupohasar.com/producto/smhp-441-f/
Click on “Herramientas” (Tools) to the right of the picture and then on “Manuales y Herramientas” or directly on the following link I extracted from there:
http://grupohasar.com/wp-content/uploads/2016/09/Manuales-y-herramientas-para-tecnicos-y-desarrolladores.zip
(2) Download the zip file. It has tools, drivers and docs 120mb+, but only three files needed: navigate to “\Hasar\Argentina\Drivers y herramientas\UTIL” and extract PRUF.EXE, WPRUF.EXE and WTESTF.DLL, and PRUF.PDF if you like, it is in Spanish, has some screenshots.
(3) Open CMD command line and test WPRUF -p 2 (if configured as COM2), it should appear:
Buscando Controlador Fiscal ...... (searching..) and then:
Controlador fiscal detectado a 9600 baudios
Version : Serie de Impresores 615/951/PR4
And then:
PRUF V4.03 - 9600 Baudios Página 1/3 Imp: 615/951/PR4
Probador de Controladores Fiscales PGDWN - Sig
* Documentos Fiscales * Documentos de Auditoria
1 - Status Fiscal 2 - Abrir Documento Fiscal 3 - Texto (etc)
Comando:
(and waits you to choose a command)
press 1 to send a “Status Request” command, on Emulator screen should be logged the request, and on the console should display:
Comando : Status Fiscal
CodOper : 2Ah (ASCII - '*')
Comando : [*]
Respuesta: [* 0080 0600 00000000 0002 00000000]
Nro. de Paquete Enviado: 24h
Nro. de Paquete Recibido: 24h
Fiscal Status: [0600]
Memoria Fiscal inicializada
Printer Status: [0080]
Buffer de impresión vacío
Presione 'D' para ver el detalle de las respuestas. (press D to see a detail of each field on the response)
Otra tecla para continuar... (another key to continue – and comes back to the first screen – esc to exit)
(4) Test PRUF in the same way as WPRUF but on DOSBOX and vDOS prior configuring serial2=directserial realport:COM2 / COM2 = “COM2”:
On DOSBOX you should see the same that with WPRUF and on vDOS, PRUF says it didn’t find the fiscal printer and the Emulator crashes, requiring restart and reconfiguring the Emulator.
I feel confident that if you can make PRUF works on VDOS like DOSBOX, it would also solve the problem with the real device and probably with different kind of devices too.
Please tell me if can help more regarding this.
Regards,
Federico Navarro
Well, that is quite a story, probably better to communicate directly: jas@vdos.info (the “a” should be an ”o”).
Problematic with serial communications in vDos are programs that install and rely on their interrupt driven routines. You can check if a program does so by starting vDos with the /log option (“…vLog.exe” /log). If the vDos.log shows “Int 0B => XXXX:XXXX” or “Int 0C => XXXX:XXXX”, it indeed implements these routines, that are then never called in vDos.
If those entries are missing, the program would directly poll the serial port(s). Though then the serial port has to be initialized correctly outside and before vDos starts, with MODE COMx … (at the Windows command prompt).
PRUF.EXE working or not, doesn’t mean the actual program would likewise. The one could use interrupt driven communications, while the other doesn’t. Interrupt driven communications are somewhat specific to dedicated communication programs, supporting high transfer rates. Not to be expected with a program, occasionally communicating with a Fiscal Printer at a mere 9,600 bps.
Jos
Jos, thanks for answering and for your support
Unfortunately in many cases software is provided "as is", or even own developed software may rely on 3rd party communications library, binary closed source without support, and in those cases vDos users are quite unable to workaround that situation.
May Interrupt driven communications being supported on vDos on the near future? Does it depend on the how many people would benefit from it or it is definitely out of scope?
I tried vDos /log. PRUF indeed shows int B, however my program does not. But both cannot communicate. I can send you details by private mail if you prefer.
I dig a bit more and debugged my program running step by step disassembled instructions and monitoring registers, what I found it fails in the first try to open port (not even at the stage of setting baud rate or handshaking lines or trying to sending / receiving data). Particularly there are some IN / OUT instruction to the line control register of serial port COM2 (2FB).
(dx=02FB)
in al,[dx] --> al is set to FF (whereas on a working PC it is set to 30), so on the following instructions it will report that the port cannot be opened.
Does this helps? Is there anything else I could try?
Regards,
Federico
FWIW to other who may be interested, a reference to those registers with a fast google search: https://versalogic.com/docs/kb/VT1612%20How%20to%20Prove%20Serial%20Ports%20Are%20Working.pdf (i have not done those test, it is just for reference)
Serial communications in vDos are quite basic; BIOS 14h functions 1-3 are more or less supported and tested, enabling a program to send and receive data. So vDos can do with Windows file functions to communicate with the assigned device (https://msdn.microsoft.com/en-us/library/ff802693.aspx). For most programs this will suffice.
At the 'hardware' level, only reading from and writing to the base port (Transmitter Holding Buffer/Receiver Buffer) will be realistic, the rest is just ignored. To support more, would be trial and error sessions; what when to fake, like the LSR and so forth.
Interrupt driven communications will be more demanding; besides the interrupt servicing routines being executed at the right moment, those routines will first try to determine what actually caused the interrupt, more faking.
If possible, you could send me a copy of your program and instructions how to test. Since it isn’t interrupt driven, I suppose it should be doable to satisfy it and let it actually start sending and receiving data. Don’t expect too much too soon. The coming weeks I’ll probably have little time to spare.
Jos