JP2006197417A - Communication control method and system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a communication control method capable of quickly transmitting data requesting real time and surely transmitting data that does not require real time. <P>SOLUTION: Burst transfer for continuously transferring a plurality of pieces of data after an address and a command is added to normal burst transfer for transferring the plurality of pieces of data in one transmission frame to set non-real time burst transfer for allowing a plurality of pieces of data to be divided and transmitted. A master unit acquires bus access right permission notice, determines the existence/nonexistence of a transmission interruption condition during the execution of the non-real time burst transfer, and temporarily interrupts the non-real time burst transfer that is currently transmitted. When the interruption condition does not exist any more and bus access right permission notice is received, the master unit which has interrupted the non-real time burst transfer restarts non-real time burst transfer about an untransmitted portion among the plurality of pieces of data that have been temporarily interrupted. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a communication control method and system, and more specifically, when a plurality of master units are connected to a control device, and the master unit transfers data with other units via a bus in the control device. Related to control.

  PLC (programmable controller) used in FA (factory automation) inputs ON / OFF information of input devices such as switches and sensors, and performs logical operations according to a sequence program (user program) written in a ladder language. Execute. Then, the PLC performs control by outputting a signal of ON / OFF information to an output device such as a relay, a valve, or an actuator according to the obtained calculation result.

  This PLC is a CPU unit that executes user programs, an I / O unit that handles ON / OFF signals when input devices and output devices are connected, a communication unit that communicates with other devices via a network, and supplies power to each unit It consists of connecting each unit, such as a power supply unit. Each unit is connected by an internal bus, and data is exchanged with each unit by bus communication centering on the CPU unit.

  Further, in the PLC, as one means for shortening the cycle time of the CPU unit, in addition to the CPU unit, a plurality of bus master units and a plurality of slave units are connected to a single bus, and between the bus master unit and the slave unit. Some use a multi-bus master system to exchange data. In this multi-bus master system, only one bus master unit that has acquired the bus access right among a plurality of bus master units can communicate with a predetermined slave unit via the bus.

  Communication performed with the slave includes burst transfer and single transfer. Here, the single transfer is a method of transferring one word by one access using an address bus, a control signal, and a data bus represented by, for example, access from MPU to memory. On the other hand, burst transfer is a method in which a plurality of data are transferred successively following an address or command represented by PCI interface burst transfer.

FIG. 1 shows an example of a transfer operation in a conventional multi-bus master system when the number of bus masters is three. In this example, each bus master # 0, # 1, # 2 is sequentially given a bus access right at a constant interval T, and the bus master executes a single transfer or a burst transfer as each bus access right is acquired. . Although not related to the PLC, a bus management system in which a plurality of bus masters are connected to one bus and each bus master secures a bus access right for communication is disclosed in Patent Document 1 and the like. .
JP-A-11-45225

  However, the conventional multibus system described above has the following problems. There are many large-volume data (messages) such as production management information, programs, and operation information among data sent by burst transfer. Since it takes a relatively long time to complete transmission of this type of large-capacity data, it may take more than the predetermined interval T assigned to each bus master. In addition, once the bus master acquires the bus access right and starts data transfer, the bus master can continue to secure the bus access right and continue transmission until the data transfer is completed.

  As a result, as shown in FIG. 2, for example, when the master # 1 transmits a large amount of data D1 acyclically, the transmission may not be completed at the time T initially allocated to itself. In such a case, since the master of # 2 continues communication as it is, the master of # 2 already communicates on the network even if it acquires the bus access right and performs data transfer next time. Data cannot be transferred. For this reason, the master of # 2 has a period in which communication cannot be performed only for the time t1 with respect to the fixed time T in which the bus access right is originally acquired and the data can be transferred, resulting in a loss of real-time property.

  In particular, large-capacity data to be transmitted acyclically is different from single transfer, and in many cases, it is not necessary to transmit all at once as a batch, and in order to transmit large capacity without such urgent (low) real-time performance It is not preferable to affect the transmission of control data (such as IO data) that is required.

  An object of the present invention is to provide a communication control method and system capable of quickly transmitting data that requires real-time property and reliably transmitting data that does not require real-time property.

  In order to achieve the above-described object, the communication control method according to the present invention is based on the condition that a plurality of master units constituting a control device receive a bus access right permission notification from an arbiter mounted on the control device. A communication method in which data is communicated with other units via a bus in the device, and burst transfer in which a plurality of data is continuously transferred following an address or command is transmitted in a single transmission frame. In addition to the normal burst transfer, non-real-time burst transfer that allows a plurality of data to be divided and transmitted is set. Then, the master unit obtains the bus access right permission notification, determines whether or not there is a transmission interruption condition during execution of the non-real-time burst transfer, and if the transmission interruption condition occurs, When the non-real-time burst transfer is suspended, the master unit that interrupted the non-real-time burst transfer when the interruption condition disappears and the bus access right permission notification is received, Non-real-time burst transfer was resumed for the untransmitted part.

  There are various interruption conditions, for example, the permission of bus access given from the arbiter is canceled, or the master unit performing the non-real-time burst transfer has received the non-real-time burst transfer. For example, data transfer with a higher priority than that may be performed.

  The high-priority data transfer can be, for example, at least one of the normal burst transfer and single transfer in which one word is transferred in one access. Of course, other types of transfer methods may be used.

  In the present invention, burst transfer that continuously transfers a plurality of data following an address or command is added to normal burst transfer that transmits the plurality of data in one transmission frame, and the plurality of data is divided and transmitted. Set non-real-time burst transfer to allow. Therefore, for example, large-volume data (messages) such as production management information, programs, operation information, and the like that need to be transmitted reliably but have no urgency are transferred using non-real-time burst transfer. As a result, if it becomes necessary to transmit IO data or other data having real-time characteristics, the non-real-time burst transfer is temporarily interrupted, and urgent data to be transmitted in real time can be quickly transmitted without delay. can do. The temporarily interrupted data to be transferred in non-real-time burst transfer is resumed when the interruption condition is resolved and the transmission is permitted upon receiving the bus access right permission notification. Therefore, since data transmitted by non-real-time burst transfer can be transmitted in a plurality of times, data can be transmitted reliably without affecting the data transfer of data that requires real-time performance. . Of course, the non-real-time burst transfer is only allowed to be divided and transmitted, and it does not prevent transmission in one transmission frame when no interruption condition or the like occurs during data transfer.

  Therefore, when a multi-bus master system (typically represented by a multi-CPU) is configured for backplane bus data transfer that generally requires real-time performance and low latency, each master is configured by an arbiter (also referred to as a bus management controller). Bus arbitration is performed to give a certain bus bandwidth to According to the present invention, in such a multi-bus master system, data transfer requiring real-time property and low latency and non-real-time data transfer can coexist.

Furthermore, according to the present invention, when a non-real-time burst transfer is temporarily interrupted, a unit that is a communication partner of the temporarily interrupted non-real-time burst transfer can be controlled not to receive another non-real-time burst transfer.
In addition, the communication partner of the non-real-time burst transfer has a reception status indicating whether or not the non-real-time burst transfer is temporarily suspended,
Prior to performing the non-real-time burst transfer, the master unit attempting to perform the non-real-time burst transfer confirms the reception status with respect to the transmission destination unit and performs the non-real-time burst transfer on condition that it is not temporarily suspended. It can also be done.

  Prior to performing the non-real-time burst transfer, the master unit that performs non-real-time burst transfer issues a non-real-time burst transfer transmission request to the transmission destination unit, and the unit that has received the transmission request When the non-real-time burst transfer from another master unit is not suspended, the master unit performs non-real-time burst transfer on the condition that the permission notification is issued, the permission notification is received and the access right is acquired. You can also do it.

  As another solution, the master unit monitors the bus, stores information on whether or not non-real-time burst transfer is performed for each node, and based on the stored information, The non-real-time burst transfer may be executed when it is determined that the transmission partner performing the non-real-time burst transfer can transfer.

  The master unit monitors the bus and stores information on whether or not there is a node performing non-real time burst transfer. Based on the stored information, there is no node performing non-real time burst transfer. If it is determined, the non-real-time burst transfer can be executed.

  In the present invention, since the non-real time burst transfer may be interrupted, the receiving unit may receive and process a plurality of non-real time messages at the same time without any control. Therefore, by adopting the four methods described above, one receiving unit can be prevented from receiving non-real-time burst transfer from different master units.

  In the system according to the present invention, the master unit receives a bus access right permission notification from the arbiter in a control device including a plurality of master units and an arbiter that controls bus access of the plurality of master units. A system that performs data communication with other units via a bus in the control device on the condition that burst transfer that continuously transfers a plurality of data following an address or a command, In addition to the normal burst transfer that is transmitted in one transmission frame, non-real-time burst transfer that allows a plurality of data to be divided and transmitted is set, and the master unit acquires the bus access right permission notification, and Means for determining whether or not there is a transmission interruption condition during non-real-time burst transfer, and the transmission interruption condition Means for issuing a pause command for temporarily interrupting the non-real-time burst transfer currently being transmitted, and the non-real-time when the interruption condition is eliminated and the bus access right permission notification is received. Means for performing non-real-time burst transfer for transmitting data that could not be transmitted due to temporary interruption of burst transfer was provided.

  In the present invention, since non-real time burst transfer that allows transmission in multiple times is provided for burst transfer in which a plurality of data is transmitted following an address or command, data that requires real time transmission is quickly transmitted. However, data that does not require real-time performance can be reliably transmitted using non-real-time burst transfer.

  FIG. 3 shows an example of a control device (PLC) 10 in which a system for executing communication control according to a preferred embodiment of the present invention is mounted. In the control device 10 of the present embodiment, a plurality of units are mounted on the backplane 11. In relation to the present invention, the plurality of units include a plurality of master units 12 that actively perform bus access, a slave unit 13 that performs data transfer with the master unit 12, and power supply to these units. And a power supply unit 14. Of course, although not shown in the figure, other units are also mounted as necessary. The backplane 11 is mounted with an arbiter 15 that performs arbitration such as granting a bus access right.

  Each master unit 12 and slave unit 13 is connected to a bus (address, data bus) 16 mounted in the backplane 11, and data is transferred between the units 12 and 13 via the bus 16. This data transfer is performed by the master unit 12 that has acquired the bus access right. Each master unit 12 is connected to the arbiter 15 by a plurality (three in this example) of control lines 17 and acquires a bus access right through the control lines 17.

  Here, two of the three control lines 17 are for outputting two pieces of information from the master unit 12 toward the arbiter 15. The two pieces of information are a “bus access right request signal” (BREQ) and a “bus accessing flag” (BSY). The remaining one control line 17 notifies the master unit 12 from the arbiter 15 of “bus access permission” (BG). As for the data of the three control lines 17, the steady state becomes High (1). That is, when BREQ is Low “0”, it means that the master unit 12 is requesting the bus access right. When BSY is Low “0”, it means that the master unit 12 is using the backplane bus due to data transfer or the like. When BG is Low “0”, it means that bus access from the arbiter 15 is permitted.

  As shown in FIG. 4, the master unit 12 that intends to perform data transfer outputs a bus access right request signal to the arbiter 15 (BREQ is updated from “1” to “0”). When the arbiter 15 receives the bus access right request signal (BREQ is “0”), the arbiter 15 determines whether or not the bus access right may be given, and determines that the bus access right is given. A bus access right permission notification is issued via 17 (BG is updated from “1” to “0”). The master unit 12 that has received the bus access right permission notice actually starts data transfer. When the master unit 12 that has acquired the bus access right (BG = 0) transfers data, the in-access flag is turned ON, and the ON information of the in-access flag is sent to the arbiter 15 via the control line 17. (BGY is “0”). Further, in the case of normal single transfer or burst transfer, the master unit 12 once acquires the bus access right (BG = 0) and starts data transfer (BGY = 0). Thereafter, the bus access right disappears ( Even if BG = 1), the data being transferred is continuously transmitted. Then, the master unit 12 keeps the in-access flag ON (BGY = 0) during the data transmission, and turns the access flag OFF (BGY = 1) after the transmission is completed.

  While the flag ON information (BGY is “0”) is received from any master unit 12, the arbiter 15 does not grant the bus access right even if the bus request signal is received. As a result, the bus access right is granted when none of the master units 12 uses the bus 16 (data transfer is not performed). Therefore, the bus access right is acquired by one master unit on the bus 16. 12

  The bus access right permission / annihilation process in the arbiter 15 is executed according to the flowchart shown in FIG. That is, it first waits for a bus access right request signal (BREQ is "0") from each master unit (S1). When the bus access right request signal is received, it is determined whether or not the bus access right may be given to the requested master (S2). Specifically, when the bus access right permission notification is not given to all the master units 12 (BG = 1) and all the master units 12 are not communicating (BGY = 1), It is determined that the bus access right permission condition is satisfied. Note that, in a normal implementation situation, each master unit 12 cyclically attempts to transfer data to a predetermined unit, and therefore may receive bus access right request signals from a plurality of master units at the same time. In such a case, a master unit that permits the bus access right is determined in accordance with a predetermined condition (for example, node address order).

  Next, when a master unit permitting the bus access right is determined, a bus access right permission notification, that is, BG is set to “0” for the master unit 12 (S3). The master unit 12 recognizes that the bus access right permission notification has been issued to itself via the BG control line 17 connected to the master unit 12.

  The arbiter 15 waits for the predetermined occupation time to be exceeded if BG = 0 is set for a predetermined master unit (S4), and if it exceeds, cancels the bus access right permission notification, that is, sets BG to Disappear (BG = 1) (S5). Note that the occupation time may be a fixed time after the BG is updated to 0 by executing the processing step S3, but in the present embodiment, the occupation time returns to BG = 1 with the previous execution of the processing step S5. The period of time occupied by this time is a period until a certain time elapses. Accordingly, if the previous master unit continues to transfer data even when BG = 0, the actual time (BG = The time when it is 0) is shorter than usual. Even in that case, as will be described later, for data that requires real-time performance, even if BG = 0, the data transfer is continued as it is, so that there is no problem. Each master unit 12 knows the approximate time required to communicate cyclically generated data that requires real-time properties, and requires a relatively short time. Therefore, the occupation time is set to a time sufficient for communicating data that requires normal real-time characteristics, and the probability that a situation in which communication is continued even when BG = 0 occurs will occur. Can be reduced.

  Here, in the present invention, non-real time burst transfer is provided in addition to the conventional single transfer and burst transfer as a classification of data transfer performed by the master unit 12. That is, the single transfer is a method in which one word is transferred by one access using an address bus, a control signal, and a data bus represented by access to the memory from the MPU 12a mounted on the master unit 12 or the like, for example. Burst transfer is a method of transferring a plurality of data continuously following an address or command typified by PCI interface burst transfer, and is a part of conventional burst transfer. The new non-real-time burst transfer, which is newly separated from burst transfer this time, is used when transferring relatively large volumes of data that do not require real-time performance, and the basic transfer method is burst transfer. This is a transfer that can temporarily interrupt the transmission of the transfer data.

  As a condition for interruption, not only when the bus access right permission notice disappears (BG = 1), but also when the bus access right permission notice given to the own station is ON (BG = 0), There are cases where transmission of normal single transfer or real burst transfer having real-time characteristics is required.

  Next, functions of the master unit 12 and the slave unit 13 for performing the data transfer process described above will be described. In the following description, the master unit 12 is a transmission side unit and the slave unit 13 is a reception side unit. However, there is of course a case where data is transferred between the master units 12. In such a case, one master unit is the receiving unit.

  FIG. 6 shows a part of the internal configuration of the master unit 12. In other words, the MPU 12a that controls the entire unit, the memory 12b that is used as a work memory while the MPU 12a is performing computations, temporarily stores data to be transmitted and received, and the backplane bus are connected to other units. A bus interface controller 12c for performing data transfer and a service execution unit 12d for executing various transfer services. Each processing unit is connected via an internal bus. The service execution unit 12d may be realized as a program in the MPU 12a. Of course, although not shown, the master unit 12 also has a ROM and other various processing units for storing system programs.

  FIG. 7 shows a part of the internal configuration of the slave unit 13. That is, the MPU 13a that controls the entire unit, the memory 13b that is used as a work memory while the MPU 13a is performing operations, temporarily stores data to be transmitted and received, and the backplane bus are connected to other units. And a bus interface controller 12c for performing data transfer. Each processing unit is connected via an internal bus. Of course, although not shown, the slave unit 13 also has a ROM and other various processing units for storing system programs.

  8 to 11 show functions of the bus interface controller 12 c of the master unit 12. When there is a need for data transfer to another unit, the MPU 12a of the master unit 12 makes a data transfer request to the service execution unit 12d and activates the corresponding service. When receiving a data transfer instruction from the MPU 12a, the service execution unit 12d makes a transfer request to the bus interface controller 12c together with the type of data transfer.

  Therefore, when the bus interface controller 12c receives a transfer request from a predetermined service of the service execution unit 12d, the bus interface controller 12c executes the flowcharts shown in FIG. 8 to FIG. 10 to determine which type of transfer request. . In the present embodiment, as described above, three types of data transfer, “single transfer”, “burst transfer (real-time burst transfer)”, and “non-real-time burst transfer”, are prepared. The urgency in the case of data transfer is also set as “single transfer”> “burst transfer (real-time burst transfer)”> “non-real-time burst transfer”.

  Accordingly, the bus interface controller 12c judges the requests received from the service execution unit 12d in descending order of priority. Specifically, it is first determined whether or not the received request is a single transfer request (S11: FIG. 8). If it is not a single transfer request, it is determined whether or not it is a burst transfer (S21: FIG. 9). If it is not a transfer request, it is determined whether it is non-real-time burst transfer (S31: FIG. 10). And when it corresponds (Yes) in any processing step of each branch judgment (S11, S21, S31), a corresponding data transfer process is performed.

  If the branch determinations in the processing steps S11, S21, S31 are all No, the processing returns to the processing step S11. Therefore, in the above description, when the predetermined data transfer request is received from the service execution unit 12d, the flowcharts of FIGS. 8 to 10 are executed, but as is clear from the drawing, the data transfer request is If not received, this flowchart may be executed at all times because the loop is repeatedly executed as S11 → S21 → S31 → S11.

  If a single transfer request is received, the branch determination in S11 is Yes, so the flowchart shown in FIG. 8 is executed. That is, first, a bus access right acquisition process is performed (S12). In this bus access right acquisition process, as shown in FIG. 11A, the bus interface controller 12c sets BREQ to 0 and transmits it to the arbiter 15 via the control line 17 (S41). . Then, the bus interface controller 12c waits for the bus access right permission notification (BG = 0) to be issued from the arbiter 15 (S42), and if the bus access right permission notification is received, the bus access flag is turned ON. That is, BSY = 0 is set (S43). As a result, the arbiter 15 cannot issue a bus access right permission notice to other units unless BSY is returned to 1, and therefore the master unit 12 of the arbiter 15 exclusively secures the right to transfer data. The above processing steps S41 to S43 are a specific processing flow of the bus access right acquisition processing (S12).

  If the bus access permission notification is received by the above procedure and the bus access right is acquired, the bus interface controller 12c transmits the transfer permission (Grant) to the single transfer service of the service execution unit (Service) 12d (S13). . As will be described later, when the service execution unit 12d receives the transfer permission, “Busy” is unanswered as a response, and thus waits to receive the response (S14). Next, when the service execution unit 12d completes the single transfer, in order to notify the request completion and non-busy, the bus interface controller 12c waits to receive the notification (S15). If such notification is received, a bus access right release process is executed (S16).

  In this bus access right release process, as shown in FIG. 11B, the bus interface controller 12c sets BREQ to 1 to cancel the request for acquiring the bus access right and sets BGY to 1 to turn off the bus access flag. Is transmitted to the arbiter 15 through the control line 17 (S45). Then, the bus interface controller 12c waits until BG = 1 and the bus access permission is released from the arbiter 15 (S46). Then, it is confirmed that BG = 1, and the bus access right release process is completed.

  If this bus access right release processing is executed, single transfer non-permission (non-Grant) is issued to the service execution unit 12d (single transfer service) (S17). As a result, the series of single transfer processes is completed, and the process returns to process step S11 to prepare for the next data transfer.

  Further, when a burst transfer request is received from the service execution unit 12d, the branch determination in processing step S21 is Yes, so the flowchart shown in FIG. 9 is executed. That is, first, a bus access right acquisition process is performed (S22). This bus access right acquisition process is the same as the process shown in FIG.

  When the bus interface controller 12c receives the bus access permission and acquires the bus access right, the bus interface controller 12c notifies the burst transfer service of the service execution unit (Service) 12d of the transfer permission (Grant) (S23). As will be described later, when the service execution unit 12d receives the transfer permission, “Busy” is unanswered as a response, and thus waits to receive the response (S24). Next, when completing the burst transfer, the service execution unit 12d notifies the request completion and non-busy, and the bus interface controller 12c waits to receive the notification (S25). If such notification is received, a bus access right release process is executed (S26). This bus access right release process is the same as that shown in FIG.

  If this bus access right release process is executed, a burst transfer non-permission (non-Grant) is issued to the service execution unit 12d (burst transfer service) (S27). As a result, a series of burst transfer processing is completed, so the processing returns to processing step S11 to prepare for the next data transfer.

  When a non-real-time burst transfer request is received from the service execution unit 12d, the branch determination in processing step S31 is Yes, so the flowchart shown in FIG. 10 is executed. That is, first, a bus access right acquisition process is performed (S32). This bus access right acquisition process is the same as the process shown in FIG.

  When the bus interface controller 12c receives the bus access right permission notification and acquires the bus access right, the bus interface controller 12c transmits the transfer permission (Grant) to the non-real-time burst transfer service of the service execution unit (Service) 12d (S33). As will be described later, when the service execution unit 12d receives the transfer permission, “Busy” is unanswered as a response, and thus waits to receive the response (S34).

  Next, when the non-real-time burst transfer is completed / suspended, the service execution unit 12d notifies the request completion and non-busy, and the bus interface controller 12c waits to receive such notification (S36). However, in the case of a non-real-time burst transfer service, if there is a request from another service (single transfer, burst transfer) of the own station during execution of the service, it is necessary to suspend the transfer process. Therefore, it is also determined whether or not there is a transmission request (Request) from another service before receiving the request completion and non-busy notification sent from the non-real-time burst transfer service (S35).

  If a predetermined notification is received from the non-real-time burst transfer service without receiving a transmission request from another service (Yes in S36), a bus access right release process is executed (S39). This bus access right release process is the same as that shown in FIG.

  If this bus access right release processing is executed, non-permission (non-Grant) of non-real-time burst transfer is issued to the service execution unit 12d (non-real-time burst transfer service) (S40). As a result, a series of non-real-time burst transfer processing is completed, and the process returns to processing step S11 to prepare for the next data transfer.

  If a transmission request is received from another service of the own station during non-real-time burst transfer, the branch determination at processing step S35 is Yes, so the process jumps to processing step S37 and the non-real-time burst transfer service of the service execution unit 12d. In response to this, a transfer non-permission (non-Grant) is sent, and a non-Bsuy notification is received as a response from the non-real-time burst transfer service (S38). If such notification is received, the process returns to processing step 11. Regarding the non-real-time burst transfer at this time, only the non-busy notification is received from the non-real-time burst transfer service, so that the request request state is maintained.

  Returning to processing step S11, since at least one of the other services (single transfer, burst transfer) that causes Yes in the branch determination in processing step S35 has issued a request, branch determination in S11 or S21 is performed. Any of them becomes Yes, and the corresponding data transfer process described above is executed.

  When the transfer service ends, the non-real-time burst transfer remains in the request, so the branch determination in S31 is Yes, and if the bus access right can be acquired, the interrupted non-real-time burst transfer is continued. . If the current occupation time has already exceeded, the BG has disappeared (BG = 1), so the bus access right cannot be continuously acquired this time. That is, it waits for S42 in the middle of execution of S32 to become Yes. However, since the bus access request continues to be output, the arbiter 15 issues a bus access right permission (BG = 0) notification at the next transmission timing, so the interrupted non-real-time burst transfer continues. Is done.

  FIG. 12 shows the single transfer function of the service execution unit 12d. This single transfer function is activated when the MPU 12a receives a single transfer service start command from the service execution unit (Service) 12d, and first issues a single transfer request (Request) to the bus interface controller 12c. (S51). Next, it waits to receive a transfer permission (Grant) from the bus interface controller 12c (S52).

  If the transfer permission has been received (Yes in S52), the single transfer function of the service execution unit 12d returns “Busy” as a response to the bus interface controller 12c (S53), and is actually directed to the desired unit. Single transfer is started (S54). Next, the single transfer function of the service execution unit 12d waits for the completion of the single transfer (S55). If the transfer is completed (Yes in S55), the request completion (as a completion notification to the bus interface controller 12c) Non-Request and Non-Busy) are notified (S56). By issuing such a notification, the current single transfer process is terminated. Note that the notification that the bus interface controller 12c waits at the branch determination in the processing step S15 shown in FIG. 8 is a notification issued by executing the processing step S56. Further, as is apparent from the flowchart shown in FIG. 12, once the single transfer is started with the execution of the processing step S54, the data transfer is continued until the transfer of the data to be transferred this time is completed (Yes in S55). Is done.

  FIG. 13 shows the burst transfer function of the service execution unit 12d. This burst transfer function is activated when a burst transfer service start command is received from the MPU 12a to the service execution unit (Service) 12d. First, a burst transfer request (Request) is issued to the bus interface controller 12c. (S61). Next, it waits to receive a transfer permission (Grant) from the bus interface controller 12c (S62).

  If the transfer permission has been received (Yes in S62), the burst transfer function of the service execution unit 12d returns “Busy” to the bus interface controller 12c as a response (S63), and is actually directed to the desired unit. Burst transfer is started (S64). Next, the burst transfer function of the service execution unit 12d waits for completion of the burst transfer (S65), and if the transfer is completed (Yes in S65), the request completion (as a completion notification to the bus interface controller 12c) (Non-Request and Non-Busy) are notified (S66). By issuing such a notification, the current burst transfer process is terminated. Note that the notification that the bus interface controller 12c waits for the branch determination in the processing step S25 shown in FIG. 9 is a notification issued by executing the processing step S66. Further, as is apparent from the flowchart shown in FIG. 13, once burst transfer is started in accordance with execution of processing step S64, data transfer continues until transfer of data to be transferred this time is completed (Yes in S65). Is done.

  FIG. 14 shows the non-real time burst transfer function of the service execution unit 12d. This non-real-time burst transfer function is activated when the MPU 12a receives a non-real-time burst transfer service start command from the service execution unit (Service) 12d. Prior to describing a specific processing algorithm, a transmission format of a transmission frame used in burst transfer will be described.

  This non-real-time burst transfer is different from single transfer or burst transfer that requires other real-time characteristics, and even during data transfer, the transfer is interrupted under certain interruption conditions, and the interruption condition is released. In this case, transfer is resumed from the interrupted data. Therefore, in addition to the normal burst transfer format shown in FIG. 15 (common to the real-time normal burst transfer format and the non-real-time burst transfer format), the temporary suspension transfer format shown in FIG. 16 and the resume transfer format shown in FIG. Prepared.

  In each figure, “Header0” describes “TYPE”, “MODE”, and “SourceAddress”. “TYPE” defines a burst transfer procedure start code, and includes “real-time burst transfer Write”, “real-time burst transfer Read”, and “non-real-time burst transfer”. “MODE” defines a burst transfer type code, “Start” indicating the start of burst transfer, “Restart” meaning restarting after temporary interruption of burst transfer, and a response from the other party after the transfer is completed. There is a “Response” indicating a response cycle waiting for a response. “SourceAddress” describes the address of the transfer source unit (master, etc.).

In “Header 1”, “Destination Address” indicating the address of the transfer destination unit is described.
In “Header2”, “CRC8-St”, “DataSize”, and “COMMAND” are described. “CRC8-St” is the header FCS at the start of transfer. The FCS range is TYPE, MODE, COMMAND, Destination Address, Source Address, DataSize. “DataSize” describes the size of the data area of this transmission frame, and is described in units of Word.

  Subsequent to “Header2”, data for the data area defined by “DataSize” is described as “Data0”, “Data1”,... “Data0” to “DataN-2” (N is a number defined by “DataSize”) are a pair of “COMMAND” and “DataArea”.

  “COMMAND” is a burst transfer control code, and specifically includes “DataStream”, “Terminate”, and “Pause”. “DataStream” represents data of burst transfer write. That is, it means that arbitrary data (Word unit) described in the paired “DataArea” is normally (without interruption) transmitting data to be transferred by burst transfer.

  “Terminate” means normal termination of transfer. The write data transmission source is issued at the write time, and the read data transmission source is issued at the read time. As shown in FIGS. 15 and 17, it is described in the command area “Data-1”. It also indicates that the frame check cycle is “CRC16-Data”. “CRC16-Data” means an FCS from the beginning of the DataArea to the last data.

  “Pause” means temporary suspension of transfer. This command is issued by the transfer source. Up to the data stored in the Data Area paired with the “Pause” command is the transferred data. Therefore, as shown in FIG. 16, in this non-real-time burst transfer, “COMMAND” of “Data1” is “Pause”, so that the transmission is temporarily suspended in a state where transmission is performed up to “DataArea” of “Data1”. . Then, when the interruption condition is resolved, as shown in FIG. 17, retransmission of the non-real-time burst transfer is started together with the mode code “Restart”. At this time, in the resume transfer format of FIG. 17, data transfer by non-real-time burst transfer is resumed from Data 2 that is a continuation of Data 1 that has been transmitted in the temporarily interrupted transfer format of FIG.

  Further, when “COMMAND” of DataN-1 becomes “Terminate”, the transfer ends normally. Therefore, as shown in FIGS. 15 and 17, the bus direction is switched and a response from the transmission partner is waited for. .

  Here, “CRC8-Rsp” of DataN is a response FCS, and the range of this FCS is Response, MODE, and COMMAND. Response is data at the time of response, and response types include ACK, NAK, and BUSY. Here, ACK Response means normal termination of transfer, and both transmission and reception are normal CRC. NAK Response is an abnormal end of transfer and is a CRC error on the receiving side. BUSY Response is an abnormal end of transfer, such as a reception buffer overflow.

  Next, the function of the non-real-time burst transfer service in the service execution unit will be described using the flowchart shown in FIG. Similar to the real-time data transfer, first, a non-real-time burst transfer request (Request) is issued to the bus interface controller 12c (S71). Next, it waits for reception of transfer permission (Grant) from the bus interface controller 12c (S72).

  If the transfer permission has been received (Yes in S72), the non-real-time burst transfer function of the service execution unit 12d returns “Busy” to the bus interface controller 12c as a response (S73).

  In the case of normal single transfer having real-time property or burst transfer, data transfer is started immediately after the reply of “Busy”. In the case of non-real-time burst transfer, whether or not Pause is in progress. Judgment is made (S74). That is, the temporary transfer format having “Pause” in “COMAND” shown in FIG. 16 is transmitted, and it is determined whether or not the non-real-time burst transfer is currently waiting. This has, for example, a flag indicating whether or not it is currently paused, and when the temporarily interrupted transfer format shown in FIG. 16 is transmitted, control is performed so that the flag is set to ON to see the state of the flag. It can be determined whether or not Pause is in progress.

  If the Pause is not in progress, there is no data to be transmitted in the non-real-time burst transfer that is currently suspended, so the non-real-time burst transfer is started (MODE code = Start) and a timer is started (S75). It is determined whether there is a non-permitted (non-Grant) notification of non-real-time burst transfer (issued by executing S37 in FIG. 10) from the bus interface controller 12c (S76). If no transfer non-permission notification is received, it is determined whether or not a timeout has occurred (S77). If no timeout has occurred, it is determined whether or not non-real-time burst transfer has been completed. (S78). Whether or not this transfer is complete can be determined by whether or not the transfer has been completed up to the Terminate command, as shown in FIGS.

  Until the non-real-time burst transfer is completed, the branch determination from S76 to S79 is repeatedly executed to determine whether or not a transfer non-permission notification is received from the bus interface controller 12c and whether or not a timeout has occurred. When a transfer non-permission (non-Grant) notification is received (Yes in S76), Pause is transmitted to the receiving unit of the transmission partner and transmission is interrupted (S81). Specifically, as shown in FIG. 16, predetermined data (data stored in the paired Data Area) is transmitted to the receiving unit together with the Pause command.

  After such processing is executed, or when a timeout occurs (Yes in S77) or non-real-time burst transfer is completed (Yes in S78), the request is completed as a completion notification to the bus interface controller 12c. (Non-Request and Non-Busy) is notified (S79). By issuing such a notification, the current non-real time burst transfer process is terminated. Note that the notification that the bus interface controller 12c waits for the branch determination in the processing step S36 shown in FIG. 10 is a notification issued by executing the processing step S79.

  On the other hand, if the non-real-time burst transfer is temporarily interrupted in the branch determination in processing step S74, the non-real-time burst transfer is resumed (S80). That is, the transfer frame generated according to the restart transfer format shown in FIG. 17 (the frame including the data area portion interrupted and not transmitted previously) is transmitted, and thereafter, the process proceeds to processing step S76, and the non-real time is performed while performing the branch determination described above. Data is transferred by burst transfer.

  Next, the processing function of the receiving unit will be described. FIG. 18 is a flowchart showing the functions of the bus interface controller 13c on the slave unit side. First, a non-real time burst transfer is waited for from the master unit (S91). If reception of such transfer is accepted, reception of non real time burst transfer is started and a timer is started (S92).

  A command for receiving the transferred data is confirmed, and it is determined whether or not a pause is received (S93). If no pause command is received, it is determined whether or not a reception timeout has occurred (S94). If the temporary stop is not received and the reception timeout does not occur, it is determined whether or not the reception is completed (Terminate reception) (S95).

  It is determined whether or not the above-mentioned temporary stop and reception timeout have occurred until reception is completed, and if reception is completed without satisfying any conditions (Yes in S95), return to S91 and transfer from the next master unit Wait for. If a reception timeout has occurred (Yes in S94), the process returns to S91 and waits for transfer from the next master unit.

  When a Pause command is received (Yes in S93), reception stop processing is performed (S96), and then a reception indicating a restart transfer format from the same master unit is timed out. (S97, S98). If Restart is received before the reception time-out (Yes in S97), the suspended reception of the non-real-time burst transfer is resumed (S99), and the process proceeds to S94, where the reception time-out is resumed or until the reception is completed. Receives data sent by non-real-time burst transfer. If the reception time-out occurs without receiving Restart (Yes in S98), the process returns to S91 and waits for transfer from the next master unit.

  Next, the function of each unit (processing unit) will be described with specific examples of the transfer services described above. FIGS. 19 and 20 show schematic timing charts when the three master units (1), (2), and (3) execute various transfer services for other slave units. As is apparent from FIGS. 19 and 20, each master unit makes a request for acquiring bus access right when data to be transferred is generated, and if a bus access right permission notification (SG = 0) is obtained. Start the desired transfer service. Of course, there may be no request for acquiring the bus access right, or there may be a request for acquiring the bus access right immediately after receiving the bus access right permission notification and releasing the acquired bus access right. In particular, as described above, in this embodiment, a non-real-time burst transfer capable of temporarily interrupting the transfer is provided. Therefore, when such non-real time burst transfer is interrupted, a bus access right acquisition request is issued immediately after the bus access right is released.

  For example, as shown in the master unit (2) in FIG. 19, different types of transfers may be performed during one bus access right acquisition. In the illustrated example, burst transfer is continued after completion of single transfer. Furthermore, as shown in the master (2) of FIG. 20, in the case of a transfer service having real-time characteristics such as burst transfer, BG is returned to 1, and the bus access right permission notification from the arbiter 15 is released. However, the state where the bus access right is acquired is maintained, and the transfer is continued until the burst transfer service is completed. Although not shown, the same applies to the single transfer service. As the master unit (2) shown in FIG. 20 continues burst transfer even after returning to BG = 1, the master unit (3) scheduled to perform the next transfer service is transferred to the master unit (3). The timing at which the given bus access right permission notice (BG = 0) is delayed, and the period of BG = 0 is also shortened. The matters described above are basically the same as those in the prior art except that the bus access right acquisition request is issued immediately after the bus access right is released due to the interruption of the non-real-time burst transfer.

  Here, in the present invention, a non-real-time burst transfer that allows the transfer service to be temporarily interrupted during transfer is provided, and the priority of the non-real-time burst transfer service is the lowest. Cases arise. Of course, the contents described are only a part, and other cases may of course occur.

  For example, as shown in FIG. 19, when the master unit (1) has acquired the bus access right, it first performs a burst transfer service having a high priority, and BG = 0 remains even when the burst transfer service is completed. When the bus access right permission notification is received, non-real-time burst transfer is subsequently started for a predetermined unit (for example, the node # 2 unit). However, during the transfer process, BG = 1 is returned and the bus access right permission notification is canceled. Accordingly, the non-real-time burst transfer is interrupted (during pause), and the master unit (the bus access right is acquired next) 2) performs a single transfer service for a predetermined unit, and then performs a burst transfer service.

  Subsequently, since it is the master unit (3) that has acquired the bus access right, the state in the pause of the master unit (1) is maintained, the master unit (3) performs single transfer, and then non-real time Start burst transfer. The transfer partner of the non-real-time burst transfer of this master unit (3) is the slave unit of node # 0. Then, this master unit (3) also returns to BG = 1 during the transfer process, and the bus access right permission notification is canceled, and accordingly, non-real-time burst transfer is interrupted (during Pause).

  Then, since the master unit (1) has acquired the bus access right next time, the non-real-time burst transfer service addressed to the suspended node # 2 is resumed. In addition, when the master unit (1) needs to perform a burst transfer service after the resumed non-real time burst transfer is completed, the bus access right is still acquired in the illustrated example. Run the transfer service.

  In addition, since the transfer service priority is single transfer → burst transfer → non-real-time burst transfer, if requests for these transfer services occur almost at the same time, they are processed according to the priority, but they are not necessarily the same. Requests for each transfer service do not always occur at the same time, and if they do not occur at the same time, the processing is performed in the order in which they occurred. As an example, as shown in the master unit (2) in FIG. 19, it is possible to execute a non-real-time burst transfer after completing a single transfer and execute a burst transfer service after the transfer is completed.

  However, if a non-real-time burst transfer is received and a request for a transfer service with higher priority than that is received, the non-real-time burst transfer is temporarily suspended and other transfer services of the self are transferred. If the bus access right has been acquired, the interrupted non-real-time burst transfer is resumed. In the illustrated example, this corresponds to the first transfer process of the master unit (1) in FIG. 20 and the second transfer process of the master unit (2).

  Further, as shown in the master unit (3) of FIG. 20, when a request for a single transfer service having a higher priority occurs during the execution of the burst transfer service, the burst transfer service is temporarily suspended. The burst transfer service that was interrupted after the completion of the single transfer service may be resumed. Such processing can be basically handled by allowing the issuance of a “Pause” command or “Restart” mode in non-real-time burst transfer even in normal burst transfer having real characteristics. Of course, only non-real-time burst transfer is interrupted. Once the burst transfer service is started, the burst transfer service is continued as it is even if a single transfer service request is received by the time it is completed. Also good.

  As described above, as a condition for temporary suspension during non-real-time burst transfer, which is a main part of the present invention, there is a request to transfer the bus access right of the unit acquired by itself to another unit (timeout or the like). BG = 1) and another transfer service request of the own unit. If there is a request for delegating the bus access right of the transmission source unit to another unit during the former non-real time burst transfer, the transfer is paused to release the bus access right. The non-real time burst transfer then waits for subsequent transmissions until the source unit acquires the bus access right.

  When the transmission source unit performs real-time burst transfer or single transfer during the latter non-real-time burst transfer, the non-real-time burst transfer is paused and the real-time transfer is performed with the bus access right unchanged. Thereafter, the non-real time burst transfer is resumed.

  FIG. 21 is a more detailed timing chart of data transmission in the former case. This corresponds to the temporary interruption processing of the non-real time burst transfer in the master (1) and the master (3) in FIG. Then, as shown in FIG. 21, it is the own unit that initially performs non-real-time burst transfer.

  As is apparent from FIG. 21, during the IDLE cycle, the self-unit that performs non-real-time burst transfer activates the non-real-time burst transfer function of the service execution unit 12d based on an instruction from the MPU 12a, and the bus interface controller 12c. BREQ, BG, and BSY change from 1 to 0 in accordance with a request for bus access between the arbiter 15 and the arbiter 15 and transmission / reception of data such as a permission notification.

  Next, the master unit, which is its own unit, executes non-real-time burst transfer having a predetermined transfer format. In the example shown in the figure, the bus access permission has disappeared (BG = 1) during the transfer (during transmission of Data0), so that the own unit sends data to be sent in the DataArea of Data1 together with the Pause command in the next Data1 (PAUSEcycle). In the next IDLE cycle, BSY is returned to 1 and the acquired bus access right is released. At this time, the own unit once cancels the bus access right acquisition request (BREQ = 1), immediately returns to BREQ = 0 to perform non-real-time burst transfer incomplete transfer, and makes a bus access right acquisition request. Note that the transfer format of the interrupted non-real-time burst transfer in FIG. 21 is the same as that of the temporary interrupt shown in FIG.

  Also, during the above IDLE cycle, another unit that performs single transfer makes a bus access right acquisition request (BREQ = 0), a bus access right permission notification (BG = 0) from the bus arbiter 15, and a bus accessing flag. Set to ON (BSY = 0). Subsequently, another unit performs single transfer using WRITEcycle.

  When the single transfer in the other unit is completed, the BREQ, BG, and BSY of the other unit return to 1, so that the non-real-time burst transfer is interrupted and the own unit making the bus access right acquisition request (BREQ = 0) When the bus access right permission notification (BG = 0) is received, the bus accessing flag is turned ON (BSY = 0), and the non-real-time burst transfer is resumed. Along with this restart, data is transmitted from the next data (Data 1) that has been transmitted (Data 1) in the previous non-real-time burst transfer (data stored in Data Area of Data 2). In this non-real time burst transfer, there is a case where the transfer can be completed to the end, and there is a case where it is further interrupted.

  In the example shown in FIG. 21, the non-real-time burst transfer that has been temporarily suspended is resumed after the completion of the serial transfer of the other unit. However, as shown in FIG. Of course, it can be resumed.

  FIG. 22 shows a specific example of temporary interruption in non-real-time burst transfer (Read). Specifically, this is the same as the non-real-time burst transfer (Write) shown in FIG. 21 described above. When the bus access right permission notification disappears (BG = 1), the own unit performs Pause processing, and the bus accessing flag Is turned OFF (BSY = 1), and the bus access right is released. As a result, other units perform real-time data transfer (single transfer in the illustrated case). When the single transfer is completed, the self-suspended unit resumes the non-real time burst transfer. Here, the difference from the transfer process shown in FIG. 21 is that the data transfer is READcycle, so the bus is switched and the data is read from the communication partner.

  FIG. 23 and FIG. 24 show a case where a master unit performing non-real time burst transfer performs data transfer having real time characteristics. That is, it corresponds to the master (1) and the master (2) in FIG.

  When suspending a non-real-time burst transfer during transfer, the Pause command is issued to temporarily suspend, and the non-real-time burst transfer is resumed after completing a data transfer that requires real-time characteristics such as a single transfer, and In the case of the READ process, the bus is switched as shown in FIGS. However, in this example, since the real-time transfer is switched within the same master unit, it is not necessary to release the bus access right, and BREQ, BG, and BSY remain 0.

  In each of the above-described embodiments, the receiving unit may be the slave unit 13 or the master unit 12.

  By the way, as described above, in the present invention, non-real time burst transfer may be divided (Pause / Restart), so that the receiving unit may receive and process a plurality of non-real time messages at the same time. In such a case, on the receiving unit side, it is necessary to combine data transmitted by non-real-time burst transfer from the same transmitting unit (master unit) in a predetermined order.

  In order to perform such processing, for example, a unique fragment ID is added to each fragmented frame as shown in FIG. 25, and non-real-time messages from a plurality of transmission sources are identified by the fragment ID. A complete frame can be generated. In addition, when such a method is adopted, there is a demerit that the data transfer efficiency is lowered because the fragment ID is added at the time of division, and the time required for the interruption process is increased by the time for sending the fragment ID. On the receiving side, complicated processing such as assembling a frame with reference to the fragment ID is necessary, and the processing load of firmware increases or the logical scale increases when processing is performed by hardware.

  Also, as shown in FIG. 26, on the receiving unit side, separate receiving buffers (for master A and master C in the figure may be provided) for each transfer source unit ID. It is necessary to provide a reception buffer corresponding to the maximum data size of the non-real-time message, resulting in high hardware costs.

  The method shown in FIGS. 25 and 26 is not hindered by the present invention, but it is preferable to implement various means described below. That is, as a basic technical idea, the receiving unit is always provided with a restriction that only one non-real-time burst transfer is received. As a result, the plurality of frames divided by the non-real-time burst transfer (Pause / Restart) are all sent from the same unit to the receiving unit. In addition, in the case of one non-real-time burst transfer, the transmission order of each data does not change even if it is divided into a plurality of parts. Therefore, the receiving unit is sent by combining the data in the order received, and is transmitted by non-real-time burst transfer. Can generate data to be sent.

  As a specific embodiment for solving the technical idea, for example, during non-real time burst transmission, non-real time burst transmission is performed on the condition that the destination unit confirms that the non-real time burst is not received.

  Several methods can be used as the “method for confirming that the destination unit has not received the non-real-time burst”, for example, after confirming the non-real-time burst reception status of the destination unit before transmission. It is to be. However, in this case, single access occurs before the non-real time burst transfer. Specifically, the non-real time burst transfer function of the master unit executes the flowchart shown in FIG.

  First, it waits for reception of a non-real-time burst transmission request (S101), and if it is received, the non-real-time burst reception status of the transmission destination is confirmed (S102). Then, it is determined whether or not the transmission destination is receiving a non-real-time burst (S103). If it is confirmed that the transmission is not being received, non-real-time burst transfer is started (S104) and transmission is completed (S105). If it is determined that the data is being received as a result of the confirmation in the processing step S102 (Yes in S103), the process returns to the processing step S102 to confirm again. That is, it waits for the transmission partner to complete non-real-time burst reception with another unit, and starts transmitting itself (S104, S105).

  Also, as shown in FIG. 28, the reception of a non-real-time burst transmission request is awaited (S111), and if it is received, a request for acquiring the access right of the reception buffer of the destination destination unit is made and the acquisition is awaited (S112). ). Then, when the access right is obtained, it is transmitted (S113, S114).

  As another method, the unit constantly monitors the bus and includes a non-real-time burst transfer execution state table (see FIG. 29). That is, it is monitored whether or not each node is performing non-real time burst transfer, and the monitoring result is stored in the execution table.

  Then, as shown in FIG. 30, it waits for reception of a non-real-time burst transmission request (S121), and if received, refers to the execution state table created by itself (S122), and whether or not the current transmission destination unit is receivable. Is determined (S123). Specifically, if the flag of the transmission destination node is “1”, reception is impossible, and if it is “0”, reception is possible. If non-real-time burst point total reception is in progress (0) and the other party can receive, non-real-time burst transfer is performed (S123, S124).

  Another technical idea is to perform non-real time burst transmission after confirming that other units are not transmitting non-real time burst transmission during non-real time burst transmission.

  Specifically, the unit constantly monitors the bus and has an execution state table (see FIG. 31) for non-real-time messages. This execution table is different from that shown in FIG. 29, and any one (regardless of whether it is a transmission partner) or not is sending a non-real-time message (suspended), and the flag is set to “1”.

  Then, as shown in FIG. 32, it waits for the reception of a non-real-time burst transmission request (S131), and if it is received, the execution state table created by itself is referred to (S132). First, it is determined whether or not the other party can receive his / her non-real time. If none of the units is performing non-real-time transfer, it is a matter of course that the current transmission destination unit can also be received (Yes in S133), and therefore non-real-time burst transfer is performed (S133, S134). . In this method, even when a unit other than the transmission destination receives non-real-time burst transfer, the transfer execution table flag is set to 1, and transmission cannot be performed, so the non-real-time message transfer latency increases. Real-time burst transfer is not a big problem because latency is not important. Therefore, it can be said that this method is the simplest and has a small processing load and hardware scale.

  In the embodiment described above, a plurality of units are mounted on the backplane (backplane board) 11 as shown in FIG. 3, and each unit is connected via a bus in the backplane and the arbiter 15 is connected to the backplane 11. The configuration installed in is adopted. However, the present invention is not limited to this, and the present invention can also be applied to a configuration in which units are laterally connected without a backplane (for example, a DIN rail mounting type) and each unit is connected by a through bus. In such a case, an arbiter can be installed in any unit constituting the control device, or an arbiter unit can be installed. In that case, a control line for connecting each master unit and the arbiter is passed through each unit.

  The master unit (bus master unit) is not only a “CPU unit” that performs user program calculation processing, but also a “motion control unit” that controls a motion system, and performs communication between other PLCs and data controllers. It can be applied to various types of devices such as a “communication unit” and a high-performance arithmetic unit for performing specialized arithmetic processing. By having this master unit function, there is an effect that input data and output data for control need not be transmitted / received via the CPU unit.

An example of the transfer operation in the conventional multibus master system is shown. It is a figure explaining the conventional problem. It is a figure which shows one suitable embodiment of this invention. It is a figure which shows the timing chart of single transfer and burst transfer. It is a flowchart which shows the function of an arbiter. It is a figure which shows an example of an internal structure of a master unit. It is a figure which shows an example of the internal structure of a slave unit. 7 is a part of a flowchart showing a part of the function of the bus interface controller 12c of the master unit 12. 7 is a part of a flowchart showing a part of the function of the bus interface controller 12c of the master unit 12. 7 is a part of a flowchart showing a part of the function of the bus interface controller 12c of the master unit 12. 7 is a part of a flowchart showing a part of the function of the bus interface controller 12c of the master unit 12. It is a flowchart which shows the single transfer function of the service execution part 12d. It is a flowchart which shows the burst transfer function of the service execution part 12d. It is a flowchart which shows the non-real-time burst transfer function of the service execution part 12d. It is a figure which shows an example of the transfer format of the flame | frame of burst transfer. It is a figure which shows an example of the temporarily interrupted transfer format of the frame of burst transfer. It is a figure which shows an example of the restart transfer format of the flame | frame of burst transfer. It is a flowchart which shows the function of the bus interface controller 13c in the slave unit side. It is a figure which shows a concrete example about each transfer service. It is a figure which shows a concrete example about each transfer service. It is a figure which shows the detailed timing chart of non-real-time burst transfer. It is a figure which shows the detailed timing chart of non-real-time burst transfer. It is a figure which shows the detailed timing chart of non-real-time burst transfer. It is a figure which shows the detailed timing chart of non-real-time burst transfer. It is a figure explaining the process which integrates the data which received and divided | segmented it by non-real-time burst transfer. It is a figure explaining the process which integrates the data which received and divided | segmented it by non-real-time burst transfer. It is a flowchart which shows the function of the master unit for a receiving unit to receive only one non-real-time burst transfer. It is a flowchart which shows the function of the master unit for a receiving unit to receive only one non-real-time burst transfer. It is a figure which shows an example of the data structure of the execution state table of non-real-time burst transfer. It is a flowchart which shows the function of the master unit for a receiving unit to receive only one non-real-time burst transfer. It is a figure which shows an example of the data structure of the execution state table of the non-real-time message of non-real-time burst transfer. It is a flowchart which shows the function of the master unit for a receiving unit to receive only one non-real-time burst transfer.

Explanation of symbols

10 Controller 11 Backplane 12 Master Unit 13 Slave Unit 15 Arbiter 16 Bus 17 Control Line

Claims (10)

A communication method in which a plurality of master units constituting a control device perform data communication with other units via a bus in the control device on condition that a bus access right permission notification is received from an arbiter mounted on the control device Because
In addition to burst transfer that continuously transfers multiple data following an address or command, in addition to normal burst transfer that transmits multiple data in one transmission frame, multiple data can be divided and transmitted Set non-real-time burst transfer to
The master unit acquires the bus access right permission notification, determines whether there is a transmission interruption condition during execution of the non-real-time burst transfer, and if the transmission interruption condition occurs, Suspend burst transfer,
The master unit that interrupted the non-real-time burst transfer when the interrupt condition disappears and the bus access right permission notification is received, the non-real-time burst for the untransmitted portion of the temporarily interrupted data A communication control method characterized by resuming transfer.   The communication control method according to claim 1, wherein the interruption condition is that a bus access right permission given from the arbiter is canceled.   2. The communication control method according to claim 1, wherein the interruption condition is that a master unit performing the non-real-time burst transfer performs data transfer having a higher priority than the non-real-time burst transfer. .   4. The communication control method according to claim 3, wherein the high-priority data transfer is at least one of the normal burst transfer and single transfer in which one word is transferred in one access.   5. When a non-real-time burst transfer is temporarily interrupted, a unit that is a communication partner of the temporarily interrupted non-real-time burst transfer is controlled not to receive another non-real-time burst transfer. The communication control method according to any one of the above. The non-real-time burst transfer communication partner has a reception status that indicates whether the non-real-time burst transfer is suspended,
Prior to performing the non-real-time burst transfer, the master unit attempting to perform the non-real-time burst transfer confirms the reception status with respect to the transmission destination unit and performs the non-real-time burst transfer on condition that it is not temporarily suspended. The communication control method according to any one of claims 1 to 4, wherein the communication control method is performed. Prior to performing the non-real-time burst transfer, the master unit attempting to perform the non-real-time burst transfer issues a non-real-time burst transfer transmission request to the transmission destination unit.
The unit that received the transmission request issues a permission notice when it is not temporarily interrupting non-real-time burst transfer from another master unit,
5. The communication control method according to claim 1, wherein the master unit performs non-real-time burst transfer on condition that the permission notice is received and the access right is acquired. The master unit monitors the bus and stores information on whether or not non-real-time burst transfer is performed for each node,
5. The non-real time burst transfer is executed when it is determined that a transmission partner performing non-real time burst transfer can transfer based on the stored information. The communication control method described. The master unit monitors the bus and stores information on whether or not there is a node performing non-real-time burst transfer.
The non-real-time burst transfer is executed when it is determined that there is no node performing non-real-time burst transfer based on the stored information. Communication control method. In a control device including a plurality of master units and an arbiter that controls bus access of the plurality of master units, the master unit receives a bus access right permission notification from the arbiter. A system for data communication with other units via a bus,
In addition to burst transfer that continuously transfers multiple data following an address or command, in addition to normal burst transfer that transmits multiple data in one transmission frame, multiple data can be divided and transmitted Set non-real-time burst transfer to
The master unit obtains the bus access right permission notification, determines whether or not there is a transmission interruption condition during execution of the non-real-time burst transfer, and when the transmission interruption condition occurs, Means for issuing a pause command to suspend real-time burst transfer;
Means for performing non-real-time burst transfer for transmitting data that could not be transmitted due to temporary interruption of the non-real-time burst transfer when the interruption condition is eliminated and the bus access right permission notification is received; A system characterized by

Images