External hardware driver for 1C on the example of the Maria-301MTM fiscal recorder

When implementing projects on 1C, one often comes across various devices and their interfaces. As long as devices exist on ancient RS232 there will be a need for external components of this kind. As a rule, there is documentation with the device, which often contains a system of commands and a driver that is distributed “as is”. Very often, the drivers "as they are" leave us to expect better. I propose to plunge into system programming a little and solve this question for myself once and for all.

An excellent article contains an example and a sufficient description of what is what, what is where to change. The example is compiled. For a quick start, a great article. A similar example is freely distributed by 1C and is lying in a heap of rubbish on an ITS disk . Many times flashed in the eyes but it was laid on the far shelf with the label "must-examine."

For simplicity, the external component hereinafter will be called the driver.

1. Refusal of OLE32 in favor of the Native API.
Heavy memories of registering OLE32 components, and the horror of registering them under Windows 7, prompted the consideration that the driver should support the Native API. Registering such an external component looks like:

(, "prn", .Native);  = ("AddIn.prn.Maria2"); 

In this case, no action of the regsvr32 type. And as far as I know, OLE32 has long been non-flagship technology Microsoft.
')
2. Storing the driver itself as part of processing or configuration.
The driver file is inserted into the 1C layout as binary data and, if necessary, we unpack it into the user's temporary directory.

  = ("");  = () + "AddInNewMaria.dll"; .(); (, "prn", .Native);  = ("AddIn.prn.Maria2"); 

3. Implementation of the driver interface. Moving the command logic to the 1C side.
Initially, when writing a driver, the ideology of existing drivers was used. DemoComp.Make up (MultiRaz).

 .NullCheck(); .CancelCheck(); 

In essence, the driver was repeated, of course, without restrictions imposed by the manufacturer. But this heredity was painful and pernicious. Every six months there is a need to add some commands, change existing ones.
A universal RS232 port driver for 1C was written. It was tested with a Huawei-1550 usb modem and with Maria. For this driver, you need to rewrite the service processing for 1C.
After the next "improvement", the idea of ​​bringing the logic of commands to the 1C side was born. The driver deals only with the implementation of the transport protocol. System programmers rejoice. Now the driver command looks like:

 .("NULL"); //   

And yes, to the delight of each programmer, 1C Native API gives the opportunity to call functions in Russian (Russian function aliases).

4. Record exchange protocol.
To write to the file maria.log in the directory of temporary files of user commands and reactions to them, you must:

  = ("AddIn.prn.Maria2"); .(); 

The time and the type of event are written in the file: c - command; and - the answer; u is a compound; t is the number of cycles to get a response; e is an error.

 [20150210205009]t: 1 8 [20150210205009]u:READY  [20150210205009]c:SYNC  [20150210205009]t: 1 29 [20150210205009]a:WAIT SYNC DONE READY  [20150210205009]c:CNAL  [20150210205009]t: 1 141 [20150210205009]a:WAIT CNAL2013120510200020150210200500000000000000000000000000000000000000000000000000000000000000000000000020131205800000uDONE READY  [20150210205009]c:UPAS1111111111' ¦Ґ  [20150210205009]t: 1 22 [20150210205009]a:WAIT DONE READY  [20150210205009]c:NREP  [20150210205012]t: 18 52 [20150210205012]a:WAIT NREP5100 PRN SOFTREGIST DONE READY  [20150210205012]e:35 

Here is the minimum set necessary to "earn". Now a little about the future:

5. Other devices of this class.
As planned, it is not difficult to replace the transport protocol of Mary with a protocol, for example, X-a. It would be possible to talk about the driver family. The skeleton of the basic necessary functions is ready.

6. External events.
In the procedures for implementing the transport protocol, it is necessary to switch to threads, and to signal the completion of the command to an external event. I want to do it this way, but a little something is missing: time or knowledge, or both. And the rock “already works like this”, “don't touch” works, cools down the heat of the rush a little.

7. Collaboration.
The plans are to write a simple web service that would accept commands, organize a queue of commands and redirect them to the device. Service processing in this case will look similar, the teams will not change. Only the object initialization will change.

Link to the project on github
The project consists of a Visual Studio project, demonstration of commands on 1C (in the managed application module) and processing service for 1C.