WO2023089665A1 - シリアル通信方法及びシリアル通信システム - Google Patents

シリアル通信方法及びシリアル通信システム Download PDF

Info

Publication number
WO2023089665A1
WO2023089665A1 PCT/JP2021/042097 JP2021042097W WO2023089665A1 WO 2023089665 A1 WO2023089665 A1 WO 2023089665A1 JP 2021042097 W JP2021042097 W JP 2021042097W WO 2023089665 A1 WO2023089665 A1 WO 2023089665A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
serial communication
command
data
latch
Prior art date
Application number
PCT/JP2021/042097
Other languages
English (en)
French (fr)
Inventor
裕史 丸山
功 加々谷
Original Assignee
多摩川精機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 多摩川精機株式会社 filed Critical 多摩川精機株式会社
Priority to PCT/JP2021/042097 priority Critical patent/WO2023089665A1/ja
Publication of WO2023089665A1 publication Critical patent/WO2023089665A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus

Definitions

  • the present invention relates to a serial communication method and serial communication system, and more particularly to a serial communication method and serial communication system for instructing a slave device to latch and release from a master device.
  • Commands and data are generally exchanged by serial communication between a master device and a slave device, specifically between a controller and a sensing device.
  • a serial communication system with such a configuration is described in Patent Document 1 and Non-Patent Document 1.
  • Patent Document 1 discloses a technique of single-master/multi-slave communication in a single-master/multi-slave connection system in which a plurality of sensing devices are connected to a single controller through a bus. However, no mention is made of the function of latching (retaining)/releasing data (releasing retention) in the sensing device.
  • Non-Patent Document 1 discloses a technique of single-master/single-slave communication in a single-master/single-slave connection system in which a single sensing device is connected to a single controller through a bus. However, no mention is made of the function of latching (retaining)/releasing data (releasing retention) in the sensing device.
  • An object of the present invention is to provide a serial communication method and a serial communication system that can hold and release data at any timing in a sensing device based on a command from a controller.
  • a serial communication method and a serial communication system provide a serial communication between a controller having a serial communication function and one or more sensing devices having a serial communication function according to a communication format.
  • the communication format includes a latch command that instructs the sensing device to hold the detected data and a release command that instructs the sensing device to release the detected data.
  • the sensing device retains the sensed data in response to a latch command from the controller, and releases the retention of the sensed data in response to a release command from the controller.
  • the sensing device responds to the latch command from the controller by transmitting to the controller a command indicating that the holding instruction has been received, and releasing the sensing device from the controller. In response to the command, a command is transmitted to the controller indicating that an instruction to release the hold has been received.
  • the controller includes an inquiry command for inquiring the state of the sensing device in the communication format and transmits the inquiry command to the sensing device, and the sensing device sends the inquiry command to the controller.
  • a command indicating that the data is held or a command indicating that the holding has been released is sent to the controller.
  • the controller includes a sensing device ID designating one of the sensing devices when transmitting a latch command and a release command to the sensing device,
  • the sensing device designated by the sensing device ID retains the detected data in response to a latch command from the controller, and releases the retention of the detected data in response to a release command from the controller. Even if the sensing device ID is not specified, when a latch command or a release command specifying all sensing devices is sent from the controller, all sensing devices hold the detected data according to the latch command and detect release the retention of the data that has been stored in response to the release command.
  • the controller is the master device
  • the sensing device is the slave device
  • serial communication is performed between the master device and the slave device.
  • the sensing device transmits held data to the controller in response to a request from the controller.
  • the controller includes the latch command and the release command in the communication format and transmits them to the sensing device, and the sensing device senses according to the latch command. Since the data is held and the data detected in response to the release command is released, the sensing device can hold and release the data at any timing based on the command from the controller.
  • FIG. 1 is a configuration diagram showing the configuration of a serial communication system according to Embodiment 1 of the present invention
  • FIG. 1 is a configuration diagram showing the configuration of a serial communication system according to Embodiment 1 of the present invention
  • FIG. 4 is a timing chart showing a communication format of the serial communication system according to Embodiment 1 of the present invention
  • FIG. 2 is an explanatory diagram showing an example of contents of a communication format of the serial communication system according to Embodiment 1 of the present invention
  • 4 is a timing chart showing a communication format of the serial communication system according to Embodiment 1 of the present invention
  • FIG. 2 is an explanatory diagram showing an example of contents of a communication format of the serial communication system according to Embodiment 1 of the present invention
  • FIG. 1 is a configuration diagram showing the configuration of a serial communication system according to Embodiment 1 of the present invention
  • FIG. 4 is a timing chart showing a communication format of the serial communication system according to Embodiment 1 of the present invention
  • FIG. 3 is an explanatory diagram showing the format of a control field in the communication format used in the serial communication system according to Embodiment 1 of the present invention
  • FIG. 4 is an explanatory diagram showing contents of a control field in a communication format used in the serial communication system according to Embodiment 1 of the present invention
  • FIG. 4 is a timing chart showing a communication format of the serial communication system according to Embodiment 1 of the present invention
  • FIG. 2 is an explanatory diagram showing an example of contents of a communication format of the serial communication system according to Embodiment 1 of the present invention
  • 4 is a timing chart showing a communication format of the serial communication system according to Embodiment 1 of the present invention
  • FIG. 2 is an explanatory diagram showing an example of contents of a communication format of the serial communication system according to Embodiment 1 of the present invention
  • 4 is an explanatory diagram showing the format of a command code field in the communication format used in the serial communication system according to Embodiment 1 of the present invention
  • FIG. 4 is an explanatory diagram showing the contents of a command code field in the communication format used in the serial communication system according to Embodiment 1 of the present invention
  • FIG. FIG. 4 is an explanatory diagram showing allocation of command codes in a communication format used in the serial communication system according to Embodiment 1 of the present invention
  • FIG. 2 is a sequence diagram showing communication procedures of the serial communication system according to Embodiment 1 of the present invention
  • Embodiment 1 of the present invention a basic configuration of a serial communication system that executes a serial communication method will be described with reference to FIG.
  • FIG. 1 is a configuration diagram showing the configuration of a serial communication system 1A according to Embodiment 1 of the present invention.
  • a serial communication system 1A that implements a serial communication method comprises a controller 10, a device 20, and a communication line 30A.
  • the controller 10 is a master device and the device 20 is a slave device, which are communicably connected through a communication line 30A.
  • a single device 20 is connected to a single controller 10 through a communication line 30A, forming a single master/single slave connection serial communication system.
  • Single master/single slave communication is performed between the controller 10 and the device 20 in the single master/single slave serial communication system 1A. That is, commands and data are transmitted and received through serial communication between the controller 10, which is a master device, and the device 20, which is a slave device.
  • the controller 10 has a serial communication function and is a control unit that reads data from the device 20 through serial communication.
  • the device 20 is a sensing device having a serial communication function, and corresponds to, for example, a sensing device that outputs data detected from a controlled object through serial communication.
  • the communication line 30A is composed of a signal line that supplies the power supply Vcc, a signal line that maintains the potential of the ground GND, and a signal line that transmits a pair of differential transmission signals SD+/SD-.
  • the power supply Vcc is supplied from the controller 10 to the device 20 through signal lines.
  • the differential transmission signals SD+/SD- are bidirectionally transmitted through signal lines, and are transmitted from the controller 10 to the device 20 and from the device 20 to the controller 10.
  • FIG. 2 is a configuration diagram showing the configuration of the serial communication system 1B according to Embodiment 1 of the present invention.
  • the serial communication system 1B mainly includes a controller 10, a device 20, and a bus communication line 30B.
  • the controller 10 is a master device and the device 20 is a slave device, which are communicably connected through a bus communication line 30B.
  • the device 20 as a slave device comprises a plurality of devices 20_1, 20_2, . . . , 20_n.
  • Single-master/multi-slave communication is performed between the controller 10 and the device 20 in the single-master/multi-slave serial communication system 1B. That is, commands and data are transmitted and received by serial communication between the controller 10, which is a master device, and one of the devices 20_1 to 20_n, which are slave devices, 20_i.
  • This device ID may be a number in order such as 1, 2, 3, .
  • the controller 10 can identify a plurality of devices 20_1, 20_2, .
  • FIG. 3 is a timing chart showing the communication format of the serial communication system 1A according to Embodiment 1 of the present invention.
  • FIG. 4 is an explanatory diagram showing an example of the contents of the communication format of the serial communication system 1A according to Embodiment 1 of the present invention.
  • FIG. 3(a) shows transmission of a request from the controller 10 to the device 20 in the single master/single slave serial communication system 1A.
  • the request transmitted by the controller 10 means a request for data to the device 20, as will be described later.
  • the controller 10 monitors whether or not there is an idle state for one data frame or more from the last part of the preceding data frame, and the idle state for one data frame or more continues from the last part of the preceding data frame. After that, the control field CF is transmitted to the device 20 as a request.
  • One data frame is a unit of a series of data transmitted from the device 20 to the controller 10 .
  • FIG. 3 shows a communication format of data transmitted from the device 20 to the controller 10 in the single master/single slave connection serial communication system 1A.
  • the device 20 determines that communication has started when the control field CF is sent as a request after the idle state continues for one data frame or more. As a result, the device 20 avoids erroneously determining that another communication has started communication.
  • the device 20 When the device 20 receives the control field CF as a request from the controller 10, it transmits data to the controller 10 by serial communication according to the communication format.
  • the device 20 is a sensing device and transmits data sensed from the controlled object to the controller 10 .
  • the device 20 transmits a series of data including a control field CF, a status field SF, data fields DF0 to DFn, and a check field CRC to the controller 10 according to the communication format, as shown in FIG. 3(b). .
  • FIG. 4 shows the contents of each field of the data shown in the timing charts of FIGS. 3(a) and 3(b).
  • the control field CF is command information for the communication partner.
  • the status field SF is device status identification information.
  • Data fields DF0 to DFn are information assigned to data IDs.
  • the check field CRC is error check information by CRC (Cyclic Redundancy Check) for all bits except the start bit and delimiter of all fields other than the CRC field.
  • FIG. 5 shows transmission of a request from the controller 10 to any one of the devices 20_1 to 20_n in the single-master/multi-slave serial communication system 1B.
  • a request sent by the controller 10 means a data request to the device 20 .
  • the controller 10 transfers the control field CF and the device ID field IDF to the devices 20_1 to 20_n. It is transmitted as a request to one of the devices 20_i.
  • FIG. 5 shows the communication format of data transmitted from the device 20 to the controller 10 in the single-master/multi-slave serial communication system 1B.
  • a plurality of devices 20_1 to 20_n determine that communication has started when the control field CF and device ID field IDF are sent as a request after the idle state continues for one data frame or more.
  • the plurality of devices 20_1 to 20_n respond to the contents of the control field CF and the contents of the device ID field IDF. Determine if it is a request.
  • the device 20_i that has determined that the request from the controller 10 is addressed to itself transmits the data to the controller 10 by serial communication according to the communication format.
  • the device 20_i is a sensing device and transmits data sensed from the controlled object to the controller 10 .
  • the device 20_i transmits a series of data including a control field CF, a device ID field IDF, a status field SF, data fields DF0 to DFn, and a check field CRC according to the communication format. Send to the controller 10 .
  • FIG. 6 is an explanatory diagram showing an example of the contents of the communication format of the serial communication system 1B according to Embodiment 1 of the present invention. Unlike the one shown in FIG. 4, FIG. 6 further has a device ID field IDF that is device ID (identification) information for identifying a plurality of devices.
  • IDF device ID (identification) information for identifying a plurality of devices.
  • control field CF in the communication format used in serial communication according to Embodiment 1 of the present invention will be described with reference to FIGS. 7 and 8.
  • FIG. 7 the control field CF in the communication format used in serial communication according to Embodiment 1 of the present invention.
  • FIG. 7 is an explanatory diagram showing the format of the control field CF in the communication format used in the serial communication systems 1A and 1B according to Embodiment 1 of the present invention.
  • the control field CF includes a start bit, a SYNC (Synchronous) code bit, a data ID code bit, a data ID parity bit, and a delimiter bit.
  • FIG. 8 is an explanatory diagram showing the contents of each bit of the control field CF in the communication format used in the serial communication systems 1A and 1B according to Embodiment 1 of the present invention.
  • the start bit is a bit that indicates the start position, and is fixed to "0", for example.
  • the SYNC code is a predetermined code used for synchronization, and repeats "0" and "1" a predetermined number of times. In this embodiment 1, the SYNC code is assigned a first SYNC code "010" for single-master/single-slave communication and a second SYNC code "101" for single-master/multi-slave communication. be done.
  • a data ID code is a code to which communication data and operation instructions are assigned in order to select communication content.
  • a data ID code can be assigned a latch/release control execution ID to execute a latch that holds data and a release that releases the latch.
  • Data ID parity is a parity check bit for the data ID code.
  • the delimiter is a bit indicating the end position, and is fixed to "1", for example.
  • the above SYNC code in the control field CF determines whether single master/single slave communication or single master/multi slave communication is performed in the serial communication systems 1A and 1B.
  • the SYNC code whether "010" or "101", is also used for original synchronization purposes.
  • the device 20 After receiving the control field CF, the device 20 returns data or performs various operations according to the data ID code.
  • the device 20_i having the corresponding device ID returns data or performs various operations according to the data ID code. to run.
  • FIG. 9 a latch means holding data not only in a flip-flop circuit but also in various circuits.
  • “Release” means releasing data held by a latch in various circuits.
  • FIG. 9 is a timing chart showing the communication format of the serial communication system 1A according to Embodiment 1 of the present invention.
  • FIG. 10 is an explanatory diagram showing an example of the contents of the communication format of the serial communication system 1A according to Embodiment 1 of the present invention.
  • FIGS. 9 and 10 the same parts as in FIGS. 3 and 4 which have already been described are given the same reference numerals to omit redundant description, and the description will focus on the parts different from FIGS.
  • the controller 10 sets the control field CF, the command code field CCF, and the check field CRC.
  • the contained series of data are transmitted to the device 20 .
  • the device 20 determines that communication has started when a series of data including the control field CF, command code field CCF, and check field CRC is sent from the controller 10 .
  • the device 20 transmits a series of data including a control field CF, a status field SF, a command code field CCF, and a check field CRC to the controller 10 according to the communication format, as shown in FIG. 9(b).
  • FIG. 10 shows the contents of each field of the data shown in the timing charts of FIGS. 9(a) and (b).
  • the control field CF is command information for the communication partner.
  • the status field SF is device status identification information.
  • the command code field CCF is a command code indicating acceptance of an instruction relating to latch or release.
  • the check field CRC is error check information by CRC (Cyclic Redundancy Check) for all bits except the start bit and delimiter of all fields other than the CRC field.
  • the controller 10 can include command information instructing the device 20 to execute latch/release control in the data ID code in the control field CF.
  • the controller 10 can further include command codes instructing latch execution and release execution as latch/release related command codes in the data in the command code field CCF.
  • the device 20 ( b), according to the communication format, send a series of data to the controller 10 including a control field CF, a status field SF, a command code field CCF and a check field CRC;
  • the command code field CCF includes a command code indicating that the latch or release command from the controller 10 has been received.
  • the device 20 then executes latching or releasing as instructed by the controller 10 .
  • FIG. 11 is a timing chart showing the communication format of the serial communication system 1B according to Embodiment 1 of the present invention.
  • the controller 10 controls field CF, device ID field IDF, command code field CCF, and a check field CRC to one of the devices 20_1 to 20_n.
  • a plurality of devices 20_1 to 20_n determine that communication is started when a series of data including a control field CF, a device ID field IDF, a command code field CCF, and a check field CRC are sent from the controller 10. do.
  • a plurality of devices 20_1 to 20_n determine whether the request is addressed to them according to the contents of the control field CF and the contents of the device ID field IDF.
  • the device 20_i determined to correspond to the device specified by the device ID field IDF follows the communication format as shown in FIG. A series of data is sent to the controller 10 including the CCF and the check field CRC.
  • FIG. 12 is an explanatory diagram showing an example of the content of the communication format of the serial communication system 1B according to Embodiment 1 of the present invention.
  • FIG. 12 differs from that shown in FIG. 10 in that it has a device ID field IDF that is device ID information for identifying a plurality of devices.
  • the controller 10 can include command information that instructs the device 20_i to execute latch/release control in the data ID code in the control field CF.
  • the controller 10 can further include the ID of the device instructing the execution of the latch/release control in the device ID field IDF, and the command code related to latch/release in the command code field CCF.
  • the latch-related command code is a command code that instructs latch execution, a target device for latch execution, release execution, and a target device for release execution.
  • the control field CF from the controller 10 is command information indicating the execution of latch/release control
  • the data in the command code field CCF includes a latch/release-related command code
  • the device ID field If the device corresponds to the device instructed to execute latch/release control by the IDF, as shown in FIG. A series of data containing the CRC is sent to the controller 10 .
  • the device 20_i corresponds to the device instructed to execute the latch/release control by the device ID field IDF, the device 20_i has received the latch or release instructed by the controller 10 at the time of the above transmission to the controller 10. is included in the command code field CCF. The device 20_i then executes latching or releasing as instructed by the controller 10 .
  • FIG. 13 is an explanatory diagram showing the format of the command code field CCF in the communication format used in the serial communication systems 1A and 1B according to Embodiment 1 of the present invention.
  • the command code field CCF includes a start bit, a command code field CCF bit, and a delimiter bit.
  • FIG. 14 is an explanatory diagram showing the contents of each bit of the command code field CCF in the communication format used in the serial communication systems 1A and 1B according to Embodiment 1 of the present invention.
  • the start bit is a bit that indicates the start position, and is fixed to "0", for example.
  • the bits of the command code field CCF are, for example, 8 bits and can take 256 different values from 0x00 to 0xFF.
  • the delimiter is a bit indicating the end position, and is fixed to "1", for example.
  • FIG. 15 is an explanatory diagram showing allocation of command codes in the communication format used in the serial communication systems 1A and 1B according to Embodiment 1 of the present invention.
  • a command code 0x00 from the controller 10 is an instruction to execute release for all of the plurality of devices 20_1 to 20_n.
  • a command code 0x00 from the device 20 side indicates acceptance of a release execution instruction for all of the plurality of devices 20_1 to 20_n.
  • a command code 0x55 from the controller 10 is an instruction to execute a release for the device 20_i, which is one of the devices 20_1 to 20_n.
  • a command code 0x55 from the device 20 side indicates acceptance of a release execution instruction for the device 20_i, which is one of the devices 20_1 to 20_n.
  • the command code 0x5F from the device 20 side indicates that one of the devices 20_1 to 20_n, the device 20_i, is latching and holding data. command code is sent from the controller 10.
  • the command code 0x50 from the device 20 side indicates that one of the devices 20_1 to 20_n, the device 20_i, is being released and has released the hold. Sent when a code is sent from the controller 10.
  • a command code 0xAA from the controller 10 is an instruction to execute a latch for the device 20_i among the plurality of devices 20_1 to 20_n.
  • a command code 0xAA from the device 20 side indicates reception of a latch execution instruction to one of the devices 20_1 to 20_n, the device 20_i.
  • a command code 0xFF from the controller 10 is a latch execution instruction for all of the plurality of devices 20_1 to 20_n.
  • a command code 0xFF from the device 20 side indicates acceptance of a latch execution instruction for all of the plurality of devices 20_1 to 20_n.
  • all the devices 20_1 to 20_n operate according to the latch or release instruction.
  • One of the determined devices 20_j may transmit a command code for acceptance to the controller 10 .
  • the communication including the latch and release commands in the single-master/multi-slave serial communication system 1B described above can also be applied to the single-master/single-slave serial communication system 1A.
  • the serial communication system 1A there is only one device 20 and there is no device specification, so the controller 10 and the device 20 may use one of the command codes in FIG.
  • FIG. 16 is a sequence diagram showing communication procedures of the serial communication system 1B according to Embodiment 1 of the present invention.
  • a plurality of devices 20_1 to 20_n are connected in parallel to the controller 10 through bus communication lines 30B.
  • a plurality of devices 20_1 to 20_n are sensing devices, and are configured to be able to latch, detect, and unlatch data on controlled objects. Assume that the device 20_a determined as the representative device is determined to transmit an acceptance to the controller 10 when the controller 10 instructs all devices to execute latch or release.
  • the controller 10 transmits a latch execution instruction to the device 20_m via the bus communication line 30B.
  • the device 20_m receives the latch execution instruction from the controller 10
  • the device 20_m transmits to the controller 10 that it has accepted the instructed latch, and executes the instructed latch, as shown in (b1) of FIG. retains the data detected by
  • the controller 10 After receiving the latch acceptance corresponding to the latch instruction, the controller 10 transmits the request instruction to the device 20_m via the bus communication line 30B, as shown in (a2) of FIG. Upon receiving the request instruction from the controller 10, the device 20_m transmits the data detected from the controlled object to the controller 10 as shown in (b2) of FIG.
  • the controller 10 After acquiring the data in response to the request, the controller 10 transmits a release execution instruction to the device 20_m via the bus communication line 30B, as shown in (a3) of FIG.
  • the device 20_m receives the release execution instruction from the controller 10
  • the device 20_m transmits to the controller 10 that the instructed release has been accepted, and executes the instructed release, as shown in (b3) of FIG. to release the latch.
  • the device 20_a determined as the representative device receives from the controller 10 instructions to execute latching for all of the devices 20_1 to 20_n, as shown in (b4) of FIG. A notification of acceptance is sent to the controller 10, and the instructed latch is executed to hold the detected data.
  • the controller 10 After receiving the latch acceptance from the representative device 20_a in response to the latch instruction for all devices, the controller 10 issues a request to the device 20_a as shown in (a5) of FIG. Instructions are sent via bus communication line 30B. Upon receiving the request instruction from the controller 10, the device 20_a transmits the detected data to the controller 10 as shown in (b5) of FIG.
  • the controller 10 After receiving the data from the device 20_a, the controller 10 transmits a request instruction to the device 20_b via the bus communication line 30B, as shown in (a6) of FIG. Upon receiving the request instruction from the controller 10, the device 20_b transmits the data detected from the controlled object to the controller 10 as shown in (b6) of FIG.
  • the controller 10 After receiving data from the device 20_n-1 in the same way, the controller 10 transmits a request instruction to the device 20_n via the bus communication line 30B, as shown in (a7) of FIG. Upon receiving the request instruction from the controller 10, the device 20_n transmits the data detected from the controlled object to the controller 10 as shown in (b7) of FIG.
  • the controller 10 transmits requests to all of the devices 20_1 to 20_n as described above, and receives data in response to the requests. . . . send a release execution instruction to all of the devices 20_n via the bus communication line 30B.
  • the device 20_a determined as the representative device receives an instruction to execute release for all of the devices 20_1 to 20_n from the controller 10, as shown in (b8) of FIG.
  • the reception is transmitted to the controller 10, the instructed release is executed, and the latch is released.
  • the devices other than the device 20_a also receive instructions from the controller 10 to execute the release for all the devices, and simultaneously execute the instructed releases. Release the latch.
  • the controller 10 transmits the latch command and the release command in the communication format to the plurality of devices 20_1 to 20_n.
  • 20_n can hold the detected data in response to the latch command, and can release the holding of the detected data in response to the release command. Therefore, data can be held and released in the plurality of devices 20_1 to 20_n based on commands from the controller 10 at arbitrary timing.
  • the plurality of devices 20_1 to 20_n simultaneously execute latching according to an instruction from the controller 10, and then transmit data according to an instruction from the controller 10.
  • the transmitted data is in a state of synchronicity.
  • the first embodiment can be applied to applications that require simultaneity of data detected by a plurality of devices 20_1 to 20_n.
  • the first embodiment can be applied.
  • the communication line 30A or the bus communication line 30B uses a pair of RS485 standard SD+ and SD using two equal signal lines for signal transmission.
  • the example is shown assuming communication using differential transmission signals of -, the present invention is not limited to this content.
  • the serial communication systems 1A and 1B according to Embodiment 1 of the present invention may be applied to communications according to the RS422 standard or the RS232 standard.
  • the serial communication systems 1A and 1B according to the first embodiment of the present invention may be applied to communication that does not rely on differential transmission signals.
  • serial communication method of Embodiment 1 an example is shown assuming an asynchronous communication form as serial communication, but the communication form is not limited to this.
  • 1A, 1B serial communication system 10 controller, 20 device (sensing device), 20_1 to 20_n multiple devices (multiple sensing devices), 30A communication line, 30B bus communication line.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Systems (AREA)

Abstract

シリアル通信機能を有するコントローラ（１０）と、シリアル通信機能を有する１以上のセンシングデバイス（２０）とを有し、コントローラ（１０）は、センシングデバイス（２０）に対して、検知したデータの保持を指示するラッチコマンドと、検知したデータの保持の解除を指示するリリースコマンドとをセンシングデバイス（２０）に対して送信し、センシングデバイス（２０）は、ラッチコマンドに応じて検知したデータを保持し、リリースコマンドに応じて検知したデータの保持を解除する。

Description

シリアル通信方法及びシリアル通信システム
　この発明は、シリアル通信方法及びシリアル通信システムに関し、特に、マスタデバイスからスレーブデバイスに対してラッチとリリースとを命じるシリアル通信方法及びシリアル通信システムに関する。
［関連出願の相互参照］
　本出願には、２０１９年１１月２７日に日本国において出願された「シリアル通信方法及びシリアル通信システム」と題された日本国特許出願２０１９－２１３７８２号の明細書の全体及び利益が参照により組み込まれる。
　マスタデバイスとスレーブデバイスとの間、具体的には、コントローラとセンシングデバイスとの間で、シリアル通信によりコマンドとデータとを授受することが一般的に行われている。このような構成のシリアル通信システムは、特許文献１及び非特許文献１に記載されている。
特開２００４－３１７２６１号公報
「ロータリーエンコーダ FA-CORDER(R)」（カタログ番号：T12-1228N58）、多摩川精機株式会社、2018年9月発行
　センシングデバイスからデータを確実に取得するため、あるタイミングでデータを保持し、保持したデータを取得する手法が存在する。また、保持したデータを二度読みして、二度読みの結果が一致するデータを採用する手法が存在している。このデータの保持はラッチと呼ばれ、データの保持を解除することはリリースと呼ばれている。
　上記特許文献１には、単一のコントローラにバスを通じて複数のセンシングデバイスが接続されたシングルマスタ／マルチスレーブ接続システムにおける、シングルマスタ／マルチスレーブ通信の技術が開示されている。しかし、センシングデバイスにおいてデータのラッチ（保持）／リリース（保持の解除）を実行する機能については言及されていない。
　上記非特許文献１には、単一のコントローラにバスを通じて単一のセンシングデバイスが接続されたシングルマスタ／シングルスレーブ接続システムにおける、シングルマスタ／シングルスレーブ通信の技術が開示されている。しかし、センシングデバイスにおいてデータのラッチ（保持）／リリース（保持の解除）を実行する機能については言及されていない。
　従って、シングルマスタ／シングルスレーブ接続システムにおけるシリアル通信システムと、シングルマスタ／マルチスレーブ接続システムにおけるシリアル通信システムとのいずれであっても、任意のタイミングでデータのラッチとリリースとを行えることが望まれている。
　本発明は、コントローラからのコマンドに基づいて、センシングデバイスにおいてデータの保持と解除とを任意のタイミングで行うことが可能なシリアル通信方法及びシリアル通信システムを提供することを目的とする。
　（１）この発明に係るシリアル通信方法及びシリアル通信システムは、シリアル通信機能を有するコントローラと、シリアル通信機能を有する１以上のセンシングデバイスとの間で、通信フォーマットに従ってシリアル通信を行う際に、コントローラは、センシングデバイスに対して検知したデータの保持を指示するラッチコマンドと、センシングデバイスに対して検知したデータの保持の解除を指示するリリースコマンドとを通信フォーマット中に含めて、センシングデバイスに対して送信し、センシングデバイスは、コントローラからのラッチコマンドに応じ、検知したデータを保持し、コントローラからのリリースコマンドに応じ、検知したデータの保持を解除する。
　（２）この発明に係るシリアル通信方法及びシリアル通信システムにおいて、センシングデバイスは、コントローラからのラッチコマンドに応じ、保持の指示を受け付けたことを示すコマンドをコントローラに対して送信し、コントローラからのリリースコマンドに応じ、保持の解除の指示を受け付けたことを示すコマンドをコントローラに対して送信する。
　（３）この発明に係るシリアル通信方法及びシリアル通信システムにおいて、コントローラは、センシングデバイスに対して状態を問い合わせる問い合わせコマンドを通信フォーマット中に含めて、センシングデバイスに対して送信し、センシングデバイスは、コントローラからの問い合わせコマンドに応じ、データを保持していることを示すコマンド、または、保持を解除したことを示すコマンドをコントローラに対して送信する。
　（４）この発明に係るシリアル通信方法及びシリアル通信システムにおいて、コントローラは、センシングデバイスに対してラッチコマンドとリリースコマンドとを送信する際に、センシングデバイスのいずれかを指定するセンシングデバイスＩＤを含め、センシングデバイスＩＤにより指定されたセンシングデバイスは、コントローラからのラッチコマンドに応じ、検知したデータを保持し、コントローラからのリリースコマンドに応じ、検知したデータの保持を解除する。指定されていないセンシングデバイスＩＤであっても、コントローラから全センシングデバイスを指定したラッチコマンドまたはリリースコマンドが送信された場合、全てのセンシングデバイスは、検知したデータをラッチコマンドに応じて保持し、検知したデータの保持をリリースコマンドに応じて解除する。
　（５）この発明に係るシリアル通信方法及びシリアル通信システムにおいて、コントローラがマスタデバイス、センシングデバイスがスレーブデバイスであり、マスタデバイスとスレーブデバイスとの間でシリアル通信を行う。
　（６）この発明に係るシリアル通信方法及びシリアル通信システムにおいて、センシングデバイスは、コントローラからのリクエストに応じ、保持したデータを前記コントローラに対して送信する。
　この発明に係るシリアル通信方法及びシリアル通信システムによれば、コントローラは、ラッチコマンドとリリースコマンドとを通信フォーマット中に含めてセンシングデバイスに対して送信し、センシングデバイスは、ラッチコマンドに応じて検知したデータを保持し、リリースコマンドに応じて検知したデータの保持を解除するため、任意のタイミングで、コントローラからのコマンドに基づいて、センシングデバイスにおいてデータの保持と解除とを行うことが可能になる。
本発明の実施の形態１におけるシリアル通信システムの構成を示す構成図である。 本発明の実施の形態１におけるシリアル通信システムの構成を示す構成図である。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットを示すタイミングチャートである。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットの内容の一例を示す説明図である。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットを示すタイミングチャートである。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットの内容の一例を示す説明図である。 本発明の実施の形態１におけるシリアル通信システムで用いられる通信フォーマット中のコントロールフィールドのフォーマットを示す説明図である。 本発明の実施の形態１におけるシリアル通信システムで用いられる通信フォーマット中のコントロールフィールドの内容を示す説明図である。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットを示すタイミングチャートである。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットの内容の一例を示す説明図である。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットを示すタイミングチャートである。 本発明の実施の形態１におけるシリアル通信システムの通信フォーマットの内容の一例を示す説明図である。 本発明の実施の形態１におけるシリアル通信システムで用いられる通信フォーマット中のコマンドコードフィールドのフォーマットを示す説明図である。 本発明の実施の形態１におけるシリアル通信システムで用いられる通信フォーマット中のコマンドコードフィールドの内容を示す説明図である。 本発明の実施の形態１におけるシリアル通信システムで用いられる通信フォーマット中のコマンドコードの割り当てを示す説明図である。 本発明の実施の形態１におけるシリアル通信システムの通信手順を示すシーケンス図である。
　以下、本発明のシリアル通信システムの実施の形態について、図面を用いて説明する。なお、各図において、同一部分には同一符号を付している。
　実施の形態１．
　はじめに、本発明の実施の形態１において、シリアル通信方法を実行するシリアル通信システムの基本的な構成について、図１を参照して説明する。
　［シリアル通信システム１Ａの構成］
　図１は、本発明の実施の形態１におけるシリアル通信システム１Ａの構成を示す構成図である。図１において、シリアル通信方法を実行するシリアル通信システム１Ａは、コントローラ１０と、デバイス２０と、通信ライン３０Ａとを備えている。コントローラ１０はマスタデバイス、デバイス２０はスレーブデバイスとして、通信ライン３０Ａを通して通信可能に接続されている。
　ここで、図１に示すシリアル通信システム１Ａは、単一のコントローラ１０に対して、通信ライン３０Ａを通して単一のデバイス２０が接続されており、シングルマスタ／シングルスレーブ接続のシリアル通信システムを構成している。
　シングルマスタ／シングルスレーブ接続のシリアル通信システム１Ａにおいて、コントローラ１０とデバイス２０との間で、シングルマスタ／シングルスレーブ通信が行われる。すなわち、マスタデバイスであるコントローラ１０とスレーブデバイスであるデバイス２０との間で、シリアル通信によりコマンドとデータとが送受信される。
　コントローラ１０は、シリアル通信機能を備えており、シリアル通信によりデバイス２０からデータを読み出す制御部である。デバイス２０は、シリアル通信機能を備えたセンシングデバイスであり、例えば、制御対象から検知したデータをシリアル通信により出力するセンシングデバイスに該当する。
　通信ライン３０Ａは、電源Ｖｃｃを供給する信号線と、グランドＧＮＤの電位を保つ信号線と、一対の差動伝送信号ＳＤ＋／ＳＤ－を伝送する信号線とによって構成されている。
　電源Ｖｃｃは、信号線を通してコントローラ１０からデバイス２０に供給される。差動伝送信号ＳＤ＋／ＳＤ－は、信号線を通して双方向に伝送されるものであり、コントローラ１０からデバイス２０に向けて送信される場合と、デバイス２０からコントローラ１０に向けて送信される場合とがある。
　［シリアル通信システム１Ｂの構成］
　次に、本発明の実施の形態１において、シリアル通信方法を実行するシリアル通信システム１Ｂの基本的な構成について、図２を参照して説明する。図２は、本発明の実施の形態１におけるシリアル通信システム１Ｂの構成を示す構成図である。
　図２において、シリアル通信システム１Ｂは、主に、コントローラ１０と、デバイス２０と、バス通信ライン３０Ｂとを備えている。コントローラ１０はマスタデバイス、デバイス２０はスレーブデバイスとして、バス通信ライン３０Ｂを通して通信可能に接続されている。スレーブデバイスとしてのデバイス２０は、複数のデバイス２０_1、デバイス２０_2、…、デバイス２０_nを備えて構成される。
　ここで、図２に示すシリアル通信システム１Ｂは、単一のコントローラ１０に対して、複数のデバイス２０、すなわち、デバイス２０_1、デバイス２０_2、…、デバイス２０_nが、バス通信ライン３０Ｂを通して並列に接続されている。これにより、シングルマスタ／マルチスレーブ接続のシリアル通信システムが構成されている。
　シングルマスタ／マルチスレーブ接続のシリアル通信システム１Ｂにおいて、コントローラ１０とデバイス２０との間で、シングルマスタ／マルチスレーブ通信が行われる。すなわち、マスタデバイスであるコントローラ１０とスレーブデバイスである複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iとの間で、シリアル通信によりコマンドとデータとを送受信される。
　複数のデバイス２０_1、デバイス２０_2、…、デバイス２０_nを識別するため、後述するデバイスＩＤがそれぞれ付与されている。このデバイスＩＤは、１，２，３，…,ｎといった順番に従った番号でもよいし、製品の製造番号の全部または一部、ネットワークアドレス、あるいは任意に設定された番号であってもよい。
　コントローラ１０は、このデバイスＩＤによって、複数のデバイス２０_1、デバイス２０_2、…、デバイス２０_nを識別し、いずれかまたは全てを指定することができる。複数のデバイス２０_1、デバイス２０_2、…、デバイス２０_n側は、このデバイスＩＤによって、コントローラ１０からの各種指示が自分宛か否かを判別することができる。
　［通信フォーマットの説明（１）］
　次に、本発明の実施の形態１のシリアル通信システム１Ａにおいて実行されるシリアル通信方法の通信フォーマットを図３及び図４を参照して説明する。また、本発明の実施の形態１のシリアル通信システム１Ｂにおいて実行されるシリアル通信方法の通信フォーマットについて図５及び図６を参照して説明する。
　図３は、本発明の実施の形態１におけるシリアル通信システム１Ａの通信フォーマットを示すタイミングチャートである。図４は、本発明の実施の形態１におけるシリアル通信システム１Ａの通信フォーマットの内容の一例を示す説明図である。
　まず、シングルマスタ／シングルスレーブ接続のシリアル通信システム１Ａにおける通信の様子を、図３を参照して説明する。図３の（ａ）は、シングルマスタ／シングルスレーブ接続のシリアル通信システム１Ａにおける、コントローラ１０からデバイス２０に対するリクエストの送信を示している。ここで、コントローラ１０が送信するリクエストとは、後述するように、デバイス２０に対するデータの要求を意味する。
　コントローラ１０は、先行するデータフレームの最終部分から１データフレーム分以上のアイドル状態が存在するか否かを監視しており、先行するデータフレームの最終部分から１データフレーム分以上のアイドル状態が継続した後に、コントロールフィールドＣＦをリクエストとしてデバイス２０に対して送信する。なお、１データフレームとは、デバイス２０からコントローラ１０に向けて送信される一連のデータの単位である。
　図３の（ｂ）は、シングルマスタ／シングルスレーブ接続のシリアル通信システム１Ａにおける、デバイス２０がコントローラ１０に向けて送信するデータの通信フォーマットを示している。
　デバイス２０は、１データフレーム分以上のアイドル状態が継続した後に、リクエストとしてコントロールフィールドＣＦが送られてくることで、通信開始であると判断する。これにより、デバイス２０は、他の通信に対して誤って通信開始と判断することを回避している。
　デバイス２０は、コントローラ１０からコントロールフィールドＣＦがリクエストとして送られてくると、通信フォーマットに従ってコントローラ１０に対して、シリアル通信によりデータを送信する。デバイス２０は、センシングデバイスであり、制御対象から検知したデータをコントローラ１０に対して送信する。
　デバイス２０は、図３の（ｂ）に示されるように、通信フォーマットに従い、コントロールフィールドＣＦ、ステータスフィールドＳＦ、データフィールドＤＦ０～ＤＦｎ、及び検査フィールドＣＲＣが含まれる一連のデータをコントローラ１０へ送信する。
　図４は、図３の（ａ）及び（ｂ）のタイミングチャートに示されるデータの各フィールドの内容を示している。コントロールフィールドＣＦは、通信相手方へのコマンド情報である。ステータスフィールドＳＦは、デバイスの状態識別情報である。データフィールドＤＦ０～ＤＦｎは、データＩＤに割り振られた情報である。検査フィールドＣＲＣは、ＣＲＣフィールド以外の全てのフィールドのスタートビットとデリミッタとを除く全てのビットに対するＣＲＣ（Cyclic Redundancy Check：巡回冗長検査）による誤り検査情報である。
　次に、シングルマスタ／マルチスレーブ接続のシリアル通信システム１Ｂにおける、通信の様子を説明する。
　図５の（ａ）は、シングルマスタ／マルチスレーブ接続のシリアル通信システム１Ｂにおける、コントローラ１０から複数のデバイス２０_1～デバイス２０_nのうちのいずれかに対するリクエストの送信を示している。ここで、コントローラ１０が送信するリクエストとは、デバイス２０に対するデータの要求を意味する。
　コントローラ１０は、上述した説明と同様に、先行するデータフレームの最終部分から１データフレーム分以上のアイドル状態が継続した後に、コントロールフィールドＣＦとデバイスＩＤフィールドＩＤＦを、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iへのリクエストとして送信する。
　図５の（ｂ）は、シングルマスタ／マルチスレーブ接続のシリアル通信システム１Ｂにおける、デバイス２０がコントローラ１０に向けて送信するデータの通信フォーマットを示している。
　複数のデバイス２０_1～デバイス２０_nは、１データフレーム分以上のアイドル状態が継続した後に、リクエストとしてコントロールフィールドＣＦとデバイスＩＤフィールドＩＤＦとが送られてくることで、通信開始であると判断する。
　複数のデバイス２０_1～デバイス２０_nは、コントローラ１０からコントロールフィールドＣＦとデバイスＩＤフィールドＩＤＦとがリクエストとして送られてくると、コントロールフィールドＣＦの内容とデバイスＩＤフィールドＩＤＦの内容とに応じて、自分宛のリクエストであるかを判別する。
　コントローラ１０からのリクエストが自分宛であると判別したデバイス２０_iは、データを通信フォーマットに従ってコントローラ１０に対してシリアル通信によりデータを送信する。デバイス２０_iはセンシングデバイスであり、制御対象から検知したデータをコントローラ１０に対して送信する。
　デバイス２０_iは、図５の（ｂ）に示されるように、通信フォーマットに従い、コントロールフィールドＣＦ、デバイスＩＤフィールドＩＤＦ、ステータスフィールドＳＦ、データフィールドＤＦ０～ＤＦｎ、及び検査フィールドＣＲＣが含まれる一連のデータをコントローラ１０へ送信する。
　以上の図５の（ａ）及び（ｂ）のタイミングチャートに示されるデータの各フィールドの内容を、図６を参照して説明する。図６は、本発明の実施の形態１におけるシリアル通信システム１Ｂの通信フォーマットの内容の一例を示す説明図である。図６は、図４に示したものと異なり、複数のデバイスを識別するデバイスＩＤ（identification）の情報であるデバイスＩＤフィールドＩＤＦを更に有している。
　次に、本発明の実施の形態１におけるシリアル通信で用いられる通信フォーマット中のコントロールフィールドＣＦについて、図７と図８を参照して説明する。
　図７は、本発明の実施の形態１におけるシリアル通信システム１Ａ及び１Ｂで用いられる通信フォーマット中のコントロールフィールドＣＦのフォーマットを示す説明図である。コントロールフィールドＣＦは、スタートビット、ＳＹＮＣ（Synchronous）コードのビット、データＩＤコードのビット、データＩＤパリティのビット、及びデリミッタのビットが含まれている。
　図８は、本発明の実施の形態１におけるシリアル通信システム１Ａ及び１Ｂで用いられる通信フォーマット中のコントロールフィールドＣＦの各ビットの内容を示す説明図である。
　スタートビットは、開始位置を示すビットであり、例えば、“０”に固定されている。ＳＹＮＣコードは、同期に用いられる予め定められたコードであり、“０”と“１”を所定回数繰り返す。この実施の形態１において、ＳＹＮＣコードは、シングルマスタ／シングルスレーブ通信を行う場合は第１のＳＹＮＣコード“０１０”、シングルマスタ／マルチスレーブ通信を行う場合は第２のＳＹＮＣコード“１０１”が割り当てられる。
　データＩＤコードは、通信内容を選択するため、通信データや動作命令を割り当てられたコードである。データＩＤコードには、データを保持するラッチ、及び、ラッチを解除するリリースを実行するため、ラッチ／リリース制御実行ＩＤを割り当てておくことができる。データＩＤパリティは、データＩＤコードに対するパリティチェックのビットである。デリミッタは、終了位置を示すビットであり、例えば、“１”に固定されている。
　以上のコントロールフィールドＣＦ中ＳＹＮＣコードによって、シリアル通信システム１Ａ及び１Ｂにおいて、シングルマスタ／シングルスレーブ通信とシングルマスタ／マルチスレーブ通信のどちらを行うかが決定される。また、ＳＹＮＣコードは、“０１０”と“１０１”のいずれであっても、本来の同期の用途にも使用される。
　シングルマスタ／シングルスレーブ通信において、デバイス２０は、コントロールフィールドＣＦを受信した後、データＩＤコードに応じたデータの返信または各種の動作を実行する。
　シングルマスタ／マルチスレーブ通信において、コントロールフィールドＣＦに続いてデバイスＩＤフィールドＩＤＦがコントローラ１０から送信されると、該当するデバイスＩＤを有するデバイス２０_iは、データＩＤコードに応じたデータの返信または各種の動作を実行する。
　［通信フォーマットの説明（２）］
　次に、コントローラ１０からの指示により、デバイス２０においてデータのラッチとリリースとを実行するコマンドを含む通信フォーマットを、図９～図１２を参照して説明する。なお、ラッチとは、フリップフロップ回路におけるラッチだけでなく、各種の回路においてデータを保持することを意味する。リリースとは、各種の回路においてラッチによるデータの保持を解除することを意味する。
　図９は、本発明の実施の形態１におけるシリアル通信システム１Ａの通信フォーマットを示すタイミングチャートである。図１０は、本発明の実施の形態１におけるシリアル通信システム１Ａの通信フォーマットの内容の一例を示す説明図である。図９及び図１０において、既に説明した図３及び図４と同一物には同一番号を付すことで重複した説明を省略し、図３及び図４とは異なる部分を中心に説明する。
　まず、シングルマスタ／シングルスレーブ接続のシリアル通信システム１Ａにおける、ラッチとリリースのコマンドを含む通信の様子を、図９を参照して説明する。
　コントローラ１０は、図９の（ａ）に示すように、先行するデータフレームの最終部分から１データフレーム分以上のアイドル状態が継続した後に、コントロールフィールドＣＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータを、デバイス２０に対して送信する。
　デバイス２０は、コントロールフィールドＣＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータがコントローラ１０から送られてくることで、通信開始であると判断する。デバイス２０は、図９の（ｂ）に示されるように、通信フォーマットに従い、コントロールフィールドＣＦ、ステータスフィールドＳＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータをコントローラ１０へ送信する。
　図１０は、図９の（ａ）及び（ｂ）のタイミングチャートに示されるデータの各フィールドの内容を示している。コントロールフィールドＣＦは、通信相手方へのコマンド情報である。ステータスフィールドＳＦは、デバイスの状態識別情報である。コマンドコードフィールドＣＣＦは、ラッチまたはリリースに関する命令、受け付けを示すコマンドコードである。検査フィールドＣＲＣは、ＣＲＣフィールド以外の全てのフィールドのスタートビットとデリミッタとを除く全てのビットに対するＣＲＣ（Cyclic Redundancy Check：巡回冗長検査）による誤り検査情報である。
　コントローラ１０は、コントロールフィールドＣＦ中のデータＩＤコードに、デバイス２０に対してラッチ／リリース制御の実行を指示するコマンド情報を含めることができる。コントローラ１０は、更に、コマンドコードフィールドＣＣＦ中のデータに、ラッチ／リリース関連のコマンドコードとして、ラッチ実行、リリース実行、を指示するコマンドコードを含めることができる。
　デバイス２０は、コントローラ１０からのコントロールフィールドＣＦがラッチ／リリース制御の実行を指示するコマンド情報であり、かつ、コマンドコードフィールドＣＣＦ中にラッチ／リリース関連のコマンドコードが含まれる場合、図９の（ｂ）に示されるように、通信フォーマットに従い、コントロールフィールドＣＦ、ステータスフィールドＳＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータをコントローラ１０へ送信する。
　デバイス２０は、以上のコントローラ１０への送信の際に、コントローラ１０から指示されたラッチまたはリリースを受け付けたことを示すコマンドコードをコマンドコードフィールドＣＣＦ中に含めるようにする。そして、デバイス２０は、コントローラ１０から指示されたラッチまたはリリースを実行する。
　次に、シングルマスタ／マルチスレーブ接続のシリアル通信システム１Ｂにおける、ラッチとリリースのコマンドを含む通信の様子を、図１１を参照して説明する。図１１は、本発明の実施の形態１におけるシリアル通信システム１Ｂの通信フォーマットを示すタイミングチャートである。
　コントローラ１０は、図１１の（ａ）に示すように、先行するデータフレームの最終部分から１データフレーム分以上のアイドル状態が継続した後に、コントロールフィールドＣＦ、デバイスＩＤフィールドＩＤＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータを、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iに対して送信する。
　複数のデバイス２０_1～デバイス２０_nは、コントロールフィールドＣＦ、デバイスＩＤフィールドＩＤＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータがコントローラ１０から送られてくることで、通信開始であると判断する。
　複数のデバイス２０_1～デバイス２０_nは、コントロールフィールドＣＦの内容とデバイスＩＤフィールドＩＤＦの内容とに応じて、自分宛のリクエストであるかを判別する。デバイスＩＤフィールドＩＤＦによって指定されたデバイスに該当すると判別したデバイス２０_iは、図１１の（ｂ）に示されるように、通信フォーマットに従い、コントロールフィールドＣＦ、デバイスＩＤフィールドＩＤＦ、ステータスフィールドＳＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータをコントローラ１０へ送信する。
　以上の図１１の（ａ）及び（ｂ）のタイミングチャートに示されるデータの各フィールドの内容について、図１２を参照して説明する。図１２は、本発明の実施の形態１におけるシリアル通信システム１Ｂの通信フォーマットの内容の一例を示す説明図である。図１２は、図１０に示したものと異なり、複数のデバイスを識別するデバイスＩＤの情報であるデバイスＩＤフィールドＩＤＦを有している。
　コントローラ１０は、コントロールフィールドＣＦ中のデータＩＤコードに、デバイス２０_iに対してラッチ／リリース制御の実行を指示するコマンド情報を含めることができる。そして、コントローラ１０は、更に、デバイスＩＤフィールドＩＤＦにラッチ／リリース制御の実行を指示するデバイスのＩＤを含め、コマンドコードフィールドＣＣＦにラッチ／リリース関連のコマンドコードを含めることができる。ここで、ラッチ関連のコマンドコードとは、ラッチ実行、ラッチ実行の対象デバイス、リリース実行、リリース実行の対象デバイス、を指示するコマンドコードである。
　デバイス２０_iは、コントローラ１０からのコントロールフィールドＣＦがラッチ／リリース制御の実行を指示するコマンド情報であり、コマンドコードフィールドＣＣＦ中のデータにラッチ／リリース関連のコマンドコードが含まれ、かつ、デバイスＩＤフィールドＩＤＦによりラッチ／リリース制御の実行を指示されたデバイスに該当する場合、図１１の（ｂ）に示されるように、通信フォーマットに従い、コントロールフィールドＣＦ、ステータスフィールドＳＦ、コマンドコードフィールドＣＣＦ、及び検査フィールドＣＲＣが含まれる一連のデータをコントローラ１０へ送信する。
　デバイス２０_iは、デバイスＩＤフィールドＩＤＦによりラッチ／リリース制御の実行を指示されたデバイスに該当する場合、以上のコントローラ１０への送信の際に、コントローラ１０から指示されたラッチまたはリリースの受付をしたことを示すコマンドコードをコマンドコードフィールドＣＣＦ中に含めるようにする。そして、デバイス２０_iは、コントローラ１０から指示されたラッチまたはリリースを実行する。
　次に、本発明の実施の形態１におけるシリアル通信で用いられる通信フォーマット中のコマンドコードフィールドＣＣＦについて、図１３と図１４を参照して説明する。図１３は、本発明の実施の形態１におけるシリアル通信システム１Ａ及び１Ｂで用いられる通信フォーマット中のコマンドコードフィールドＣＣＦのフォーマットを示す説明図である。コマンドコードフィールドＣＣＦは、スタートビット、コマンドコードフィールドＣＣＦのビット、及びデリミッタのビットが含まれている。
　図１４は、本発明の実施の形態１におけるシリアル通信システム１Ａ及び１Ｂで用いられる通信フォーマット中のコマンドコードフィールドＣＣＦの各ビットの内容を示す説明図である。スタートビットは、開始位置を示すビットであり、例えば、“０”に固定されている。コマンドコードフィールドＣＣＦのビットは、例えば、８ビットであり、０ｘ００～０ｘＦＦの２５６通りの値をとりうる。デリミッタは、終了位置を示すビットであり、例えば、“１”に固定されている。
　次に、本発明の実施の形態１におけるシリアル通信で用いられる通信フォーマット中のコマンドコードフィールドＣＣＦの具体的なコード内容を、図１５を参照して説明する。図１５は、本発明の実施の形態１におけるシリアル通信システム１Ａ及び１Ｂで用いられる通信フォーマット中のコマンドコードの割り当てを示す説明図である。
　図１５に示すコマンドコードの割り当ては、一例として以下の通りである。
コントローラ１０からのコマンドコード０ｘ００は、複数のデバイス２０_1～デバイス２０_nの全てに対するリリース実行の指示である。
　デバイス２０側からのコマンドコード０ｘ００は、複数のデバイス２０_1～デバイス２０_nの全てに対するリリース実行指示の受付を示している。
　コントローラ１０からのコマンドコード０ｘ５５は、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iに対するリリース実行の指示である。
　デバイス２０側からのコマンドコード０ｘ５５は、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iに対するリリース実行指示の受付を示している。
　デバイス２０側からのコマンドコード０ｘ５Ｆは、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iがラッチ中でありデータを保持していることを示しており、特定の問い合わせコマンドコードあるいは未指定のコマンドコードがコントローラ１０から送られてきた場合に送信する。
　デバイス２０側からのコマンドコード０ｘ５０は、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iがリリース中であり保持を解除したことを示しており、特定の問い合わせコマンドコードあるいは未指定のコマンドコードがコントローラ１０から送られてきた場合に送信する。
　コントローラ１０からのコマンドコード０ｘＡＡは、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iに対するラッチ実行の指示である。
　デバイス２０側からのコマンドコード０ｘＡＡは、複数のデバイス２０_1～デバイス２０_nのうちのいずれかのデバイス２０_iに対するラッチ実行指示の受付を示している。
　コントローラ１０からのコマンドコード０ｘＦＦは、複数のデバイス２０_1～デバイス２０_nの全てに対するラッチ実行の指示である。
　デバイス２０側からのコマンドコード０ｘＦＦは、複数のデバイス２０_1～デバイス２０_nの全てに対するラッチ実行指示の受付を示している。
　以上の場合において、複数のデバイス２０_1～デバイス２０_nの全てに対してラッチまたはリリースの指示が出された場合、全てのデバイス２０_1～デバイス２０_nがラッチまたはリリースの指示に応じて動作するが、代表として定められたいずれかのデバイス２０_jが受付のコマンドコードをコントローラ１０に送信すればよい。
　以上の場合において、指定されていないデバイスＩＤがデバイスＩＤフィールドＩＤＦにおいて指示され、全てのデバイス２０_1～２０_nを指定したラッチコマンドまたはリリースコマンドがコントローラ１０から送信された場合、全てのデバイス２０_1～２０_nがラッチコマンドまたはリリースコマンドの指示に応じて動作する。
　なお、以上のシングルマスタ／マルチスレーブ接続のシリアル通信システム１Ｂにおけるラッチとリリースのコマンドを含む通信については、シングルマスタ／シングルスレーブのシリアル通信システム１Ａに対しても適用することができる。シリアル通信システム１Ａの場合は、デバイス２０が単一であってデバイスの指定が存在していなため、コントローラ１０とデバイス２０は図１５中のいずれかのコマンドコードを使用すればよい。
　［シリアル通信システム１Ｂにおける通信手順］
　次に、本発明の実施の形態１のシリアル通信システム１Ｂにおいて実行されるシリアル通信方法の通信手順について、図１６を参照しながら説明する。図１６は、本発明の実施の形態１におけるシリアル通信システム１Ｂの通信手順を示すシーケンス図である。
　ここで、シリアル通信システム１Ｂは、コントローラ１０に対して、複数のデバイス２０_1～デバイス２０_nがバス通信ライン３０Ｂを通して並列に接続されている。複数のデバイス２０_1～デバイス２０_nは、センシングデバイスであり、制御対象についてのデータをラッチし、検知し、リリースによりラッチを解除することが可能に構成されている。コントローラ１０から全てのデバイスに対するラッチまたはリリース実行の指示があった場合、代表デバイスとして定められたデバイス２０_aが、受付をコントローラ１０に対して送信するように定められている場合を想定する。
　まず、コントローラ１０は、図１６の（ａ１）に示すように、デバイス２０_mに対するラッチ実行の指示を、バス通信ライン３０Ｂ経由で送信する。
　デバイス２０_mは、コントローラ１０からのラッチ実行の指示を受信すると、図１６の（ｂ１）に示すように、指示されたラッチの受付をしたことをコントローラ１０へ送信し、指示されたラッチを実行して検知したデータを保持する。
　コントローラ１０は、ラッチの指示に応じたラッチ受付を受信した後、デバイス２０_mに対して、図１６の（ａ２）に示すように、リクエストの指示をバス通信ライン３０Ｂ経由で送信する。
　デバイス２０_mは、コントローラ１０からのリクエストの指示を受信すると、図１６の（ｂ２）に示すように、制御対象から検知したデータをコントローラ１０に対して送信する。
　コントローラ１０は、リクエストに応じてデータを取得した後、図１６の（ａ３）に示すように、デバイス２０_mに対するリリース実行の指示を、バス通信ライン３０Ｂ経由で送信する。
　デバイス２０_mは、コントローラ１０からのリリース実行の指示を受信すると、図１６の（ｂ３）に示すように、指示されたリリースの受付をしたことをコントローラ１０へ送信し、指示されたリリースを実行してラッチを解除する。
　コントローラ１０は、図１６の（ａ４）に示すように、複数のデバイス２０_1～デバイス２０_nの全てのデバイスに対するラッチ実行の指示を、バス通信ライン３０Ｂ経由で送信する。
　代表デバイスとして定められたデバイス２０_aは、コントローラ１０からの複数のデバイス２０_1～デバイス２０_nの全てのデバイスに対するラッチ実行の指示を受信すると、図１６の（ｂ４）に示すように、指示されたラッチの受付をしたことをコントローラ１０へ送信し、指示されたラッチを実行して検知したデータを保持する。
　また、以上のデバイス２０_aのラッチ実行と並行して、デバイス２０_a以外の他のデバイスも、コントローラ１０からの全てのデバイスに対するラッチ実行の指示を受信し、指示されたラッチを一斉に実行して検知したデータを保持する。
　コントローラ１０は、全てのデバイスに対するラッチの指示に対して、代表と定められたデバイス２０_aからのラッチ受付を受信した後、図１６の（ａ５）に示すように、デバイス２０_aに対して、リクエストの指示をバス通信ライン３０Ｂ経由で送信する。
　デバイス２０_aは、コントローラ１０からのリクエストの指示を受信すると、図１６の（ｂ５）に示すように、検知したデータをコントローラ１０に対して送信する。
　コントローラ１０は、デバイス２０_aからデータを受信した後、図１６の（ａ６）に示すように、デバイス２０_bに対して、リクエストの指示をバス通信ライン３０Ｂ経由で送信する。
　デバイス２０_bは、コントローラ１０からのリクエストの指示を受信すると、図１６の（ｂ６）に示すように、制御対象から検知したデータをコントローラ１０に対して送信する。
　コントローラ１０は、同様にしてデバイス２０_n-1からデータを受信した後、図１６の（ａ７）に示すように、デバイス２０_nに対して、リクエストの指示をバス通信ライン３０Ｂ経由で送信する。
　デバイス２０_nは、コントローラ１０からのリクエストの指示を受信すると、図１６の（ｂ７）に示すように、制御対象から検知したデータをコントローラ１０に対して送信する。
　コントローラ１０は、以上のようにして複数のデバイス２０_1～デバイス２０_nの全て対してリクエストを送信し、リクエストに応じてデータを受信した後、図１６の（ａ８）に示すように、複数のデバイス２０_1～デバイス２０_nの全てに対するリリース実行の指示を、バス通信ライン３０Ｂ経由で送信する。
　代表デバイスとして定められたデバイス２０_aは、コントローラ１０からの複数のデバイス２０_1～デバイス２０_nの全てのデバイスに対するリリース実行の指示を受信すると、図１６の（ｂ８）に示すように、指示されたリリースの受付をしたことをコントローラ１０へ送信し、指示されたリリースを実行してラッチを解除する。
　また、以上のデバイス２０_aのリリース実行と並行して、デバイス２０_a以外の他のデバイスも、コントローラ１０からの全てのデバイスに対するリリース実行の指示を受信し、それぞれ指示されたリリースを一斉に実行してラッチを解除する。
　以上の図１６のシーケンス図を用いた説明では、複数のデバイス２０_1～デバイス２０_nが存在する場合を具体例にしたが、単一のデバイス２０の場合であっても、以上の説明と同様に、ラッチ、データ送信、リリースを実行することが可能である。
　本実施の形態１によれば、任意のタイミングで、コントローラ１０は、ラッチコマンドとリリースコマンドとを通信フォーマット中に含めて複数のデバイス２０_1～デバイス２０_nに対して送信し、複数のデバイス２０_1～デバイス２０_nは、ラッチコマンドに応じて検知したデータを保持し、リリースコマンドに応じて検知したデータの保持を解除することができる。
　このため、任意のタイミングで、コントローラ１０からのコマンドに基づいて、複数のデバイス２０_1～デバイス２０_nにおいてデータの保持と解除とを行うことが可能になる。
　以上のように、複数のデバイス２０_1～デバイス２０_nは、コントローラ１０からの指示により一斉にラッチを実行し、その後にコントローラ１０からの指示によりデータを送信することで、複数のデバイス２０_1～デバイス２０_nから送信されたデータは同時性を有する状態になっている。
　従って、複数のデバイス２０_1～デバイス２０_nで検知されたそれぞれのデータに同時性を必要とするアプリケーションに対して、本実施の形態１を適用することが可能になる。
　また、複数のデバイス２０_1～デバイス２０_nは、コントローラ１０からの指示により一斉にラッチを実行しているため、複数のデバイス２０_1～デバイス２０_nにおいてデータを二度読みして一致を確認するアプリケーションに対して、本実施の形態１を適用することが可能になる。
　［その他の実施の形態］
　以上の実施の形態１のシリアル通信システム１Ａ及び１Ｂの説明では、通信ライン３０Ａまたはバス通信ライン３０Ｂにおいて、信号伝送するための２本の対等な信号線を用いたＲＳ４８５規格の一対のＳＤ＋とＳＤ－の差動伝送信号による通信を想定した例として示しているが、本発明はこの内容に限定されるものではない。例えば、本発明の実施の形態１のシリアル通信システム１Ａ及び１ＢをＲＳ４２２規格やＲＳ２３２規格による通信に適用してもよい。また、本発明の実施の形態１のシリアル通信システム１Ａ及び１Ｂを差動伝送信号によらない通信に適用してもよい。
　以上の実施の形態１のシリアル通信方法の説明では、通信フォーマットおよび内部のフィールド構成、ビット構成、及びコマンドコードなどの具体例を説明したが、これらの内容に限定されるものではない。
　以上の実施の形態１のシリアル通信方法の説明では、シリアル通信として調歩同期式の通信形態を想定した例を示しているが、この通信形態に限定されるものではない。
　以上の実施の形態１のシリアル通信システム１Ａにおける図３と図９の説明では、デバイスＩＤフィールドＩＤＦを省略した状態の通信を示しているが、コントロールフィールドＣＦの直後にデバイスＩＤフィールドＩＤＦを付加した状態で通信することが可能である。
　１Ａ，１Ｂ　シリアル通信システム、１０　コントローラ、２０　デバイス（センシングデバイス）、２０_1～２０_n　複数のデバイス（複数のセンシングデバイス）、３０Ａ　通信ライン、３０Ｂ　バス通信ライン。

Claims (7)

  1. 　シリアル通信機能を有するコントローラと、シリアル通信機能を有する１以上のセンシングデバイスとの間で、通信フォーマットに従ってシリアル通信を行うシリアル通信方法であって、
    　前記コントローラは、前記センシングデバイスに対して検知したデータの保持を指示するラッチコマンドと、前記センシングデバイスに対して検知したデータの保持の解除を指示するリリースコマンドとを前記通信フォーマット中に含めて、前記センシングデバイスに対して送信し、
    　前記センシングデバイスは、
    　前記コントローラからの前記ラッチコマンドに応じ、検知した前記データを保持し、
    　前記コントローラからの前記リリースコマンドに応じ、検知した前記データの保持を解除する、
    シリアル通信方法。
  2. 　前記センシングデバイスは、
    　前記コントローラからの前記ラッチコマンドに応じ、保持の指示を受け付けたことを示すコマンドを前記コントローラに対して送信し、
    　前記コントローラからの前記リリースコマンドに応じ、保持の解除の指示を受け付けたことを示すコマンドを前記コントローラに対して送信する、
    請求項１に記載のシリアル通信方法。
  3. 　前記コントローラは、前記センシングデバイスに対して状態を問い合わせる問い合わせコマンドを前記通信フォーマット中に含めて、前記センシングデバイスに対して送信し、
    　前記センシングデバイスは、前記コントローラからの前記問い合わせコマンドに応じ、前記データを保持していることを示すコマンド、または、保持を解除したことを示すコマンドを前記コントローラに対して送信する、
    請求項１または請求項２のいずれか１項に記載のシリアル通信方法。
  4. 　前記コントローラは、前記センシングデバイスに対して前記ラッチコマンドと前記リリースコマンドとを送信する際に、前記センシングデバイスのいずれかを指定するセンシングデバイスＩＤを含め、
    　前記センシングデバイスＩＤにより指定された前記センシングデバイスは、
    　前記コントローラからの前記ラッチコマンドに応じ、検知した前記データを保持し、
    　前記コントローラからの前記リリースコマンドに応じ、検知した前記データの保持を解除する、
    請求項１から請求項３のいずれか１項に記載のシリアル通信方法。
  5. 　前記コントローラがマスタデバイス、前記センシングデバイスがスレーブデバイスであり、
    　前記マスタデバイスと前記スレーブデバイスとの間で前記シリアル通信を行う、
    請求項１から請求項４のいずれか１項に記載のシリアル通信方法。
  6. 　前記センシングデバイスは、前記コントローラからのリクエストに応じ、保持した前記データを前記コントローラに対して送信する、
    請求項１から請求項５のいずれか１項に記載のシリアル通信方法。
  7. 　シリアル通信機能を有するコントローラと、シリアル通信機能を有する１以上のセンシングデバイスとを備え、
    　請求項１から請求項６のいずれか１項に記載されたシリアル通信方法により、前記コントローラと１以上の前記センシングデバイスとの間でシリアル通信を行う、
    シリアル通信システム。
PCT/JP2021/042097 2021-11-16 2021-11-16 シリアル通信方法及びシリアル通信システム WO2023089665A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/042097 WO2023089665A1 (ja) 2021-11-16 2021-11-16 シリアル通信方法及びシリアル通信システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/042097 WO2023089665A1 (ja) 2021-11-16 2021-11-16 シリアル通信方法及びシリアル通信システム

Publications (1)

Publication Number Publication Date
WO2023089665A1 true WO2023089665A1 (ja) 2023-05-25

Family

ID=86396357

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/042097 WO2023089665A1 (ja) 2021-11-16 2021-11-16 シリアル通信方法及びシリアル通信システム

Country Status (1)

Country Link
WO (1) WO2023089665A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021086325A (ja) * 2019-11-27 2021-06-03 多摩川精機株式会社 シリアル通信方法及びシリアル通信システム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021086325A (ja) * 2019-11-27 2021-06-03 多摩川精機株式会社 シリアル通信方法及びシリアル通信システム

Similar Documents

Publication Publication Date Title
US5519603A (en) Intelligent process control communication system and method having capability to time align corresponding data sets
CN106557446B (zh) 总线系统
EP3651417B1 (en) Control system and control method
JP7324455B2 (ja) シリアル通信方法及びシリアル通信システム
CN107205063A (zh) 一种智能家居控制总线的设备冲突解决方法
KR100373617B1 (ko) 전자기기및그동작모드제어방법
WO2023089665A1 (ja) シリアル通信方法及びシリアル通信システム
JPH0654911B2 (ja) マスターシップを転送する方法および装置
US7836224B2 (en) Method and system for transmitting data of a data type to be transmitted cyclically and of a data type which can be transmitted acyclically via a common transmission channel
EP0115348B1 (en) Remote initialization of interconnected communications stations
JP2005277978A (ja) 識別番号自動設定方法及び識別番号自動設定装置
US10979177B2 (en) Method for identifying data corruption in a data transfer over an error-proof communication link
WO2021010166A1 (ja) シリアル通信方法及びシリアル通信システム
Elliott et al. The IBM enterprise systems connection (ESCON) architecture
CN111698016B (zh) 用于数据传输的设备和方法
JP2008118349A (ja) 通信装置
JPH0522329A (ja) 信号伝送障害の特定方法
US7167940B2 (en) Data processing method, data processing apparatus, communications device, communications method, communications protocol and program
JP3127939B2 (ja) イベント情報伝送装置
JP2735078B2 (ja) 通信制御方式
JPH04306029A (ja) 単方向通信における障害装置の特定方法
JP3459046B2 (ja) テストマネージャ付きメディアコンバータ、障害検出システムおよび障害検出方法
JPS6267664A (ja) データ転送方法
US6885715B1 (en) Method and apparatus for synchronizing a network link
JPH0375842A (ja) 誤制御防止回路

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21964681

Country of ref document: EP

Kind code of ref document: A1