Sensoray 2410 - Manual (Page 6)

2410 Instruction Manual 4 Network Interface
Chapter 3: Network Interface
The 2410 module connects to a network through its Ethernet
interface. This interface supports 10/100 Mbps networks with
automatic speed detection. Ethernet provides several important
advantages over other popular communication interfaces,
including:
• Platform independence.
• Protection from hardware obsolescence.
• Elimination of disruptive ground loops in the client-server
communication path.
3.1 HTTP Server
The module implements an embedded HTTP server and web
site. The web site makes it possible to configure the module
and control digital I/O states from a web browser.
The module’s web site is intended for module configuration
and diagnostic uses. It is not recommended for automated
client applications.
3.2 Telnet Server
A built-in telnet server provides the principal means for
controlling the module’s I/O resources from automated client
applications. Because it is based on plaintext messages, telnet
also serves as a practical alternative to HTTP for manually
controlling the module.
The module’s telnet server supports multiple concurrent telnet
sessions, each with a private, dedicated shell. The shells, in
turn, provide access to a variety of plaintext shell commands.
Network clients interact with I/O devices by sending shell
commands, and receiving the output of shell commands, over
telnet.
Upon receiving a shell command from a network client, the
module executes the command—often causing manipulation of
an I/O interface—and then returns any requested data to the
client. In most cases, a client will open a telnet session and
leave it open until it has completely finished communicating
with the module (e.g., when the client application closes).
Every telnet client can access all of the I/O resources on the
module, except that only one telnet client may receive
asynchronous event notifications (i.e., notification of captured
digital input edges) at a time.
Applications may have any number of open telnet sessions on a
module, up to the maximum number supported by the module.
This is a flexible arrangement that makes possible a wide range
of configurations. For example:
• A host computer could employ a telnet session for
automated module control while, at the same time, a
portable laptop computer employs another session for
diagnostic monitoring.
• Multiple host computers—each responsible for managing
specific I/O resources on a 2410 module (e.g., a subset of
the 48 DIO channels)—can concurrently communicate
with a specific module over independent telnet sessions.
• A module’s telnet clients need not reside on different host
computers; a single host may run multiple threads or
processes, each of which has a private telnet session.
3.2.1 Telnet Time-outs
Each telnet session has a programmable time-out interval that
specifies the maximum time allowed between consecutive
shell commands. If no shell commands are received within the
time-out interval, the telnet server will automatically close the
session and optionally reset DIO interfaces to their default
states.
The module’s telnet time-out function serves two purposes:
• Crash recovery. If a client terminates a telnet session in
an “ungraceful” way (e.g., application crash), the server
will time-out the session, thus freeing it for re-use. This is
a critical feature in systems with deeply embedded 2410
modules.
• Safety. Malfunctioning hardware or software may cause a
telnet client to cease communicating with the 2410. In
such cases, the telnet server will time-out and force the
outputs of various module interfaces to their “safe” states.
All telnet sessions begin with a default time-out interval and
disabled time-out reset (time-out will not reset the module).
Once a telnet session has been opened, the client can issue a
“WTO” shell command to change the interval and specify
whether to reset the module upon time-out.