Handling of RTS, CTS, DTR, and DSR Signals
The status of RTS, CTS, DTR, and DSR lines can be exchanged between the VSP and the DS. This means that the VSP can remotely control the state of RTS and DTR outputs of the serial port on the DS while the DS can notify the VSP of the state changes on the CTS and DSR inputs of its serial port. This topic provides detailed information on the subject.
RTS and DTR outputs of the DS serial port
Whenever the application requires the state of the RTS or DTR line to be changed the VSP sends an appropriate on-the-fly command to the DS. Here is how this is reflected in the Port Monitor :
12/16/03 0924 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set RTS to low...success
12/16/03 0927 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set RTS to high...success
12/16/03 1006 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set DTR to low...success
12/16/03 1006 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set DTR to high...success
The DS always replies to each such command with the A (OK) status code *. Whether or not the DS actually processes the command depends on the current DS setup:
If the application is running with RTS/CTS flow control disabled (which means the VSP has sent a Flow Control (FC) parameter of 0) the DS does process all RTS-related on-the-fly commands. If the application is running with RTS/CTS flow control enabled (the VSP has sent a Flow Control (FC) parameter of 1) the DS ignores all RTS-related on-the-fly commands (but still replies with A ). This is because in this mode the DS controls the RTS line on its own and the function of the RTS line is to regulate the flow of data from the attached serial device into the serial port of the DS (also see Flow Control (FC) setting ).
As for the DTR line, whether or not the DS actually processes DTR-related on-the-fly commands depends on the DTR Mode (DT) setting . If this setting is 0 (idle) the DS does process all DTR-related on-the-fly commands. If this setting is 1 (connection mode) the DS ignores all such commands. This is because in this mode the DS controls the DTR line on its own and the function of the DTR line is to reflect current status of the data connection.
CTS and DSR inputs of the DS serial port
Changes in the states of CTS and DTR inputs of the DS serial port are delivered to the VSP through Notification (J) messages . For the notifications to work the DS must first be informed the status change of which lines should be reported to the VSP . This is done through the Notification Bitmask (NB) parameter . Depending on the flow control mode selected by the application the VSP sets the bitmask in one of the two ways:
• | If the application is running with RTS/CTS flow control disabled, the VSP programs the DS to react to the changes of both the CTS and DSR lines. |
• | If the application is running with RTS/CTS flow control enabled, the VSP programs the DS to react to the changes of the DSR line only. This is because when the flow control is enabled the CTS line is handled on the DS "level"- it is used to regulate the flow of serial data from the DS into the serial device. |
Since the bitmask depends on the selected flow control it is re-programmed each time the application changes the flow control mode:
--- application disables RTS/CTS flow control so the bitmask is set to include the CTS line ---
12/16/03 1018 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set flowcontrol to none...success
12/16/03 1018 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: enabling line change notification for DSR, CTS...success
---
--- application enables RTS/CTS flow control so the bitmask is set to exclude the CTS line ---
12/16/03 1020 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set flowcontrol to RTS/CTS...success
12/16/03 1020 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: enabling line change notification for DSR...success
Additional considerations concerning notification messages
Just as on-the-fly commands can be sent using out-of-band or inband access method, notification messages can also be sent out-of-band or inband. When the Inband (IB) setting of the DS is programmed to 1 (enabled) the DS sends inband notifications (otherwise, the DS sends out-of-band notifications).
For the inband notifications to work no additional DS setup is required (past the pre-programming needed to make the DS accept inband commands in principle- see preparing the DS for inband access ).
For the out-of-band notifications to work properly the Notification Destination (ND) setting of the DS must be programmed to 0 (last known port). In this case the DS will send its notifications to the port from which it last received an on-the-fly command. Because the VSP sends on-the-fly commands from an "automatic" port the DS has no way of knowing beforehand what this port number will be. Therefore, the DS won't send notifications unless it receives at least one on-the-fly command from the VSP . This is not a limitation since on-the-fly commands are generated by the VSP as soon as it is opened and/or connection is established (see when the VSP sends on-the-fly commands ).
There are certain limitations associated with notification messages:
• | Notifications are only generated when the data connection is established between the VSP and the DS. This is different from on-the-fly commands which can be sent by the VSP at any time, even when the data connection is not established yet. |
• | The change in the state of the CTS or DSR input of the DS serial port is recognized with a 20 millisecond delay. That is, the line must change the state and remain in this new state for at least 20 milliseconds for this change to be detected and notification to be sent to the VSP. |
* That is, if on-the-fly commands are enabled in principle.