TW202336602A - Method of transmitting data and command through rs232 serial port - Google Patents

Abstract

A method of transmitting data and command through an RS232 serial port incorporated with a user-end device and a server-end device connected through the RS232 serial port is disclosed and includes following steps: accumulating a value of a first counter of the user-end device and a value of a second counter of the server-end device whenever a data is sent from the server-end device to the user-end device; controlling the server-end device to stop transmitting the data and to wait when both of the two values reach a triggering threshold; controlling the user-end device to transmit a control command to the server-end device through the RS232 serial port while the server-end device is waiting; and, resetting the first and the second counter and controlling the server-end device to restore transmitting the data to the user-end device after a waiting time is elapsed.

Description

Data and command transmission method based on RS232 serial port

The present invention relates to a data and instruction transmission method, and in particular to a data and instruction transmission method based on an RS232 serial port.

In an industrial environment, client equipment (such as industrial computers) and server equipment (such as servo motors) are often connected using RS232 serial ports to transmit data and control instructions.

The standard data transmission procedure of the RS232 serial port must go through handshaking. Specifically, when the sender sends data to the receiver, the receiver must reply with a confirmation signal to the sender to complete the data transmission process. However, such a back-and-forth handshaking process is a waste of communication time, resulting in a decrease in the amount of data that can be transmitted per unit time. Therefore, the RS232 serial port is not suitable for performing real-time data transmission.

Refer to Figure 1, which is a schematic diagram of RS232 serial port transmission in related technology. As shown in Figure 1, when the client device 1 and the server device 2 are connected through the RS232 serial port 3 and execute the standard transmission procedure, if the client device 1 sends the control command 11 to the server device 2, the server device 2 must After receiving, a confirmation packet 12 is sent back to the client device 1 . Similarly, when the server device 2 sends data 21 to the client device 1, the client device 1 must also reply a confirmation packet 12 to the server device 2 after receiving it.

Generally speaking, the server device 2 can be used to connect to industrial equipment in a factory to collect and record real-time data of the industrial equipment. The server device 2 sends the recorded data back to the client device 1, so that the user can monitor the industrial equipment in real time through the client device 1. In the above-mentioned usage environment, the data 21 transmitted by the server device 2 may be very large (for example, each piece of data is 1~64KB). If it needs to go through the above-mentioned standard transmission procedure, it will definitely not be transmitted within a limited time (for example, 1000ms). As a result, users' needs for real-time monitoring will not be met.

In view of this, how to modify the transmission program of the RS232 serial port to increase the amount of transmitted data has become a subject of intensive research by those skilled in the field.

The present invention provides a data and instruction transmission method based on the RS232 serial port, which can enable the client device using the RS232 serial port to receive the maximum amount of data in the shortest time.

In one embodiment of the present invention, the transmission method is applied to a client device and a server device connected through an RS232 serial port, and includes the following steps:

a) When the server device transmits data to the client device, control the counts of a first counter of the client device and a second counter of the server device to synchronously accumulate;

b) Repeat step a) before the counts of the first counter and the second counter reach a trigger threshold;

c) When the counts of the first counter and the second counter reach the trigger threshold, the server device stops transmitting data to the client device within a waiting time, and the server device temporarily stores the data within the waiting time. the information to be transmitted;

d) The client device sends a control command to the server device within the waiting time; and

e) Clear the first counter and the second counter after the waiting time, and the server device resumes transmitting data to the client device.

In another embodiment of the present invention, the transmission method is applied to a client device connected to a server device through an RS232 serial port, and includes the following steps:

a) When receiving data sent by the server device, control a first counter to accumulate, wherein the first counter is synchronized with a second counter in the server device;

b) When sending a control command to the server device, store the control command in a command queue;

c) Repeat step a) and step b) before the count of the first counter reaches a trigger threshold;

d) When the count of the first counter reaches the trigger threshold, send the control command in the command queue to the server device; and

e) Clear the first counter after step d), and perform steps a) to step d) again.

In another embodiment of the present invention, the transmission method is applied to a server device connected to a client device through an RS232 serial port, and includes the following steps:

a) When sending data to the client device, control a second counter to accumulate, wherein the second counter is synchronized with a first counter in the client device;

b) Repeat step a) before the count of the second counter reaches a trigger threshold;

c) When the count of the second counter reaches the trigger threshold, stop sending data to the client device and maintain a waiting time, and temporarily store the data to be sent during the waiting time; and

d) Clear the second counter after the waiting time and resume sending data to the client device.

Compared with related technologies, the present invention can enable the client device to receive the maximum amount of data in the shortest time by using the RS232 serial port and without performing data handshaking. Moreover, when the client device sends a control command to the server device, it will not collide with the data transmitted by the server device.

A preferred embodiment of the present invention is described in detail below with reference to the drawings.

The present invention discloses a data and command transmission method (hereinafter referred to as the transmission method in the specification). The transmission method is mainly applied to two or more electronic devices that transmit data and control instructions through the RS232 serial port. device.

Refer to Figure 2, which is a schematic diagram of RS232 serial port transmission according to the first specific embodiment of the present invention. As shown in Figure 2, the transmission method of the present invention is applied to the client device 4 and the server device 5 connected through the RS232 serial port 6, so that the client device 4 and the server device 5 can transmit data and control instructions. There is no need to go through the handover process to obtain the maximum data transmission volume per unit time.

Specifically, the client device 4 can be, for example, a personal computer, an industrial computer, a cloud server, or other electronic device that can support the RS232 serial port 6, but is not limited thereto. After the client device 4 executes a specific application or software, it can communicate with the server device 5 through the RS232 serial port 6 and receive the data 50 sent by the server device 5 in real time.

The servo device 5 may be, for example, a server or a servo motor (Servo), especially an AC servo motor (AC Servo), but is not limited thereto. The server device 5 can connect to various industrial devices (not shown in the figure) in the environment, and based on the request of the client device 4 (especially the application or software executed on the client device 4), the industrial The device data 50 is immediately sent to the client device 4 . In this way, the main purpose of the user to monitor the industrial equipment in real time through the client device 4 can be achieved.

In the embodiment of FIG. 2 , the client device 4 (mainly refers to the application or software) has been modified so as not to reply with a corresponding confirmation packet after receiving the data 50 sent by the server device 5 . Correspondingly, the server device 5 has also been modified and can continue to send the next piece of data 50 to the client device 4 without receiving any confirmation packet. This can effectively shorten the transmission time of data 50 and increase the amount of data transmitted per unit time, thereby meeting the user's needs for real-time monitoring through RS232 serial port 6.

It is worth mentioning that since there is no need to wait for the confirmation packet, the server device 5 will continue to send data 50 to the client device 4, so that the client device 4 will not be able to predict when the server device 5 will stop sending the data 50 (i.e., When will RS232 serial port 6 be idle). Therefore, when the client device 4 wants to send the control command 40 to the server device 5 to control the server device 5, it can only send it directly to the server device 5 via the RS232 serial port 6 without any judgment procedure. In this case, the control command 40 sent by the client device 4 and the data 50 sent by the server device 5 may collide, causing the server device 5 to be unable to receive the control command 40 correctly.

When the client device 4 receives the next piece of data 50 sent by the server device 5 and finds through the content of the data 50 that the status of the server device 5 has not changed based on the content of the control command 40, it will be judged that the server device 5 has not received it correctly. Control instructions 40. In this case, the client device 4 can only send the same control command 40 to the server device 5 again.

For example, the client device 4 may send a control instruction 40 to control the server device 5 to stop computing. If the client device 4 continues to receive the calculated data 50 after sending the control command 40, it can be determined that the server device 5 has not indeed received the control command 40.

In view of the above problems, the present invention further proposes another implementation manner based on the embodiment of FIG. 2 .

Please refer to FIG. 3 , which is a schematic diagram of RS232 serial port transmission according to the second specific embodiment of the present invention. The main difference between the embodiment of FIG. 3 and the embodiment of FIG. 2 is that the client device 4 has a first counter 41 and the server device 5 has a second counter 51 , and the first counter 41 and the second counter 51 are synchronized.

Specifically, before starting to transmit the data 50 or the control command 40, the client device 4 and the server device 5 can respectively set the first counter 41 and the second counter 51 to 0 (for example, execute a reset procedure), so that The first counter 41 and the second counter 51 are synchronized. Moreover, after the first counter 41 and the second counter 51 are synchronized, the transmission of the data 50 is started through the RS232 serial port 6.

In the present invention, when the server device 5 sends data 50 to the client device 4, the first counter 41 and the second counter 51 accumulate simultaneously. When the counts of the first counter 41 and the second counter 51 meet the preset conditions (for example, the number of sent data 50 reaches the trigger threshold A1), the server device 5 will temporarily stop sending the data 50 to the client device 4.

In the transmission method of the present invention, the server device 5 will suspend sending the data 50 when the count of the second counter 51 meets the preset condition, and continues for a length of waiting time T1. At this time, the client device 4 knows that the server device 5 has entered the waiting time T1 because the count of the first counter 41 meets the preset condition, and will send the control command 40 to the server device 5 during the waiting time T1. Sent to server device 5.

When the waiting time T1 elapses, the client device 4 clears the first counter 41, and the server device 5 clears the second counter 51. Furthermore, the client device 4 stops sending the control instructions 40 , and the server device 5 resumes sending data 50 to the client device 4 . When the server device 5 resumes sending the data 50, the first counter 41 and the second counter 51 resume accumulation as the data 50 is sent.

The transmission method of the present invention can ensure that the client device 4 only sends the control command 40 to the server device 5 when the server device 5 stops sending data 50, thereby effectively avoiding the conflict between the control command 40 sent by the client device 4 and the server device 5. The data 50 sent by the device 5 collides, causing the server device 5 to be unable to receive the control command 40 correctly. Moreover, since the server device 5 only suspends sending the data 50 during the waiting time T1, it does not need to perform a standard handshake procedure with the client device 4. Therefore, it can still provide the maximum data transmission volume per unit time to meet users' needs for real-time monitoring.

Please continue to refer to FIG. 3 and FIG. 4 at the same time. FIG. 4 is a first specific embodiment of the transmission flow chart of the present invention, and each step in FIG. 4 is applicable to the transmission architecture shown in FIG. 3 . In the present invention, the client device 4 and the server device 5 can be connected through the RS232 serial port 6, and perform various specific steps shown in Figure 4 to achieve the main purpose of real-time transmission of data.

As shown in Figure 4, after the client device 4 starts to request data from the server device 5 (for example, the client device 4 executes the monitoring software or application), the server device 5 starts transmitting based on the request of the client device 4. The data 50 is sent to the client device 4 (step S10). Moreover, the first counter 41 in the client device 4 and the second counter 51 in the server device 5 will accumulate simultaneously (step S12).

In one embodiment, when transmitting a piece of data 50 to the client device 4, the server device 5 controls the second counter 51 to accumulate (for example, add one). Furthermore, when receiving a piece of data 50 sent by the server device 5, the client device 4 controls the first counter 41 to accumulate (for example, add one). Specifically, the values accumulated by the first counter 41 and the second counter 51 are the same, but the accumulation time points are not necessarily the same.

Then, the client device 4, the server device 5, or other electronic devices (not shown) connected to the client device 4 or the server device 5 determine whether the counts of the first counter 41 and the second counter 51 reach the predetermined value. Set the trigger threshold A1 (step S14).

In one embodiment, when transmitting a piece of data 50 to the client device 4, the server device 5 controls the second counter 51 to increase by one. Correspondingly, when receiving a piece of data 50 sent by the server device 5, the client device 4 controls the first counter 41 to increase by one. In this embodiment, the trigger threshold A1 is the amount of data that the server device 5 can send within a specified time, for example, ranging from five pieces of data to ten pieces of data, but is not limited to this.

In another embodiment, the second counter 51 can start accumulating time after the server device 5 starts sending the data 50 , and the first counter 41 can start accumulating the time after the client device 4 starts receiving the data 50 . The above step S14 is to determine whether the accumulated time reaches the preset trigger threshold A1. In this embodiment, the trigger threshold A1 may be, for example, a time length sufficient for the server device 5 to send a sufficient amount of data, such as 3000 ms, but is not limited thereto.

For ease of understanding, the following will describe an embodiment in which the server device 5 controls the first counter 41 and the second counter 51 to increase by one each time it sends a piece of data 50, but it is not limited to this.

If it is determined in step S14 that the counts of the first counter 41 and the second counter 51 have not reached the trigger threshold A1, then return to step S10 to continue sending data 50 to the client device 4 from the server device 5, and the first counter 41 Accumulation continues with the second counter 51 . It is worth mentioning that during the execution of steps S10 and S12, the client device 4 is not allowed to send any control instructions 40 to the server device 5.

Specifically, as shown in FIG. 3 , the client device 4 may have a command queue (Command Queue) 42 . When the counts of the first counter 41 and the second counter 51 have not reached the trigger threshold A1 and the server device 5 continues to send data 50 to the client device 4, the client device 4 will send the control to the server device 5. The command 40 is first stored in the command queue 42 .

If it is determined in step S14 that the counts of the first counter 41 and the second counter 51 reach the trigger threshold A1, the server device 5 will temporarily stop transmitting the data 50 to the client device 4 and continue for a waiting time T1 (step S16).

In the present invention, the counting of the first counter 41 and the counting of the second counter 51 are synchronized. When the server device 5 suspends sending the data 50 based on the counting content of the second counter 51, the client device 4 can based on the first counter 51. The count content of 41 is used to determine that the server device 5 will not transmit data 50 temporarily.

In the present invention, the server device 5 first temporarily stores the data 50 to be transmitted during the waiting time T1 (for example, temporarily stores it in the register 52 as shown in FIG. 3 ). At the same time, the client device 4 sends the control command 40 to be sent to the server device 5 to the server device 5 via the RS232 serial port 6 (step S18). In one embodiment, in step S18, the client device 4 mainly sends one or more control instructions 40 temporarily stored in the command queue 42 to the server device 5.

More specifically, the server device 5 temporarily stores the data 50 to be sent to the client device 4 during the waiting time T1, and the client device 4 sends the control command 40 to the server device 5 during the waiting time T1. By setting the waiting time T1, the control command 40 sent by the client device 4 and the data 50 sent by the server device 5 will not collide, thus ensuring that the server device 5 can correctly receive the control command 40.

Next, the client device 4, the server device 5 or other electronic devices determine whether the waiting time T1 has passed (step S20). Before the waiting time T1 elapses, the client device 4 and the server device 5 repeatedly execute steps S16 and S18 so that the server device 5 continues to temporarily store the data 50 and the client device 4 continues to send the control command 40 .

Generally speaking, the size of the control instruction 40 will be much smaller than the size of the data 50 . The size of a piece of data 50 can be, for example, 1~64KB, and the size of a piece of control instruction 40 can be, for example, 30~50byte. In the present invention, the length of the waiting time T1 only needs to be such that the client device 4 can transmit a complete control command 40 . In one embodiment, the waiting time T1 may be, for example, 100 ms, but is not limited thereto.

If it is determined in step S20 that the waiting time T1 has elapsed, the client device 4 and the server device 5 clear the first counter 41 and the second counter 51 respectively (step S22). Moreover, after the waiting time T1 elapses, the client device 4, the server device 5 or other electronic devices determine whether the current data transmission mode (that is, the transmission mode without handshaking procedure) ends (step S24). If the current data transmission mode has not ended, step S10 is returned to allow the server device 5 to resume transmitting data 50 to the client device 4 and to re-accumulate the first counter 41 and the second counter 51 .

In the first embodiment, the client device 4 and the server device 5 calculate the waiting time T1 respectively, and clear the first counter 41 and the second counter 51 respectively after the waiting time T1 elapses. In the second embodiment, the client device 4 clears the first counter 41 after sending the control command 40, and the server device 5 clears the second counter 51 after receiving the control command 40 sent by the client device 4.

As mentioned above, the server device 5 will temporarily store the data 50 to be sent during the waiting time T1. Therefore, after the waiting time T1 elapses, the data volume of the first data 50 sent by the server device 5 will be larger than that of other data. The amount of data sent at the time point is 50. In the third embodiment, after receiving the control command 40 from the client device 4 during the waiting time T1, the server device 5 determines that the communication with the client device 4 is normal, and therefore clears the second counter 51. Moreover, after the waiting time T1 elapses, after the client device 4 receives the data 50 with an obviously larger amount of data, it determines that the communication with the server device 5 is normal, and therefore clears the first counter 41 .

However, the above are only some specific implementation examples of the present invention, but are not limited thereto.

As mentioned above, after the waiting time T1 has elapsed and the current data transmission mode has not yet ended, the server device 5 resumes transmitting the data 50 to the client device 4 . Since the server device 5 will temporarily store the data 50 originally intended to be sent to the client device 4 in the register 52 during the waiting time T1, so after leaving the waiting time T1, the server device 5 will first send the register The data 50 in 52 is sent to the client device 4, and the first counter 41 and the second counter 51 are accumulated synchronously. After the data 50 in the register 52 is sent, the server device 5 further sends the real-time data 50 to the client device 4, and causes the first counter 41 and the second counter 51 to accumulate synchronously.

Please refer to Figure 3, Figure 4 and Figure 5 at the same time. Figure 5 is a second specific embodiment of the transmission flow chart of the present invention, and each step in Figure 5 is applicable to the transmission architecture shown in Figure 3. FIG. 5 further explains the flow chart of FIG. 4 from the perspective of the client device 4 .

As shown in Figure 5, after establishing a connection with the server device 5 through the RS232 serial port 6, the client device 4 can continue to receive the data 50 sent by the server device 5 through the RS232 serial port 6 (step S30). Furthermore, upon receiving the data 50, the client device 4 controls the first counter 41 therein to accumulate (step S32). Specifically, the counting of the first counter 41 is synchronized with the counting of the second counter 51 in the server device 5 .

In one embodiment, the client device 4 controls the first counter 41 to increase by one each time it receives a piece of data 50, but it is not limited to this.

Before the count of the first counter 41 reaches the preset trigger threshold (for example, the trigger threshold A1 shown in FIG. 3 ), the client device 4 continues to determine whether it is necessary to send the control command 40 to the server device 5 (step S34 ). . If the control command 40 needs to be sent to the server device 5, the client device 4 first stores one or more control commands 40 to be sent in the command queue 42 in the client device 4 (step S36). In other words, before the count of the first counter 41 reaches the trigger threshold A1, the client device 4 will not send any control instruction 40 to the server device 5.

Following the above, while connected to the server device 5 , the client device 4 continues to determine whether the count of the first counter 41 reaches the trigger threshold A1 (step S38 ). Furthermore, the client device 4 repeatedly executes steps S30 to S36 before the count of the first counter 41 reaches the trigger threshold A1, so as to continue to receive the data 50 sent by the server device 5, continue to accumulate the first counter 41, and continue to Temporarily store control instructions 40.

After the count of the first counter 41 reaches the trigger threshold A1, the client device 4 directly determines that the server device 5 will temporarily stop sending data 50, and the RS232 serial port 6 will temporarily enter an idle state. Therefore, the client device 4 can sequentially send one or more control commands 40 stored in the command queue 42 to the server device 5 through the RS232 serial port 6 (step S40). After step S40, the client device clears the first counter 41 (step S42).

In the first embodiment, the client device 4 clears the first counter 41 after all control commands 40 in the command queue 42 have been sent. In the second embodiment, the client device 4 clears the first counter 41 after the waiting time T1 has elapsed. In the third embodiment, the client device 4 directly clears the first counter 41 after the count of the first counter 41 reaches the trigger threshold A1. In the fourth embodiment, the client device 4 clears the first counter 41 when it receives the data 50 sent by the server device 5 again and determines that the amount of data 50 is greater than the amount of data 50 received at other points in time. .

However, the above are some specific implementation examples of the present invention, but are not limited to the above.

After step S42, the client device 4 can determine whether the transmission method of the present invention ends (step S44), and repeat the above steps S30 to step S42 before the transmission method ends.

In one embodiment, the client device 4 starts the transmission method of the present invention when it accepts external control (for example, triggered by the user) to enter a specific mode (for example, oscilloscope mode), and ends when it leaves the specific mode. The transmission method of the present invention (described in detail later). In this embodiment, only in the specific mode, the client device 4 will operate based on each step in the flowchart of FIG. 5 (ie, step S30 to step S44).

Please refer to Figure 3, Figure 4 and Figure 6 at the same time. Figure 6 is a third specific embodiment of the transmission flow chart of the present invention, and each step in Figure 6 is applicable to the transmission architecture shown in Figure 3. Figure 6 is a further explanation of the flow chart of Figure 4 from the perspective of the server device 5.

As shown in Figure 6, after establishing a connection with the client device 4 through the RS232 serial port 6, the server device 5 can continue to send data 50 to the client device 4 through the RS232 serial port 6 (step S50). Specifically, the user can operate the client device 4 to issue commands to the server device 5 so that the server device 5 externally retrieves the data 50 required by the user and transmits it back to the client device 4 immediately. In this way, the purpose of allowing the user to perform real-time monitoring through the client device 4 can be achieved.

When sending the data 50, the server device 5 controls the second counter 51 in the server device 5 to accumulate (step S52). Specifically, the counting of the second counter 51 is synchronized with the counting of the first counter 41 in the client device 4 .

In one embodiment, the server device 5 controls the second counter 51 to increment by one every time it sends a piece of data 50, but it is not limited to this.

The server device 5 continues to determine whether the count of the second counter 51 reaches the trigger threshold A1 (step S54). Before the count of the second counter 51 reaches the trigger threshold A1, the server device 5 repeatedly executes steps S50 and S52 to continue to collect and send data 50 to the client device 4, and controls the second counter 51 to continue to accumulate.

After the count of the second counter 51 reaches the trigger threshold A1, the server device 5 stops sending the data 50 to the client device 4 and maintains a preset waiting time (such as the waiting time T1 shown in FIG. 3) (step S56 ). During the waiting time T1, the server device 5 does not directly send the data 50 to the client device 4, but first temporarily stores the data 50 in the internal register 52. Moreover, during the waiting time T1, the server device 5 may receive one or more control instructions 40 sent from the client device 4.

During the waiting period, the server device 5 continues to determine whether the waiting time T1 has passed (step S58).

Before the waiting time T1 elapses, the server device 5 repeatedly executes step S58 to continue waiting, temporarily store the data 50 originally intended to be sent to the client device 4, and receive the control command 40 sent by the client device 4. After the waiting time T1 elapses, the server device 5 clears the second counter 51 (step S60).

In the first embodiment, the server device 5 clears the second counter 51 after the waiting time T1 elapses. In the second embodiment, the server device 5 directly clears the second counter 51 after the count of the second counter 51 reaches the trigger threshold A1. However, the above are only some specific implementation examples of the present invention, but are not limited thereto.

After step S60, the server device 5 can determine whether the transmission method of the present invention is completed (step S62), and before the transmission method is completed, repeatedly execute the above steps S50 to step S60 to resume sending the data 50 to the client device 4. , and controls the second counter 51 to continue to accumulate.

It is worth mentioning that when the server device 5 resumes sending the data 50 to the client device 4, the server device 5 will first send the data 50 temporarily stored in the register 52 in step S56 to the client device 4. After the second counter 51 is accumulated, step S50 is executed to send the next real-time data 50 to the client device 4 .

As mentioned above, the client device 4 and the server device 5 may enable the transmission method of the present invention to transmit the data 50 and the control command 40 only after entering a specific mode. In other words, when the client device 4 and the server device 5 enter other modes, other transmission methods will be used to transmit other data.

Referring to FIG. 3 and FIG. 7 , FIG. 7 is a fourth specific embodiment of the transmission flow chart of the present invention, and each step in FIG. 7 is applicable to the transmission architecture shown in FIG. 3 . As shown in Figure 7, first, the client device 4 and the server device 5 are connected through the RS232 serial port 6 (step S70). Furthermore, the client device 4 and the server device 5 execute a standard transmission procedure through the RS232 serial port 6 (step S72).

In one embodiment, the standard transmission procedure refers to a transmission method that requires a handshake procedure. Specifically, the standard transmission procedure includes: (1) the server device 5 transmits the data 50 to the client device 4, and (2) the client device 4 sends a confirmation packet of the data 50 to the server after receiving the data 50. Terminal device 5.

During the execution of the standard transmission procedure, the client device 4, the server device 5 or other electronic devices continue to determine whether the client device 4 is controlled by the user, and enter the oscilloscope mode (step S74). In one embodiment, the oscilloscope mode refers to real-time data monitoring in which the server device 5 continuously sends real-time data 50 to the client device 4, and the client device 4 draws a waveform based on the received data 50 and displays it in real time. model.

The oscilloscope mode is a common technology in this field and will not be described in detail here.

One of the technical features of the present invention is that before the client device 4 enters the oscilloscope mode, the client device 4 and the server device 5 repeatedly execute step S72 to continue to transmit data and control instructions through standard transmission procedures. . When the client device 4 enters the oscilloscope mode, the client device 4 and the server device 5 end the standard transmission procedure and enable the transmission method of the present invention (that is, perform the steps shown in Figure 4, Figure 5 and Figure 6) .

In the present invention, the client device 4 can dynamically establish the first counter 41 in it after entering the oscilloscope mode (step S76), and the server device 5 can dynamically establish the second counter 51 in it after entering the oscilloscope mode. (Step S78). Thereby, during the execution of the oscilloscope mode, the client device 4 and the server device 5 can perform synchronous counting through the first counter 41 and the second counter 51, thereby executing the transmission method of the present invention (step S80).

The client device 4, the server device 5 or other electronic devices continue to determine whether the client device 4 accepts the user's operation and leaves the oscilloscope mode (step S82). Before leaving the oscilloscope mode, the client device 4 and the server device 5 repeatedly execute step S80 to continue executing the transmission method of the present invention.

If it is determined in step S82 that the client device 4 has left the oscilloscope mode, since the standard transmission procedure does not require counting, the client device 4 and the server device 5 can selectively cancel the first counter 41 and the second counter 51 ( Step S84).

Next, the client device 4, the server device 5 or other electronic devices determine whether the data transmission process between the client device 4 and the server device 5 is interrupted (step S86). In one embodiment, the data transmission process between the client device 4 and the server device 5 is interrupted when the RS232 serial port 6 is removed, but it is not limited to this.

Before the data transmission procedure between the client device 4 and the server device 5 is interrupted, the client device 4 and the server device 5 end the transmission method of the present invention and return to step S72 to re-execute the standard transmission procedure. In this way, the limited resources of the client device 4 and the server device 5 can be saved.

Through the transmission method of the present invention, even if the RS232 serial port is used for connection, the client device can still receive the maximum amount of data in the shortest time, and the control instructions sent by the client device will not conflict with those sent by the server device. data collided.

The above descriptions are only preferred specific examples of the present invention, which do not limit the patent scope of the present invention. Therefore, all equivalent changes made by applying the content of the present invention are equally included in the scope of the present invention, and are hereby stated. bright.

1: Client device

11:Control instructions

12:Confirm packet

2:Servo-side equipment

21:Information

22:Confirm packet

3:RS232 serial port

4: Client device

40:Control instructions

41: first counter

42: Command queue

5:Servo-side equipment

50:Information

51: Second counter

52: Temporary register

6:RS232 serial port

A1: Trigger threshold

T1: waiting time

S10~S24, S30~S44, S50~S62, S70~S86: Transmission steps

Figure 1 is a schematic diagram of RS232 serial port transmission in related technology.

Figure 2 is a schematic diagram of RS232 serial port transmission according to the first specific embodiment of the present invention.

Figure 3 is a schematic diagram of RS232 serial port transmission according to the second specific embodiment of the present invention.

Figure 4 is a first specific embodiment of the transmission flow chart of the present invention.

Figure 5 is a second specific embodiment of the transmission flow chart of the present invention.

Figure 6 is a third specific embodiment of the transmission flow chart of the present invention.

Figure 7 is a fourth specific embodiment of the transmission flow chart of the present invention.

S10~S24: Transmission steps

Claims (11)

A data and command transmission method based on an RS232 serial port, applied to a client device and a server device connected through an RS232 serial port. The transmission method includes: a) When the server device transmits data to the client device, control the counts of a first counter of the client device and a second counter of the server device to synchronously accumulate; b) Repeat step a) before the counts of the first counter and the second counter reach a trigger threshold; c) When the counts of the first counter and the second counter reach the trigger threshold, the server device stops transmitting data to the client device within a waiting time, and the server device temporarily stores the data within the waiting time. the information to be transmitted; d) The client device sends a control command to the server device within the waiting time; and e) Clear the first counter and the second counter after the waiting time, and the server device resumes transmitting data to the client device. The transmission method as described in claim 1, wherein step a) is to control the second counter to be incremented by one when the server device sends a piece of data to the client device, and to control when the client device receives the data. The first counter is incremented by one. The transmission method as described in claim 1, wherein step e) is for the server device to first transmit the data temporarily stored in step c) to the client device and control the synchronization of the first counter and the second counter. After accumulation, perform step a) to step e) again. The transmission method as described in claim 1, wherein step a) before step further includes: a01) The server device and the client device perform a standard transmission procedure through the RS232 serial port, wherein the standard transmission procedure includes transmitting a data from the server device to the client device, and transmitting the data from the client device A confirmation packet of data is sent to the server device; a02) When the client device enters an oscilloscope mode, control the server device and the client device to end the standard transmission procedure through the RS232 serial port and execute step a) to step e). The transmission method as described in claim 4, including a step a03): when the client device enters the oscilloscope mode, establish the first counter in the client device, and establish the third counter in the server device. Two counters. The transmission method as described in claim 4, including a step f): when the client device leaves the oscilloscope mode, cancel the first counter and the second counter, and control the server device and the client device Restore this standard transfer procedure. The transmission method as described in claim 1, wherein the client device has an instruction queue, and the transmission method includes: a1) Before the counts of the first counter and the second counter reach the trigger threshold, the client device stores the control command to be sent to the server device in the command queue; The step d) is to send the control command in the command queue to the server device. A method for transmitting data and instructions based on an RS232 serial port, applied to a client device connected to a server device through an RS232 serial port. The transmission method includes: a) When receiving data sent by the server device, control a first counter to accumulate, wherein the first counter is synchronized with a second counter in the server device; b) When sending a control command to the server device, store the control command in a command queue; c) Repeat step a) and step b) before the count of the first counter reaches a trigger threshold; d) When the count of the first counter reaches the trigger threshold, send the control command in the command queue to the server device; and e) Clear the first counter after step d), and perform steps a) to step d) again. The transmission method as described in request item 8, which further includes: f) Establish the first counter when entering an oscilloscope mode, and perform step a) to step e); and g) Cancel the first counter when leaving the oscilloscope mode, wherein the client device performs a standard transmission procedure with the client device through the RS232 serial port after leaving the oscilloscope mode. The standard transmission procedure includes by the server device Send a piece of data to the client device, and send an acknowledgment packet of the data to the server device from the client device. A method for transmitting data and instructions based on an RS232 serial port, which is applied to a server device connected to a client device through an RS232 serial port. The transmission method includes: a) When sending data to the client device, control a second counter to accumulate, wherein the second counter is synchronized with a first counter in the client device; b) Repeat step a) before the count of the second counter reaches a trigger threshold; c) When the count of the second counter reaches the trigger threshold, stop sending data to the client device and maintain a waiting time, and temporarily store the data to be sent during the waiting time; and d) Clear the second counter after the waiting time and resume sending data to the client device. The transmission method as described in claim 10, wherein step d) is to first send the data temporarily stored in step c) to the client device and control the accumulation of the second counter, and then perform step a) again to the client device. Step c).

Images