For background information see LOWIS Server Architecture Overview.
In LOWIS, the mipscan.exe program is used to communicate with devices that are reachable via a TCP/IP address/port identification. There are two different categories of devices that can be reached via TCP/IP: devices that truly support IP access and devices that are reached via an IP to Serial device/gateway.
The advantage of TCP/IP communications is that the TCP/IP protocol layer guarantees the integrity of the data that is transmitted, so error detection and recovery information is no longer needed to be included in the provided data stream. Note that this guarantee only is effective for data while it is within the confines of the TCP/IP system, this does not mean that data received via a radio network and then sent over TCP/IP is guaranteed to be correct. It just means that what was was received on the TCP/IP end point is the same data as was initially added on the TCP/IP origin point.
True TCP/IP Devices
Communications to true TCP/IP devices tends to be much faster and reliable than radio devices, due to the entire communications chain being done in a digital fashion instead of requiring digital to analog to digital conversions.
IP To Serial Devices
IP To Serial Devices are slightly more complicated to setup than true TCP/IP device as these are typically used to access a radio transmitter that is not able to be directly connected to the LOWIS server. This means that all of the various transmission errors that were mentioned in Radio Communications (mscan.exe) can still occur but are no longer under the direct control of LOWIS. All of the settings that control how the radio communications will occur have to be configured within the IP to Serial device itself as LOWIS can no longer influence those settings.
TCP/IP Com Port Configuration
To add any kind of TCP/IP accessible device into LOWIS, you need to navigate to the LOWIS Admin Configuration and locate Common, then Server, and then right click on Comm Ports and select Add Section. For most devices you will want to select Serial Over IP Port (unless all of the devices on this Com Port are going to be Modbus TCP devices - see Modbus TCP below for requirements for this - in which case Modbus TCP Port should be selected). Once the new Com Port has been added, you can look inside of its configuration and see that Port Type has been set to ARCOMOVERIP (or MODBUSOVERIP if Modbus TCP was chosen).
The other main configuration option to be considered is IP Timeout, which specifies the amount of time (in milliseconds) to wait before considering the reply to have been completely received or to decide that no reply is coming from the device if nothing has been received so far. Note that IP communications will still use the calculated reply size and RTUERRORBYTES setting as there is nothing in TCP/IP that requires the entire reply to be returned as one message and IP to Serial devices will typically return received data in one or two character increments as they are received (given the typical speed difference between an Ethernet network to a serial port).
Modbus TCP is a special form of TCP/IP communications to Modbus devices that has specific requirements and provides some specific benefits. The requirements are:
- Communications to the Modbus device must be true TCP/IP communications, no IP to Serial can be used
- The Modbus device must explicitly support the Modbus TCP mode
- Communication to the device is done over port 502.
If all of these requirements are met, then the benefits from doing this are
- It is not required to pass in the RTU address in the request as the communication is already going to a specific device. It is good practice to include the correct RTU Address in case the device still requires it and for help in communications debugging. Note that the space used by the RTU address has to be included in the request for correct processing of the message to occur.
- The reply from the device will not have the CRC signature added to the end of the reply. As the CRC is included to detect any problems in the data feed from the device which is already guaranteed to be detected by the TCP/IP layer the CRC is no longer necessary.