CN110311847B - Batch data transmission method and device - Google Patents

Batch data transmission method and device Download PDF

Info

Publication number
CN110311847B
CN110311847B CN201910559877.7A CN201910559877A CN110311847B CN 110311847 B CN110311847 B CN 110311847B CN 201910559877 A CN201910559877 A CN 201910559877A CN 110311847 B CN110311847 B CN 110311847B
Authority
CN
China
Prior art keywords
modbus
request
messages
sending
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910559877.7A
Other languages
Chinese (zh)
Other versions
CN110311847A (en
Inventor
贺学文
智艳利
李元鹏
黄亮
李剑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Helishi System Integration Co ltd
Original Assignee
Beijing Helishi System Integration Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Helishi System Integration Co ltd filed Critical Beijing Helishi System Integration Co ltd
Priority to CN201910559877.7A priority Critical patent/CN110311847B/en
Publication of CN110311847A publication Critical patent/CN110311847A/en
Application granted granted Critical
Publication of CN110311847B publication Critical patent/CN110311847B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40228Modbus

Abstract

The application discloses a batch data transmission method and a device, wherein the batch data transmission method comprises the steps of generating n Modbus request messages and sending the n Modbus request messages in batches according to a preset sequence, wherein n is an integer greater than or equal to 1; and receiving m returned Modbus response messages within a preset timeout interval, and judging whether batch sending is successful or not according to the received Modbus response messages, wherein m is an integer between 0 and n. According to the method and the device, the multiple Modbus request messages are sent in batches, the multiple Modbus response messages returned are received in the preset timeout interval, the data transmission time is greatly shortened, and errors caused by delaying to the slave station calibration are greatly avoided.

Description

Batch data transmission method and device
Technical Field
The present application relates to, but not limited to, the field of communications technologies, and in particular, to a method and an apparatus for transmitting batch data.
Background
The Modbus protocol is a response communication protocol widely used in the field of industrial automation, and has become a general industrial standard. One feature of the response communication protocol is that the responses are first asked and first obtained, and then in turn. The Modbus Protocol is classified into a Modbus RTU (Remote Terminal Unit, RTU) Protocol based on serial ports (RS-232, RS-422, RS-485) and a Modbus TCP Protocol based on Transmission Control Protocol/Internet Protocol (TCP/IP). As shown in fig. 1, Modbus communication uses Master-Slave (Slave) technology, where the Master initiates transmission (Query, which is also called Query/request, and in turn is called polling), and the Slave responds accordingly according to data provided by the Master Query. The master station can communicate with the slave stations individually or in a broadcast manner. If communicating alone, the slave station returns a message in response, and if queried in a broadcast manner, the slave station does not respond.
In the Modbus protocol, only the master station has the right to initiate Query, and the slave station has the right to send a Response message to the master station only after receiving the Query. In other words, in the Modbus protocol, the master station can only obtain the data of the slave station through Query/Response, and the slave station can never send any message to the master station actively. As shown in fig. 2, the master station sends a request to the slave station at a certain time, the slave station receives the request, identifies the request, and sends a response message to the master station as a receipt to the master station, and the master station receives the response message and then successfully completes the session of the request. In fig. 2, we note the time of a request/response as Ts, i.e.: and starting timing from the start of sending a request by the master station, receiving the request by the slave station and carrying out internal processing, then sending a response message to the master station by the slave station, and receiving the interval time corresponding to the end of timing by the master station when the response of the slave station is received. Obviously, Ts consists of three parts, one of which is the time interval from the time when the master station sends a request to the time when the slave station receives the request, which is denoted as Ta; secondly, the slave station consumes time for internal processing of the request, which is recorded as Tb; and thirdly, the slave station sends a response message to the master station, and the time interval of the master station receiving the response of the slave station is recorded as Tc. Namely Ts ═ Ta + Tb + Tc.
As shown in fig. 3, the master station sequentially reads a request from the polling list as a request to be sent this time, then generates a sending message according to the request, and starts a TimeOut timer (assuming that TimeOut time is TimeOut) after the message is successfully sent. If the master station successfully receives the response message of the equipment within the Timeout time, the master station processes the response message and then enters a next sending standby state; if the master station fails to receive the response message of the device within the TimeOut time, the master station considers that the request fails, the master station enters TimeOut processing (the master station records that the transmission fails once, and the link needs to be reconnected when the transmission fails continuously), and then the master station enters a next transmission standby state, and the process is repeated.
Modbus protocol is a typical request/response type communication protocol, and the conventional process always gives a question of one response, i.e. the last request is either timed out or is responded, and then the next sending request is entered. In practical application of the Modbus protocol, it is sometimes encountered that a certain operation needs to include n requests/responses to complete, for example, some remote control operations including an enable bit operation, and a timing operation in which time information is included in a plurality of messages. These remote control operations and timing are also accomplished by request/response combinations, so that such remote control and timing are also accomplished by a question-and-answer serial synchronization operation under the conventional flow.
Under a conventional method, the remote control and timing operation strictly follows the conventional flow of a Modbus protocol, the process is complicated, the operation time is long, and particularly for the timing operation, the longer the operation time is, the larger the timing error is.
Disclosure of Invention
The application provides a batch data transmission method and device, which can greatly shorten the data transmission time.
The embodiment of the invention provides a batch data transmission method, which comprises the following steps:
generating n Modbus request messages, and sending the n Modbus request messages in batches according to a preset sequence, wherein n is an integer greater than or equal to 1;
and receiving m returned Modbus response messages within a preset timeout interval, and judging whether batch sending is successful or not according to the received Modbus response messages, wherein m is an integer between 0 and n.
In an exemplary embodiment, when the n Modbus request messages are sent in batch according to the preset sequence, the method further includes:
and setting an exclusive identifier, wherein the exclusive identifier is used for forbidding the sending of other messages except the n Modbus request messages in the process of sending the n Modbus request messages in batches.
In an exemplary embodiment, the time for sending the n Modbus request messages is TAb, the time for completing n times of batch sending and receiving is TBb,
TAb=(n-1)*(Ta+T0)+Ta,
TBb=(n-1)*(Ta+T0)+Ts,
wherein: the mark is a multiplication number, and Ta is a time interval from the time when the master station sends a request message to the time when the slave station receives the request message;
t0 is the master station transmission interval time;
Ts=Ta+Tb+Tc;
tb is the time consumption of the slave station for internal processing of the request message;
tc is the time interval from when the slave station sends a response message to the master station to when the master station receives the response message from the slave station.
In an exemplary embodiment, when the first n-1 request messages are sequentially sent, a TimeOut timer is not started, and the TimeOut timer is started only after the nth request message is sent.
In an exemplary embodiment, after the step of generating the n Modbus request messages and before the step of sending the n Modbus request messages in batch according to the preset sequence, the method further includes:
configuring one or more of the n Modbus request messages as key request messages;
the step of judging whether the batch sending is successful or not according to the received Modbus response message comprises the following steps:
if the Modbus response messages corresponding to all the key request messages one to one are received within the preset timeout interval, judging that the batch sending is successful;
and if the Modbus response messages corresponding to all the key request messages one to one are not received within the preset timeout interval, judging that the batch sending fails.
In an exemplary embodiment, the Modbus request message includes a Modbus TCP message or a Modbus RTU message; the Modbus response message comprises a Modbus TCP message or a Modbus RTU message.
In an exemplary embodiment, when the Modbus request message and the Modbus response message are Modbus TCP messages, each time a request message is successfully sent, the request message is stored in a local first sending request list AQS, where the AQS includes valid information of n request messages, and further includes an RF flag and a KQ flag of each request message, where the RF flag is used to indicate whether a response message corresponding to the request message is received, and the KQ flag is used to indicate whether the request message is a critical request message.
In an exemplary embodiment, when the Modbus request message and the Modbus response message are Modbus RTU messages, the n generated request messages are stored in a local second transmission request list TM before being transmitted, or the request messages are sequentially stored in the TM after the batch transmission is successful; the TM includes effective information of n request messages, and further includes an RF flag and a KQ flag of each request message, where the RF flag is used to indicate whether a response message corresponding to the request message is received, and the KQ flag is used to indicate whether the request message is a critical request message.
The embodiment of the invention also provides a batch data transmission device, which comprises a processor and a memory, wherein: the processor is configured to execute a program stored in the memory to implement the steps of the batch data transfer method as described in any one of the above.
The embodiment of the invention also provides a batch data transmission device, which comprises a batch sending module and a batch receiving module, wherein:
the system comprises a batch sending module, a data processing module and a data processing module, wherein the batch sending module is used for generating n Modbus request messages and sending the n Modbus request messages in batches according to a preset sequence, and n is an integer greater than or equal to 1;
and the batch receiving module is used for receiving the returned m Modbus response messages within a preset timeout interval and judging whether the batch sending is successful or not according to the received Modbus response messages, wherein m is an integer between 0 and n.
Compared with the prior art, the batch data transmission method and the device send a plurality of Modbus request messages in batch and receive a plurality of returned Modbus response messages within the preset timeout interval, so that the data transmission time is greatly shortened, and errors caused by delay to slave station timing are greatly reduced.
Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application. Other advantages of the application may be realized and attained by the instrumentalities and combinations particularly pointed out in the specification, claims, and drawings.
Drawings
The accompanying drawings are included to provide an understanding of the present disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the examples serve to explain the principles of the disclosure and not to limit the disclosure.
FIG. 1 is a schematic diagram of a Modbus master-slave communication network in the related art;
FIG. 2 is a conventional sequence diagram of a Modbus protocol master-slave communication in the related art;
FIG. 3 is a schematic flow chart illustrating a Modbus data transmission method according to the related art;
FIG. 4 is a schematic diagram illustrating a six-step Modbus remote control process in the related art;
FIG. 5 is a schematic diagram of a six-step timing process of a Modbus in the related art;
FIG. 6 is a flowchart illustrating a batch data transmission method according to an embodiment of the present invention;
FIG. 7 is a flow chart illustrating another batch data transmission method according to an embodiment of the invention;
FIG. 8 is a schematic diagram of a Modbus master-slave communication network according to an embodiment of the present invention;
FIG. 9 is a schematic diagram of a batch remote control process according to an embodiment of the present invention;
FIG. 10 is a schematic diagram of a batch timing process according to an embodiment of the present invention;
fig. 11 is a schematic structural diagram of a batch data transmission apparatus according to an embodiment of the present invention.
Detailed Description
The present application describes embodiments, but the description is illustrative rather than limiting and it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are possible. Any feature or element of any embodiment may be used in combination with or instead of any other feature or element in any other embodiment, unless expressly limited otherwise.
The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features and elements disclosed in this application may also be combined with any conventional features or elements to form a unique inventive concept as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other inventive aspects to form yet another unique inventive aspect, as defined by the claims. Thus, it should be understood that any of the features shown and/or discussed in this application may be implemented alone or in any suitable combination. Accordingly, the embodiments are not limited except as by the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.
Further, in describing representative embodiments, the specification may have presented the method and/or process as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. Other orders of steps are possible as will be understood by those of ordinary skill in the art. Therefore, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. Further, the claims directed to the method and/or process should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the sequences may be varied and still remain within the spirit and scope of the embodiments of the present application.
The Modbus RTU protocol is a widely used acknowledge communication protocol in the field of industrial automation and has become the Fieldbus industry standard. Recent industrial network market reports published by HMS industrial networks limited, sweden, show that the Modbus RTU protocol lives the second share of the global field bus market.
The Modbus RTU protocol can carry out communication based on various serial port standards (hereinafter referred to as serial ports) of RS-232, RS-422, two-wire system RS-485 and four-wire system RS-485, wherein the two-wire system RS-485 adopts a half-duplex working mode, namely only one point can be in a sending state at any time, and other serial port standards are full-duplex working modes, namely data receiving and sending of the serial ports are separated, and data receiving and sending can be simultaneously supported. Therefore, the application layer communication protocol based on the full-duplex serial port provides the possibility of batch sending and receiving of the application layer.
The batch data transmission scheme based on the Modbus RTU protocol works in a full-duplex serial port working mode.
The Modbus TCP message is a frame formed by embedding a Protocol Data Unit (PDU) irrelevant to a base communication layer into an application layer of an Open System Interconnection (OSI) model, adding a 6-byte header in the front of the PDU, and removing a checksum portion at the end of the Modbus RTU Protocol (the TCP Protocol itself contains a cyclic redundancy check CRC32 checksum). The request/response mechanism of the TCP can work well with the master/slave mechanism of the Modbus.
The Modbus TCP message format is as follows:
header Function code Data of
The header description:
Figure BDA0002107946690000071
the fields are described as follows:
1) and the transaction identification is used for transaction pairing. And the Modbus server copies the transaction identification requested by the client terminal in response.
The request and the response correspond to each other by a transaction identification. Therefore, at the same time, the transaction identity of the TCP connection must be unique. The standard committee recommends that the transaction identifier does not use a simple count-message sequence number (abbreviated sequence number) and that the master station adds 1 to each request. For more than ten years, the Modbus TCP protocol has appeared so far, and mainstream manufacturers adopt standard recommendations, that is, the transaction identifier is actually the sequence number.
2) And the protocol identification is used for multi-element identification in the system. The Modbus protocol is identified with a '0'.
3) The length field is counted in bytes and includes a unit identification and a data field.
4) A unit identifier for intra-system routing. The typical application is that the request and server reply message return values must be the same in this field value.
In some cases, the unit identification carries the Modbus slave address of the remote device. However, in the TCP layer, the Modbus server uses its IP address to address, so that the Modbus unit ID has no practical meaning. This field value is then 0 xFF.
However, if the slave station has its own subnet, the device address may be 1 to 247.
Application of sequence numbers:
I) for each message, the master station initializes the slave station and generates a sequence number;
II) the response information of the slave station should use the same sequence number sent from the master station;
III) the master station shall confirm that the sequence number received from the slave station is the same as the sequence number previously sent to the slave station;
the principle that the master station increases the sequence number value is as follows:
A) the sequence number is stored in two bytes;
B) the range of sequence numbers should be (0-65535) or (0x0000to 0 xFFFF);
C) the starting value of the sequence number should be 0;
D) for each message sent by the master station, which includes information or control for normal polling, fault polling and retry, the master station should increase the sequence number by 1;
E) if the master station finds that the sequence number of the response message of the slave station is wrong, the master station disregards the message and declares that the communication state is not good enough.
In conclusion, the Modbus TCP protocol has the following key characteristics:
(1) the initial two bytes of the Modbus TCP protocol message are called "transaction id", which is actually the sequence number.
(2) The master determines the value of the sequence number and the slave must copy the sequence number in the request as a response.
(3) The sequence number is incremented by one each time the master sends a request.
The following application scenarios of two Modbus protocols (Modbus RTU protocol or Modbus TCP protocol) are assumed:
scenario 1 applies under conventional methods: as shown in fig. 4, remote control of a certain slave device needs to be performed in 6 steps, which are: remote control enabling, remote control executing, remote control enabling canceling, remote control enabling, remote control executing zero clearing and remote control enabling canceling. Under the conventional condition, the complete process of remote control needs to be divided into six rounds of response, which are respectively as follows: 1) the master station sends remote control enabling, and the slave station responds to the remote control enabling; 2) after receiving the remote control enabling response, the master station sends remote control execution, and the slave station responds to the remote control execution; 3) after receiving the remote control execution response, the master station sends a remote control enable cancel, and the slave station responds to the remote control enable cancel; 4) after receiving the cancellation of the remote control enable, the master station sends the remote control enable, and the slave station responds to the remote control enable; 5) after receiving the remote control enabling response, the master station sends remote control execution zero clearing, and the slave station responds to the remote control execution zero clearing; 6) and after receiving the remote control execution zero clearing response, the master station sends the remote control enable cancellation, the slave station responds the remote control enable cancellation, and the master station completes the remote control operation of the current round after receiving the remote control enable cancellation.
Scenario 2 applies under conventional methods: as shown in fig. 5, the timing of a certain slave device needs to be divided into 6 steps, and the master station sequentially sends messages of function codes 6, wherein the messages sequentially carry the year, month, day, hour, minute and second of the master station time.
When the Modbus RTU protocol is used for serial port communication, Ta and Tc are related to the number of message bytes and the serial port communication baud rate (hereinafter referred to as baud rate), are in direct proportion to the number of the message bytes and are in inverse proportion to the baud rate, and the time consumed for transmitting one byte is about 1 millisecond under the classic 9600bps baud rate. Tb is related to the slave station device, and Tb is between 5 and 20 milliseconds generally depending on the hardware performance of the device and the software processing capability thereof.
For the sake of illustration, we do not take the baud rate to be 9600bps, and the time taken to transmit one byte is about 1 millisecond. A typical request ( function codes 1, 2, 3, 4, 5, 6) of a Modbus RTU has a message length of 8 bytes, where Ta is 8 milliseconds; the length of the response message of the functional codes 1, 2, 3 and 4 depends on the corresponding point number in the request, the value range is 6-256 bytes, and Tc is 6-256 milliseconds; the message of the function codes 5 and 6 is also 8 bytes, and in this case, Tc is 8 milliseconds.
In Modbus communication, after receiving the response from the slave station of the last request, the master station usually needs to have a certain active rest time, called master station delay time for short, or master station interval time (denoted as T0), before sending the next request, and the purpose is two: firstly, the communication traffic of both the master and the slave is controlled, and secondly, if T0 is 0 (indicating that the master station immediately sends the next request after receiving the response of the slave station of the last request), some slave stations often fail to process the request, which may cause communication abnormality or even interruption. T0 is usually set to a value ranging from 0to 100 milliseconds.
Let TA be the time for completing batch transmission n times, and TB be the time for completing batch transmission n times and receiving n times.
For the convenience of distinction, when the traditional Modbus protocol is used for communication, TA is TAa, and TB is TBa; note that when the bulk data transfer scheme of the present application is used for communication, TA is TAb and TB is TBb.
As shown in fig. 2, in the conventional method, the next transmission must be performed after the previous transmission/reception is completed, the transmission/reception times 1 to (n-1) are all (Ts + T0), the transmission time for the nth time is Ta, and the transmission/reception time for the nth time is Ts. Ts is Ta + Tb + Tc, and therefore,
TAa=(n-1)*(Ts+T0)+Ta-------(1)
TBa=(n-1)*(Ts+T0)+Ts-------(2)
embodiment batch data transmission method
As shown in fig. 6, an embodiment of the present invention provides a batch data transmission method, including the following steps:
step 601: generating n Modbus request messages, and sending the n Modbus request messages in batches according to a preset sequence, wherein n is an integer greater than or equal to 1;
in an exemplary embodiment, the Modbus request message includes a Modbus RTU message or a Modbus TCP message.
In an exemplary embodiment, when the n Modbus request messages are sent in batch according to the preset sequence, the method further includes:
and setting an exclusive identifier, wherein the exclusive identifier is used for forbidding the sending of other messages except the n Modbus request messages in the process of sending the n Modbus request messages in batches.
In this embodiment, when n pieces of Modbus request messages are sent in batch, an exclusive identifier (Lock for short) is set to true, and after the batch request is sent, Lock is set to false, so as to ensure that the master station does not insert any other request during the batch sending of the n pieces of Modbus request messages. Why will there be a possibility to insert other requests? Because the sending and receiving of the master station are usually two independent threads, it is possible that after n times of batch requests are sent to the x (x < n) th request, the slave station receives a response, at this time, a receive callback function of the master station is triggered, the master station can normally recognize and process a received message, and if there is no Lock identifier, the master station may trigger a new round of request, thereby causing an unexpected request to be inserted after the x request. With the Lock identification, even if the master station receives the response of the slave station during the batch sending, after the master station normally receives the response, the master station cannot generate a new request when checking that the Lock identification is true, so that the master station is prevented from inserting any other request during the batch sending of the request.
After the bulk transmission scheme is adopted, the next transmission can be performed only after the last transmission is completed, the 1 st to (n-1) th transmissions all take (Ta + T0), and the nth transmission takes Ta, namely TAb is (n-1) × (Ta + T0) + Ta. Next, we calculate TBb by only calculating the time (denoted as TimeN) when the master station receives its response after the nth request is sent, because one feature of the response communication protocol is that the master station first gets and sequentially responds, so as long as the master station receives the response of the nth request, it indicates that the master station must collect all responses of the previous (n-1) requests before that. As a rule, since the transmission/reception time of any request is Ts + Ta + Tb + Tc, the nth transmission/reception time is also Ts in the present application. Thus:
TAb=(n-1)*(Ta+T0)+Ta;
TBb=(n-1)*(Ta+T0)+Ts。
in an exemplary embodiment, after the step of sending the n Modbus request messages in batch according to a preset sequence, the method further includes:
and storing the transmitted Modbus request message into a transmission request queue.
In an exemplary embodiment, after the step of generating n Modbus request messages and before the step of sending the n Modbus request messages in batch according to a preset sequence, the method further includes:
and configuring one or more of the n Modbus request messages as key request messages.
In an exemplary embodiment, a preset sending interval time is set between every two sent Modbus request messages, so that the slave station can conveniently recognize different requests and process the requests.
In an exemplary embodiment, when the primary station sequentially transmits the first n-1 request messages, the primary station does not start the TimeOut timer, and only starts the TimeOut timer after the nth request message is transmitted.
Step 602: and receiving m returned Modbus response messages within a preset timeout interval, and judging whether batch sending is successful or not according to the received Modbus response messages, wherein m is an integer between 0 and n.
It should be noted that, because the Modbus TCP protocol and the Modbus RTU protocol have the following differences:
1. the physical Ethernet TCP protocol is full duplex, and communication nodes on the Ethernet can receive and transmit simultaneously;
2. as an application layer protocol of the TCP, a Modbus TCP protocol message includes a "packet sequence number" field (i.e. a sequence number), and both a master and a slave can clearly identify and receive one Modbus TCP message in a data stream by using the "packet sequence number";
therefore, when the received Modbus TCP response message is analyzed, the analysis can be carried out according to the packet sequence number field in the Modbus TCP response message and the specific content of the message; when the received Modbus RTU response message is analyzed, the analysis can be carried out according to the specific content of the Modbus RTU response message.
In an exemplary embodiment, after the step of receiving the m pieces of returned Modbus response messages, the method further includes:
determining the Modbus request message corresponding to each Modbus Response message, and modifying the receiving mark RF (Response Flag, 0 is in an initial state, 1 indicates that the request has successfully received the equipment Response, and RF1, RF2, … …, and RFn indicates the receiving marks of the requests 1, 2, … … n, respectively) of the Modbus request message corresponding to the sending request queue.
In an exemplary embodiment, the determining whether the batch transmission is successful according to the received Modbus response message includes:
if Modbus response messages corresponding to all sent Modbus request messages one to one are received within a preset timeout interval, judging that the batch sending is successful;
and if Modbus response messages corresponding to all sent Modbus request messages one to one are not received within the preset timeout interval, judging that the batch sending fails.
In another exemplary embodiment, the determining whether the batch transmission is successful according to the received Modbus response message includes:
if Modbus response messages corresponding to all the key request messages one to one are received within a preset timeout interval, judging that the batch sending is successful;
and if Modbus response messages corresponding to all the key request messages one to one are not received within the preset timeout interval, judging that the batch sending fails.
In an exemplary embodiment, the method further comprises:
if the batch sending is judged to be successful, deleting the sent Modbus request message and the mark thereof in the sending request queue;
if the batch sending is judged to fail, whether the retransmission is needed is detected; if the messages need to be retransmitted, the n Modbus request messages are retransmitted in batches according to a preset sequence; and if the Modbus request message does not need to be retransmitted, deleting the transmitted Modbus request message and the mark thereof in the transmission request queue.
In an exemplary embodiment, we assume that an operation needs to include n requests/responses to complete, and the corresponding n requests and responses are respectively recorded as: Q1/R1, Q2/R2, … …, Qn/Rn.
As shown in fig. 7, the master station first checks whether it is currently required to send requests in batches, and if not, enters a master-slave conventional communication flow; and if so, entering a batch sending request flow.
Illustratively, in the flow of bulk sending requests, if the Modbus TCP protocol is used, n requests Q1, Q2, … …, Qn that need to be Sent in bulk at this time are sequentially generated, and then the requests Q1, Q2, … …, Qn are sequentially Sent, and each time a request is successfully Sent, the request is saved in a local first sending request list (Array of Query send, AQS for short), the AQS further includes RF (Response Flag, initial value is 0) and KQ (Key Query, 1 indicates whether the request is a critical request or not, default value is 1, and KQ of all requests is 1, indicates that all requests need to be returned), and uses "packet number" as a subscript index of the AQS (we note that "packet number" corresponding to the n requests and responses "is 1, SN2, … …, SNn, respectively). Note that a certain transmission interval (denoted T0) is usually required between two of these n requests because it is convenient for the slave to recognize different requests and enable the slave to process, T0 defaults to 5 milliseconds and is of an adjustable configuration, the minimum available value of T0 is often dependent on the slave device, and T0 is typically given directly by the slave or from actual testing. Specifically, T0 is a device attribute parameter, and is not specifically required or dependent on the patent, and will not be further described herein. After all n requests Q1, Q2, … …, Qn are successfully sent by the primary station in sequence, a TimeOut timer is started, TimeOut (TimeOut is generally 1000 milliseconds and is configurable). After receiving the request sequence, the device will reply to R1, R2, … …, Rn in turn, the primary station will parse R1, R2, … …, Rn in turn from the received data stream according to the transmission information in AQS, especially the "packet sequence number" in the transmission information, and concatenate the corresponding re-calibration value RF as 1 to indicate that the primary station has successfully received R1, R2, … …, Rn. After each receiving process, the master station checks the RF values of all requests with KQ of 1 in AQS, if the master station has RF of all requests with KQ of 1 within the TimeOut time, it indicates that all responses of key requests are successfully received, since KQ of all requests is usually 1 (configurable), it usually means that all responses of requests R1, R2, … …, Rn are received, at this time, the TimeOut timer is aborted, and the batch request is declared that the transaction is successfully sent, and the next round of sending transaction is entered; if the TimeOut TimeOut timer reaches, if the RF of any request with KQ of 1 in the AQS is not 1, the request indicates that the response of all key requests cannot be successfully received, the batch request transmission failure is declared, if the request needs to be retransmitted, the retransmission process is entered, and if the request does not retransmit, the AQS and the mark thereof are cleared, the next round of transaction transmission is entered.
Illustratively, in the flow of batch transmission requests, if the Modbus RTU protocol is used, the master station generates n sequential transmission messages (these n sequential messages are denoted as Q1, Q2, …, Qn-1, Qn in turn), and these requests are stored in a local second transmission request list (denoted as TM, which contains valid information of Q1, Q2, …, Qn-1, Qn, and each request further includes RF and KQ flags, and RF and KQ meanings and usage are the same) before transmission (these requests may also be stored in the local second transmission request list TM after the master station has successfully transmitted in turn). After all n requests Q1, Q2, … …, Qn are successfully sent by the primary station in sequence, a TimeOut timer is started, TimeOut (TimeOut is generally 1000 milliseconds and is configurable). After receiving the request sequence, the device will reply to R1, R2, … …, Rn in turn, the primary station will parse out R1, R2, … …, Rn in turn from the received data stream according to the transmitted information in TM, and concatenate the corresponding back-corrected values RF to 1 to indicate that the primary station has successfully received R1, R2, … …, Rn. After each receiving process, the master station checks the RF values of all requests with KQ of 1 in the TM, if the master station has 1 RF of all requests with KQ of 1 within the TimeOut time, it indicates that all responses of the key requests are successfully received, since the KQ of all requests is usually 1 (configurable), it usually means that all responses of the requests R1, R2, … …, and Rn are received, at this time, the TimeOut timer is aborted, and the batch request is declared that the transaction is successfully sent, and the next round of sending transactions is entered; if the TimeOut TimeOut timer reaches, as long as the RF of any request with KQ of 1 in the TM is not 1, the request indicates that all responses of the key requests cannot be successfully received, the batch request transmission failure is declared, if the request needs to be retransmitted, the retransmission process is entered, if the request does not need to be retransmitted, the TM and the mark thereof are cleared, and a new round of response process is entered. Obviously, when n is 1, the application is completely consistent with the conventional question-and-answer mode.
As shown in fig. 8, the master station continuously sends four requests in batches according to the batch transmission scheme of the present application, the slave stations sequentially identify the four requests, and sequentially reply corresponding four response messages to the master station, which vividly shows the asynchronous concurrent processing effect when the present application executes the batch requests. Asynchronous means that after a request, the next request can be sent without waiting for a response; concurrent means that the master station continues to send multiple requests for a continuous period of time during which no devices respond.
Example two-batch data transmission device
The embodiment of the invention also provides a batch data transmission device, which comprises a processor and a memory, wherein: the processor is configured to execute a program stored in the memory to implement the steps of the batch data transfer method as described in any one of the above.
Embodiment three-batch data transmission device
As shown in fig. 11, an embodiment of the present invention further provides a batch data transmission apparatus, including a batch sending module 1101 and a batch receiving module 1102, where:
the batch sending module 1101 is configured to generate n Modbus request messages and send the n Modbus request messages in batches according to a preset sequence, where n is an integer greater than or equal to 1;
and the batch receiving module 1102 is configured to receive m returned Modbus response messages within a preset timeout interval, and determine whether batch sending is successful according to the received Modbus response messages, where m is an integer between 0 and n.
In an exemplary embodiment, the Modbus request message includes a Modbus RTU message or a Modbus TCP message; the Modbus response message comprises a Modbus RTU message or a Modbus TCP message.
In an exemplary embodiment, when the Modbus request packet and the Modbus response packet are Modbus TCP packets, the batch sending module 1101 stores a request packet in a local first sending request list AQS every time a request packet is successfully sent, where the AQS includes valid information of n request packets, and further includes an RF flag and a KQ flag of each request packet, where the RF flag is used to indicate whether a response packet corresponding to the request packet is received, and the KQ flag is used to indicate whether the request packet is a critical request packet.
In an exemplary embodiment, when the Modbus request message and the Modbus response message are Modbus RTU messages, the batch sending module 1101 stores the n generated request messages into a local second sending request list TM before sending, or sequentially stores the request messages into the TM after the master station successfully sends the batch messages; the TM includes effective information of n request messages, and further includes an RF flag and a KQ flag of each request message, where the RF flag is used to indicate whether a response message corresponding to the request message is received, and the KQ flag is used to indicate whether the request message is a critical request message.
In an exemplary embodiment, the batch sending module 1101 is further configured to:
and when the n Modbus request messages are sent in batches according to a preset sequence, setting an exclusive identifier, wherein the exclusive identifier is used for forbidding the sending of other messages except the n Modbus request messages in the process of sending the n Modbus request messages in batches.
In an exemplary embodiment, assuming that the time for the batch sending module 1101 to send the n Modbus request messages is TAb, and the time for the batch receiving module 1102 to complete n times of batch sending and receiving is TBb, then:
TAb=(n-1)*(Ta+T0)+Ta,
TBb=(n-1)*(Ta+T0)+Ts,
wherein: the mark is a multiplication number, and Ta is a time interval from the time when the master station sends a request message to the time when the slave station receives the request message;
t0 is the master station transmission interval time;
Ts=Ta+Tb+Tc;
tb is the time consumption of the slave station for internal processing of the request message;
tc is the time interval from when the slave station sends a response message to the master station to when the master station receives the response message from the slave station.
In an exemplary embodiment, the batch sending module 1101 does not start the TimeOut timer when sequentially sending the first n-1 request messages, and starts the TimeOut timer only after sending the nth request message.
In an exemplary embodiment, the batch sending module 1101 is further configured to:
and after the n Modbus request messages are sent in batches according to a preset sequence, storing the sent Modbus request messages into a sending request queue.
In an exemplary embodiment, the batch sending module 1101 is further configured to: and configuring one or more of the n Modbus request messages as key request messages.
In an exemplary embodiment, a preset sending interval time is set between every two Modbus request messages sent by the batch sending module 1101, so that the slave station can recognize different requests and process the requests.
In an exemplary embodiment, the batch receiving module 1102 is further configured to:
determining the Modbus request message corresponding to each Modbus response message, and modifying the receiving mark of the Modbus request message corresponding to the sending request queue.
In an exemplary embodiment, the determining, by the batch receiving module 1102, whether the batch transmission is successful according to the received Modbus response message includes:
if Modbus response messages corresponding to all sent Modbus request messages one to one are received within a preset timeout interval, judging that the batch sending is successful;
and if Modbus response messages corresponding to all sent Modbus request messages one to one are not received within the preset timeout interval, judging that the batch sending fails.
In another exemplary embodiment, the determining, by the batch receiving module 1102 according to the received Modbus response message, whether the batch transmission is successful at this time includes:
if Modbus response messages corresponding to all the key request messages one to one are received within a preset timeout interval, judging that the batch sending is successful;
and if Modbus response messages corresponding to all the key request messages one to one are not received within the preset timeout interval, judging that the batch sending fails.
In an exemplary embodiment, the batch receiving module 1102 is further configured to:
if the batch sending is judged to be successful, deleting the sent Modbus request message in the sending request queue;
if the batch sending is judged to fail, whether the retransmission is needed is detected; if the messages need to be retransmitted, the n Modbus request messages are retransmitted in batches according to a preset sequence; and if the Modbus request message does not need to be retransmitted, deleting the transmitted Modbus request message in the transmission request queue.
After the bulk transmission scheme is adopted, the next transmission can be performed only after the last transmission is completed, the 1 st to (n-1) th transmissions all take (Ta + T0), and the nth transmission takes Ta, namely TAb is (n-1) × (Ta + T0) + Ta. Next, we calculate TBb by only calculating the time (denoted as TimeN) when the master station receives its response after the nth request is sent, because one feature of the response communication protocol is that the master station first gets and sequentially responds, so as long as the master station receives the response of the nth request, it indicates that the master station must collect all responses of the previous (n-1) requests before that. As a rule, since the transmission/reception time of any request is Ts + Ta + Tb + Tc, the nth transmission/reception time is also Ts in the present application. Thus:
TAb=(n-1)*(Ta+T0)+Ta-------(3)
TBb=(n-1)*(Ta+T0)+Ts-------(4)
in particular, in the following representation and calculation, we hide the unit, note that the time unit is milliseconds.
For the convenience of distinction, we particularly note that when using conventional serial communication, TA is TAa1, TB is TBa 1; when the traditional Modbus TCP protocol is used for communication, TA is TAa2, and TB is TBa 2.
In the serial communication mode, generally:
Ta=8,Tb∈[5,20],Tc∈[6,256],T0∈[0,100].
we take the minimum of the above four parameters, i.e.: ta is 8, Tb is 5, Tc is 6, T0 is 0, Ts is 19, and equations (1) to (4) are substituted to obtain:
TAa 1=19n-11-------(5)
TBa 1=19n-----------(6)
TAb1=8n------------(7)
TBb1=8n+11--------(8)
when n is 1, obviously TAa1 is TAb1 is 8 is Ta; TBa1 TBb1 Ts 19.
When n is 6, TAa1 is 103, TBa1 is 114; TAb1 ═ 48, TBb1 ═ 59.
We take the maximum of the above four parameters, i.e.: ta is 8, Tb is 20, Tc is 256, T0 is 100, Ts is 284, and equations (1) to (4) are substituted to obtain:
TAa1=292n-284-------(9)
TBa 1=292n-8---------(10)
TAb1=108n-100------(11)
TBb1=108n+176------(12)
when n is 1, obviously TAa1 TAb1 Ta 8 Ta; TBa1 TBb1 Ts 284.
When n is 6, TAa1 is 1468, TBa1 is 1744, TAb1 is 548, and TBb1 is 824.
We take the above four parameters as typical representative values, namely: ta is 8, Tb is 10, Tc is 8, T0 is 5, Ts is 26, and equations (1) to (4) are substituted to obtain:
TAa1=31n-23-------(13)
TBa1=31n-5--------(14)
TAb1=13n-5--------(15)
TBb1=13n+13------(16)
when n is 1, obviously TAa1 is TAb1 is 8 is Ta; TBa1 TBb1 Ts.
When n is 6, TAa1 is 163, TBa1 is 181, TAb1 is 73, and TBb1 is 91.
When the bulk transfer scheme of the present application is applied to the above application scenario 1: when the scene is remotely controlled, as shown in fig. 9, the master station continuously sends six requests in batches, and the slave station sequentially identifies the six requests and sequentially replies corresponding six response messages to the master station. In a typical scenario (Ta-8, Tb-10, Tc-8, T0-5), when using a conventional one-to-one transmission method, it takes 163 milliseconds to transmit a round of all remote transactions (TAa); when the batch transmission scheme is used, only 73 milliseconds are needed, which is equivalent to 45% of the conventional transmission time; using the conventional one-to-one transmission method, 181 milliseconds are required to complete a round of all remote transactions (TAb); when the batch transmission scheme is used, only 91 milliseconds are needed, which is equivalent to 50% of the conventional completion time;
when the bulk transfer scheme of the present application is applied to the above application scenario 2: in the timing scenario, as shown in fig. 10, the master station continuously sends six requests in batch, and the slave station sequentially identifies the six requests and sequentially replies corresponding six response messages to the master station. In this scenario we should pay more attention to the time when the device receives all commands, obviously this value is equal to TA. In a typical scenario (Ta-8, Tb-10, Tc-8, T0-5), when using a conventional one-to-one transmission method, it takes 163 milliseconds to transmit a round of all remote transactions (TAa); when the batch transmission scheme is used, only 73 milliseconds are needed, which is equivalent to 45% of the conventional transmission time; using the conventional one-to-one transmission method, 181 milliseconds are required to complete a round of all remote transactions (TAb); with the bulk transfer scheme of the present application, only 91 milliseconds are required, corresponding to 50% of the normal completion time. Further, since TAb ═ n-1 ═ Ta + T0) + Ta, n is known to the master station, and Ta is only related to the transmission bytes and baud rate in serial communication as described above, T0 is also known. The value of TAb (n-1) (Ta + T0) + Ta can be calculated in advance, time compensation is carried out by the master station, the time in the message is the master station time + TAb, and when the batch transmission scheme is used and serial port full-duplex communication is carried out, errors caused by time correction of the slave station due to delay are completely avoided. Under the conventional transmitting method, TAa is (n-1) x (Ts + T0) + Ta is (n-1) + Ta + Tb + Tc + T0) + Ta, and Tb is not constant, which causes great difficulty and error in the compensation of the primary station.
In TCP/IP ethernet communication, Ta and Tc are often only sensitive to network delay and are substantially independent of message length in the case of short message (less than 1024 bytes) transmission. Because the maximum message length of the Modbus TCP is only 260 bytes, in the local area network, the value range of Ta and Tc is usually 1-10 milliseconds. Tb is related to the slave station device, and Tb is between 5 and 20 milliseconds generally depending on the hardware performance of the device and the software processing capability thereof. That is, in an industrial local area network, generally:
Ta∈[1,10],Tb∈[5,20],Tc∈[1,10],T0∈[0,100].
we take the minimum of the above four parameters, i.e.: ta is 1, Tb is 5, Tc is 1, T0 is 0, Ts is 7, and equations (1) to (4) are substituted to obtain:
TAa2=7n-6-------(17)
TBa 2=7n---------(18)
TAb2=n----------(19)
TBb2=n+6-------(20)
when n is 1, obviously TAa2 is TAb2 is 1 is Ta; TBa2 ═ TBb2 ═ 7 ═ Ts.
When n is 6, TAa2 is 36, TBa2 is 42; TAb2 ═ 6, TBb2 ═ 12.
We take the maximum of the above four parameters, i.e.: when Ta is 10, Tb is 20, Tc is 10, T0 is 100, Ts is 40, and equations (1) to (4) are substituted, the following can be obtained:
TAa 2=140n-130-------(21)
TBa 2=140n-100-------(22)
TAb 2=110n-100-------(23)
TBb 2=110n-70--------(24)
when n is 1, obviously TAa2 is TAb2 is 10 is Ta; TBa2 TBb2 Ts 40.
When n is 6, TAa2 is 710, TBa2 is 740, TAb2 is 560, and TBb2 is 590.
We take the above four parameters as typical representative values, namely: ta is 2, Tb is 10, Tc is 2, T0 is 5, Ts is 14, and equations (1) to (4) are substituted to obtain:
TAa2=16n-14-------(25)
TBa2=16n-2--------(26)
TAb2=7n-5---------(27)
TBb2=7n+7---------(28)
when n is 1, obviously TAa2 is TAb2 is 2 is Ta; TBa 2-TBb 2-14-Ts.
When n is 6, TAa2 is 82, TBa2 is 94, TAb2 is 37, and TBb2 is 49.
When the bulk transfer scheme of the present application is applied to the above application scenario 1: in a remote control scenario, in a typical scenario (Ta is 2, Tb is 10, Tc is 2, and T0 is 5), when a conventional one-to-one transmission method is used, 82 milliseconds are required to transmit a round of all remote control transactions (TAa 2); when the batch transmission scheme is used, only 37 milliseconds are needed, which is equivalent to 45% of the conventional transmission time; with the conventional one-to-one send method, 94 milliseconds are required to complete a round of all remote transactions (TAb 2); when the batch transmission scheme is used, only 49 milliseconds are needed, which is equivalent to 52% of the conventional completion time;
when the bulk transfer scheme of the present application is applied to the above application scenario 2: in the timing scenario, we should pay more attention to the time when the device receives all commands, and obviously, this value is equal to TA. In a typical scenario (Ta 2, Tb 10, Tc 2, T0 5), when using a conventional one-to-one transmission method, it takes 82 milliseconds to transmit a round of all remote transactions (TAa 2); with the bulk transmission scheme of the present application, only 37 milliseconds are required, corresponding to 45% of the normal transmission time. Further, since TAb ═ n-1 (Ta + T0) + Ta, n is known to the master, T0 is known, and a unique variable Ta remains, as mentioned above, Ta is only related to network delay in the lan, and Ta oscillates narrowly around a fixed value T0 ' in most cases, we can calculate in advance the value of TAb ═ n-1 (Ta + T0 ') + Ta, and perform time compensation by the master, and the time in the message ═ master time + TAb ', through the time compensation by the master, the error caused by delay to the slave timing is greatly reduced when the bulk transmission scheme of the present application is used. In the conventional one-to-one transmission method, TAa (n-1) × (Ts + T0) + Ta (n-1) × (Ta + Tb + Tc + T0) + Ta brings great difficulty and error to the compensation of the master station.
The method for transmitting and receiving the Modbus protocol in batches is realized, a conventional question-and-answer synchronous serial mode is converted into an asynchronous parallel mode for continuously transmitting and continuously receiving the Modbus protocol in batches, and the asynchronous mode refers to that after one request, the next request can be transmitted without waiting for response; concurrent means that the master station continues to send multiple requests for a continuous period of time during which no devices respond.
Under the multi-step remote control mode, the batch transmission scheme can greatly compress the sending time and the complete execution time of remote control;
under certain time-sensitive multi-step operation modes, such as timing operation, the batch transmission scheme can greatly reduce errors brought by delay to timing of the slave station through time compensation of the master station;
the batch transmission scheme is simple and easy to understand, does not need to depend on high-performance software and hardware, and is suitable for any software/hardware platform.
It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.

Claims (9)

1. A method for transmitting data in batches, comprising:
generating n Modbus request messages, and sending the n Modbus request messages in batches according to a preset sequence, wherein n is an integer greater than or equal to 1;
receiving m returned Modbus response messages within a preset timeout interval, and judging whether batch sending is successful or not according to the received Modbus response messages, wherein m is an integer between 0 and n;
when the n Modbus request messages are sent in batches according to the preset sequence, the method further comprises the following steps:
setting an exclusive identifier, wherein the exclusive identifier is used for forbidding the sending of other messages except the n Modbus request messages in the process of sending the n Modbus request messages in batches;
the time for sending the n Modbus request messages is TAb,
TAb=(n-1)*(Ta+T0)+Ta,
wherein: the mark is a multiplication number, and Ta is a time interval from the time when the master station sends a request message to the time when the slave station receives the request message; t0 is the master station transmission interval time;
calculating to obtain a value of TAb, and performing time compensation by the main station according to the value of TAb, wherein the time compensation formula is as follows: the time in the message is the master station time + TAb.
2. The method of claim 1,
the time to complete n batch sending and receiving is TBb,
TBb=(n-1)*(Ta+T0)+Ts,
Ts=Ta+Tb+Tc;
tb is the time consumption of the slave station for internal processing of the request message;
tc is the time interval from when the slave station sends a response message to the master station to when the master station receives the response message from the slave station.
3. The method of claim 2, wherein the TimeOut timer is not started when the first n-1 request messages are sequentially sent, and the TimeOut timer is started only after the nth request message is sent.
4. The method according to claim 1, wherein after the step of generating the n Modbus request messages and before the step of sending the n Modbus request messages in batches according to the preset sequence, the method further comprises:
configuring one or more of the n Modbus request messages as key request messages;
the step of judging whether the batch sending is successful or not according to the received Modbus response message comprises the following steps:
if the Modbus response messages corresponding to all the key request messages one to one are received within the preset timeout interval, judging that the batch sending is successful;
and if the Modbus response messages corresponding to all the key request messages one to one are not received within the preset timeout interval, judging that the batch sending fails.
5. The method according to any one of claims 1 to 4, wherein the Modbus request messages comprise Modbus TCP messages or Modbus RTU messages; the Modbus response message comprises a Modbus TCP message or a Modbus RTU message.
6. The method of claim 5, wherein:
when the Modbus request message and the Modbus response message are Modbus TCP messages, each time a request message is successfully sent, the request message is stored in a local first sending request list AQS, the AQS contains effective information of n request messages, and the Modbus request message and the Modbus response message further comprise an RF (radio frequency) mark and a KQ (KQ) mark of each request message, wherein the RF mark is used for indicating whether the response message corresponding to the request message is received, and the KQ mark is used for indicating whether the request message is a key request message.
7. The method of claim 5, wherein:
when the Modbus request message and the Modbus response message are Modbus RTU messages, storing the n generated request messages into a local second sending request list TM before sending, or sequentially storing the request messages into the TM after the batch sending is successful; the TM includes effective information of n request messages, and further includes an RF flag and a KQ flag of each request message, where the RF flag is used to indicate whether a response message corresponding to the request message is received, and the KQ flag is used to indicate whether the request message is a critical request message.
8. A device for transmitting data in batches, comprising a processor and a memory, wherein: the processor is configured to execute a program stored in the memory to implement the steps of the batch data transmission method according to any one of claims 1 to 7.
9. A batch data transmission device is characterized by comprising a batch sending module and a batch receiving module, wherein:
the system comprises a batch sending module, a batch sending module and a data processing module, wherein the batch sending module is used for generating n Modbus request messages and sending the n Modbus request messages in batches according to a preset sequence, and comprises an exclusive identifier, the exclusive identifier is used for forbidding sending of other messages except the n Modbus request messages in the process of sending the n Modbus request messages in batches, and n is an integer greater than or equal to 1;
the time for sending the n Modbus request messages is TAb,
TAb=(n-1)*(Ta+T0)+Ta,
wherein: the mark is a multiplication number, and Ta is a time interval from the time when the master station sends a request message to the time when the slave station receives the request message; t0 is the master station transmission interval time;
calculating to obtain a value of TAb, and performing time compensation by the main station according to the value of TAb, wherein the time compensation formula is as follows: time in the message is master station time + TAb;
and the batch receiving module is used for receiving the returned m Modbus response messages within a preset timeout interval and judging whether the batch sending is successful or not according to the received Modbus response messages, wherein m is an integer between 0 and n.
CN201910559877.7A 2019-06-26 2019-06-26 Batch data transmission method and device Active CN110311847B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910559877.7A CN110311847B (en) 2019-06-26 2019-06-26 Batch data transmission method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910559877.7A CN110311847B (en) 2019-06-26 2019-06-26 Batch data transmission method and device

Publications (2)

Publication Number Publication Date
CN110311847A CN110311847A (en) 2019-10-08
CN110311847B true CN110311847B (en) 2022-08-05

Family

ID=68077594

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910559877.7A Active CN110311847B (en) 2019-06-26 2019-06-26 Batch data transmission method and device

Country Status (1)

Country Link
CN (1) CN110311847B (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111294264B (en) * 2020-02-17 2021-12-24 北京和利时系统集成有限公司 Communication method and device based on Modbus TCP protocol
CN111245687B (en) * 2020-03-20 2021-11-16 北京和利时系统工程有限公司 Communication state updating method and device
CN111586182B (en) * 2020-05-11 2023-06-06 北京和利时系统集成有限公司 Data transmission method and device
CN113746647B (en) * 2020-05-27 2023-12-19 中国联合网络通信集团有限公司 Data transmission method, node, electronic device and readable storage medium
CN111813733B (en) * 2020-06-30 2022-05-13 厦门科灿信息技术有限公司 Synchronous communication method, system and terminal equipment based on Modbus protocol
CN114019834B (en) * 2021-11-03 2024-02-09 深圳市奥拓普科技有限公司 Yacht control method, yacht control system, storage medium and intelligent terminal

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104205709A (en) * 2012-02-28 2014-12-10 三星电子株式会社 Apparatus and method for transmitting feedback information in wireless communication systems
CN106533639A (en) * 2016-12-06 2017-03-22 迈锐数据(北京)有限公司 Data retransmission method and device
CN106561014A (en) * 2015-11-18 2017-04-12 天地融科技股份有限公司 Data transmission method and system, main communication equipment, and slave communication equipment
CN109327288A (en) * 2015-12-14 2019-02-12 华为技术有限公司 Data transmission acceleration method, apparatus and system
CN109379355A (en) * 2018-10-11 2019-02-22 无锡威孚力达催化净化器有限责任公司 Adaptive reliable multiwindow data transmission method based on udp protocol

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8195844B2 (en) * 2007-09-20 2012-06-05 Siemens Aktiengesellschaft Systems, devices, and/or methods for managing communications
CN102820959B (en) * 2011-06-10 2015-08-26 哈尔滨工业大学 In Modbus main website and the method for carrying out big data quantity between slave station and communicating
US20130294322A1 (en) * 2012-05-04 2013-11-07 Electronics And Telecommunications Research Institute Apparatus and method for sequentially transmitting data
EP2939495A4 (en) * 2012-12-26 2016-08-17 Ict Res Llc Mobility extensions to industrial-strength wireless sensor networks
CN103280814B (en) * 2013-03-26 2016-04-20 南京南瑞集团公司 A kind of wind power plant reactive voltage complex control system and method
CN108762193A (en) * 2018-07-31 2018-11-06 吉林大学 Numerically controlled machine remote data acquire and analysis system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104205709A (en) * 2012-02-28 2014-12-10 三星电子株式会社 Apparatus and method for transmitting feedback information in wireless communication systems
CN106561014A (en) * 2015-11-18 2017-04-12 天地融科技股份有限公司 Data transmission method and system, main communication equipment, and slave communication equipment
CN109327288A (en) * 2015-12-14 2019-02-12 华为技术有限公司 Data transmission acceleration method, apparatus and system
CN106533639A (en) * 2016-12-06 2017-03-22 迈锐数据(北京)有限公司 Data retransmission method and device
CN109379355A (en) * 2018-10-11 2019-02-22 无锡威孚力达催化净化器有限责任公司 Adaptive reliable multiwindow data transmission method based on udp protocol

Also Published As

Publication number Publication date
CN110311847A (en) 2019-10-08

Similar Documents

Publication Publication Date Title
CN110311847B (en) Batch data transmission method and device
US8284669B2 (en) Data acknowledgement apparatus and method
CN113411313B (en) Data transmission method, device and system
JP2925678B2 (en) Data communication method and data communication system
US5805594A (en) Activation sequence for a network router
CN110649984B (en) Clock synchronization method and device, computer storage medium and electronic equipment
US7969900B2 (en) Determination of network performance characteristics
US11509561B2 (en) Performance measurement using extended bidirectional forwarding control packet
CN112214441A (en) Communication switching method, equipment and system based on serial bus polling protocol
CN108886713B (en) Data transmission method, data receiving equipment and data sending equipment
CN112887014A (en) Congestion control method, device, terminal and medium for satellite link
US6452946B1 (en) Apparatus and method for improving performance in master and slave communications systems
US6570852B1 (en) Relay communication system
CN101989896B (en) Feedback method and device for ARQ connection
CN110492978B (en) LoRaWAN system capable of achieving rapid confirmation and implementation method thereof
US7024610B2 (en) Data transmission method
JP2003283472A (en) Data transfer control method
CN112714036B (en) Network quality measurement method, apparatus, device and medium for bundled link
US9473597B2 (en) Implementing multiple MAC protocols using a single wireless communication unit
EP1584167A2 (en) Optimization of transmissions on a shared communications channel
CN111083016B (en) Polling table processing method and device, storage medium and equipment
SG180095A1 (en) Method and device for transmitting information in contention on time slots between transceiver nodes of an ad hoc network
CN110289937B (en) Delayed responder not ready negative acknowledgement
CN107204824B (en) Data transmission method and system for low-speed channel
CN109995724B (en) Communication method, client and communication system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20211117

Address after: 100176 room 3412, floor 4, building 3, yard 2, Desheng Middle Road, Beijing Economic and Technological Development Zone, Daxing District, Beijing

Applicant after: Beijing Helishi system integration Co.,Ltd.

Address before: 100176 No.2, Disheng Middle Road, Yizhuang Economic and Technological Development Zone, Daxing District, Beijing

Applicant before: BEIJING HOLLYSYS Co.,Ltd.

GR01 Patent grant
GR01 Patent grant