| Cogent SA85 Driver for Modicon Modbus Plus Cards : Version 1.10 | ||
|---|---|---|
 | Chapter 4. Communicating with the Administrator |  |
| Cogent SA85 Driver for Modicon Modbus Plus Cards : Version 1.10 | ||
|---|---|---|
| | Chapter 4. Communicating with the Administrator | |
The SA85 and PC85 Modbus Plus cards support four types of Modbus communication paths: data master output, data slave input, program master output and program slave input. The mbpadmin device administrator supports only the data paths and not the program paths. The program paths are intended to allow Modbus programming commands to be sent to other nodes on the network; the details of the operation of these paths are not published by Modicon.
The SA85 and PC85 cards have 8 data master output paths. They allow the transmission of Modbus data access commands to read and write register data, perform station management and read status information. Any Modbus function code except 9, 10, 13, 14, 18 and 126 can be sent through a data master path (these function codes are programming commands and must be sent through the program master output paths, which are not supported by mbpadmin).
In order to use a data master output path, a task must send a request to mbpadmin to open it. Having opened it, the task may write Modbus commands to it and read the corresponding Modbus responses from it. When a path has been opened, only the task that opened it may write to it or read responses from it. Attempts by other tasks to read or write the path are refused and the MBP_R_NOT_OWNER error is returned.
A data master output path is used to conduct Modbus transactions between a Modbus master task and a Modbus command handler task. The Modbus master task is a task which has opened the path with a request to mbpadmin. The Modbus command handler task is the software in the destination Modbus Plus node that acts upon the Modbus commands sent through the path. A Modbus transaction consists of a Modbus command sent by the master to the slave and either a standard Modbus response or a routing failed error response.
It is important that a transaction be completed before another transaction is initiated on the same path. If another Modbus command is sent to a path that is still awaiting the response from the previously sent command, the peer processor crashes and the MBP_INIT request must be used to re-boot the card. If it is necessary to abort a transaction before the response is received, the MBP_ABORT_TRANS request may be used. After successful completion of the MBP_ABORT_TRANS request, another transaction may be initiated.
There are five request types that pertain to the data master output paths: MBP_OPEN_OUT, MBP_WRITE_OUT, MBP_ABORT_TRANS, MBP_CLOSE_OUT and MBP_READ_RESPONSE.
The MBP_OPEN_OUT request assigns ownership of the specified data master output path to the requesting task. If mbpadmin responds MBP_R_OK, no task except the requesting task may write to or read from the path until the path is closed by an MBP_CLOSE_OUT request or the owning task dies. If the path is already owned by another task, the MBP_R_PATH_IN_USE error is returned.
The state of each path is available through the MBP_GET_STATE request (see MBP_GET_STATE).
The path_num field of the mbp_open_out structure specifies which data master output path to open. It must be between 1 and 8 inclusive, otherwise the MBP_R_BAD_PARM error is returned.
If the path was opened successfully, the MBP_R_OK response is returned.
The MBP_WRITE_OUT request sends a Modbus command to the destination Modbus slave device through the specified data master output path. The output path must have been previously opened by an MBP_OPEN_OUT request or the write will fail and return the MBP_R_NOT_OPEN error. If the path has been opened by another task, the response is MBP_R_NOT_OWNER.
The path_num field of the mbp_write_out message is the number of the opened data master output path. It must be between 1 and 8 inclusive or the MBP_R_BAD_PARM error is returned.
The route field contains the 5-byte Modbus Plus routing path.
The len field contains the length of the Modbus command contained in the data field. The Modbus command has the RTU format defined in the Gould Modbus Protocol Reference Guide, except that only the function and data fields are sent; that is, the address and check fields are not sent.
![[Note]](images/note.gif) | Modbus function codes 9, 10, 13, 14, 18 and 126 should not be sent through a data master output path. These are Modbus programming commands that must be sent through program master output paths, which are not supported by mbpadmin. |
If mbpadmin cannot correctly write the request to the peer processor to send the Modbus command, the MBP_R_WRITE_FAILED response is returned. Otherwise, the response is MBP_R_OK.
The MBP_ABORT_TRANS request is used to abort any Modbus transaction that may be pending on a data master output or slave input path.
The path_num field of the mbp_abort_trans request specifies the path number to abort. It must be between 1 and 8 inclusive or the MBP_R_BAD_PARM error is returned.
If the path is not open or has been opened by another task, the MBP_R_NOT_OWNER error is returned. Otherwise, the result code is MBP_R_OK.
The MBP_CLOSE_OUT request releases control of an output path from the owning task. This makes the path available to be opened by other tasks.
The path_num field of the mbp_close_out message specifies the path number to close. It must be between 1 and 8 inclusive or the MBP_R_BAD_PARM error is returned.
If the path is not open or has been opened by another task, the MBP_R_NOT_OWNER error is returned. Otherwise, the result code is MBP_R_OK.
The MBP_READ_RESPONSE request is used to get the response to the last Modbus command sent on the specified data master output path. The response message from mbpadmin is delayed until the Modbus response is received and processed by the SA85 or PC85 peer processor and mbpadmin. If no Modbus response is received, the requesting task is reply-blocked indefinitely. The requesting task could use a timer operation to abort the request if the response has not arrived after a specified time.
The path_num field of the mbp_read_response request specifies the number of the path from which to read a Modbus response. It must be between 1 and 8 inclusive or the MBP_R_BAD_PARM error is returned. If the path is not owned by the requesting task, the MBP_R_NOT_OWNER error is returned. If the path is not open at all, the MBP_R_NOT_OPEN error is returned.
The response from mbpadmin contains information about the source (slave) node and the actual Modbus response. The src_node field contains the Modbus Plus node number of the originating node. The route_path field contains the 5-byte routing path.
If the command was rejected by the slave device or could not be delivered, a routing failure error is returned. This is signified by the MBP_R_ROUTING_FAIL result code and a 2-byte message in the data field of the mbp_r_read_response message. The first byte is the failed node type and the second byte is the routing failure error condition. These error conditions are defined in Appendix A of the Modicon Modbus Plus Network Programming Guide.
The len field indicates the length of the Modbus response contained in the data field.
A normal Modbus response has the format defined in the Gould Modbus Protocol Reference Guide. The format of each response depends on the function code of the command.
The SA85 and PC85 cards have 8 data slave input paths. They allow the reception of Modbus data access commands to read and write register data, perform station management and read status information. Any Modbus function code except 9, 10, 13, 14, 18 and 126 can be received from a data slave path (these function codes are programming commands and must be sent through the program paths, which are not supported by mbpadmin).
In order to use a data slave input path, a task must send a request to mbpadmin to open it. Having opened it, the task may read Modbus commands from it and write the corresponding Modbus responses to it. When a path has been opened, only the task that opened it may read from it or write responses to it. Attempts by other tasks to read or write the path are refused and the MBP_R_NOT_OWNER error is returned.
A data slave input path is used to conduct Modbus transactions between a Modbus master task and a Modbus command handler task. The Modbus master task is the software in the originating Modbus Plus node that initiates transactions with the Modbus command handler task. The Modbus command handler task is a task that has opened the path with a request to mbpadmin. The command handler task acts upon the Modbus commands sent through the path and responds with the result. A Modbus transaction consists of a Modbus command sent by the master to the slave and either a standard Modbus response or a routing failed error response. The interpretation of the Modbus commands as they pertain to the application running on the QNX or Linux machine is at the discretion of that machine's programmer. Note that a Modbus response should never be sent to an input path that is not expecting a response because the SA85 or PC85 peer processor will crash, requiring a reboot with an MBP_INIT request.
After mbpadmin is started or the MBP_INIT request has been issued, the data slave input paths are idle. Until a path has been opened by an MPB_OPEN_IN request, it is handled directly by mbpadmin; that is, any Modbus commands received on a closed input path are rejected by mbpadmin.
After a path has been opened, the Modbus command handler task (i.e., the task that opened the path) should issue an MBP_READ_IN or MBP_READ_IN_MANY request to wait for and receive the next Modbus command from the path. After performing the appropriate action based on the received Modbus command, the command handler task should send the Modbus response with an MBP_RESPOND_IN request or a routing failure error response with an MBP_ROUTING_FAIL request.
| The Modbus command handler task that has an input path open should respond as quickly as possible to a received Modbus command. Although there is no fixed time limit, the initiating Modbus master task may be blocked from performing other processing until it receives a response. |
There are six request types that pertain to the data slave input paths: MBP_OPEN_IN, MBP_READ_IN, MBP_READ_IN_MANY, MBP_RESPOND_IN, MBP_ABORT_TRANS, MBP_CLOSE_IN and MBP_ROUTING_FAIL.
The MBP_OPEN_IN request assigns ownership of the specified data slave input path to the requesting task. If mbpadmin responds MBP_R_OK, no task except the requesting task may read or write from the path until the path is closed by an MBP_CLOSE_IN request or the owning task dies. If the path is already owned by another task, the MBP_R_PATH_IN_USE error is returned.
The state of each path is available through the MBP_GET_STATE request (see MBP_GET_STATE).
The path_num field of the mbp_open_in structure specifies which data slave input path to open. It must be between 1 and 8 inclusive, otherwise the MBP_R_BAD_PARM error is returned.
If the path was opened successfully, the MBP_R_OK response is returned.
The MBP_READ_IN request notifies mbpadmin that the next command received from the specified data slave input path should be forwarded to the task that opened the path. If a path has been opened but no MBP_READ_IN request has been made on it and a Modbus command is received from the path, it remains in the SA85 or PC85 until an MBP_READ_IN request is received for it.
If no Modbus command has been received on the path, the response from mbpadmin to the requesting task is deferred until a command arrives. That is, an MBP_READ_IN request on an idle path puts the requesting task in the reply-blocked state until a Modbus command is received on the path (which may never happen).
The path_num field of the mbp_read_in request specifies the number of the path from which to read a Modbus command. It must be between 1 and 8 inclusive or the MBP_R_BAD_PARM error is returned.
If the path is not owned by the requesting task, the MBP_R_NOT_OWNER error is returned. If the path is not open at all, the MBP_R_NOT_OPEN error is returned.
The response from mbpadmin contains information about the source (master) node and the actual Modbus command. The src_node field contains the Modbus Plus node number of the originating node. The route_path field contains the 5-byte routing path.
The len field contains the length of the Modbus command contained in the data field. The Modbus command has the RTU format defined in the Gould Modbus Protocol Reference Guide, except that only the function and data fields are sent; that is, the address and check fields are not sent.
The MBP_READ_IN_MANY request is the same as the MBP_READ_IN request except that the requesting task can tell mbpadmin to wait for a command from any of several opened data slave input paths. Each of the paths specified in the path_mask field must have been previously opened by the requesting task. If there is a command pending on any of the specified paths, it is forwarded to the requesting task.
If no Modbus command has been received on any of the paths, the response from mbpadmin to the requesting task is deferred until a command arrives on one of them. That is, an MBP_READ_IN_MANY request on a set of idle paths puts the requesting task in the reply-blocked state until a Modbus command is received on one of the specified paths (which may never happen).
The path_mask field of the mbp_read_in_many request specifies the paths from which to read a Modbus command. It consists of a bit for each of the eight possible data slave input paths. The low-order bit is path 1 and the high-order bit is path 8.
If one of the specified paths is not owned by the requesting task, the MBP_R_NOT_OWNER error is returned. If one of the specified paths is not open at all, the MBP_R_NOT_OPEN error is returned.
The response from mbpadmin contains the path number, information about the source (master) node and the actual Modbus command. The src_node field contains the Modbus Plus node number of the originating node. The route_path field contains the 5-byte routing path.
The len field contains the length of the Modbus command contained in the data field. The Modbus command has the RTU format defined in the Gould Modbus Protocol Reference Guide, except that only the function and data fields are sent; that is, the address and check fields are not sent.
The MBP_RESPOND_IN request is used to respond to a Modbus command received from a data slave input path. It should be sent after a Modbus command has been received with an MBP_READ_IN request and processed by the command handler task. The MBP_RESPOND_IN request should never be sent to a path on which no command has been received because the peer processor will crash, requiring a reboot with the MBP_INIT request.
If the input path has not been opened, the MBP_R_NOT_OPEN error is returned. Also, if the input path has been opened by another task, the MBP_R_NOT_OWNER error is returned.
The path_num field of the mbp_respond_in message is the number of the opened data slave input path. It must be between 1 and 8 inclusive or the MBP_R_BAD_PARM error is returned.
The len field contains the length of the Modbus response contained in the data field. A normal Modbus response has the format defined in the Gould Modbus Protocol Reference Guide. The format of each response depends on the function code of the command.
If mbpadmin cannot correctly write the request to the peer processor to send the Modbus response, the MBP_R_WRITE_FAILED response is returned. Otherwise, the response is MBP_R_OK.
See MBP_ABORT_TRANS.
The MBP_CLOSE_IN request is used to release control of a previously opened data slave input path so that it may be opened by other tasks.
The path_num field of the mbp_close_in message specifies the path number to close. It must be between 1 and 8 inclusive or the MBP_R_BAD_PARM error is returned.
If the path is not open or has been opened by another task, the MBP_R_NOT_OWNER error is returned. Otherwise, the result code is MBP_R_OK.
The MBP_ROUTING_FAIL request is used to reject a Modbus command that has been received on a data slave input path. A routing failure should be generated if an unsupported Modbus function code is received or if any of the routing failure conditions described in Appendix A of the Modicon Modbus Plus Network Programming Guide occur.
The path_num field of the mbp_routing_fail message specifies the data slave input path on which to send a routing failure error response. The path number must be between 1 and 8 or the MBP_R_BAD_PARM error is returned.
The code field of the mbp_routing_fail message is the routing failure error code as defined in the Modicon Modbus Plus Network Programming Guide.
If the data slave input path has not been opened, the MBP_R_NOT_OPEN error is returned and if the path has been opened by another task, the MBP_R_NOT_OWNER error is returned. Otherwise, the MBP_R_OK result code is returned.
| |  | |
| 4.3. Administrator Control |  | Chapter 5. Sample Program: mbptest |
Copyright © 1995-2010 by Cogent Real-Time Systems, Inc. All rights reserved.