Devices Channels Reference

Organize device communications in channels.

Reference → Modules → Devices → UI → Points | Protocols | Channels | Nodes | AccessTypes | Monitor

Creating Channels

1. Navigate to Devices → Channels
2. Click New Channel or Plus button
3. Select protocol from list
4. Configure:
   • Channel Name - Unique identifier
   • Description - Documentation
5. Click OK

Channel Properties

Core Settings

Interface Types

Serial

• RS-232/485 communication
• Single port configuration
• Hardware handshaking options

Multi Serial

• Multiple RS-232 ports
• Port count configuration
• Independent port settings

TCP/IP

• Ethernet/wireless networks
• Connection pooling
• Multiple simultaneous connections

Interface Settings

TCP/IP Settings

Serial Settings

• Baud Rate - Communication speed
• Data Bits - 7 or 8
• Parity - None, Even, Odd
• Stop Bits - 1 or 2
• Handshake - None, RTS/CTS, XON/XOFF

Channel States

Remote Channels

Execute Device Module on remote computers for gateway and tunneling applications.

How it works

The main server (where the solution runs and where you want the tags to update) reads each channel whose InitialState is Remote, connects to the remote node named in RemoteSettings, and launches a TRemoteDevice process on that remote node only. TRemoteDevice runs the protocol driver locally on the node, talks to the field device, and connects back to the main server to deliver the data. The remote node is the computer physically wired to the device; the main server never runs TRemoteDevice itself.

System Requirements

• Main server and remote node reachable over the network
• FrameworX installed on both computers, including the channel's protocol driver on the remote node
• The TWebServices (Solution Center) service must be running on the remote node and listening on its configured port (default 10108). This is the service that receives the remote-launch request — if it is not running or the port is wrong, no TRemoteDevice starts and no values arrive.
• Firewall open both directions: main server → remote node on the TWebServices port, and remote node → main server on the TServer port (the remote device connects back to the server)

Configuration

1. On the main server's solution, set the channel's InitialState to Remote
2. Set RemoteSettings to the remote node's address as IP:Port, where the port is that node's TWebServices service port (default 10108):

   192.168.1.100:10108

Required Ports

Enable in firewall (Inbound/Outbound):

• TWebServices (Solution Center) on the remote node — default 10108. This is the port you put in RemoteSettings.
• TServer on the main server — default 3101. The remote device connects back to this.
• Custom ports as configured

Remote Execution Process

1. The main server (TServer/TStartup) connects to the TWebServices (Solution Center) service on the remote node at the RemoteSettings address
2. TRemoteDevice launches on the remote node only — it does not run on the main server
3. TRemoteDevice runs the channel's protocol driver locally on the remote node and connects back to the main server
4. Field data is transmitted back to the main server, where the channel's tags update

Special Considerations

Runtime Control

Start/Stop Operations

csharp

// Stop channel
@Device.Channel.ChannelName.Stop();

// Start channel
@Device.Channel.ChannelName.Start();

// Stop with timeout
@Device.Channel.ChannelName.Stop(10);

Script Example

csharp

public class ChannelControl
{
    public void RestartChannel(string channelName)
    {
        // Stop channel
        @Device.Channel[channelName].Stop(5);

        // Wait for stop
        Thread.Sleep(1000);

        // Start channel
        @Device.Channel[channelName].Start();
    }
}

Common Configurations

Modbus TCP

Protocol: Modbus
Interface: TCP/IP
Port: 502
Node Connection: 1
Timeout: 1000ms

Serial RS-485

Protocol: Modbus RTU
Interface: Serial
Baud: 19200
Data Bits: 8
Parity: Even
Stop Bits: 1

OPC UA

Protocol: OPC UA
Interface: TCP/IP
Port: 4840
Security: Basic256
Max Connections: 5

Best Practices Checklist

• Name Channels Clearly - Include protocol and purpose
• Document Settings - Use description field
• Set Appropriate Timeouts - Match network conditions
• Configure Connection Limits - Prevent overload
• Use Remote Channels - For distributed systems
• Monitor Channel Status - Track communication health
• Test Before Production - Verify all settings

Troubleshooting

Channel won't start:

• Check InitialState setting
• Verify protocol license
• Review interface configuration
• Check port availability

Communication timeouts:

• Increase timeout value
• Check network latency
• Verify device response time
• Review connection settings

Connection failures:

• Verify IP addresses
• Check firewall rules
• Test network connectivity
• Review security settings

Remote channel issues (no TRemoteDevice / no values):

• Confirm the TWebServices (Solution Center) service is running on the remote node and reachable on the RemoteSettings port (default 10108) — this is the most common cause
• Verify RemoteSettings uses the TWebServices port, not the TServer port (3101) and not the field-device port
• Confirm the reverse path is open: the remote node must reach the main server's TServer port
• Verify TRemoteDevice and the channel's protocol driver are present in the remote node's install
• Review firewall exceptions in both directions

Diagnostics

Remote Channel Monitoring

Verification Steps

1. On the main server, the TStartup/TServer trace shows Starting Module Device (Channel: <name>) :: Remote: <ip>
2. Confirm a TRemoteDevice process is running on the remote node (it does not appear on the main server)
3. If it did not start, the server trace shows Module Device (Channel: <name> failed with the connection error — check that the remote node's TWebServices service is running and reachable on the RemoteSettings port
4. Once running, confirm the channel's IsRunning = 1 and WatchDog advancing (see Driver-health signals below)

Monitor channel performance:

csharp

// Get channel run state
int isRunning = @Device.Channel.ChannelName.IsRunning; // 1 = running, 0 = stopped

// Check last error code
int lastErrorCode = @Device.Channel.ChannelName.LastErrorCode;

// Get statistics
uint successAmount = @Device.Channel.ChannelName.SuccessAmount;
uint failAmount = @Device.Channel.ChannelName.FailAmount;

Diagnosing a channel reading TotalPoints = 0

TotalPoints is the count of device points (Tag-to-address mappings) actually bound to a channel's live driver across every Node and AccessType beneath it. The runtime writes it from the driver's resolved point list when the Device Module initializes the channel — it is not a count of rows in the configuration. A channel showing TotalPoints = 0 therefore has three distinct causes that look identical on a dashboard but call for different responses:

Driver-health signals

Judge whether a channel's driver is actually alive by the affirmative signals it maintains, rather than by TotalPoints or SuccessAmount — both of which are legitimately zero for a healthy server/slave-role channel with no master connected, or for a master channel that has not yet completed a poll.

In this section...