System for programming and lighting electronic detonators and associated method

[0001] The present invention relates to a programming system and firing of a set of electronic detonators, as well as to a corresponding programming method.

[0002] In most works with explosives, detonation of charges associated with the detonators is induced in a well-defined time sequence to improve the efficiency of the blasting works and to better control their effects. The recent emergence of blasting electronic detonator systems has enabled much greater precision of this time sequence than that of traditional pyrotechnic systems.

[0003] During the implementation of blasting systems for electronic detonators, an important task is to prepare blasting records of detonators corresponding to this time sequence, and then to program and test these blasters << on the front >>, i.e. in the vicinity of boreholes, and then firing blasting detonators from < <firing point>, i.e. at a safe distance from the firing point.

[0004] WO 97/45696 describes the steps of programming detonators consisting mainly of using one or more programming units or consoles to associate delay times, in milliseconds, with each detonator. An association table corresponding to the shape of the blasting record, which is then sent to the blasting unit or console having the capabilities and firing codes of the detonators.

[0005] This transfer can be accomplished using infrared technology, but this requires the exact arrangement of two units relative to each other, which is difficult to implement in a working environment or excavation.

[0006] Other blasting systems propose transferring this data between one or more programming consoles and the blasting console via a connection cable or using Bluetooth wireless technologies (trade name). In the first case, you may find that

53P34174PL00

The cable will be faulty or lost, which prevents data from the programming consoles being restored.

[0007] Finally, the technologies currently used, regardless of whether they are wired or wireless via infrared or Bluetooth, require electrical power to ensure data transmission.

[0008] There is therefore a need to secure data transmission to the blasting console without using the cables or the power supply to the console from which we want to restore the data.

[0009] In practice, the operator traverses the workplace back and forth to connect each detonator successively to the blasting network. The operator programming unit is also connected to the blasting network, it detects the connection of a new detonator and identifies it. The operator then enters, via the alphanumeric keypad of the programming console, the delay time assigned to each of the detonators sequentially identified in the blasting network. Later in the description, this operation will be called "detonator programming".

In a variant, instead of assigning each detonator to the blasting information the type of delay time, the operator can specify, in his programming unit, the blasting information identifying the type of the drilled hole at the place where the detected detonator is located, the association with the delay time can be realized later, for example, on the shooting console.

[0011] During the detonator programming operation, the detonator identification step is performed. This identification is for the programming unit to reproduce the identification parameter of the connected detonator by means of a message exchange in the blasting network, which parameter can, for example, be stored in the ROM of the electronic detonator. The programming unit then remembers, in the EEPROM, the association realized between this identification parameter and the delay time or the corresponding hole number entered. The resulting table is a shot metric.

53P34174PL00

[0012] In a variant, the identification may rely on the programming unit to send an identification parameter to the detonator, which will be saved by the detonator, for example in an EEPROM memory, wherein the programming unit then remembers the association of this identifier and time type shot information. delay or hole number.

[0013] In the course of significant blasting works, this programming operation can quickly become labor intensive in relation to mainly a large number of detonators to be connected and programmed. Thus, many hours of programming may be required. In this case, the programming operation can be performed by several operators, each of which is equipped with a programming console to program, with the help of each of them, a part of the blasting record. In practice, the blast record is divided into several zones, the detonators of each of them are connected to bus lines, together these bus lines form a network connected to the main line called the blast network. In this configuration, it is common to use the same programming console to program one or more bus lines and not to mix detonators programmed by different programming units on the same bus line.

[0014] Once all detonators have been programmed, it is also common to carry out on-site tests using the programming console (programming consoles). These tests are carried out in particular to verify that the set of programmed detonators is well connected to the blasting network and that no other <<intruz>> detonator has been connected without prior programming by the programming console.

[0015] When several programming consoles were used to program blasting works, each of them only contains the identification parameters of a portion of the detonators present in the blasting network, corresponding only to the detonators programmed by that console. Each console performs the functions of counting and then identifying the connected detonators. However, they should not be considered intruders or detonators

53P34174PL00

EP 2 531 809 B1 programmed by other consoles. This requires mental intervention by operators in particular to compare the number of connected detonators with the number of programmed detonators, without allowing easy detection of possible intruders.

[0016] Excluding the case where only one programming console was used, no programming console contains a set of detonator identifiers from the blasting records. It is then impossible to test the entire blast record at one time.

[0017] Therefore, there is also a need to have means for simplifying the testing operations to be carried out in blast kits or networks.

[0018] Furthermore, it may happen that the programming unit fails during these programming operations, for example due to a failure of the supply battery or mechanical damage resulting from an accident at the excavation. This situation requires a comprehensive reprogramming of the detonators initially stored in the blast (partial) metric of the defective console. There may therefore be a significant waste of time. It may also happen that the operator will not be able to complete his programming operations because the battery is discharged and requires recharging.

[0019] There is also a need for more efficient programming means in particular in the event of a programming console failure. [0020] In this context, the invention aims to solve at least one disadvantage in the prior art by proposing in particular the simplification of data transfer, including programmed blasting records, between different consoles.

[0021] To this end, the invention relates in particular to a programming and firing system for a plurality of electric detonators, each of which is associated with a respective identification parameter, the system comprising:

- at least one programming unit containing memory and adapted to determine the identification parameters

53P34174PL00

Electronic detonators and individually assigning them, in memory, firing information in such a way as to form a firing record;

- a firing unit adapted for reproduction, with a memory of at least one programming unit, said blasting record formed from the links between the identification parameters and the respective blasting information, and for directing the blasting sequence of detonators based on the reconstructed blasting record;

characterized in that at least one programming unit includes;

- a passive read / write label over radio frequencies equipped with a chip that functions as a memory for storing blast records, and

- a radio frequency reader adapted to read and write passive labels, including said programming unit passive label.

[0022] The system according to the invention is based on RFID tags for storing blast metrics during on-site or "front" programming. The term "on-site" or "on the front" is understood as operations carried out on-site where detonators are installed. This naming is opposed to firing, which is carried out remotely via the firing network via the firing console, also called the firing console. In a variant, the "master" firing console can alternatively direct several different shots through "slave" firing consoles and local ones connected each to a specific firing network.

[0023] In contrast to the EEPROM memory used in the state of the art solutions, which require improvement in order to gain access to them, the use of RFID labels allows, despite the hostility of the workplace during IT work, simplification and security

53P34174PL00

The transmission of these blast records to other consoles, although the original programming console may be defective.

[0024] By sending a partial blasting record to the new programming console by RFID means, he can continue programming the blasting record without losing what was done until the first console failed.

[0025] Furthermore, during tests carried out after programming the blast metric through several consoles, the invention also simplifies the transmission of programming to a single console. Tests carried out using this single console allow easier identification of intruder detonators and reduces or eliminates operator mental intervention.

[0026] It is further seen that, in contrast to the traditional use of RFID passive labels to identify radio frequency frequencies, the passive label of the invention functions, mainly, as a memory of de-correlated data with any identification of the programming console which includes this passive label. Here, the memorized shot metric is not intended to identify the programming console.

[0027] This is clear from the following detailed description in which this passive label occurs as a temporary memory of the blast records before being transferred to either another programming console or to the firing console in general.

[0028] In one implementation mode, the first programming unit includes control means for said radio frequency reader adapted to read the blast metrics in the passive memory of the second programming unit label and to copy again the said blast metrics read in the passive memory of the first programming unit label.

[0029] Such an arrangement makes it possible to provide a simple and efficient reproduction of the blast metrics partly programmed by the programming unit which has become defective.

53P34174PL00

[0030] In particular, said passive label includes, associated with said blasting record, identification data of the geographical zone to which said blasting record forming detectors belong. In particular, since the programming console is generally used in only one blasting network or one bus line, this may be the identification of that network, e.g. via a slave identifier and a local blasting console connected to this network.

[0031] This simplifies in particular the rearrangement of blast metrics for testing and / or to power the blast consoles.

In one mode of implementation of the invention, said firing unit comprises a radio frequency reader adapted to read and write the passive label of at least one programming unit in such a way as to reproduce the blasting record.

[0033] Thanks to this configuration, it is much easier to restore the blasting records from one or several programming consoles compared to, for example, infrared techniques known in the art.

[0034] In particular, said programming unit comprises means for blocking its radio frequency reader when the external radio frequency reader transmits a blasting record from the memory of this programming unit.

[0035] Conflicts between the reading of radio frequency labels by two competing readers are therefore avoided. This applies in particular when the firing console reproduces the blast metrics of a set of programming consoles, but also when it is desirable to concentrate the set of blast metrics entered on one programming console for the purposes of, for example, testing through that only console.

[0036] According to one of the features of the invention, said blasting information comprises a firing delay time of the respective detonator. The blasting record obtained in this way is directly functional for the blasting consoles. In particular, said identification parameters are

53P34174PL00

EP 2 531 809 B1 encoded in 24 bits, and said time delays are encoded in 14 bits.

[0037] This configuration allows storing, in the form of a table, a blasting record of several thousand entries on traditional radio frequency labels, for example equipped with 32 ko (kilo-octets) of memory.

[0038] In one implementation mode, the at least one programming unit includes a plurality of radio frequency labels for storing a portion of the blast metric by each label. Thanks to anti-collision techniques of the radio frequency reader, the advantages of the present invention are retained by extending the programming possibilities of associated units.

In another implementation mode, the radio frequency label is removable. It can therefore be placed in another programming unit to continue the programming operation.

[0040] Accordingly, the invention also relates to a programming method for firing a plurality of electronic detonators, each of which has an associated identification parameter assigned, the method comprising:

- the stage of determining, through at least one programming unit containing memory, the identification parameters of electronic detonators;

- the stage of associating, in the programming unit's memory, the blasting information with each specific identification parameter in such a way as to create a blasting record;

- the step of obtaining, by means of a firing unit capable of directing the blasting sequence of detonators, from the memory of at least one programming unit, said blasting record formed from the relationship between the identification parameters and the corresponding blasting information;

characterized in that the binding stage includes recording via the radio frequency of said association, in

53P34174PL00

EP 2 531 809 B1 to the passive memory of the read / write label via radio frequency.

[0041] The method has advantages similar to those of the system outlined above, in particular the easy sharing of blast records to other consoles.

[0042] Optionally, the method may comprise steps relating to the characteristics of the programming and firing system described above.

In particular, the method also includes the step of transmitting by the reader the radio frequency of the blast metrics from the passive label of the first programming unit to the passive memory of the label of the second programming unit. This transmission may in particular be carried out in the event of the failure of said first programming unit or when it is desired to regroup, on-site, shot records of several programming consoles, for example, to test all detonators.

[0044] According to a particular characteristic, said second programming unit carries out the acquisition and binding steps so as to complete the transmitted blasting record. Thanks to this arrangement, the programming of the blast metric is not lost in the event of the first programming unit failing. It is therefore envisaged to continue, using a second programming unit, e.g. an auxiliary unit, to program detonators by completing a blast record reproduced in a defective console.

[0045] In one implementation mode, many electronic detonators are separated into several separate geographical zones, and the method comprises the step of reading and associating said geographical zone identifier with said shot-in-memory records. This step may in particular involve reading the RFID tag contained in the secondary firing console connected to the firing network to which detonators of said geographical zone are connected.

53P34174PL00

[0046] Other features and advantages of the invention will be further disclosed in the following description, illustrated by the accompanying drawings, in which:

- figure 1 shows the overall organization of the arrow set for carrying out the invention;

- figures 2A, 2B and 2C are schematic representations of a shot set containing detonators mounted in parallel, visualizing communication circuits set up respectively during the programming of the detonator, the transmission of information from the programming unit to the shot control unit and during the firing sequence of the detonator series

- figure 3 schematically shows a programming unit or console according to the invention; and

figure 4 schematically shows an example of a shot unit according to the invention.

[0047] As shown in figure 1, the shot assembly can be formed based on detonators 1 similar to those shown in WO 97/45696. This blasting set, also visible in Figures 2B and 2C, contains any number of electronic detonators 1 connected to the bus lines 30, which themselves are connected to the blasting network 40, which in turn is connected to the remote shot control unit 10 also called the "firing console" or "firing console".

[0048] In order to reduce the wiring required to connect the remote shot control unit to the network, the same remote control unit, called "master", may be provided that sends, via radio, control instructions to many local shot control units, called "slave" each of which is connected, for example, to a blasting network 40.

[0049] The detonators 1 can be used in large numbers, mounted in parallel, up to over 1000.

53P34174PL00

[0050] The detonators 1 are equipped with a permanent ROM memory storing a unique ID_det detonator for example at 24 bits. Any other combination of parameters identifying detonators may be envisaged, such as the one cited in WO 97/45696.

[0051] The detonators are able to communicate with the firing console 10 (or slave consoles), which can send them orders and receive information from them.

[0052] The blasting set also includes one or more programming units 20, also called "programming consoles". They are intended to identify each of the electronic detonators 1 before or after they are placed in a drilled hole in place, and to create successively information about the blasting sequence or "blasting record" during this identification. They are also used to send this information of the blasting record to the blasting console 10.

[0053] Three configurations for the connections between the detonators 1, the firing console 10 and the programming console 20 may be provided.

[0054] In the first configuration, shown in Figure 2A, the programming console 20 is connected in turn to each of the detonators 1. This first configuration corresponds to the first stage, during which the operator on-site "programs" the blasting record by linking each connected detonator (and its identifier in turn) ) with a delay time corresponding to the programming console level 20. As will be shown below, these associations are saved via a table in the memory of the programming console 20.

[0055] As an alternative, this connection may consist in connecting the programming console 20 to the bus line 30 and then detecting, via exchanged messages, each new detonator 1 connected to the same line, wherein the sending of the message by the newly connected detonator may be automatic when connected or is made manually by the operator.

[0056] In the second configuration, shown in figure 2B, the programming console 20 is connected via a frequency connection

53P34174PL00

As described below, with the firing console 10, while the connection between the detonators 1 and the firing console 10 is deactivated. [0057] This second configuration corresponds to the second stage during which information regarding the programmed shot metric is transmitted from the programming console 20 to the firing console 10.

[0058] In the third configuration, shown in figure 2C, the programming console 20 and the detonators 1 are connected to the firing console 10, the detonators 1 being connected to the firing console 10 via the bus line 30 and the shot network 40. As shown in figure 1, the shot set can comprise a plurality of parallel lines 30, thus forming a two-wire detonator network.

[0059] This third configuration corresponds to the third stage, during which the firing console 10 is able to communicate with electronic detonators 1, then in the final stage, during which the firing console 10 can manage the firing procedure and firing of detonators 1 connected to the bus lines connected 30 to the blasting network 40, in accordance with the intended blasting record.

[0060] The firing console 10 and the detonators 1 exchange information via encoded binary messages, for example in the form of words with several octets, in a 30/40 two-wire shot network.

[0061] The firing console 10 also serves to power the electronic detonator modules 1. This power supply is an energy source capable of triggering firing. In this way, the detonators are not subject to the risk of accidental firing outside of the shot sequence.

[0062] In the case of a "master" blasting console and "slave" blasting consoles each connected to a blasting network 40, the slave consoles communicate, on the one hand, with detonators 1 via a two-wire network and, on the other hand, with the "master" radio console.

[0063] The firing consoles 10 and the programming 20 have related structures and differ mainly in their functionality and thus the management software with which they are associated. It should be noted that for reasons

53P34174PL00

For safety reasons, only the firing console 10 has firing means, in particular software controlling the firing sequence of detonators 1, as well as firing codes. These firing codes can for example be represented on the firing console 10 by means of a chip card read by the card reader integrated with this console 10.

[0064] As shown schematically in Figure 3, the programming console 20 is of the portable type, equipped with autonomous power supply 21 to allow the operator to move from detonator to detonator, in particular to perform the first stage operation (Figure 2A).

[0065] The console 20 has an IT bus 22 connecting the processing processor 23, a permanent memory 24 for storing software implementing console functionality, an input / output interface 25 for connecting the console 20 either directly with the detonator 1, or to a two-wire network 30, user interface 26 (in in particular a display screen and alphanumeric keyboard for data entry) and an RFID reader 27 (radio frequency identification).

[0066] The programming console 20 also includes an RFID tag 28 equipped with a memory chip 280 capable of storing data. By "RFID label" is meant a traditional RFID chip with an antenna, whereby the RFID chip is equipped with communication means in accordance with radio frequency protocols and memory capabilities.

[0067] The RFID tag 28 with a capacity of 32 KB has at the same time sufficient possibilities for the applications of the blast metric programming according to the invention and the relatively low acquisition cost.

[0068] As an alternative, the programming console 20 may include a plurality of RFID labels 28 available to the reader 27 and polled sequentially when the memory of the previous label is fully used. Anti-collision mechanisms, well known to those skilled in the art, are implemented at the level of this reader in order to read these labels. In this way, you can easily program the console 20.

[0069] In one implementation mode, the RFID tag 28 is mounted on a removable medium, e.g., chip card format. It can be, therefore

53P34174PL00

EP 2 531 809 B1 is easily removed for placement in another programming console or in a blasting console, which simplifies the data transfer between different units. [0070] To implement the invention, the memory chip 280 stores a PT table forming all or part of the blast metric by associating the detonator ID with a delay corresponding to the firing delay time of the associated detonator. This table can be identified by the blasting record number possibly associated with the blasting network identifier or bus lines that will be programmed by this blasting meter (for example, the identifier of the "slave" blasting console connected to the blasting network). In this way, many PT tables can be stored together in the programming console 20.

[0071] Furthermore, it can be provided that the IDcons of the RFID tag 28 is stored in this memory chip in such a way as to allow, via the label 28-console 20, to identify the programming console 20 containing the label. In a variant, this identifier may be replaced by the identifier of the programming console 20 containing this label.

[0072] Examples of functions implemented by the software from the permanent memory 24 are shown in WO 97/45696, in particular the reconstruction of the identifier of the detonator 1 connected during the first stage shown in figure 2A.

[0073] An additional function of controlling the RF reader 27 is also provided. This function has various subfunctions such as write function, copy function, block function and traditional read function.

[0074] A recording function is provided to supplement the PT table during the first programming step of the blasting record.

[0075] The copy function makes it possible to copy, by reading-writing, the contents in the memory of the RFID tag present in the read field of the console 20, to the RFID tag 28 of the same console 20. This function is particularly carried out during the recovery of a blast metric partly developed before the console failure programming, or when combining several partial blast metrics in the same console 20 to perform detonator connection tests.

53P34174PL00

[0076] The blocking function enables the deactivation of the reader 27 during the intended transmission of the blasting record either to the blasting console 10 or to another programming console 20 for example before testing. This blocking can be triggered by automatic detection of another radio frequency field, or manually.

[0077] As shown schematically in figure 4, the firing console 10 also has an RFID reader 17 capable in particular of reading the RFID tags 28 of the programming consoles 20, which are shown in its reading field.

[0078] The firing console 10 thus has the function of transmitting PT tables stored in programming consoles 20 by reading radio frequency. The storage of these uploaded PT tables can be carried out either in an RFID tag 18 suitable for the firing console 10 or, preferably, in the multi-writable memory 19, of the RAM type, in the firing console.

[0079] Other functions and interfaces of the firing console 10 are traditional and similar, for example, to those described in WO 97/45696.

[0080] Again, referring to Figure 2A, the first programming step of the detonators 1 is carried out by one or more programming consoles 20. Each console may, for example, initially recover the identifier (LTi) of the blasting network or bus lines which it must program. To this end, the programming console 20 will simply read the RFID tag contained in the "slave" firing console connected to one or more programming networks.

[0081] By traveling the place where detonators are installed, the operator connects each detonator 1 individually and sequentially to the programming console 20. [0082] As an option, the operator can connect the programming console 20 to a two-wire network 30 (or to a part of this network, e.g. a blasting network) ) then without detonators 1. The operator then connects each detonator 1 in turn to the network 30.

53P34174PL00

[0083] The connection of a new detonator 1 to the network or to the console 20 is detected by the console which automatically recovers the ID_deta detonator, by exchanging messages via an interface 25. [0084] The operator is then called via the user interface

26, to the Tdet delay time assigned to the connected detonator. This "programming" may consist of entering digital data on a numeric keypad to specify a delay between 1 and 16,000 milliseconds by coding this delay in 14 bits.

[0085] In a variant, the delay times may be consistent with the logic string and the programming console 20 then automatically proposes a delay corresponding to this logic string. The operator approves then the proposed delay or introduces another delay. Implementation of this solution is generally when it is easy for the operator to traverse the place in accordance with the logical order of firing detonators and programming in turn these detonators, in order to fire the part with the maximum delays proposed automatically without manually entering data.

[0086] The programming console 20 thus associates, in RFID memory, the delay Tdet selected in the selected detonator 1. This association is saved in the form of a dependence table, a lookup table type, in a memory chip 280. The following table is a simplified example of a shot metric designated PT1 for the blasting network marked with LT1 number:

Table 1: PT1 blasting record containing n detonators

<td colspan="2">PT1 - LT1</td>

<td>^IDdet</td><td>Tdet (ms)</td>

<td> 1</td><td> 0</td>

<td> 2</td><td> 5</td>

<td> 3</td><td> 25</td>

<td></td><td></td>

<td>n</td><td>x</td>

53P34174PL00

[0087] When multiple blast metrics are stored, the operator further indicates to which blast metric (and thus the PTi table - LTi) the data entry binding must be made.

[0088] In the specific case of figure 2A, the programmed detonator 1 is then disconnected from console 20 and connected to the network 30.

[0089] These operations are carried out sequentially for each of the detonators 1 to be programmed until a complete blasting metric is obtained for all the detonators provided in the LT1 blasting network.

[0090] Sometimes, however, during this first stage, the programming console 20 a relief relief (battery 21 empty) or is damaged by construction equipment when the operator is in place, away from the IT center having the firing console 10.

[0091] Under these conditions, the invention makes it possible to easily recover, in situ, a blast metric partially created in the programming console and to continue programming in the secondary console without having to reprogram the detonators already processed.

To this end, the operator takes an auxiliary programming console 20 'identical to the defective console 20. When the defective console is in the RFID reading field of the auxiliary console, the operator selects the PT table copy function proposed by the auxiliary console, thanks in particular to the PTi and LTi identifiers, which makes it possible to identify with certainty the information to be reproduced.

[0093] Reading and writing in RFID labels are then carried out in a traditional manner and are not given in detail here.

[0094] It follows that the secondary console regains the configuration of the PT blasting metric when the first programming console fails.

[0095] The operator can thus continue programming other detonators without having to lose the work done so far.

[0096] The first programming stage may end with the test phase of connecting detonators 1 to the two-wire network. To this end, the programming console 20 containing the programmed blasting record is connected to the network. IN

53P34174PL00

In a variant, the test can be carried out in only one part of the network, e.g. only one bus line 30.

[0097] During this test, the programming console 20 must check that the set of detonators stored in the PT table is well connected to the network and that there are no detonators that are intruders in this network.

[0098] In practice for extensive locations, the first stage is implemented by many operators in parallel, using several programming consoles 20, to prepare a blast metric in less time.

[0099] In the methods known in the art, each programming console is therefore used separately for the test. Each console has the function of counting the number of connected detonators (through the recovery procedure of all detonators connected at a given time) and the function of verifying the connection of detonators in memory by sending / receiving messages to / from each of these detonators (console 20 retrieves each stored identifier and polls, through message for the presence in the blasting network of a detonator having this identifier). Detecting intruders is, however, difficult because among the detonators not programmed by the current console 20, some are programmed by another programming console. Mental or manual operations are therefore necessary and time consuming.

[0100] Within the scope of the present invention, during the test operation, it is initially possible to combine (for example by associating) the blast metrics of several programming consoles in one of them, called the main console. For example, it could be a set of consoles 20 that programmed the same LTi blasting network.

[0101] In this case, based on the only recovery procedure for all connected detonators, the main console can automatically determine the intruder detonators and whether the programmed detonators are all well connected.

[0102] Starting from the list received by the recovery procedure, each of the connected programmed detonators is marked in the PT table (using, for example, a marker), and the detonator counter is increased.

53P34174PL00

EP 2 531 809 B1 being intruders. The latter are, for example, detonators that have been forgotten to be programmed. The PT table entries, which are ultimately unmarked, correspond to detonators incorrectly connected to the network.

[0103] Thus, it can be seen that, by combining blast metrics facilitated by the RFID tags of the invention, the test operations are significantly simplified. [0104] To connect the blast metrics, the RFID reader 27 of the secondary programming consoles 20 is deactivated through the blocking function, and all or part of these secondary consoles are placed in the RFID reading field of the main console.

[0105] The latter, by means of the copy function described in detail above, sends the blast metrics of each secondary console to its respective memory 280, and combines them into one PT table, taking into account the PTi blast metric number and possibly the LTi blasting network.

[0106] Tests can therefore be carried out with a single programming console 20, for the entire network, without disconnecting some of the detonators. [0107] In a variant, the sub-part of the programming consoles may be rearranged depending on the network zones, for example a blasting network.

[0108] As the set of detonators 1 used in the blasting record sequence has been programmed and tested, the programming console 20, preferably the main console collecting the overall blasting record derived from the combination of partial blasting records, is placed near the blasting console 10 as shown in the figure 2B to send blast records.

[0109] The RFID reader 27 of the programming console 20 is deactivated via the blocking function.

[0110] The operator then activates the transmission function of the blasting console 10. This activation can only be authorized after entering the appropriate card containing secret codes. Any other security element can also be used to authorize this activation.

[0111] The PT blasting record table is then automatically sent to the blasting console 10 by reading the radio frequency by the reader 17. If several RFID labels are available, the blasting console 10 may

53P34174PL00

Request the operator to select all or part of them and all or part of the PTi tables stored therein for transmission. The transferred PT table is then stored in the RAM memory of the firing console 10.

[0112] As an alternative, this table can be stored in the memory of the RFID tag 18 also provided in the firing console 10. This configuration enables the copy function in the secondary firing console to be implemented, if desired, in a manner similar to the copy function provided for programming consoles 20.

[0113] Also, if many programming consoles 20 are shown to the firing console 10 for transferring a portion of the blasting metric, the blasting console 10 combines the PT tables recovered to form a general blasting metric, taking into account in particular the number of the PTi blasting metric associated with each PT console table programming.

[0114] When everything from the PT table is sent to the firing console 10, the firing network 40 connecting the firing console 10 to the detonators 1 is activated, as seen in figure 2C. The firing console 10 can thus perform pre-firing tests as described in WO 97/45696: automatic test of detonator firing modules in the network, detonator availability test.

[0115] After these tests, the operator gives the arming command using the appropriate button of the shot console 10, then fires with the shot button. This operation causes firing of each of the detonators with a delay appropriate to that provided in the PT metering shot loaded into the memory of the firing console 10. Traditional firing mechanisms can be used, for example those described in the publication referred to above.

[0116] The previous examples are only modes of the invention that are not limiting.

[0117] In particular, the PT table described above in the memory of programming consoles 20 that associate the detonator ID with the delay. However, a preliminary blast metric can be provided separately that assigns delay times to a set of holes of a given physical configuration

53P34174PL00

EP 2 531 809 B1 places. Programming by the programming console 20 can thus consist in associating detonators 1 with the holes, the table PT in memory thus associates the detonator with the hole of the given place. In this case, the delay detonator association is accomplished indirectly using the initial shot metric. Any blasting information, other than time delay or hole number, can be associated with a detonator at the programming console level, and as above, this information allows the creation of a blasting sequence (detonator ID - firing time delay). [0118] Furthermore, the firing console 10 described above has a structure similar to the structure of programming consoles 20, including in particular a radio frequency reader and optionally an RFID tag. The invention is however compatible with existing blasting consoles (without radio frequency means). In this case, the programming consoles 20 have a transfer function similar to that of WO 97/45696, for the automatic transmission of blast records from the memory to the blast console 10, to which they are (20) connected via infrared or via a wired connection. This function, however, provides for controlling the RF reader 27 of the programming console 20 to read the PT table from the memory and to send it to the firing console 10 via a suitable communication interface. This automatic transfer function is implemented by software stored in non-volatile 24 memory.

Davey Bickford Agent:

53P34174PL00

EP 2 531 809 B1