Tibbo Docs
Tibbo Docs
Table of Contents
Introduction
Hardware Manuals
Ethernet-to-Serial Modules
................................................................................................................................... 1
Comparison Chart for Ethernet-to-Serial
...............................................................................................................................................................
Modules
EM100 Ethernet-to-Serial Module
...............................................................................................................................................................
I/O Pin Assignment and Pin Functions
............................................................................................................................................................
Ethernet Port Lines
..........................................................................................................................................................
Serial Port and General-Purpose
..........................................................................................................................................................
I/O Lines
LED Lines
..........................................................................................................................................................
Power, Reset, and Mode Selection
..........................................................................................................................................................
Lines
Mechanical Dimensions
............................................................................................................................................................
Specifications and EM100 Modifications
............................................................................................................................................................
EM120 Ethernet-to-Serial Module
...............................................................................................................................................................
I/O Pin Assignment and Pin............................................................................................................................................................
Functions
Ethernet Port Lines
..........................................................................................................................................................
Serial Port and General-Purpose
..........................................................................................................................................................
I/O Lines
LED Lines
..........................................................................................................................................................
Power, Reset, and Mode Selection
..........................................................................................................................................................
Lines
Mechanical Dimensions
............................................................................................................................................................
Specifications and EM120 Modifications
............................................................................................................................................................
EM200 Ethernet Module ...............................................................................................................................................................
I/O Pin Assignment and Pin............................................................................................................................................................
Functions
Ethernet Port Lines
..........................................................................................................................................................
Serial Port and General-Purpose
..........................................................................................................................................................
I/O Lines
LED Lines
..........................................................................................................................................................
Power, Reset, and Mode Selection
..........................................................................................................................................................
Lines
Mechanical Dimensions
............................................................................................................................................................
Specifications and EM200 Modifications
............................................................................................................................................................
EM202 Ethernet-to-Serial Module
...............................................................................................................................................................
I/O Pin Assignment and Pin............................................................................................................................................................
Functions
Serial Port and General-Purpose
..........................................................................................................................................................
I/O Lines
LED Lines
..........................................................................................................................................................
Power, Reset, and Mode Selection
..........................................................................................................................................................
Lines
Built-in LEDs
............................................................................................................................................................
Built-in RJ45 Ethernet Connector
............................................................................................................................................................
Mechanical Dimensions
............................................................................................................................................................
Specifications and EM202 Modifications
............................................................................................................................................................
EM1000 BASIC-programmable
...............................................................................................................................................................
Ethernet Module
EM1000-00 and -01
............................................................................................................................................................
I/O Pin Assignment and Pin............................................................................................................................................................
Functions
General-purpose I/O Lines ..........................................................................................................................................................
Ethernet Port Lines
..........................................................................................................................................................
Serial Ports
..........................................................................................................................................................
Square Wave Generator ..........................................................................................................................................................
FLASH and EEPROM Memory
..........................................................................................................................................................
Real-time Counter
..........................................................................................................................................................
LED Lines
..........................................................................................................................................................
Power, Reset, PLL Control,..........................................................................................................................................................
and Mode Selection Lines
Mechanical Dimensions
............................................................................................................................................................
Specifications and EM1000 ............................................................................................................................................................
Modifications
2
4
5
5
6
7
8
9
9
10
11
11
12
13
14
15
15
16
17
17
19
20
21
22
22
23
24
25
26
27
28
28
29
30
30
32
33
37
37
40
40
40
40
41
42
43
44
Ethernet-to-Serial Boards
................................................................................................................................... 45
EM100-EV Evaluation Board
...............................................................................................................................................................
46
Contents
II
Power Jack
............................................................................................................................................................
Ethernet Port Pin Assignment
............................................................................................................................................................
RS232 Port Pin Assignment............................................................................................................................................................
EM120/EM200-EV Evaluation
...............................................................................................................................................................
Board
Power Jack
............................................................................................................................................................
Ethernet Port Pin Assignment
............................................................................................................................................................
RS232 Port Pin Assignment............................................................................................................................................................
Expansion Connector Pin Assignment
............................................................................................................................................................
EM202-EV Ethernet-to-Serial
...............................................................................................................................................................
Board
Power Jack
............................................................................................................................................................
Ethernet Port Pin Assignment
............................................................................................................................................................
RS232 Port Pin Assignment............................................................................................................................................................
TTL Interface Connector Pin
............................................................................................................................................................
Assignment
Mechanical Dimensions
............................................................................................................................................................
EM1000-EV Evaluation Board
...............................................................................................................................................................
EM1000-EV-00 and -01
............................................................................................................................................................
Converting EM1000-EV-00 ..........................................................................................................................................................
into -01
Power Jack and Power Terminals
............................................................................................................................................................
Ethernet Port (RJ45) Pin Assignment
............................................................................................................................................................
RS232 Port (DB8M) and 2x5............................................................................................................................................................
Header Pin Assignment
LEDs
............................................................................................................................................................
Jumpers and Buttons
............................................................................................................................................................
47
47
47
48
48
49
49
50
51
52
52
52
53
54
55
56
56
59
60
60
61
62
Ethernet-to-Serial Servers
................................................................................................................................... 63
Comparison Chart for Ethernet-to-Serial
...............................................................................................................................................................
Servers
DS100 Serial Device Server
...............................................................................................................................................................
DS100 Connectors and Controls
............................................................................................................................................................
Power Jack
..........................................................................................................................................................
Ethernet Port Pin Assignment
..........................................................................................................................................................
Serial Port Pin Assignment..........................................................................................................................................................
and i/f Selection
Status LEDs
..........................................................................................................................................................
Setup Button
..........................................................................................................................................................
Specifications and DS100 modifications
............................................................................................................................................................
DS202 Serial Device Server
...............................................................................................................................................................
DS202 Connectors and Controls
............................................................................................................................................................
Power Jack
..........................................................................................................................................................
Ethernet Port Pin Assignment
..........................................................................................................................................................
RS232 Port Pin Assignment..........................................................................................................................................................
Status LEDs
..........................................................................................................................................................
Setup Button
..........................................................................................................................................................
Specifications and DS202 Modifications
............................................................................................................................................................
63
64
65
65
65
66
67
67
68
69
70
70
71
71
72
72
72
Firmware Manuals
75
75
75
76
76
76
77
78
78
81
...............................................................................................................................................................
...............................................................................................................................................................
...............................................................................................................................................................
82
83
83
III
85
87
88
89
90
91
91
92
93
93
95
97
98
99
99
101
101
102
103
104
104
105
106
107
108
109
110
110
110
111
112
112
113
114
115
116
116
117
118
121
123
124
124
125
126
126
127
128
129
130
130
130
132
132
133
134
134
135
136
Contents
IV
136
137
138
139
139
140
141
142
142
143
144
145
145
146
147
148
148
149
150
150
151
152
153
155
155
156
157
159
160
161
161
162
163
163
165
166
166
167
168
169
170
171
171
172
173
173
174
174
175
175
176
176
177
177
178
178
180
181
182
183
183
183
184
184
185
186
187
188
194
194
195
196
196
197
197
198
198
199
200
201
202
202
Software Manuals
204
205
207
208
209
210
212
214
215
216
218
219
220
220
222
223
223
225
225
226
226
227
228
228
228
229
229
230
230
230
231
Contents
VI
Unknown Device
.......................................................................................................................................................
Unreachable IP-address .......................................................................................................................................................
Warning and Error Messages
.......................................................................................................................................................
Broadcast Access Not Supported
.......................................................................................................................................................
Could Not Connect to the DS
.......................................................................................................................................................
(Inband Access)
Data Link In Progress
.......................................................................................................................................................
DS Lost (After Changing IP)
.......................................................................................................................................................
DS Lost (After Entering NetLoader)
.......................................................................................................................................................
DS Lost (After Exiting NetLoader)
.......................................................................................................................................................
DS Lost (After Initialization)
.......................................................................................................................................................
Duplicate Address Book Entry
.......................................................................................................................................................
Error Mode (Initialization Required)
.......................................................................................................................................................
Failed to Start the NetLoader
.......................................................................................................................................................
Function Not Available (Upgrade
.......................................................................................................................................................
Mode)
Function Not Supported .......................................................................................................................................................
Incorrect Password
.......................................................................................................................................................
Initialization Failed
.......................................................................................................................................................
Initialization Not Allowed .......................................................................................................................................................
Initialization Required
.......................................................................................................................................................
Input Login Password
.......................................................................................................................................................
Invalid Firmware File (or Comm
.......................................................................................................................................................
Error)
Invalid Firmware Uploaded.......................................................................................................................................................
Invalid IP-address
.......................................................................................................................................................
Network Firmware Upload.......................................................................................................................................................
Aborted
New Password Not Accepted
.......................................................................................................................................................
No Response From the DS.......................................................................................................................................................
(Network)
No Response From the DS.......................................................................................................................................................
(Serial)
Operation Cannot Be Executed
.......................................................................................................................................................
Out-of-Band (UDP) Access.......................................................................................................................................................
Required
Password Will Be Disabled.......................................................................................................................................................
Potential DHCP Conflict .......................................................................................................................................................
Power Up With Setup Button
.......................................................................................................................................................
Pressed
Press Setup Button
.......................................................................................................................................................
Serial Firmware Upload Failed
.......................................................................................................................................................
Serial Upgrade Completed.......................................................................................................................................................
Setting Description File Error
.......................................................................................................................................................
Unable to Find Setting Description
.......................................................................................................................................................
Files
Unexpected NetLoader Error
.......................................................................................................................................................
Unreachable IP-address .......................................................................................................................................................
Unable to Send a Broadcast
.......................................................................................................................................................
VSPD and VSP Manager ...............................................................................................................................................................
How VSP Works
............................................................................................................................................................
VSP Manager
............................................................................................................................................................
VSP Properties
..........................................................................................................................................................
VSP Name Selection
..........................................................................................................................................................
Transport Protocol
..........................................................................................................................................................
Additional Info on UDP and
.......................................................................................................................................................
TCP Connections
On-the-fly Commands
..........................................................................................................................................................
When the VSP Sends On-the-fly
.......................................................................................................................................................
Commands
Handling of RTS, CTS, DTR,
.......................................................................................................................................................
and DSR Signals
Synchronization Issues for.......................................................................................................................................................
On-the-fly Commands
Disabled (With FF Escape).......................................................................................................................................................
Mode of the VSP
Connection Timeout
..........................................................................................................................................................
Routing Mode
..........................................................................................................................................................
Connection Mode
..........................................................................................................................................................
Listening Port
..........................................................................................................................................................
Destination Modes
..........................................................................................................................................................
Single-destination Mode .......................................................................................................................................................
Multi-destination Mode .......................................................................................................................................................
2000-2006 Tibbo Technology Inc.
232
232
232
232
233
233
234
234
235
235
236
236
236
237
237
238
238
239
239
240
240
240
241
241
242
242
243
243
243
244
244
245
245
245
246
246
246
247
247
247
248
249
250
251
252
253
254
255
256
258
260
262
263
263
263
264
264
265
266
VII
270
270
271
272
272
273
273
273
273
274
274
275
276
277
278
278
279
279
280
281
282
284
285
286
288
290
291
293
294
294
295
296
297
298
300
303
303
304
305
306
307
308
309
310
311
313
315
316
317
317
318
319
320
321
321
322
322
323
323
Contents
VIII
323
323
324
324
324
324
325
325
326
326
328
329
329
331
331
332
333
334
334
334
334
335
335
336
336
336
337
337
338
338
339
340
341
341
343
343
343
344
344
345
345
345
346
347
347
347
348
348
349
350
350
351
352
352
353
354
IX
355
355
356
356
357
357
358
358
358
359
359
360
360
361
362
362
364
365
365
365
366
367
368
368
369
369
370
370
371
372
372
373
373
374
375
376
376
377
378
378
379
379
379
380
380
382
384
385
388
389
389
389
390
391
391
392
392
392
393
Contents
Application Notes
393
394
394
394
AN001. Customization
...................................................................................................................................
Options in Our Products
395
AN002. Practical Advice
...................................................................................................................................
on Integrating EM Module into Your Device
400
Example: PIC with EM202...............................................................................................................................................................
406
419
420
420
423
424
424
425
427
428
431
432
432
434
435
441
447
448
449
449
450
450
451
451
454
455
456
458
459
460
461
462
463
464
467
469
471
472
473
XI
474
474
476
477
477
478
Update history
480
Introduction
Introduction
This Document System was last updated on 02 MARCH 2007
Update history can be found here
WELCOME to Tibbo Document System!
This Document System consists of four parts:
Hardware Manuals describe the hardware of Tibbo Device Servers
Firmware Manuals describe internal software (called "firmware") of Tibbo
Device Servers
Software Manuals describe available PC software
Application Notes part is a collection of articles on practical use of Tibbo Device
Servers
Hardware Manuals
This part of documentation describes all hardware supplied by Tibbo.
All hardware manufactured by Tibbo is divided into three categories:
Ethernet-to-serial Modules for onboard installation
Ethernet-to-serial Boards
Ethernet-to-serial Servers for external use
Additionally, Tibbo supplies a number of Accessories and Kits.
Ethernet-to-Serial Modules
This part of documentation describes Ethernet-to-serial Modules for onboard
installation supplied by Tibbo.
The following Modules are currently manufactured:
EM100 Ethernet-to-serial Module
EM120 Ethernet-to-serial Module
EM200 Ethernet-to-serial Module
EM202 Ethernet-to-serial Module
EM1000 BASIC-programmable Ethernet Module
To simplify choosing between Ethernet-to-serial Modules we provide the following
comparison chart.
EM10
0
EM12
0
EM200
EM202
YES
NO
NO
10Bas
eT
Built-i
n
TCP,
UDP,
ICMP
(ping),
DHCP
YES
100BaseT
External
Built-in
External
External
Built-in
TCP, UDP, ICMP (ping),
DHCP(3)
TCP, UDP, ICMP (ping),
DHCP, HTTP(4)
External
TCP,
UDP,
ICMP
(ping),
DHCP,
HTTP(4)
16(4)
(3)
Number of simultaneous
TCP or UDP connections
Number of serial ports
Available serial port
modes
Available UART
baudrates, bps
Serial port lines
Number of
general-purpose I/O lines
Additional hardware
EM1000
1(3)
1(3)
16(4)
1
4
UART(3)
(3)
UART, Wiegand, clock/data(4)(5)
150-115200
85-13824
00
TX, RX, RTS, CTS, DTR, DSR(6)
TX, RX,
RTS,
CTS,
DTR,
DSR,
DCD(6)
none/even/odd/mark/space parity, 7/8
bits/character,
full-duplex operation with optional RTS/CTS flow
control,
half-duplex operation with automatic direction
control(7)
(8)
(8)
6
9
9(8)
4(8)
49(9)
UART
---
2KByte EEPROM
Square
wave
generator
,
x8
interrupt
lines,
512KB
FLASH(10),
2KB
EEPROM,
RTC(11),
PLL(12)
Hardware Manuals
Routing buffer size,
KBytes
Power supply voltage
Average current
consumption, mA
Mechanical dimensions,
mm(15)
0.5*2
(3)
40
46.2x2
8x13
8*2(3)
up to 20 (total)(4)
--5V
50
220
230
35x27
.5x9.1
32.1x1
8.5x7.3
32.5x1
9x15.5
up to 20
(total)(4)
3.3V(13)
300(14)
38.4x28.
4x7
Notes:
1. Fixed device server firmware offers ready-to-use serial-over-Ethernet
functionality. This firmware is covered in Device Server Application Firmware
section of this Manual. Related PC software is covered in Software Manuals.
2. Tibbo BASIC, related firmware and development tools are covered in a separate
manual ("TAIKO Manual").
3. Feature of "device server" firmware.
4. Feature available for BASIC applications.
5. Wiegand and clock/data interfaces are actually implemented in firmware, so
these are not features of the hardware.
6. All lines except TX and RX in the UART mode are actually under firmware control.
In the Wiegand and clock/data modes ALL these lines are under firmware
control.
7. Full-duplex and half-duplex operation, flow control, and direction control are
features of the firmware.
8. This count does not include TX and TX lines of the serial port but does include
RTS, CTS, DTR, and DSR lines. These four lines can be viewed as
general-purpose I/O pins or dedicated pins of the serial port depending on the
application.
9. This count includes all lines, including TX, RX, RTS, CTS, DTR, DSR, and DCD
lines of all serial ports.
10. 64KByte of the FLASH memory are used to store firmware, the rest is used to
store BASIC application and data.
11.RTC= Real-Time Counter. Has its own backup power input.
12. PLL= Phase-Locked Loop. Used to control the clock frequency of the device.
When PLL is off, the clock frequency is 11.0592MHz. When PLL is on, the clock
frequency is 88.4736MHz.
13. All I/O pins of this device are 5V-tolerant.
14. Maximum power consumption (PLL on, 100BaseT mode).
15. Dimensions do not include leads (pins).
Hardware Manuals
Click on the pin in the diagram above or one of the links provided below to learn
more about EM100's I/O pins:
Ethernet port lines
Serial port and general-purpose I/O lines
LED lines
Power, reset, and mode selection lines
TX+
TXRX+
RX-
Output
Output
Input
Input
Ethernet port of the EM100 is of 10BaseT type. The EM100 is compatible with all
10BaseT Ethernet hubs and also 99% of 100BaseT hubs. This is because most
100BaseT hubs are actually 100/10 machines that auto-detect the type of device
connected to each port.
The EM100 is designed to attach directly to the RJ45 Ethernet connector. Standard
magnetics circuitry (YCL part 20F001N) has been included onboard to provide a
"glueless" interface to the Ethernet network.
It is important to make the PCB wire connections between the Ethernet port pins
and the RJ45 as short as possible. Making the wires too long may cause the noise
TX
RX
P5
(RTS/DIR)
Output
Input
Input/output
(output)
The application firmware of the EM100 maps certain serial port functions onto the
general-purpose I/O pins- these functions are shown in blue in the table at the top
of this topic. For example, P5 is a universal input/output but the application
firmware can be set to turn this line into the RTS output of the serial port.
Therefore, depending on your application you can view P5 as a general-purpose
I/O line or specific control line of the serial port (RTS).
Being of CMOS type, the serial port and I/O lines of the EM100 can be connected
directly to the serial port pins and I/O lines of most microcontrollers,
Hardware Manuals
LED Lines
#4
L1 (ER) Output
LED output 1, Red Ethernet status LED
#5
L2 (EG) Output
LED output 2, Green Ethernet status LED
#6
L3 (SG) Output
LED output 3, Green status LED
#7
L4 (SR) Output
LED output 4, Red status LED, Watchdog reset line
Line functions defined by the application firmware are shown in blue
The EM100 has four LED control lines. All lines have the same internal structure
and the LEDs should be connected to these lines as shown on the schematic
diagram below. Maximum load for each line is 10mA.
The firmware of the EM100 assigns specific functions to these LED control linesthese functions are shown in blue in the table at the top of this topic.
ER and EG lines reflect the status of the Ethernet port. The EG LED is normally ON,
and is temporarily turned off whenever the EM100 receives a network packet. The
EG is normally OFF, and is temporarily turned on whenever a data collision is
detected on the Ethernet*.
Additionally, ER line serves as a watchdog reset line. A very short (<10us) pulses
are generated on this line at a rate of about 100Hz. When connected to the
watchdog reset pin of external reset/watchdog IC, ER line keeps the watchdog "in
check" preventing it from resetting the EM100. Watchdog reset pulses do not
interfere with the main function of the line (that is, to indicate the status of
Ethernet port). This is because the pulses are so short that they are not visible on
the LED connected to the ER line.
The SR and SG LEDs display various status information depending on what
VCC
Input
Hardware Manuals
When the EM100 is used as a co-processor in a host system the MD line can be
also controlled by the host microcontroller. Ability to control both the RST and DS
lines allows the host microcontroller to switch between the operating modes of the
EM100.
Mechanical
Dimensions
2.1.2.2
L
W
H
I
m
d
p
Max.
Max.
Max.
Min.
Max.
Aver.
Aver.
46.2
28.0
13.0
4.5
1.0
40.6
2.0
Module length
Module width
Module height
Lead length
Lead "flash"
Distance between lead rows
Pin pitch
Specifications
2.1.2.3 and EM100 Modifications
There are five different EM100 sub-models in circulation: EM100-00, EM100-01,
EM100-02, EM100-03, and EM100-04. Currently, only the EM100-04 is being
manufactured so the information on EM100-00...EM100-03 is provided for your
reference only.
The EM100-00, EM100-01, and EM100-02 devices were basically the same, with
only minor changes made to the internal hardware (such as bypass capacitors on
the internal PCB, etc.). We will refer to all three modifications as the EM100-02.
The EM100-03 has extended functionality compared to the EM100-02. There are
two notable differences:
Memory size inside the device has been increased so the routing buffers of the
EM100-03 are double the size of the buffers inside the EM100-02 (510 bytes in
each direction vs. 255 bytes in each direction).
Ability to upgrade the application firmware through the network was added (this
10
EM100-04
10BaseT Ethernet, standard magnetics
built-in
Serial interface and I/O lines
CMOS-level; TX, RX, and 6 additional I/O
lines with RTS, CTS, DTR, DSR implemented
in application firmware
Routing buffers size
510 bytes x 2 (255 bytes x 2)
Maximum load current of I/O lines
10mA
Power requirements
DC 5V, +/- 5%, app. 40 mA
Operating temperature
-10 to +70 degrees C
Operating relative humidity
10-90%
Mechanical dimensions (excl. leads) 46.2x28x13mm
Packing
Plastic tray, 30 modules/tray
Hardware Manuals
11
Manuals for the information on PC software that works with devices running
serial device server firmware.
TiOS (Tibbo Operating System) firmware turns the EM120 into a
BASIC-programmable controller. This controller can be used to created any kind
of network and/or serial port-related control application. When running TiOS, the
EM120 has no pre-defined functionality -- it simply executes your BASIC
application. TiOS and BASIC programming are covered in a separate Manual
("TAIKO Manual").
The application firmware of the EM120 can be upgraded through the module's
serial port or Ethernet port. Serial upgrades are facilitated by a so-called Monitor- a
fixed "service" firmware inside the EM120. The Monitor cannot be upgraded.
Network upgrades rely on the application firmware itself- there is a self upgrade
algorithm that will be detailed later.
By default, the EM120 is supplied with "serial device server" firmware pre-loaded.
If you wish to make the module run your BASIC application you need to upload
TiOS firmware onto the Module. Visit Tibbo website to get the latest TiOS firmware.
Click on the pin in the diagram above or one of the links provided below to learn
more about EM120's I/O pins:
Ethernet port lines
Serial port and general-purpose I/O lines
LED lines
Power, reset, and mode selection lines
TX+
TXRX+
RX-
Output
Output
Input
Input
12
It is important to make the PCB wire connections between the Ethernet port pins of
the EM120 and external magnetics circuitry as short as possible. Making the wires
too long may cause the noise level generated by your PCB surpass the maximum
radiated emission limits stipulated by FCC and CE regulations. Additionally, longer
Ethernet lines on the PCB will make your board more susceptible to the damage
from the ESD (electrostatic discharge).
P8
P7
P6
P1
P0
P3
(DTR)
P2
(DSR)
TX
RX
P4
(CTS/SEL)
Input/output
Input/output
Input/output
Input/output
Input/output
Input/output
(output)
Input/output
(input)
Hardware Manuals
13
The application firmware of the EM120 maps certain serial port functions onto the
general-purpose I/O pins- these functions are shown in blue in the table at the top
of this topic. For example, P5 is a universal input/output but the application
firmware can be set to turn this line into the RTS output of the serial port.
Therefore, depending on your application you can view P5 as a general-purpose
I/O line or specific control line of the serial port (RTS).
Being of CMOS type, the serial port and I/O lines of the EM120 can be connected
directly to the serial port pins and I/O lines of most microcontrollers,
microprocessors, etc. An interface IC* must be added to the EM120 externally if
you want to connect the module to a "true" serial port (for example, COM port of
the PC).
Logical signals on the serial port lines of the EM120 are active LOW. TX and RX
lines are high when idle, start bit is LOW, stop bit is HIGH; LOW on CTS and RTS
lines means "transmission allowed" and HIGH means "transmission not allowed".
This is standard for CMOS-level serial ports and is exactly opposite to the signalling
on the RS232 cables. Logical signals on the EM120 are inverted because standard
interface ICs* invert the signals internally too.
As explained earlier, actual functionality of the I/O lines is firmware-dependent.
See serial port and serial communications for details.
* Such as MAX232 for RS232, MAX485 for RS485, etc.
LED Lines
#1
EG
Output
Green Ethernet status LED
#2
EY
Output
Yellow Ethernet status LED
#21 L3 (SG) Output
LED output 3, Green status LED
#22 L4 (SR) Output
LED output 4, Red status LED
Line functions defined by the application firmware are shown in blue
The EM120 has four LED control lines. All lines have the same internal structure
and the LEDs should be connected to these lines as shown on the schematic
diagram below. Maximum load for each line is 10mA.
14
EG and EY lines reflect the status of the Ethernet port. The EG LED is normally ON,
and is temporarily turned off whenever the EM120 receives a network packet. The
EY is normally OFF, and is temporarily turned on whenever a data collision is
detected on the Ethernet.
SG and SR lines are under firmware control and display various status information
depending on what firmware is running at the moment. Follow the links below to
learn more about the behaviour of these LEDs under different conditions:
SR/SG behavior in the monitor firmware.
SR/SG behavior in the application firmware.
VCC
Input
Hardware Manuals
15
Mechanical
Dimensions
2.1.3.2
L
W
H
I
m
d
p
Max.
Max.
Max.
Min.
Max.
Aver.
Aver.
35.0
27.5
9.1
5.0
0.5
30.0
2.0
Module length
Module width
Module height
Lead length
Lead "flash"
Distance between lead rows
Pin pitch
Specifications
2.1.3.3 and EM120 Modifications
The EM120 has two sub-models in circulation- the EM120-00 and EM120-01. The
EM120-01 is a RoHS-compliant version of the EM120-00. There are no other
differences between these two versions. Currently, only the EM120-01 is being
16
EM120-01
10BaseT Ethernet, magnetics not built-in
CMOS-level; TX, RX, and 9 additional I/O
lines with RTS, CTS, DTR, DSR implemented
in application firmware
Routing buffers size
12Kbytes x 2*
Maximum load current of I/O lines
10mA
Power requirements
DC 5V, +/- 5%, app. 50mA
Operating temperature
-10 to +70 degrees C
Operating relative humidity
10-90%
Mechanical dimensions (excl. leads) App. 35x27.5x9.1mm
Packing
Plastic tray, 50 modules/tray
* Maximum possible buffer size. Actual size may be smaller depending on how
much RAM is "consumed" by the firmware
Hardware Manuals
17
Click on the pin in the diagram above or one of the links provided below to learn
more about EM200's I/O pins:
Ethernet port lines
Serial port and general-purpose I/O lines
LED lines
Power, reset, and mode selection lines
TX+
18
RX-
Ethernet port of the EM200 is of 100BaseT type. Onboard electronics of the EM200
do not include Ethernet magnetics, so magnetic circuitry must be connected
externally. You can use either a standalone magnetics part (such as
YCL-PH163112) or RJ45 connector with integrated magnetics (for example,
YCL-PTC1111-01G). Diagrams below show circuit diagrams for both parts.
Please, note the following:
The 3.3Vout is an output that provides clean power for the magnetics circuitry,
which is very sensitive to noise.
Do not combine 3.3Vout with the VCC (main power) pin. This is
counter-productive and will cause FCC/CE certification issues.
Hardware Manuals
19
It is important to make the PCB wire connections between the Ethernet port pins of
the EM200 and external magnetics circuitry as short as possible. Making the wires
too long may cause the noise level generated by your PCB surpass the maximum
radiated emission limits stipulated by FCC and CE regulations. Additionally, longer
Ethernet lines on the PCB will make your board more susceptible to the damage
from the ESD (electrostatic discharge).
P8
P7
P6
P1
P0
P3
(DTR)
P2
(DSR)
TX
RX
P4
(CTS/SEL)
Input/output
Input/output
Input/output
Input/output
Input/output
Input/output
(output)
Input/output
(input)
20
Device server application firmware of the EM1000 maps certain serial port
functions onto the general-purpose I/O pins- these functions are shown in blue in
the table at the top of this topic. For example, P5 is a universal input/output but
the application firmware can be set to turn this line into the RTS output of the
serial port. Therefore, depending on your application you can view P5 as a
general-purpose I/O line or specific control line of the serial port (RTS).
Being of CMOS type, the serial port and I/O lines of the EM200 can be connected
directly to the serial port pins and I/O lines of most microcontrollers,
microprocessors, etc. An interface IC* must be added to the EM200 externally if
you want to connect the module to a "true" serial port (for example, COM port of
the PC).
Logical signals on the serial port lines of the EM200 are active LOW. TX and RX
lines are high when idle, start bit is LOW, stop bit is HIGH; LOW on CTS and RTS
lines means "transmission allowed" and HIGH means "transmission not allowed".
This is standard for CMOS-level serial ports and is exactly opposite to the signalling
on the RS232 cables. Logical signals on the EM200 are inverted because standard
interface ICs* invert the signals internally too.
As explained earlier, actual functionality of the I/O lines is firmware-dependent.
See serial port and serial communications for details.
* Such as MAX232 for RS232, MAX485 for RS485, etc.
LED Lines
#1
EG
Output
Green Ethernet status LED
#2
EY
Output
Yellow Ethernet status LED
#21 L3 (SG) Output
LED output 3, Green status LED
#22 L4 (SR) Output
LED output 4, Red status LED
Line functions defined by the application firmware are shown in blue
The EM200 has four LED control lines. All lines have the same internal structure
and the LEDs should be connected to these lines as shown on the schematic
diagram below. Maximum load for each line is 10mA.
Hardware Manuals
21
EG and EY lines reflect the status of the Ethernet port. The EG LED is switched on
whenever a live Ethernet connection is detected by the EM200's Ethernet port. The
EG LED is momentarily switched off whenever the EM200 receives a network
packet. The EY shows whether current Ethernet link is of 10BaseT type (EY off) or
100BaseT (EY on).
SG and SR lines are under firmware control and display various status information
depending on what firmware is running at the moment. Follow the links below to
learn more about the behaviour of these LEDs under different conditions:
SR/SG behavior in the monitor firmware.
SR/SG behavior in the application firmware.
VCC
Input
22
Mechanical
Dimensions
2.1.4.2
L
W
H
I
m
d
p
Max.
Max.
Max.
Min.
Max.
Aver.
Aver.
32.1
18.5
7.3
2.2
0.5
28.0
1.27
Module length
Module width
Module height
Lead length
Lead "flash"
Distance between lead rows
Pin pitch
Specifications
2.1.4.3 and EM200 Modifications
The EM200 has two sub-models in circulation- the EM200-00 and EM200-01. The
EM200-01 is a RoHS-compliant version of the EM200-00. There are no other
differences between these two versions. Currently, only the EM200-01 is being
manufactured.
Hardware Manuals
23
EM200-01
10/100BaseT Ethernet, magnetics not
built-in
CMOS-level; TX, RX, and 9 additional I/O
lines with RTS, CTS, DTR, DSR implemented
in application firmware
12Kbytes x 2*
10mA
DC 5V, +/- 5%, app. 220mA
+55 degrees C** (in 100BaseT mode)
-10 to +70 degrees C
10-90%
App. 32.1x18.5x7.3mm
Plastic tray, 50 modules/tray
* Maximum possible buffer size. Actual size may be smaller depending on how
much RAM is "consumed" by the firmware
** As measured on top of the device
The EM202 is a "RJ45 form factor" Ethernet Module for onboard installation. Module
hardware includes one 100BaseT Ethernet port (standard Ethernet magnetics and
RJ45 connector are integrated in the EM202*), one serial port (CMOS-level), and
an internal processor, whose firmware acts as a bridge between the Ethernet and
serial ports. Standard Ethernet cable plugs directly into the RJ45 connector on the
network "side" of the Module. Serial "side" interfaces directly to the serial port pins
of most microcontrollers, microprocessors, UARTs, etc.
From the hardware standpoint, the EM202 can be viewed as a universal platform
suitable for running a variety of network and serial communications-related
applications. It is the application firmware, not the hardware that gives the EM202
most of its functionality.
The EM202 can run two distinctively different kinds of application firmware:
The "serial device server" firmware, currently in its 3rd generation ("Release3"),
turns the EM202 into a ready-to-work Serial Device Server that can connect
almost any kind of serial device to the Ethernet (TCP/IP) network. This firmware
has fixed functionality; you adjust the way the EM202 behaves by specifying the
values of programmable parameters (settings) defined in this firmware.
Functional description of the EM202 under the "serial device server" firmware can
be found in the Device Server Application Firmware Manual. Also see Software
Manuals for the information on PC software that works with devices running
serial device server firmware.
24
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
#11
MD (MD)
RST
P3
(DTR)
P2
(DSR)
L3
(SG)
L4
(SR)
VCC
GND
RX
TX
P4
(CTS/SEL)
Input
Input
Input/output
(output)
Input/output
(input)
Output
(output)
Output
(output)
Input
Output
Input/output
(input)
Hardware Manuals
#12
25
P5
Input/output
(RTS/DIR) (output)
P3
(DTR)
P2
(DSR)
RX
TX
P4
(CTS/SEL)
Input/output
(output)
Input/output
(input)
The application firmware of the EM202 maps certain serial port functions onto the
general-purpose I/O pins- these functions are shown in blue in the table at the top
of this topic. For example, P5 is a universal input/output but the application
26
LED Lines
#5
L3* (SG) Output
LED output 3, Green status LED
#6
L4* (SR) Output
LED output 4, Red status LED
Line functions defined by the application firmware are shown in blue
The EM202 has two LED control lines. Both lines have the same internal structure.
Each line drives one internal LED (see figure below). If you want to connect an
external LEDs as well you may do so but we recommend using a TTL buffer
element to reduce the load on the I/O line of the EM202's internal microcontroller.
Maximum load for each line without the buffer is 2mA.
The firmware of the EM202 uses L3 and L4 as "status LEDs" which display various
status information depending on what firmware is running at the moment. Follow
the links below to learn more about the behaviour of these LEDs under different
conditions:
SR/SG behavior in the monitor firmware.
SR/SG behavior in the application firmware.
Hardware Manuals
27
* There are no lines L1 and L2. Line names were selected for naming compatibility
with the EM100
VCC
Input
28
Built-in2.1.5.2
LEDs
The EM202 features four built-in LEDs (shown on figure below) that are placed on
the front of the device, next to the RJ45 connector.
Built-in2.1.5.3
RJ45 Ethernet Connector
TX+
TXRX+
<No connection>
Hardware Manuals
#5
#6
#7
#8
<No connection>
RX<No connection>
<No connection>
Mechanical
Dimensions
2.1.5.4
L
W
w
H
I
M
t1
t2
t3
p
s1
s2
s3
s4
s5
h1
h2
Max.
Max.
Max.
Max.
Min.
Min.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Max.
Aver.
Aver.
32.3
20.0
19.0
16.0
4.5
1.9
2.45
1.5
0.25
1.27
29.7
6.3
19.0
23.0
5.0
17.5
18.5
Module length
Module width including mounting holders
Module width excluding mounting holders
Module height
Lead length
Height of mounting holders and solder pins
Mounting holder diameter
Solder pin width
Solder pin thickness
Pin pitch
Distance from device "face" to the leads
Distance from leads to the center of "pockets"
Distance from leads to the mounting solder pins
Distance from leads to the mounting holders
"Pocket" length
Distance between center lines of mounting holders
Distance between center lines of mounting solder pins
29
30
Specifications
2.1.5.5 and EM202 Modifications
The EM202 has two sub-models in circulation- the EM202-00 and EM202-01. The
EM202-01 is a RoHS-compliant version of the EM202-00. There are no other
differences between these two versions. Currently, only the EM202-01 is being
manufactured.
Device specifications are presented in the table below.
Parameter
Ethernet interface
Serial interface and I/O lines
EM202-01
10/100BaseT Ethernet, standard magnetics
and RJ45 connector built-in
CMOS-level; TX, RX, and 4 additional I/O
lines with RTS, CTS, DTR, DSR implemented
in application firmware
12Kbytes x 2*
10mA
DC 5V, +/- 5%, app. 230 mA (in 100BaseT
mode)
+40 degrees C** (in 100BaseT mode)
* Maximum possible buffer size. Actual size may be smaller depending on how
much RAM is "consumed" by the firmware
** As measured on top of the device
Please, make sure that you read the following topic: EM1000-00 and -01.
The EM1000 is a BASIC-programmable Ethernet Module for onboard installation.
Module hardware includes:
High-performance (88MIPS) RISC processor.
One 100BaseT Ethernet port with Auto-MDIX (automatic detection of "straight"
and "cross" cables). Standard Ethernet magnetics are NOT integrated into the
Module.
Support for UDP(1), TCP(1), ICMP (ping)(1), DHCP(1), and HTTP(1) protocols; up to 16
Hardware Manuals
31
32
EM1000-00
and -01
2.1.6.1
Small hardware changes were made to the EM1000 since its first release.
Currently Tibbo supplies version "-01" of the module. The first version ever
supplied was "-00". The main difference is in the Ethernet IC: the EM1000-...-00
used Davicom's DM9000 while the EM1000-...- 01 features newer DM9000A. This
change reduced module's current consumption and operating temperature.
Unfortunately, this transition requires certain changes to how Ethernet magnetics
and RJ45 are wired to the module. Tibbo apologizes for any inconvenience caused!
Throughout this document, differences between hardware versions of the module
are highlighted in pink. Please, note that from the programming standpoint there
are no functional differences between the EM1000-...- 00 and EM1000-...- 00.
Pictures below show the original EM1000-...- 00 and the EM1000-...- 01.
This is how the original EM1000-...- 00 looks like:
Hardware Manuals
33
I/O pin assignment for the EM1000 Module is provided in the table below.
Additional information on various hardware modules of the EM1000 can be found in
the following topics:
General-purpose I/O Lines
Ethernet Port Lines
Serial Ports
Square Wave Generator
FLASH and EEPROM Memory
Real-time Counter
LED Lines
Power, Reset, PLL Control, and Mode Selection Lines
I/O pin assignment for the EM1000 Module
Pin
#
1
(1)
Function
Description
GPIO0/RTS0/W0out0/
cout0 (2)
34
3
(1)
4
(1)
GPIO1/RTS1/W0out1/
cout1 (2)
GPIO2/RTS2/W0out2/
cout2 (2)
GPIO3/RTS3/W0out3/
cout3 (2)
GPIO4/DTR0 (3)
(1)
GPIO5/DTR1 (3)
(1)
GPIO6/DTR2 (3)
(1)
GPIO7/DTR3 (3)
(1)
GPIO8/RX0/W1in0/din0 (4)
(1)
10
GPIO9/TX0/W1out0/dout0
(1)
(4)
11
GPIO10/RX1/W1in1/din1 (4)
(1)
12
(1)
13
GPIO11/TX1/W1out1/
dout1 (4)
GPIO12/RX2/W1in2/din2 (4)
(1)
14
(1)
15
GPIO13/TX2/W1out2/
dout2 (4)
GPIO14/RX3/W1in3/din3 (4)
(1)
16
(1)
17
(1)
18
(1)
19
(1)
20
(1)
21
(1)
GPIO15/TX3/W1out3/
dout3 (4)
GPIO16/INT0/CTS0/
W0&1in0/cin0 (5)
GPIO17/INT1/CTS1/
W0&1in1/cin1 (5)
GPIO18/INT2/CTS2/
W0&1in2/cin2 (5)
GPIO19/INT3/CTS3/
W0&1in3/cin3 (5)
GPIO20/INT4/DSR0 (6)
Hardware Manuals
22
GPIO21/INT5/DSR1 (6)
35
GND
GPIO44
GPIO25
GPIO24
GPIO27
GPIO26
GPIO29
GPIO28
GPIO31
GPIO30
GPIO33
GPIO32
GPIO35
GPIO34
GPIO37
GPIO36
GPIO39
GPIO38
47
48
49
50
MD
<TEST PIN>
RST
PM
51
SR
(1)
23
GPIO22/INT6/DSR2 (6)
(1)
24
GPIO23/INT7/DSR3 (6)
(1)
25
GPIO40/DCD0 (7)
(1)
26
GPIO41/DCD1 (7)
(1)
27
GPIO42/DCD2 (7)
(1)
28
GPIO43/DCD3 (7)
(1)
29
30
(1)
31
(1)
32
(1)
33
(1)
34
(1)
35
(1)
36
(1)
37
(1)
38
(1)
39
(1)
40
(1)
41
(1)
42
(1)
43
(1)
44
(1)
45
(1)
46
(1)
36
SG
GPIO46
GPIO45/CO
GPIO48
GPIO47
57
DBGRX
58
VCCB
59
DBGTX
60
VCC
61
TX-
62
AVCC
63
TX+
64
65
EY
EM1000-...- 00: --EM1000-...- 01: SCAP
66
67
EG
RX-
68
(1)
54
(1)
55
(1)
56
(1)
69
70
Notes:
1. This line is 5V-tolerant and can be interfaced to 5V CMOS devices directly.
2. Pin function shown in blue is implemented in firmware and can be remapped
(reassigned) to any other I/O pin (provided that this pin is not occupied by some
other function).
3. DTR is not a special pin of the serial port, it is just an I/O pin that can be
controlled by BASIC application. The word "conventionally" refers to the fact
that Tibbo will typically use this pin to serve as a DTR line. This does matter for
board level and external devices.
4. Pin function shown in blue is implemented in firmware.
5. Pin function shown in blue is implemented in firmware and can be remapped
Hardware Manuals
37
(reassigned) to any other interrupt I/O pin INT0-INT7 (provided that this pin is
not occupied by some other function).
6. DSR is not a special pin of the serial port, it is just an I/O pin that can be
controlled by BASIC application. The word "conventionally" refers to the fact
that Tibbo will typically use this pin to serve as a DSR line. This does matter for
board level and external devices.
7. DCD is not a special pin of the serial port, it is just an I/O pin that can be
controlled by BASIC application. The word "conventionally" refers to the fact
that Tibbo will typically use this pin to serve as a DCD line. This does matter for
board level and external devices.
I/O pin control is described in details in the documentation for the "IO object"
found inside the "TAIKO Manual".
38
Hardware Manuals
39
Once again, the EM1000-...- 00 is a legacy part that has been replaced with the
EM1000-...- 01. In case you have already made the PCB based on the
EM1000-...- 00 specifications and are not willing to change it, you can easily
modify it to accommodate the EM1000-...- 01 (see diagram below):
Do not install four 50 Ohm resistors (they are crossed out on the diagram).
Connect a wire between pins 4 and 7 of the RJ45 connector (pin numbers are for
YCL-PTC1111-01G).
If possible, find a way to install a 220uF capacitor. The circuit will still work even
if you don't have this capacitor but you may have FCC/CE certification issues.
Notice that one of the 0.1 capacitors becomes redundant but that's OK.
All of the above is based on the assumption that your host PCB was designed
correctly and the AVCC output of the EM1000 is not joined together with the
main VCC line. If you erroneously had AVCC and VCC combined together then
you will need to separate them as well: pin AVCC outputs 2.5V on the
EM1000-...- 01 and this is different from the main power on the VCC pin, which
is 3.3V. Applying 3.3V to pin AVCC of the EM1000-...- 01 appears to be causing
no immediate permanent damage to the device, but the circuit will not work and
the effects of prolonged over-voltage on the AVCC line are not known.
It is important to make the PCB wire connections between the Ethernet port pins of
the EM1000 and external magnetics circuitry as short as possible. Making the wires
too long may cause the noise level generated by your PCB surpass the maximum
radiated emission limits stipulated by FCC/CE regulations. Additionally, longer
Ethernet lines on the PCB will make your board more susceptible to the damage
from the ESD (electrostatic discharge).
The EM1000 also has two Ethernet status LED control lines- see here for details.
40
Serial Ports
The EM1000 has four serial ports that can work in one of the three modes: UART,
Wiegand, or clock/data. All three modes are described in details in the
documentation for the "serial object" found inside the "TAIKO Manual".
Additionally, see the "Platform-dependent programming information" section inside
the "EM1000" platform documentation (same manual).
Notice that some serial port functionality is hardwired and some is implemented in
firmware.
Real-time Counter
The real-time counter (RTC) of the EM1000 is a free-running 40-bit register that
increments at a rate of 128Hz.
As a source of backup power, the EM1000 can rely on a supercapacitor. Option "-S"
of the device (see Specifications and EM1000 Modifications) has an onboard
supercapacitor. To enable charging, connect 3.3V power to the VCCB pin of the
EM1000, preferably through a current-limiting resistor (50 Ohm is a good value). A
fully discharged supercapacitor creates a nearly short-current inrush when it starts
charging and this can damage the power supply on the host board.
Hardware Manuals
41
The EM1000-...-S carries the supercapacitor on the bottom side of its PCB (see
Mechanical Dimensions). With this supercapacitor present, it is impossible to solder
the module into the host PCB directly and the module can only be installed on the
socket. If this is not acceptable you can use a "plain" EM1000 (not "-S") and
connect an external supercapacitor to the SCAP pin of the EM1000. This option is
only available in the EM1000-...- 01 device (EM1000-...- 00 does not have the
SCAP pin).
The supercapacitor has many advantages- it charges almost immediately and has
virtually unlimited life. The disadvantage is that the supercapacitor is only able to
sustain the RTC of the EM1000 for several days at most (about 6 days for the 5F
supercapacitor of the EM1000-...-S), which may appear to be insufficient.
Remember, however, that the EM1000 is a "connected" device. As such, it can
always synchronize its clock with the Internet time or the master clock on some
server in your system. Therefore, the role of the supercapacitor is to provide
backup power during relatively short periods of power absence, for example when
the device is unplugged and being moved to another location, or when the device
is powered off over the weekend.
It is also possible to use a lithium 3V battery to power the RTC (in this case, do not
use the EM1000 with "-S"). Connect the battery to the VCCB pin through a small
SMT Shotty diode. This diode is necessary to slightly reduce the voltage on the
VCCB pin. You can calculate the time the battery will be able to sustain the
EM1000 from the average backup current -- this current is ~13uA.
Your BASIC application can access the RTC through the "rtc object", which is
documented in the "TAIKO Manual".
LED Lines
This topic covers the following pins of the EM1000: EG, EY, SG, and SR.
The EM1000 has four LED control lines. All lines have the same internal structure
and the LEDs should be connected to these lines as shown on the schematic
diagram below. Maximum load for each line is 10mA.
42
EG and EY lines reflect the status of the Ethernet port. The EG LED is switched on
whenever a live Ethernet connection is detected by the EM1000's Ethernet port.
The EG LED is momentarily switched off whenever the EM1000 receives a network
packet. The EY shows whether current Ethernet link is of 10BaseT type (EY off) or
100BaseT (EY on).
SG and SR lines are under firmware control and display various status information.
The Monitor uses these LEDs to display various status information during the
firmware upgrade through the serial port. When the EM1000 is running TiOS
firmware and your BASIC application is not running, these LEDs are used to display
the status of loaded project. When your BASIC program is executing, the SG and
SR LEDs can be controlled by your application through the "pat object" (see
"TAIKO Manual").
Hardware Manuals
43
The state of the PM pin at power-on or external reset (i.e. reset pulse on the RST
line) defines whether the EM1000 will run with PLL on or off. To have the PLL on,
leave the PM pin unconnected. To disable PLL and run at lower clock frequency,
ground the PM pin.
Your BASIC application can also change the PLL mode programmatically. The
application can check the current PLL mode through the "sys object" (see "TAIKO
Manual"). If the PLL mode needs to be changed, the application can set new mode
and then perform an internal reset (again, through the "sys object"). The internal
reset is identical to the power-on or external reset with one difference: the PLL
mode is set basing not on the PM pin but on the PLL mode requested by the
application prior to the reset.
The MD line of the EM1000 is used to select the operating mode of the EM1000.
When the EM1000 powers up it verifies the state of the MD input. If the MD input is
at HIGH the EM1000 proceeds to verifying and running the application firmware
(TiOS) loaded into its internal FLASH memory. If the MD input is at LOW the
EM1000 enters the serial upgrade mode.
Typically, a button is connected to the MD line. Your application can also work with
this button through the "button object" (see "TAIKO Manual").
*Current consumption figures for the 100BaseT mode of the Ethernet controller.
Mechanical
Dimensions
2.1.6.3
L
W
H
H'
Max.
Max.
Max.
Max.
38.4
28.4
5.5
9.5
Min.
6.0
Module length
Module width
Module height (option without supercapacitor)
Module height ("-S" option -- with supercapacitor installed).
In this case the EM1000 is meant to be mounted on a
socket.
Lead length
44
Aver.
2.54
Pin pitch
Specifications
2.1.6.4 and EM1000 Modifications
The EM1000 currently has two sub-models available:
Model number
EM1000-512K-01
EM1000-512K-S-01
Description
EM1000 Module with 512KBytes of FLASH
memory
EM1000 Module with 512KBytes of FLASH
memory and supercapacitor (backup power
source for the RTC)
Hardware Manuals
Nominal power supply
voltage (VCC pin)
Reset circuit trip voltage
(VCC pin)
45
DC 3.3V, +/- 5%
3.0V on power-up (i.e. when the voltage on VCC is
rising)
2.9V on brown-out (i.e. when the voltage on VCC is
dropping)
40mA with PLL off, Ethernet cable unplugged
50mA with PLL off, 10BaseT mode
110mA with PLL off, 100BaseT mode
160mA with PLL on, Ethernet cable unplugged
170mA with PLL on, 10BaseT mode
230mA with PLL on, 100BaseT mode
2.2V - 3.3V (option without "-S" only)
Ethernet-to-Serial Boards
This part of documentation describes Ethernet-to-serial Boards supplied by Tibbo.
These boards can be used for convenient evaluation and testing of Tibbo
Ethernet-to-serial Modules. At the same time, some boards are also suitable for
46
The EM100-EV Evaluation Board offers a convenient way of testing EM100 Ethernet
Module. The board features the following components:
A socket for EM100 Module installation
Power jack and a linear voltage regulator circuitry (12VDC-->5VDC, adaptor
current rating must be no less than 500mA)
RJ45 connector
DB9M RS232 connector and RS232 transceiver (supported signals are RX, TX,
RTS, CTS)
Setup button (connected to the MD line of the EM100)
Ethernet LEDs and Status LEDs (connected to LED lines of the EM100)
Hardware Manuals
47
Power 2.2.1.1
Jack
Power Jack of the EM100-EV accepts "large" power connectors with 5.5mm
diameter. Use ARP-1014, ARP-1015A, or ARP-1018Apower adaptor supplied by
Tibbo or similar adaptor. Nominal voltage is 12VDC and adaptor current rating
should be at least 500mA. On the power jack, the ground is "on the outside", as
shown on the figure below.
Ethernet
Port Pin Assignment
2.2.1.2
RJ45 Ethernet connector has the following pin assignment:
#1
#2
#3
#4
#5
#6
#7
#8
TX+
TXRX+
<No connection>
<No connection>
RX<No connection>
<No connection>
RS232 2.2.1.3
Port Pin Assignment
DB9M RS232 connector has the following pin assignment:
#1
#2
#3
#4
#5
#6
#7
#8
#9
<No connection>
RX (input)
TX (output)
<No connection>
Ground
<No connection>
RTS (output)
CTS (input)
<No connection>
48
Power 2.2.2.1
Jack
Power Jack of the EM120/EM200-EV accepts "large" power connectors with 5.5mm
diameter. Use ARP-1014, ARP-1015A, or ARP-1018A power adaptor supplied by
Tibbo or similar adaptor. Nominal voltage is 12VDC and adaptor current rating
should be at least 500mA. On the power jack, the ground is "on the outside", as
shown on the figure below.
Hardware Manuals
Ethernet
Port Pin Assignment
2.2.2.2
RJ45 Ethernet connector has the following pin assignment:
#1
#2
#3
#4
#5
#6
#7
#8
TX+
TXRX+
<No connection>
<No connection>
RX<No connection>
<No connection>
RS232 2.2.2.3
Port Pin Assignment
DB9M RS232 connector has the following pin assignment:
#1
#2
#3
#4
#5
#6
#7
#8
#9
<No connection>
RX (input)
TX (output)
DTR (output)
Ground
DSR (input)
RTS (output)
CTS (input)
<No connection>
49
50
Expansion
Connector Pin Assignment
2.2.2.4
15-pin expansion connector has the following pin assignment:
P0
P1
P6
P7
P8
GND
VCC
RST
MD
DTR
RTS
TX
RX
CTS
DSR
Output signals that are present both on the DB9M and expansion connectors (DTR,
RTS, TX) need not be switched. So, for example, the TX (output) line from the
EM120/EM200 is connected to the RS232 transceiver IC and to the expansion
connector. For input signals (RX, CTS, DSR) there must be a way to disconnect the
RS232 transceiver IC from the EM120/EM200. Three jumpers (combined with pins
RX, CTS, DSR of the expansion connector) serve this purpose.
For example, when the RX jumper is closed the RX pin of the EM120/EM200
receives a signal from the RS232 transceiver. When the jumper is opened you can
use the RX pin on the expansion connector to supply a TTL RX signal from your
own external board. Figure below illustrates this.
Maximum load for all CMOS-type lines (P0, P1, ... RX, TX...) is 10mA.
Hardware Manuals
51
EM202-EV-RS EM202-EV-TM
(RS232)
(TTL master)
YES
EM202-EV-TS
(TTL slave)
YES
YES
YES
YES
NO
Power Jack
Switching power supply
Reset IC
NO
NO
NO
YES*
YES
YES
YES
NO
NO
NO
52
Power 2.2.3.1
Jack
Power Jack of the EM202-EV accepts "small" power connectors with 3.5mm
diameter. Use ARP-P0005, ARP-P0006, or ARP-P0007 power adaptor supplied by
Tibbo or similar adaptor. Acceptable supply power range is 10-25VDC. Adaptor
current rating should be at least 500mA. On the power jack, the ground is "on the
outside", as shown on the figure below.
Ethernet
Port Pin Assignment
2.2.3.2
RJ45 Ethernet connector has the following pin assignment:
#1
#2
#3
#4
#5
#6
#7
#8
TX+
TXRX+
<No connection>
<No connection>
RX<No connection>
<No connection>
RS232 2.2.3.3
Port Pin Assignment
DB9M RS232 connector (only available on EM202-EV-RS) has the following pin
assignment:
Hardware Manuals
#1
#2
#3
#4
#5
#6
#7
#8
#9
53
<No connection>
RX (input)
TX (output)
DTR (output)
Ground
DSR (input)
RTS (output)
CTS (input)
<No connection>
TTL Interface
2.2.3.4Connector Pin Assignment
10-pin TTL interface connector (available on EM202-EV-TM and EM202-EV-TS) has
the following pin assignment:
EM202-EV-TM
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
RST (output)
+5V VCC (output)
EM202-EV-TS
P5(RTS/DIR) of EM202
P4(CTS/DIR) of EM202
TX of EM202
RX of EM202
P2(DSR) of EM202
P3(DTR) of EM202
MD (wire AND)
RST (input)
Ground
+5V VCC (input)
Notice, that MD is a "wire AND" line and is pulled low internally when the
download/setup button is pressed on the board. Therefore, if your circuit needs to
control this line it needs to do so through an open collector output.
Another point where care should be exercised is related to RST and VCC pins. On
the EM202-EV-TM these are outputs, while on the EM202-EV-TS these pins are
inputs.
Maximum load for all CMOS-type lines (TX, RX, P2,...) is 10mA.
54
Mechanical
Dimensions
2.2.3.5
L
l
Aver.
Aver.
52.6
2.7
W
H
Aver.
Max.
38.0
17.5
t
m1
m2
m3
m4
m5
m6
d1
d2
d3
d4
n1
n2
n3
n4
n5
n6
n7
n8
n9
n10
h1
h2
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
Aver.
1.6
26.0
14.0
19.0
45.0
31.0
21.0
4.2
2.3
5.0
3.3
11.0
XXX
40.5
46.9
50.1
33.0
6.0
15.0
5.1
14.5
7.5
5.9
Board length
Distance from the PCB edge to the front face of EM202,
power jack, and setup button
Board width
Board height excluding the heing of the tallest component
on the bottom side of the PCB
PCB thickness
Distance between mounting holes
Distance to the mounting holes
Distance to the mounting holes
Distance to the mounting holes
Distance between mounting holes
Distance between mounting holes
Mounting hole diameter
Mounting hole diameter
LED diameter
Setup button diameter
PCB outline dimension
PCB outline dimension
Distance to the LEDs
Distance to the TTL interface connector
PCB outline dimension
PCB outline dimension
Distance between LEDs
Distance to the power jack
Power jack width
Distance to the setup button
Power jack height
Distance to the center of setup button
Hardware Manuals
h3
Max.
2.5
h4
h5
p
Aver.
Max.
Aver.
6.2
9.0
2.0
55
The EM1000-EV Evaluation Set offers a convenient way of testing EM1000 Ethernet
Modules. The board features the following components:
Metal base.
Network PCB with EM1000 Ethernet Module installed on a socket, Ethernet port
(RJ45) connector, Ethernet Status LEDs, Mode and Resetbuttons, power jack
and power terminals, power supply circuit, buzzer, and three jumpers.
Interface PCB with four RS232 transceivers, two DB9M connectors for serial ports
1 and 2, two 2x5 headers for attaching two more external DB9M connectors for
serial ports 3 and 4, and three jumpers.
Network-side LEDs installed on a separate PCB. These LEDs include: System
Status LEDs (green and red), Ethernet Status LEDs (green and yellow), and an
56
EM1000-EV-00
2.2.4.1 and -01
Small hardware changes were made to the EM1000 since its first release.
Currently Tibbo supplies version "-01" of the module. The first version ever
supplied was "-00". The main difference is in the Ethernet IC: the EM1000-...-00
used Davicom's DM9000 while the EM1000-...- 01 features newer DM9000A. This
change reduced module's current consumption and operating temperature.
Unfortunately, this transition requires certain changes to how Ethernet magnetics
and RJ45 are wired to the module.
Because of the above difference, the EM1000-EV boards also exist in two versions:
the EM1000-EV-00 for the EM1000-00 and EM1000-EV-01 -- for the EM1000-01.
Throughout this document, differences between hardware versions of the EM1000EV are highlighted in pink.
Notice, that the EM1000-...- 00 module will only work properly with the
EM1000-EV-00. If you plug it into the EM1000-EV-01 you won't be able to
communicate with the module through the Ethernet. Likewise, the EM1000-...- 01
can only work with the EM1000-EV-01 board. Moreover, running the EM1000-...01 on the EM1000-EV-00 board for prolonged period of time may theoretically
lead to a permanent damage to the EM1000-...- 01 device.
The skilled and adventurous can easily convert the EM1000-EV-00 board into the
EM1000-EV-01.
Hardware Manuals
57
(2) Cut the 3.3V wire trace in two places (do not cut any other wire by mistake -the 3.3V trace is thicker):
58
(3) Install two wires on the bottom side of the PCB as shown below:
Hardware Manuals
59
That is it! Your work is done. And if the board doesn't work after that you can send it
to us for repair :-)
Power 2.2.4.2
Jack and Power Terminals
Power Jack of the EM202-EV accepts "small" power connectors with 3.5mm
diameter. Use ARP-P0005, ARP-P0006, or ARP-P0007 power adaptor supplied by
Tibbo or similar adaptor. Acceptable supply power range is 10-25VDC. Adaptor
current rating should be at least 500mA. On the power jack, the ground is "on the
outside", as shown on the figure below.
Another way to connect power is through the power terminals located next to the
power jack. Ground and "+" terminal positions are shown on the main diagram.
60
Ethernet
Port (RJ45) Pin Assignment
2.2.4.3
RJ45 Ethernet connector has the following pin assignment:
#1
#2
#3
#4
#5
#6
#7
#8
TX+
TXRX+
<No connection>
<No connection>
RX<No connection>
<No connection>
RS232 2.2.4.4
Port (DB8M) and 2x5 Header Pin Assignment
The EM1000-EV has four serial ports marked 1-4 on the main diagram. Note that
the EM1000 "counts" its serial ports from 0. . Therefore, ports 1-4 on the
EM1000-EV correspond to ports 0-3 on the EM1000.
DB9M connectors has the following pin assignment:
#1
#2
#3
#4
#5
#6
#7
#8
#9
<No connection>
RX (input)
TX (output)
DTR (output)
Ground
DSR (input)
RTS (output)
CTS (input)
<No connection>
Hardware Manuals
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
61
<No connection>
RX (input)
TX (output)
DTR (output)
Ground
DSR (input)
RTS (output)
CTS (input)
<No connection>
<No connection>
LEDs 2.2.4.5
This section covers all LEDs of the EM1000-EV Evaluation Board.
System Status LEDs
This is a pair of green and red LEDs connected to the SG and SR pins of the
EM1000. Status LEDs are used to display various status information -- see here for
details.
Ethernet Status LEDs
Two identical pairs of these LEDs are present on the EM1000-EV board: one pair is
located on the network board, another one- on the network LED board. Each pair
consists of a yellow and green LED connected to the EY and EG pins of the
EM1000. These LEDs display current Ethernet link state -- see here for details.
LED "bar"
Five yellow LEDs of the LED bar can display the strength of the wireless signal
(when the EM1000 has an optional wireless board installed). These LEDs are
controlled through three GPIO lines of the EM1000- GPIO46, GPIO47, and
GPIO48.
GPIO46 is a reset line of the LED bar. Setting this line to low sets all five outputs to
LOW and this turns all LEDs ON. GPIO47 is a clock line- a negative transition on
this line "shifts in" the data on the GPIO48, which is the data line. The circuit that
controls LEDs looks like this:
62
Notice, that the data on the data line will be inverted. Therefore, if you want to
switch the LEDs ON set the data line HIGH. This will produce LOW on the outputs,
and this will turn an LED on.
As an example, let's say that you need to have LED1, LED2, and LED3 off, while
LED4 and LED5 are on. To achieve this:
Generate a negative pulse on the reset line- this will turn all five LEDs on.
Set the data line to LOW.
Generate three negative pulses on the CLOCK line.
LED pairs on the network LED PCB
There are four pairs, each consisting of a red and green LED. These LEDs are
connected to GPIO24 thru GPIO31 of the EM1000 (see main diagram). The LED is
on when corresponding GPIO line is at logical LOW. Four LED pairs are intended for
displaying the state of four serial ports of the interface board.
Jumpers
and Buttons
2.2.4.6
This section covers all jumpers of the EM1000-EV Evaluation Board.
PLL jumper
Leave this jumper open if you want the EM1000 to run at 88.4736MHz. Close the
jumper if you want the EM1000 to run at 11.0592MHz. Notice, that the jumper
state is only recognized after the power-up or external reset (caused by pressing
the RST button). For more information on PLL check Power, Reset, PLL Control, and
Mode Selection Lines.
US jumper
This jumper is reserved for factory testing. Leave it opened.
MD jumper and Mode button
Powering up or the EM1000 (or pressing Reset button) while pressing the Mode
button or keeping the MD jumper closed causes the EM1000 to enter the serial
upgrade mode. The jumper and the button are connected to the MD pin of the
EM1000. Firmware upgrades through the serial port always use the serial port 1.
Hardware Manuals
63
For more information see Power, Reset, PLL Control, and Mode Selection Lines.
Reset button
This button is connected to the RST pin of the EM1000. Pressing this button causes
"external" reset. For more information see Power, Reset, PLL Control, and Mode
Selection Lines.
Three jumpers on the interface board
Keep all three jumpers in the 1-2 position. Position 2-3 disconnects the serial port
3 of the EM1000 from the DB9 connector #4 (ports 0-3 of the EM1000 correspond
to ports 1-4 on the EM1000-EV) and instead connects the port to the GPRS modem
that can be optionally installed on the interface PCB.
Ethernet-to-Serial Servers
This part of documentation describes Ethernet-to-serial Servers (for external use)
supplied by Tibbo.
The following devices are currently manufactured:
DS100 Serial Device Server
DS202 Serial Device Server
To simplify choosing between Ethernet-to-serial Devices we provide the following
comparison chart.
DS100R
DS100B
DS202R
10BaseT
100/10BaseT
RS232
RS232/422/485 RS232
Baudrates: 150-115200bps; parity: none, even, odd,
mark, space; 7 or 8 bits/byte
RX, TX, RTS, RX, TX, RTS, CTS, DTR, DSR*
CTS
510bytes*2
12KB*2
10~25VDC
60x47x30mm
V3.5x or above
* For DS100B this refers to the RS232 mode of the serial port.
** V3.5 has introduced new features that are not supported by earlier firmware
released.
64
The DS100 is a Serial Device Server for external use. Device hardware includes one
10BaseT Ethernet port, one serial port and an internal processor that "glues"
network and serial sides together. Internally, the DS100 is based on the EM100
Ethernet Module.
The DS100 is supplied in two modifications:
DS100R with RS232 serial port.
DS100B with universal RS232/422/485 serial port.
From the hardware standpoint, the DS100 can be viewed as a universal platform
suitable for running a variety of network and serial communications-related
applications. It is the application firmware, not the hardware that gives the DS100
most of its functionality. The firmware is currently in its 3rd generation
("Release3").
The application firmware of the DS100 can be upgraded through the device's serial
port or Ethernet port. Serial upgrades are facilitated by a so-called Monitor- a fixed
"service" firmware inside the DS100. The Monitor itself cannot be upgraded.
Network upgrades rely on the NetLoader firmware component that, like the
application firmware itself, can be upgraded through the serial port of the DS100
(using the Monitor). The DS100 is supplied with the application firmware and the
NetLoader already pre-loaded.
Since most of the DS100's operation is defined by its firmware the major part of
the functional description can be found in the Device Server Application Firmware
Manual. This DS100 Serial Device Server Manual focuses on the hardware portion
of the DS100.
* Network upgrades are only possible on the latest DS100-03 modification of the
device (see specifications and EM100 modifications for details)
Hardware Manuals
65
DS100 2.3.2.1
Connectors and Controls
Click on the area on the picture above or one of the links provided below to learn
more about the DS100:
Power Jack (input power is 12VDC, adaptor current rating must be no less than
500mA)
Ethernet port pin assignment.
Serial port pin assignment and interface selection.
Status LEDs.
Setup button.
Power Jack
Power Jack of the DS100 accepts "large" power connectors with 5.5mm diameter.
Use ARP-1014, ARP-1015A, or ARP-1018A power adaptor supplied by Tibbo or
similar adaptor. Nominal voltage is 12VDC and adaptor current rating should be at
least 500mA. On the power jack, the ground is "on the outside", as shown on the
figure below.
66
TX+
TXRX+
<No connection>
<No connection>
RX<No connection>
<No connection>
The serial port connector of the DS100 is of DB9M type. The DS100 is supplied in
two models: the DS100R with RS232 port and DS100B with universal
RS232/RS422/RS485 serial port. Notice, that there are no terminators (usually
required at the ends of RS422 and RS485 buses) inside the DS100B. Termination
circuits are present on the TB100 Terminal Block Adaptor that can be optionally
supplied with the DS100B.
#1
#2
#3
#4
#5
#6
#7
#8
#9
DS100R
DS100B
RS232
RS232
RS422
(full-duplex op.) (full-duplex op.) (full-duplex op.)
<No connection> <No connection>
RTS- (output)
RX (input)
RX (input)
RX- (input)
TX (output)
TX (output)
TX+ (output)
<No connection>
DTR (output)
TX- (output)
Ground
Ground
Ground
<No connection>
DSR (input)
RX+ (input)
RTS (output)
RTS (output)
RTS+ (output)
CTS (input)
CTS (input)
CTS+ (input)
<No connection> <No connection>
CTS- (input)
RS485
(half-duplex op.)
<No connection>
RX- (input)
TX+ (output)
TX- (output)
Ground
RX+ (input)
<No connection>
<No connection>
<No connection>
The difference between the RS422 and RS485 modes of the DS100B is not just in
that there are no RTS+ and RTS- signals in the RS485 mode. Notice that the table
above also details whether the serial port is running in the full-duplex or
half-duplex mode when a particular interface is selected. When RS422 is selected
the serial port is in the full-duplex mode and the TX+/TX- and RTS+/RTS- signal
pairs are active at all times (i.e. output the data). When RS485 is selected the
TX+/RX+ signal pair outputs the data only when the DS100 needs to send the data
out through the serial port. The incoming data is ignored at this time. When the
DS100 is not outputting the data the TX+/TX- signal pair is tri-stated and the
DS100 is "listening" to the incoming data on the RX+/RX- signal pair. This allows
you to arrange a 2-wire RS485 bus by externally connecting TX+ to the RX+ and
Hardware Manuals
67
TX- to the RX- (this can be conveniently done by using TB100 Terminal Block
Adaptor).
Interface selection for the DS100B is done through the DIP switches located on the
bottom of the device, next to the setup button (DS100B only). Only switches 1 and
2 are used at the moment, switch 3 is reserved.
Interface
RS232
RS422
RS485
Switch 1
OFF
OFF
ON
Switch 2
OFF
ON
ON
If you change interface selection you need to power the DS100B off and back on
again for the new selection to be recognized by the device. Also, for the interface
selection to work you need to make sure that the Serial Interface (SI) setting of
the application firmware is programmed to 2 (auto).
Status LEDs
The Green and Red status LEDs are located on the top of the DS100. The LEDs
display various status information depending on what firmware is running at the
moment. Follow the links below to learn more about the behaviour of these LEDs
under different conditions:
Status LED behavior in the monitor firmware
Status LED behavior in the NetLoader
Status LED behavior in the application firmware
There are also two Ethernet Status LEDs- Green and Red- located next to the RJ45
Ethernet connector. The Green LED is normally ON, and is temporarily turned off
whenever the EM100 receives a network packet. The Red LED is normally OFF, and
is turned on momentarily whenever a data collision is detected on the Ethernet.
Setup Button
The setup button is located on the bottom side of the DS100. The button can be
pushed by a sharp tip of a pencil, pen, etc.
The Button is used to select an operating mode of the DS100:
When the DS100 is powered up with the button pressed it enters a serial
upgrade mode in which new application firmware file can be uploaded into the
DS100 through its serial port. If the DS100 is powered up with the setup button
not pressed the Device proceeds to running its current application firmware. This
functionality is delivered by the Monitor firmware component of the DS100.
When the application firmware is already running the setup button is used to
make the DS100 enter the serial programming mode (hence, the name of a
68
Specifications
2.3.2.2 and DS100 modifications
There are two models of the DS100: the DS100R with RS232 serial interface and
the DS100B with RS232/RS422/RS485 serial interface.
There are five different DS100R sub-models in circulation: DS100R-00,
DS100R-01, DS100R-02, DS100R-03, and DS100R-04. Currently, only the
DS100R-04 is being manufactured so the information on DS100R-00...DS100R-03
is provided for your reference only.
The DS100R-00, DS100R-01, and DS100R-02 devices were basically the same,
with only minor changes made to the internal hardware (such as bypass capacitors
on the internal PCB, etc.). We will refer to all three modifications as DS100R-02.
The DS100R-03 had extended functionality compared to the DS100R-02. There are
two notable differences:
Memory size inside the device has been increased so the routing buffers of the
DS100R-03 are double the size of the buffers inside the DS100R-02 (510 bytes
in each direction vs. 255 bytes in each direction).
Ability to upgrade the application firmware through the network was added (this
is facilitated by the NetLoader firmware) to the DS100R-03. The DS100R-02
cannot run the NetLoader and cannot be upgraded through the network.
The DS100R-04 is a RoHS-compliant version of the DS100R-03. The DS100R-04
and DS100R-03 are identical in every other way.
There are two DS100B sub-models in circulation: the DS100B-00 and the
DS100B-01. The DS100B-01 is a RoHS-compliant version of the DS100B-00. The
DS100B-01 and DS100B-00 are identical in every other way. On the functional
side, both the DS100B-00 and the DS100B-01 had larger memory buffers and the
possibility of firmware upgrades over the network from the very beginning of their
production.
Device specifications are presented in the table below.
Parameter
Ethernet interface
Serial interface and I/O lines
DS100R-04
DS100B-01
10BaseT Ethernet
RS232 (TX,RX,RTS,CTS) RS232
(TX,RX,RTS,CTS,D
TR,DSR)
RS422
(TX+/-,RX+/-,RTS
+/-,CTS+/-)
RS485
(half-duplex,
TX+/-,RX+/-)
510 bytes x 2 (255 bytes x 2)
DC 12V, app. 100mA
-5 to +70 degrees C
10-90%
95x57x30mm
130x100x65mm
Hardware Manuals
Gross weight ("bare" DS100)
Carton dimensions (DS100-KIT)
Gross weight (DS100-KIT)
69
170g.
325x45x90mm
950g.
The DS202 is a Serial Device Server for external use. Device hardware includes one
10/100BaseT Ethernet port, one RS232 serial port and an internal processor that
"glues" network and serial sides together. Internally, the DS202 is based on the
EM202 Ethernet Module.
From the hardware standpoint, the DS202 can be viewed as a universal platform
suitable for running a variety of network and serial communications-related
applications. It is the application firmware, not hardware that gives the DS202
most of its functionality.
The DS202 can run two distinctively different kinds of application firmware:
The "serial device server" firmware, currently in its 3rd generation ("Release3"),
turns the DS202 into a ready-to-work Serial Device Server that can connect
almost any kind of serial device to the Ethernet (TCP/IP) network. This firmware
has fixed functionality; you adjust the way the DS202 behaves by specifying the
values of programmable parameters (settings) defined in this firmware.
Functional description of the DS202 under the "serial device server" firmware can
be found in the Device Server Application Firmware Manual. Also see Software
Manuals for the information on PC software that works with devices running
serial device server firmware.
TiOS (Tibbo Operating System) firmware turns the DS202 into a
BASIC-programmable controller. This controller can be used to created any kind
of network and/or serial port-related application. When running TiOS, the DS202
has no pre-defined functionality -- it simply executes your BASIC application.
TiOS and BASIC programming are covered in a separate Manual ("TAIKO
Manual").
The application firmware of the DS202 can be upgraded through the device's serial
port or Ethernet port. Serial upgrades are facilitated by a so-called Monitor- a fixed
"service" firmware inside the DS202. Network upgrades rely on the application
firmware itself- there is a self upgrade algorithm that will be detailed later.
By default, the DS202 is supplied with "serial device server" firmware pre-loaded.
If you wish to make the module run your BASIC application you need to upload
TiOS firmware onto the Module. Visit Tibbo website to get the latest TiOS firmware.
70
DS202 2.3.3.1
Connectors and Controls
Click on one of the links provided below to learn more about the DS202:
Power Jack (input power is 10-25VDC, adaptor current rating must be no less
than 500mA)
Ethernet port pin assignment
RS232 port pin assignment
Status LEDs
Setup button
Power Jack
Power Jack of the DS202 accepts "small" power connectors with 3.5mm diameter.
Use ARP-P0005, ARP-P0006, or ARP-P0007 power adaptor supplied by Tibbo or
similar adaptor. Acceptable power supply voltage range is 10-25VDC. Adaptor
current rating should be at least 500mA. On the power jack, the ground is "on the
outside", as shown on the figure below.
Hardware Manuals
TX+
TXRX+
<No connection>
<No connection>
RX<No connection>
<No connection>
#1
#2
#3
#4
#5
#6
#7
#8
#9
<No connection>
RX (input)
TX (output)
DTR (output)
Ground
DSR (input)
RTS (output)
CTS (input)
<No connection>
71
72
Status LEDs
The DS202 has two pairs of status LEDs: one on the Ethernet connector itself (left
side), and one on top of the Device. Both pairs are controlled by the same internal
circuitry and exhibit exactly the same behavior.
Status LEDs display various status information depending on what firmware is
running at the moment. Follow the links below to learn more about the behaviour
of these LEDs under different conditions:
Status LED behavior in the monitor firmware
Status LED behavior in the application firmware
There are also two Ethernet Status LEDs- Green and Yellow- located on the
Ethernet connector (right side):
Link/Data LED (green) is turned on when "live" Ethernet cable is plugged into
the Module. The LED is temporarily switched off whenever an Ethernet packet is
received.
100BaseT LED (yellow) is turned on when the EM202 links with the hub at
100Mb. The LED is off when the link is established at 10Mb.
Setup Button
The setup button is located next to the Ethernet port of the DS202.
The Button is used to select an operating mode of the DS202:
When the DS202 is powered up with the button pressed it enters a serial
upgrade mode in which new application firmware file can be uploaded into the
DS202 through its serial port. If the DS202 is powered up with the setup button
not pressed the Device proceeds to running its current application firmware. This
functionality is delivered by the Monitor firmware component of the DS202.
When the application firmware is already running the setup button is used to
make the DS202 enter the serial programming mode (hence, the name of a
button)*.
* Strictly speaking, this is a functionality that is defined by the application
firmware, not the DS202 hardware.
Specifications
2.3.3.2 and DS202 Modifications
The DS202 has two sub-models in circulation- the DS202-00 and DS202-01. The
DS202-01 is a RoHS-compliant version of the DS202-00. There are no other
differences between these two versions. Currently, only the DS202-01 is being
manufactured.
Device specifications are presented in the table below.
Parameter
Ethernet interface
Serial interface and I/O lines
Routing buffers size
Power requirements
DS202-00
10/100BaseT Ethernet
RS232 (TX,RX,RTS,CTS,DTR,DSR)
12Kbytes x 2*
DC 10-25V, use adaptor with current rating
of at least 500mA
Hardware Manuals
Operating temperature
Operating relative humidity
Mechanical dimensions
Carton dimensions ("bare" DS202)
Gross weight ("bare" DS202)
Carton dimensions (DS202-KIT)
Gross weight (DS202-KIT)
73
-5 to +70 degrees C
10-90%
60x47x30mm
125x95x52mm
110g.
325x45x90mm
950g.
* Maximum possible buffer size. Actual size may be smaller depending on how
much RAM is "consumed" by the firmware
74
DS100B-SK Starter Kit. The Kit includes all necessary parts for evaluation of
the DS100B Serial Device Server:
DS100B Serial Device Server;
WAS-P0004(B) DS-to-device serial cable;
WAS-P0005(B) DS-to-PC serial cable;
WAS-1499 "straight" Ethernet cable;
WAS-1498 "crossover" Ethernet cable;
12VDC/500mA Power Adaptor;
TB100 Terminal Block Adaptor.
EM202-SK Starter Kit. The Kit includes all necessary parts for evaluation of
the EM202 Ethernet-to-serial Module:
EM202-EV-RS Evaluation Board with one EM202 Module (soldered in);
WAS-P0004(B) DS-to-device serial cable;
WAS-P0005(B) DS-to-PC serial cable;
WAS-1499 "straight" Ethernet cable;
WAS-1498 "crossover" Ethernet cable;
12VDC/500mA Power Adaptor.
EM200-SK Starter Kit. The Kit includes all necessary parts for evaluation of
the EM200 Ethernet-to-serial Module:
EM120/EM200-EV Evaluation Board with one EM200 Module (installed on a
socket);
WAS-P0004(B) DS-to-device serial cable;
WAS-P0005(B) DS-to-PC serial cable;
WAS-1499 "straight" Ethernet cable;
WAS-1498 "crossover" Ethernet cable;
12VDC/500mA Power Adaptor.
EM120-SK Starter Kit. The Kit includes all necessary parts for evaluation of
the EM120 Ethernet-to-serial Module:
EM120/EM200-EV Evaluation Board with one EM120 Module (installed on a
socket);
WAS-P0004(B) DS-to-device serial cable;
WAS-P0005(B) DS-to-PC serial cable;
WAS-1499 "straight" Ethernet cable;
WAS-1498 "crossover" Ethernet cable;
12VDC/500mA Power Adaptor.
EM100-SK Starter Kit. The Kit includes all necessary parts for evaluation of
the EM100 Ethernet-to-serial Module:
EM100-EV Evaluation Board with one
Hardware Manuals
75
DB9F (Female)
#2
#3
#4
#5
#6
#7
#8
DB9F (Female)
#2
#3
#5
#7
#8
The cable is of black color, approximately 1.5m long. Notice, that the cable doesn't
have DTR/DSR lines!
DB9F (Female)
#3
#2
#6
76
#5
#4
#8
#7
DB9F (Female)
#3
#2
#5
#8
#7
The cable is of white color, approximately 1.5m long. Notice, that the cable doesn't
have DTR/DSR lines!
1)
1)
2)
2)
Side B
#1
#2
#3
#6
1)
1)
2)
2)
Side B
#3
#6
#1
#2
Hardware Manuals
77
The following table details terminal block contact functions in case the terminal
block is connected to the DS100:
DS100R
RS232
(full-duplex op.)
RS232
(full-duplex op.)
DS100B
RS422
(full-duplex op.)
#2
<No connection>
<No connection>
RTS- (output)
#7
#8
#9
#10
#6
#1
RX (input)
TX (output)
<No connection>
Ground
<No connection>
RTS (output)
RX (input)
TX (output)
DTR (output)
Ground
DSR (input)
RTS (output)
RX- (input)
TX+ (output)
TX- (output)
Ground
RX+ (input)
RTS+ (output)
#3
CTS (input)
CTS (input)
CTS+ (input)
#4
<No connection>
<No connection>
CTS- (input)
RS485
(half-duplex
op.)
<No
connection>
RX- (input)
TX+ (output)
TX- (output)
Ground
RX+ (input)
<No
connection>
<No
connection>
<No
connection>
As explained in serial port pin assignment the DS100B supports half-duplex RS485
communications, but the RX and TX line pairs on the DB9M connector of the
DS100B are separated. In order to arrange a half-duplex two-wire RS485 bus you
need to externally connect RX+ to TX+ and RX- to TX-. On the TB100 this is
conveniently done by closing (putting to ON position) two switches- SW1 and SW2located on the back of the TB100.
Additionally, the TB100 provides termination circuits typically needed at the end of
the RS422 or RS485 bus. There are four identical terminators that can be switched
on individually using switches located on the back of the TB100. The following
table details which line pairs the terminators can be connected to:
SW3
SW4
SW5
SW6
CTS+/CTSRTS+/RTSRX+/RXTX+/TX-
78
Notice, that if you are using RS485 half-duplex mode (SW1 and SW2 are closed)
and you want to terminate the RS485 bus, then you only need to close either SW5
or SW6. Having both switches closed will effectively add two termination circuits to
the bus!
U.S. style
ARP-1014
U.S. style
ARP-P0005
Hardware Manuals
79
80
Latch the DS100/DS202 onto the DIN Rail as shown below. IMPORTANT! Be
careful when removing the DS100/DS202 from the DIN rail. Applying too much
force may damage the Mounting Brackets or render them too loose.
Hardware Manuals
81
Firmware Manuals
This part of the documentation describes all firmware components related to Tibbo
Device Servers.
Three firmware components are currently available:
Monitor is a "fixed" firmware that is responsible for starting the application
firmware and firmware upgrades through the serial port of the Device Server.
Device Server Application Firmware (currently in its V3.0x/3.5x) is what
gives Tibbo Device Servers their functionality. The firmware can be uploaded into
the Device Server through its serial port or through the network. Firmware
release history can be found here.
NetLoader is a firmware component that facilitates application firmware
upgrades through the network in the following devices: EM100-03, DS100R-03,
DS100B-00. Like the application firmware itself, the NetLoader can be uploaded
into the Device Server through the serial port (but not through the network- the
NetLoader cannot network-upgrade itself!).
All EM100-03, DS100R-03, DS100B-00 devices come from the factory with the
NetLoader already installed. Certain earlier devices- EM100-00/ -01/ -02,
DS100-00/ -01/ -02- cannot be upgraded through the network at all. All other
devices have "self-upgrading" firmware that doesn't require the NetLoader.
82
The pattern above means that both green and red status LEDs blink together three
times. The following pattern means that red LED makes one long blink followed by
two short ones:
Firmware Manuals
83
DS Startup Procedure
The following describes what happens when the Device Server is powered
up:
After the powerup the Monitor starts running.
First, the Monitor verifies whether the Setup button is pressed (on EM100,
EM120, EM200, EM202, EM1000- whether the MD line is low). If yes then the
Monitor goes into the firmware upgrade mode and is ready to receive new
application firmware file through the serial port of the DS (see serial upgrade
mode). If the DS has several serial ports, then the serial port #0 is always
selected for firmware upgrade.
If the Setup button is not pressed the Monitor verifies the presence and validity
of the application firmware. If the firmware checks OK the control is passed to it
and the DS starts running its application.
If the application firmware is not present the following happens depending on the
DS model:
For EM100-03, DS100R-03, DS100B-00
devices:
84
Firmware Manuals
85
The pattern above means that both green and red status LEDs blink together three
times. The following pattern means that red LED makes one long blink followed by
two short ones:
Status LEDs of the DS display a number of conditions, some of which can exist at
the same time. Because status LEDs can reflect only one condition at any given time
there is a certain hierarchy that defines which conditions are more important and
displayed in favor of other conditions.
Listed below are all patterns generated by this firmware**. Patterns are arranged in
order of decreasing priority. For example, serial programming mode pattern is listed
above the error mode pattern which means that if the DS is running in the serial
programming mode and error mode at the same time it is the serial programming
mode pattern that will be played by the status LEDs.
Most LED patterns correspond to states of various flags contained in response to the
Echo (X) command. Where this is true a short note was added to reflect this fact
(like this: s flag='S').
Patterns that are played once in response to a
certain event:
Powerup pattern. This pattern is played once
when the DS is switched on.
Buzz pattern. Both LEDs blink fast- this pattern is
played when the DS receives the Buzz (B)
command. This is used to identify a particular DS.
Patterns that are played repeatedly until
replaced by another pattern:
Serial programming mode (s flag= 'S').
Error mode (e flag= 'E').
Ethernet port failure (e flag= 'N'). Indicates that
the Ethernet port hardware is malfunctioning and
network communications with the DS is not
possible.
IP-address not obtained (i flag= '*'). Occurs at
startup when DHCP (DH) setting is 1 (enabled)
and the DS has not yet obtained its IP-address from
the DHCP server.
86
Firmware Manuals
87
Operation
The DS has two ports- Ethernet port and serial port. Typically, the serial port of the
DS is connected to a certain serial device ("attached serial device"). Ethernet port
links the DS to the Ethernet (TCP/IP) network (see figure below). Potentially, any
network host (including another DS) on the network can communicate with the DS
and the serial device "behind" it.
The job of the DS (i.e. the firmware described in this Manual) is to ensure
transparent communications between the network host and the attached serial
device by routing the data between the Ethernet and serial ports of the DS. Routing
means that the data received into the Ethernet port is sent out via the serial port
and vice versa. Routing is effected through two routing buffers- one for each routing
direction*. In addition to routing the serial data itself, the DS allows the network
host and the attached serial device to exchange the state of RTS, CTS, DTR, and
DSR lines.
DS operation is governed by settings, parameters, and instructions:
Settings are permanent functioning parameters that are stored in the non-volatile
memory (EEPROM) of the DS. Once programmed, they remain intact even when the
DS is powered off. Many (but not all) settings require the DS to be rebooted for the
new setting value to take effect. For example, the Baudrate (BR) setting defines
the baudrate of the serial port. When the DS boots up it sets the baudrate of its
serial port according to the value of this setting.
Parameters are temporary overrides for settings. Parameters are not saved into the
EEPROM and have immediate effect (no rebooting required). For example, there is a
Baudrate (BR) parameter that can be used to immediately change
communications speed of the serial port (and override the permanent value defined
by the Baudrate (BR) setting).
Instructions are used to make the DS perform a certain action. For example,
Establish Connection (CE) instruction makes the DS establish a data connection
with a specified network host.
Because parameters can override settings this Manual will sometimes make
references to current values. For example, current Baudrate (BR) will mean, quite
literally, the baudrate at the moment, regardless of what caused it to be such- a
permanent value obtained from the setting or a temporary overriding parameter
88
Ethernet
Port and Network Communications
3.2.2.1
Just like any other Ethernet device, the DS has a unique MAC-address (defined by
the MAC-address (FE) setting) and must be assigned a valid IP-address (defined
by the IP-address (IP) setting) to function properly on the network. Unique
MAC-address is preset during the production. Assigning a valid IP-address is the
responsibility of the user. IP-address can be assigned manually or automatically,
through DHCP (must be enabled through the DHCP (DH) setting).
To route the data between attached serial device and the network host the DS
needs to establish and maintain a data connection. Depending on current
Transport Protocol [setting/ parameter] the data connections can use TCP/IP
or UDP/IP.
The DS only allows for a single data connection. This is because the serial port
is not a shared media and cannot be controlled by more than a single network
source at any given time. This is analogous to the COM port of the PC, which can
only be opened by one program at a time.
The DS is capable of both accepting incoming connections (passive opens) and
establishing outgoing connections of its own (active opens). Whether passive
and/or active opens are allowed is defined by the current Routing Mode (RM) [
setting/ parameter].
Passive opens, when allowed, are accepted from any network host as long as
correct transport protocol is used (must match current Transport Protocol [
setting/ parameter]) and connection is made to a correct data port (defined by
the Data Port (DP) setting). [V3.24/3.54+]: Current Source IP Filtering [
setting/parameter] defines whether an incoming connection will be accepted
from any network host or only the host whose IP-address matches the one
specified by current Destination IP-address (DI) [setting/parameter/
instruction].
When performing an active open the DS attempts to connect to the current
Destination IP-address (DI) [setting/parameter/instruction] and current
Destination Data Port (DP) [setting/parameter/instruction]. When the
destination is located on a different subnet, which is derived from comparing the
destination IP-address, IP-address of the DS itself, and the netmask (defined by
the Netmask (NM) setting), the DS connects through default gateway or
[V3.54+] PPPoE Access Concentrator:
When PPPoE is not used connection is made through default gateway defined by
the Gateway IP-address (GI) setting
[V3.54+]: When PPPoE is enabled (through PPPoE Mode (PP) setting)
connection is made through PPPoE Access Concentrator. For more information
see PPPoE.
Exactly when the DS attempts to establish an outgoing connection (when such
connections are allowed) depends on the selected connection mode (see
Connection Mode (CM) setting). Attached serial device can optionally control
Firmware Manuals
89
90
Firmware Manuals
91
DHCP
The DS supports Dynamic Host Configuration Protocol (DHCP). DHCP is used to
automatically configure the following settings: IP-address (IP), Gateway
IP-address (GI), and Netmask (NM). For the DHCP to work there must be a
DHCP server on the network where the DS is installed.
The DHCP is enabled and disabled through the DHCP (DH) setting. When DHCP
(DH) settingis at 1 (enabled) the DS uses DHCP protocol to obtain its IP-address
immediately upon startup. The DS does not start its normal operation until it
receives an IP-address from the DHCP server. Gateway IP-address and
netmask configuration is optional so the DS does not require these two parameters
to be received from the DHCP server.
"IP-address not obtained" pattern is displayed by
the status LED's of the DS while the IP-address is
being configured through DHCP. This condition
corresponds to the value '*' of the i flag returned by
the Echo (X) command.
When requesting an IP-address for itself, the DS asks for a maximum possible
lease time (this is the period of time during which the DS will be allowed to use the
IP-address). The DS memorizes the lease time actually offered by the DHCP server
and applies for a lease extension well before the lease expires. If the lease is
92
PPPoE [V3.54+]
ATTENTION! This topic covers firmware functionality that is only supported in
firmware V3.54+ and, hence, only available on second-generation Devices (
EM120-00, EM200-00, EM202-00, DS202-00).
PPPoE family of protocols is mostly used by ADSL modems. Some ADSl links
(modems) are of "always on" type and do not require any link establishment. Other
ADSL links require link establishment procedure based on PPPoE protocol that is
very similar to that of old-style POTS dial-up modems. In fact, PPPoE means "PPP
over Ethernet"- it is an Ethernet adaptation of an old PPP (point-to-point protocol)
used with dial-up modems. If the DS is directly connected to such an ADSL modem
it will need to establish a PPPoE link in order to connect to any remote network
host (i.e. network host residing on a different network segment)*.
PPPoE only affect communications with remote network hosts, i.e. hosts that reside
on a different network segment (local segment boundaries are defined by the
Netmask (NM) setting). With PPPoE enabled, all communications with remote
hosts are effected through PPPoE link and not default gateway (therefore,
Gateway IP-address (GI) setting is irrelevant in this case).
PPPoE is enabled through PPPoE Mode (PP) setting. PPPoE protocol includes
authentication phase (login). PPPoE login name and password are defined by
PPPoE Login Name (PL) and PPPoE Login Password (PD) settings. Several
Firmware Manuals
93
authentication protocols are defined for PPPoE. Currently, the DS only supports
authentication through a protocol called PAP.
The PPPoE Mode (PP) setting offers two options that define when PPPoE link is
established. When this setting is at 1 (on connection) the link is established when
the DS needs to open a data connection to a remote host. The link is terminated 30
seconds after the data connection is closed. When this setting is at 2 (on powerup)
the PPPoE link is established during powerup procedure. The DS then attempts to
maintain this link at all times and re-establishes the link if it is broken.
With any PPPoE link both sides have to agree on the IP-addresses that will be used
on each side of the link. IP-address on the DS side is requested from and supplied
by the Access Concentrator. This IP-address has nothing to do with the "main"
IP-address of the DS which is defined by IP-address (IP) setting or supplied by
DHCP server when DHCP (DH) setting= 1 (enabled). Just like on PC, a PPPoE link
becomes a "virtual" network card (interface) of the DS. As such, it has its own
IP-address. This does not affect operation of the DS in any way since it is, actually,
not important which IP-address is used for PPPoE link- as long as the Access
Concentrator is "satisfied" with this address.
The status of PPPoE link can be obtained via Echo (X) and Status (U) commands.
Status LEDs of the DS also display PPPoE-related patterns.
* PPPoE is not required if the DS is connected to the ADSL modem through a router
that supports PPPoE. In this case it is the job of this router to take care of PPPoE
link management.
DS Powerup Procedure
This topic details steps that the DS takes after the powerup. Shown on the left are
status LED patterns that are displayed during each step of powerup procedure.
94
Firmware Manuals
95
96
Firmware Manuals
97
Serial Port
and Serial Communications
3.2.2.2
Serial port of the DS has two modes of operation:
Data routing mode. Incoming serial data is routed to the Ethernet port and
Ethernet data is routed to the serial port. It is in this mode that the DS performs its
routing function. After the powerup the DS is running in the data routing mode.
Serial programming mode. In this mode the serial port is used for serial
programming and all data received into the serial port is interpreted as
programming commands.
Data connection with the network host can still be established and maintained
while in the serial programming mode but the data received from the network host
will be discarded and the data received into the serial port will be interpreted as
commands. Therefore, data exchange with the network host and serial
programming cannot be concurrent. DS can only perform one of the two at any
given time. This is different from the network programming that can be performed
concurrently with the data routing.
Operation of the serial port in the data routing mode is governed by several
settings (see below), some of which (baudrate, parity, etc.) have corresponding
parameters. These parameters are delivered to the DS via the network Parameter
(P) command and are commonly known as on-the-fly commands (or, more
officially, network-side parameters). On-the-fly commands provide a way for the
network host to immediately change communications mode of the serial port
without rebooting the DS. There are also network-side instructions (Set I/O Pin
Status (Sx) and Get I/O Pin Status (Gx)) that are used to set and sense the
state of RTS, CTS, DTR, DSR, and also additional P0 and P1 lines* of the DS.
Serial port of the DS has the following capabilities:
Half-duplex or full-duplex operation as defined by the Serial Interface (SI)
setting;
Baudrates of up to 115200 bps as defined by the current Baudrate (BR) [
setting/ parameter];
7 or 8 bits/byte as defined by the current Bits Per Byte (BB) [setting/
parameter];
Several parity options as defined by the current Parity (PR) [setting/
parameter]**;
There are also several options related to the RTS, CTS, DTR, and DSR lines:
In full-duplex communications the RTS and CTS lines can be programmed to
serve as flow control lines between the DS and attached serial device- this is
defined by the current Flow Control (FC) [setting/ parameter];
In half-duplex serial communications the RTS line serves as a direction control
line (see Serial Interface (SI) setting for details). This is why this line is
called "RTS/DIR";
The CTS line optionally serves as an additional function of selecting between
full- and half-duplex communications (see "auto" selection of the Serial
Interface (SI) setting).
98
Firmware Manuals
99
* Not all incoming data will necessarily be recorded into the buffer- see
serial-to-Ethernet data routing
** Happens at startup when the DHCP (DH) setting is 1 (enabled)
Data Routing
3.2.2.3
Data routing between the Ethernet and serial ports of the DS is effected through
two routing buffers*, one for each routing direction. Buffers are necessary because
Ethernet and serial ports operate in fundamentally different ways and at different
speeds. Ethernet port receives and sends the data in packets (groups) while the
serial port sends and receives serial data stream where each data byte is
independent. Here is how the DS transforms Ethernet packets into the serial
stream and back:
Ethernet-to-serial data routing. The DS outputs the contents of arriving
Ethernet data packets byte by byte via the serial port. The DS does not check or
filter the contents of the data arriving from the network host.
Serial-to-Ethernet data routing. This requires grouping arriving serial data into
Ethernet packets of suitable size. Several settings define what data is accepted into
the buffer and when and how this data is combined into the Ethernet packets and
sent out- see serial-to-Ethernet data routing for details.
Routing buffers are initialized (their data discarded) each time the data connection
is closed.
* The size of routing buffers is hardware-dependent and is different for different
models and modifications of Tibbo Device Servers. Routing buffer size can be
verified using the Status (U) command.
100
Firmware Manuals
101
Programming
The DS is programmed using programming commands that can be sent through the
serial port of the DS or via the network. For each command the DS issues a reply.
All DS commands have the following format:
C.C.
Optional parameter(s)
C.C. is the command code. Command code always consists of a single ASCII
character. All available commands and their codes are listed in the command table
at commands, messages, and replies.
Optional parameter(s) field contains necessary data if required by the
command.
All DS replies have the following format:
R.C.
Optional data
R.C. is the reply code. Reply codes inform the sender of the command about the
result of command execution. All available reply codes are listed in the reply code
table at commands, messages, and replies.
Optional Data field contains necessary data if requested by the command.
Example: here is a sample exchange between a certain device (performing the
programming) and the DS. This device can be a network host (programming
through the network) or attached serial device (programming through the serial
port):
-->DS:
DS-->:
GIP
A192.168.100.90
In the above example programming device requests the IP-address of the DS. This
is done by issuing the Get Setting (G) command with parameter "IP" (for
IP-address (IP) setting). The DS replies with the OK (A) reply code indicating
that command was processed successfully, followed by the current value of the
IP-address (IP) setting, which is 192.168.100.90.
All commands and replies sent to the DS always have the same format, regardless
of which interface is used. What is interface-dependent is the encapsulation that is
used to mark the beginning and the end of commands (replies) and how these
commands and replies are sent. For more information see serial programming and
network programming.
Serial Programming
3.2.3.1
When the DS is powered up its serial port is running in the data routing mode (see
serial port and serial communications). To enable DS programming via the serial
port the latter must be switched into the serial programming mode.
Status LEDs of the DS are playing a serial
programming mode pattern when the serial port of the
DS is in the serial programming mode (click here to
see all available patterns).
102
Command/reply
CR
STX (ASCII code 2) and CR (ASCII code 13) characters provide necessary
encapsulation. All data before the STX and after the CR is ignored.
Command/reply field contents has been explained in programming.
Example: here is a sample exchange between a serial device and the DS. Special
characters are represented as follows: STX- J, CR- .
Serial device-->DS:
DS-->Serial device:
JGIP
JA192.168.100.40
* HI and LOW states are described with respect to the serial ports of DS100R,
DS100B, DS202R, EM100-EV, EM120/EM200-EV, EM202-EV. For EM100, EM120,
EM200, EM202, EM1000 the signaling is exactly opposite.
Network
Programming
3.2.3.2
Unlike serial programming that requires the serial port of the DS to be in the serial
programming mode, in which the serial port cannot exchange data with the network
host, network programming can continue concurrently with the data routing
between the network host and attached serial device. Therefore, network
programming is not a "mode" of the Ethernet port.
Firmware Manuals
103
104
Firmware Manuals
105
the command (reply) in the data stream. IEC code is 255. When the Inband (IB)
setting is 1 (enabled) and the DS receives a character with code 255 followed by
any character other than 255, the DS considers this to be a beginning of the
inband command. If the network host wants to send a data character with code
255 it needs to send two consecutive characters with code 255. This will be
interpreted by the DS as a single data character with code 255. Therefore, it is the
responsibility of the network host to parse through the data it is sending to the DS
and "double" all data characters with code 255.
When sending a reply back to the network host, the DS will also prefix this reply
with the IEC. When sending a data byte with code 255 the DS will automatically
double this character. It is the responsibility of the network host to parse through
the data it receives from the DS and replace all double characters with code 255
with a single one.
All inband commands and replies use the following format:
IEC
STX
Command/reply
CR
IEC character followed by STX (ASCII code 2) mark the beginning of command
(reply). CR (ASCII code 13) marks the end of command (reply). All characters
before the IEC/STX and after the CR are considered to be a "regular" routing data.
Command/reply field contents has been explained in programming.
Example: here is a sample exchange between the network host and the DS.
Shown below is the data passed within a data TCP connection. Special characters
are represented as follows: IEC- u, STX- J, CR- .
Host-->DS: ABCuuDEFuJGIPGHIK
DS-->Host: LMNuJA192.168.100.40XYZ
In the above exchange the network host is sending the following data string: "ABC
uDEFGHIK". There is a single character with code 255 (u) but the DS has to
double this character. Command inserted into this data stream is "GIP" (Get
Setting (G) command, setting to be read is IP-address (IP)). Command is
preceded with IEC (u)followed by STX (J) and ended by CR ().
The DS sends the following data string to the network host: "LMNXYZ". At some
point, when the reply to the command is ready, the DS inserts this reply into the
data stream. Reply contains current IP-address of the DS.
Unlike out-of-band UDP programming, inband programming does not support
multiple commands. It is not possible to send several commands and receive
several replies back. The network host should only send the next command after
having received a reply to the previous command.
Very important! Since inband commands are transmitted together with data
execution of such commands by the DS can be delayed indefinitely if the data
cannot be transmitted by (sent out of) the serial port of the DS. This will happen if
current Flow Control (FC) [setting/parameter] is at 1 (enabled) and the CTS
input of the DS is held in the "do not transmit" state. In this case the DS will not
be sending out data and the inband command "embedded" within this data stream
won't be processed (until all data before this command is finally transmitted).
106
Command/reply
CR
Thus, command-phase commands and replies have the same format as those used
in serial programming. STX (ASCII code 2) and CR (ASCII code 13) characters
provide necessary encapsulation. All data before the STX and after the CR is
ignored. Command/reply field contents has been explained in programming.
To switch the data connection from the command phase into the data phase the
network host has to issue the Logout (O) command. After this command is sent*
and accepted the DS switches into the data phase. From this moment on and until
the TCP connection is terminated the network host can exchange the data with the
attached serial device in the normal way.
Logout (O) command is only accepted after the network host logs in using Login
(L) command, and this requires a valid password (if set in the Password (PW)
setting). Therefore, setting Data Login (DL) to 1 (enabled) also enables network
host authentication for data exchange with the attached serial device(hence, the
name of this setting).
Example: here is a sample exchange that switches the DS into the data phase.
Shown below is the data passed within a data TCP connection. Special characters
are represented as follows: STX- J, CR- . Login password is "123pwd"
---TCP connection established, command phase--Host-->DS: JL123pwd
'network host logs in
DS-->Host: JA
'OK
Host-->DS: JO
'exit into the data phase (no reply)
---data phase from this point and until the TCP connection is closed--Command-phase programming should not be confused with inband programming.
The first one is enabled by the Data Login (DL) setting, the second one- by the
Inband (IB) setting. Both can be enabled at the same time! After the DS exits into
the data phase inband commands can still be sent (this time, with proper escape
character), provided that inband programming is enabled.
Command-phase programming is disabled automatically when current Link
Service Login (TL) [setting/parameter] is 0 (disabled).
*Command-phase inband programming is the only programming method in which
no reply is returned upon successful completion of the Logout (O) command. The DS
simply switches into the data phase.
Firmware Manuals
107
one of them will be at "logged in" state at any given time i.e. have a programming
session in progress (see authentication and programming priorities).
Note, that port 23 cannot be used for programming if this port is assigned to be
the data port (i.e Port Number (PN)= 23). In this case all TCP connections to
port 23 will be interpreted as data connections, thus rendering "telnet"
programming impossible. If the Port Number is set to any port other than 23, a
TCP connection to port 23 will be interpreted as a programming connection.
All telnet commands and replies use the following format:
STX
Command/reply
CR
Thus, telnet commands and replies have the same format as those used in serial
programming. STX (ASCII code 2) and CR (ASCII code 13) characters provide
necessary encapsulation. All data before the STX and after the CR is ignored.
Command/reply field contents has been explained in programming.
The replies from the DS will include an additional LF character trailing
the CR at the end of the reply, just to improve readability on most
terminal software. You don't have to send an LF when you send
commands to the DS.
Authentication
Certain commands, when sent through the network, require authentication. To
authenticate itself the network host must provide a password, that matches the
one defined by the Password (PW) setting.
From the authentication standpoint, all commands can be divided into
three groups:
Commands that do not require authentication. These commands can be sent
at any time and by any network host.
Commands with immediate authentication. In these commands the password
is supplied in the command body itself and authenticates this particular command.
For some of these commands authentication is optional.
Commands that require prior login. These commands are only accepted after
the network host has logged in using the Login (L) command. Login is performed
once and is said to open a programming session.
The DS memorizes the source IP-address from which the Login (L) command is
sent as well as the mode in which it is sent: out-of-band, inband, etc.
Programming session must continue from the same IP-address and using the same
way of command delivery. So, if the session was opened using out-of-band Login
(L) command and the network host sends inband Set Setting (S) command
(this command requires prior login) then this command is not considered to be a
part of the opened programming session and is rejected.
Programming sessions are ended either by switching the DS off or using Logout
(O) or Reboot (E) commands. There is also a two-minute programming session
timeout: if no command (that requires prior login) is issued for two minutes the
session is ended automatically. Inband, command-phase, and telnet-mode
programming sessions are also closed when their TCP connection is closed.
The DS makes sure that only one programming session is opened at any given
time- see programming priorities for details.
Command table at commands, messages, and replies details which commands
108
Programming
3.2.3.3 Priorities
The DS has five programming methods: serial, out-of-band UDP, inband TCP,
command-phase TCP, and telnet programming. For the subject discussed below
inband and command-phase programming are the same since they both take place
within a data TCP connection. Therefore, four programming methods will be
discussed: serial, out-of-band, inband/command-phase, and telnet.
Since all four programming methods can be used at the same time the DS
maintains priority mechanism to avoid conflicts that might arise if attached serial
device and the network host(s) attempted to program the DS at the same time.
Serial programming has the highest priority of all- any command sent to the DS
via the serial interface (in the serial programming mode) is always accepted and
processed*, regardless of whether any form of network programming is (has been)
taking place at the time.
As explained in authentication, all network commands can be divided into those
that do not require any authentication, commands that require immediate
authentication, and commands that require prior login using Login (L) command
(commands that need a programming session to be opened).
Network commands that do not require authentication can be sent at any time,
using any method. For example, network Echo (X) command will be accepted
and processed even when the DS is in the serial programming mode.
Network Commands that require immediate authentication can be sent at any time
and using any method, as long as the DS is not in the serial programming mode.
When the DS is in the serial programming mode these commands are rejected (R
reply code).
For network commands that require prior login the following hierarchy of
priorities is applied:
Serial programming (highest priority)
Out-of-band programming session
Telnet programming session
Inband or command-phase programming session (lowest priority)
The above should be understood as follows:
Programming session using lower-priority programming method cannot start
while higher-priority programming session is in progress. For example,
programming session using out-of-band commands cannot start while the DS is
in the serial programming mode. Programming session using TCP connection to
telnet port cannot start while out-of-band session is in progress.
Higher-priority programming can start at any time, even when lower-priority
programming session was already in progress. In this case lower-priority
programming session is aborted immediately. Thus, if out-of-band programming
session was already opened and the DS enters a serial programming mode then
out-of-band programming session is aborted.
Firmware Manuals
109
Error Mode
3.2.3.4
The value of each DS setting (stored in the EEPROM) is protected by its own
checksum. Every time the DS stores new setting value into the EEPROM it
recalculates the checksum and saves it into the EEPROM along with the new setting
data. Every time the DS reads out the value of a certain setting it verifies this
setting's checksum. If the checksum error is detected (for any setting) the DS
enters an error mode.
Status LEDs of the DS are playing an error mode
pattern when the DS is in the error mode (unless the
serial port of the DS is in the serial programming
mode. Click here to see all available patterns).
Once entered, the error mode cannot be exited other then by rebooting the DSeither by power-cycling it or executing the Reboot (E) command.
DS operation in the error mode is characterized by the following:
Status LEDs of the DS are displaying an error mode pattern (unless the DS is in
the serial programming mode);
Error status (e flag) returned by the Echo (X) command is set to 'E';
For every invalid setting the DS takes the default value* of this setting (which is
fixed and does not depend on the EEPROM data) and assumes this default value
as a run-time parameter. For example, if the DHCP (DH) setting is found to be
invalid the DS will boot up with DHCP off because the default value of the DHCP
(DH) setting is 0 (disabled);
For two setting- Routing Mode (RM) setting and Password (PW) settingthe DS uses their default values in any case, even if these settings are valid. This
means that:
The DS will be in the slave routing mode (default value of the Routing Mode
(RM) setting);
Password authentication will be disabled (default value of the Password (PW)
setting is <NULL>). Consequently:
No password is to be supplied in the Login (L) command, although this
command itself must still be executed before sending commands that require
prior authentication (such as the Initialize (I) command);
Login password doesn't need to be supplied in commands that require
immediate authentication, such as on-the-fly (network side) Parameter (P)
command, even if the On-the-fly Password (OP) setting is 1 (enabled).
The above also applies to two most important settings that define DS visibility on
110
Quick Initialization
3.2.3.5
Quick initialization is a way to completely reinitialize the DS without using any
commands. This feature is handy when the DS is running in the error mode and
needs to be repaired.
Quick initialization provides the same result as the serial Initialize (I) command.
See individual setting description for the information on how each settings will
behave during the initialization (some settings will be initialized unconditionally
and some- only when found to be invalid).
To quick-initialize the DS:
Make sure the DS is powered;
Press and release the Setup button* to enter the serial programming mode.
Status LEDs will play the serial programming mode pattern;
Wait for at least three seconds;
Press and hold the Setup button for at least three seconds- both status LEDs will
be switched off and this will indicate that the initialization has been started;
Initialization takes about one second to complete. Initialization result will be
shown by the status LEDs- green LED will be switched on for about 2 seconds
indicating successful initialization. (If the red LED is switched on this means that
the DS is malfunctioning).
Switch the DS off and back on again to exit the error mode if necessary.
* For EM100, EM120, EM200, EM202, EM1000 pull the MD line low
Custom3.2.3.6
Profiles
Default setting values (i.e. values that settings assume after they are initialized
through the Initialize (I) command or by using quick initialization) can be
changed by adding a custom profile to the firmware file loaded into the DS.
Request more information on the subject via email.
Reference
Reference contains all necessary information on:
DS commands, messages and replies. Commands are used to control the DS
and can be issued through the network or through the serial port. The DS replies
to the commands- reply codes indicate the result of command execution.
Messages are different in that they are not replied to. For more information see
programming.
Firmware Manuals
111
Commands,
messages, and replies
3.2.4.1
This section contains a reference for all DS commands and messages.
Commands are used to control the DS and can be issued through the network or
through the serial port. The DS replies to the commands- reply codes indicate the
result of command execution. Messages are different in that they are not replied to.
For more information see programming.
Command and message description format can be found here.
Table below lists all available commands and messages:
C.C.
L
O
E
I
S
G
P
X
U
B
R
A
W
V
N
N
Q
D
C
T
J
N
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
L
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(+) +
+
+
+
+
+
+
+
+
+
+
+
Description
Login command
Logout command
Reboot command
Initialize command
Set Setting command
Get Setting command
Parameter command
Echo command
Status command
Buzz command
Reset Overflow Flags command
Assign IP-address command
Select In Broadcast Mode command
Get Firmware Version command
Jump To NetLoader command
Set Programming Request Flag
Reset Upload Process
Upload Data Block
Cable Status
Get My IP
Notification message
Notes:
C.C.- command codes;
N- '+' in this column indicates that command can be issued through the network;
B- '+' in this column indicates that command can be issued in the broadcast mode
(when sent through the network) without the need to pre-select a particular DS
using Select In Broadcast Mode (W) command first;
L- '+' in this column indicates that command, when issued through the network,
112
Description
OK (command completed successfully)
Error (incorrect command was issued)
Rejected (command was rejected by the DS)
Denied (access was denied by the DS)
Failed (command execution failed)
Bad Sequence (D command only)
Out-of-range (D command only)
Notes:
R.C.- reply code.
Command format:
Possible replies:
First introduced:
See also:
Details
Additional information about the command.
Command format:
Firmware Manuals
Possible replies:
A, R, D
First introduced:
See also:
113
Details
Login command is used to authenticate the network host, which is a necessary
step to perform before attempting to execute certain commands over the network
(such as Set Setting (S). Check the "L" column of the command table at
commands, messages, and replies to find out which commands require prior
authentication.
Login password to supply in the Login command body is defined by the
Password (PW) setting. Note, that to execute commands that require prior login
you need to use the Login command even when the password is not set (i.e. it is
<NULL>).
OK (A) reply code is returned if login is accepted by the DS. Rejected (R) reply
code is returned if the DS is in the serial programming mode or a higher-priority
programming session is already in progress (see programming priorities for
details). Denied (D) reply code is returned if incorrect password is supplied.
Login command is said to open a programming session. For more information on
programming sessions see authentication.
The DS memorizes the IP-address of the network host from which the Login
command is sent. If subsequent commands (that require login) are sent from a
different IP-address then these commands are replied to with the Denied (D)
reply code.
Login password is not verified when the DS is running in the error mode. Login
command should still be used as usual but it is not necessary to supply any
password, leaving the pp...p field blank in this situation is OK.
* Without prior selection using Select In Broadcast Mode (W) command.
Command format:
Possible replies:
A, D
First introduced:
See also:
Details
Logout command performs a different action depending on whether it was issued
114
Command format:
Possible replies:
First introduced:
See also:
Authentication
Details
Reboot command causes the DS to reset (restart).
When issued through the network, this command requires prior login using the
Login (L) command (programming session must be opened). Denied (D) reply
code is returned if the programming session is not in progress or if it doesn't
belong to the sender of the Reboot command- the DS remembers the IP-address
of the network host that opens the programming session and requires that all
subsequent commands (that require prior login) are sent from the same IP.
No reply code is returned if command is accepted- the DS simply reboots. This
makes the DS "lose" any data connection that might be in progress so the network
host must discard such a connection if it was established before.
Reboot command can be used to exit the serial programming mode or end the
network programming session. This may be necessary, for instance, to make the
DS reread new setting values that were programmed prior to the reboot. If it is
necessary to end the programming without rebooting the DS the Logout (O)
command should be used instead.
Firmware Manuals
115
Command format:
Possible replies:
A, D, F
First introduced:
See also:
Authentication
Details
Initialize command restores the settings of the DS to their default factory
values**. Some settings are initialized each time this command is executed. Other
settings are initialized or left intact depending on the interface (network or serial)
through which the Initialize command was issued and also on whether or not a
particular setting contained a valid or invalid value.
All settings can be divided into three groups:
Settings that are initialized unconditionally, no matter whether the Initialize
command is issued through the network or through the serial port. For
example, the Routing Mode (RM) setting is always reset to 0 (server) after
the initialization.
Settings that are initialized unconditionally for the serial Initialize command,
but are only initialized in case they contained an invalid value (or found to be
corrupted)*** for the network Initialize command. One of such settings is the
IP-address (IP). Since resetting the IP-address might possibly make the DS
inaccessible through the network the risk is minimized by leaving the setting
intact unless it is "bad".
Settings that are only initialized when they contained an invalid value, no matter
whether command was issued through the network or through the serial port.
For example, the MAC-address (FE) setting is never altered unless found to be
invalid. This is because the MAC-address is preset during the production and
should not be altered unless absolutely necessary.
When issued through the network, the Initialize command requires prior login
using the Login (L) command (programming session must be opened). Denied
(D) reply code is returned if the programming session is not in progress or if it
doesn't belong to the sender of the Initialize command- the DS remembers the
IP-address of the network host that opens the programming session and requires
that all subsequent commands (that require prior login) are sent from the same IP.
Failed (F) reply code is returned if the DS fails to reset one or more settings.
This usually indicates a hardware malfunction (EEPROM failure).
* Without prior selection using Select In Broadcast Mode (W) command.
** Or the values defined by the Custom profile created by the User.
***
116
Command format:
Possible replies:
A, D, C, F
First introduced:
See also:
Details
Set Setting command assigns new values to the selected setting. ss is the
setting mnemonic, i.e. "IP" for the IP-address (IP) setting.
Example: to set IP-address to 192.168.100.40 issue the following command**:
-->DS:
DS-->:
SIP192.168.100.40
A
When issued through the network, this command requires prior login using the
Login (L) command (programming session must be opened). Denied (D) reply
code is returned if the programming session is not in progress or if it doesn't
belong to the sender of the Set Setting command- the DS remembers the
IP-address of the network host that opens the programming session and requires
that all subsequent commands (that require prior login) are sent from the same IP.
Error (C) reply code is returned if the setting mnemonic and/or supplied setting
value is/are invalid. Failed (F) reply code is returned if the DS fails to write new
setting value. This usually indicates a hardware malfunction (EEPROM failure).
* Without prior selection using Select In Broadcast Mode (W) command.
** Encapsulation characters such as IEC, STX, CR are not shown.
Command format:
Possible replies:
First introduced:
See also:
---
Details
Get Setting command reads out current value of the selected setting. ss is the
setting mnemonic, i.e. "IP" for the IP-address (IP) setting.
Firmware Manuals
117
GIP
A192.168.100.40
When issued through the network, this command requires prior login using the
Login (L) command (programming session must be opened). Denied (D) reply
code is returned if the programming session is not in progress or if it doesn't
belong to the sender of the Get Setting command- the DS remembers the
IP-address of the network host that opens the programming session and requires
that all subsequent commands (that require prior login) are sent from the same IP.
Error (C) reply code is returned if the setting mnemonic is invalid. Failed (F)
reply code is returned if the DS fails to read out the setting value, setting value is
not valid, or if the data is found to be corrupted***. This may indicate a hardware
malfunction (EEPROM failure).
Invalid setting can be repaired using the Set Setting (S) command or
(recommended) using the Initialize (I) command or quick initialization (this will
initialize all other invalid settings).
* Without prior selection using Select In Broadcast Mode (W) command.
** Encapsulation characters such as IEC, STX, CR are not shown.
*** Each setting's data is protected by an individual checksum.
Command format:
Possible replies:
A, C, D, R
First introduced:
See also:
Details
Command code 'P' (Parameter) serves as a "common entry point" for sending a
variety of parameters and instructions.
Network Parameter command can be made to require immediate authentication.
To enable this feature:
On-the-Fly Password (OP) setting must be programmed to 1 (enabled);
Password (PW) setting must contain a password (i.e. a string of non-zero
length).
When two above conditions are met each network Parameter command sent to
the DS must contain a password, which is to be added at the end of the command
after a slash character.
Example: below is the parameter command that changes the baudrate. The
password is "123pwd"**:
118
PBR4/123pwd
A
Command format:
Annn.nnn.nnn.nnn.nnn.nnn/ppppp/mseic[p]/
ES/oo...o/dd...d, where
nnn.nnn.nnn.nnn.nnn.nnn- MAC-address of the
DS;
ppppp- data port numberof the DS;
m- fixed to 'N' (means that the application
firmware, not the NetLoaderis running);
s- programming mode: '*' (none), 'S' (serial), 'U' (
out-of-band UDP), 'T' (inband TCP or
command-phase TCP);
e- error status: '*' (no errors detected), 'E'
(running in the error mode); 'N' (Ethernet port
failure)
i- IP-address status: '*' (not obtained yet), 'I'
(obtained via DHCP), 'M' (fixed, set manually);
c- data connection status: '*' (closed), 'A' (sending
ARP OR [V3.54+] establishing PPP link), 'O'
(being established), 'C' (TCP connection
established or being closed), 'U' (UDP connection
established), 'R' (reset by remote host), 'F' (Link
Server login failed), 'L' (Link Server login in
progress);
[V3.54+] p- only returned when command
version parameter of >1 is supplied: '*' (PPPoE
disabled), 'D' (PPPoE login denied), 'N' (PPPoE link
not opened), 'B' (PPPoE link is being established),
'P' (PPPoE link established);
E- Ethernet-to-serial bufferoverflow: '*' (no
overflow), 'E' (overflow detected);
S- serial-to-Ethernet bufferoverflow: '*' (no
overflow), 'S' (overflow detected);
oo...o- owner name;
dd...d- device name.
Firmware Manuals
119
First introduced:
See also:
Details
The primary use of the network Echo command is to auto-discover Device
Servers on the network: when the network host sends this command in the
broadcast mode, it collects the replies from all locally attached Device Servers
(hence, the name of the command). Reply from each DS contains all necessary
information (MAC-address, etc.) that is needed to continue communicating with
each specific DS in a non-broadcast mode.
Information returned by the Echo command contains the following data:
MAC-address is the most important field that can be used to uniquely identify
each DS*! Besides, the MAC-address is used (and, therefore, must be known in
advance) as a reference to the particular DS in such commands as Assign
IP-address (A) and Select in Broadcast Mode (W).
Data port number field is read directly from the Port Number (PN) setting of
the DS.
Follow are several one-character flag fields that tell the network host about the
present status of the DS:
m flag always returns 'N'. This is meant to indicate that the DS is running
(this) application firmware. In contrast, when the NetLoader is running this
flag shows 'L' (NetLoader also supports Echo command);
s flag shows whether or not any form of programming is in progress. 'S' is
returned when the serial port of the DS is in the serial programming mode. If
the network programming session is in progress the 'U' is returned for
out-of-band (UDP) programming session and 'T' is returned for inband (TCP) or
command-phase (TCP)programming sessions;
e flag indicates whether or not the DS is running in the error mode.
Additionally, for serial Echo command this flag can be set to 'N' indicating
hardware failure of the Ethernet port;
i flag reflects current IP-address status. It is useful when the DHCP is enabled
(see the DHCP (DH) setting). The flag is set to '*' while the DS is trying to
obtain the IP-address from the DHCP server. When this is done the flag is set
to 'I'. When the DHCP is off this flag returns 'M' (for "manual");
c flag reflects the connection state;
[V3.54+] p flag reflects PPPoE link state. This flag is only returned when
optional command version parameter is supplied and is >1;
E and S flags display routing buffer overflows. Both flags are reset
automatically when the data connection is closed or aborted. The flags can also
be reset manually through the Reset Overflow Flags (R) command.
oo...o and dd...d fields return the data from the Owner Name (ON) and
Device Name (DN)settings. Using meaningful names simplifies identification of
a particular DS.
Optional command version parameter has been introduced in firmware V3.54.
Command version is a decimal number (up to 255). When command version is
omitted it is assumed to be 1. Earlier firmware releases do not support this
parameter and will simply ignore it (result will be the same as having command
120
X
A0.150.30.213.55.74/1001/NS*IC/*S/BigCorp/Device1
X2
A0.150.30.213.55.74/1001/N**MUP/**/BigCorp/Device1
Firmware Manuals
121
Command format:
Addd.ddd.ddd.ddd/ppppp/eee
/ttt/ccc/sss/fff/r/sdfpb/RCTS[/iii.iii.iii.iii],
where
ddd.ddd.ddd.ddd- IP-address of the network host
with which the data connection is (was/ to be)
established;
ppppp- data port number on the network host
with which the data connection is (was/ to be)
established;
eee- total number of characters in the
Ethernet-to-serial buffer;
ttt- capacity of the Ethernet-to-serial buffer;
ccc- number of committed characters in the
serial-to-Ethernet buffer;
sss- total number of characters in the
serial-to-Ethernet buffer;
fff- capacity of the serial-to-Ethernet buffer;
r- current baudrate (same numbering is used as in
the Baudrate (BR) setting);
s- serial port state: '*' (closed), 'O' (opened);
d- serial port mode: 'F' (full-duplex), 'H'
(half-duplex);
f- flow control: '*' (disabled), 'R' (RTS/CTS flow
control);
p- parity: '*' (none), 'E' (even), 'O' (odd), 'M'
(mark), 'S' (space);
b- bits per byte: '7' (7 bits), '8' (8 bits);
R- current state of the RTS (output) line: '*'
(LOW*), 'R' (HIGH*);
C- current state of the CTS (input) line: '*'
(LOW*), 'C' (HIGH*);
T- current state of the DTR (output) line: '*'
(LOW*), 'T' (HIGH*);
S- current state of the DSR (input) line: '*'
(LOW*), 'S' (HIGH*);
[V3.54+] iii.iii.iii.iii- only returned when
command version parameter of >1 is supplied
- IP-address of the DS on the PPPoE link.
Addd.ddd.ddd.ddd/ppppp[/iii.iii.iii.iii] (see
122
See also:
Details
Status command returns additional information about the status of the DS. In
conjunction with the Echo (X) command it can be used to obtain extensive
information about the state of the DS.
The following data is returned:
ddd.ddd.ddd.ddd and ppppp fields. IP-address and port number of the
network host with which the data connection is (was/ to be) established.
IP-address in this field shows the following:
After the power-up the fields returns the IP-address and port defined by the
Destination IP-address (DI) setting and Destination Port Number (DP)
setting;
If these default values are overridden by the Destination IP-address (DI)
parameter, Destination Port Number (DP) parameter, or Establish
Connection (CE) instruction, then the fields show new overriding values;
While the data connection is established and after it is closed (aborted) the
fields show the IP-address and port of the network host with which this
connection is (was) established. Notice that this may be different from the
above- if the DS has accepted an incoming connection.
eee and ttt fields show the total number of data bytes in the Ethernet-to-serial
buffer and the capacity of this buffer. Capacity information is included because
the buffer size is different for different models of the DS.
ccc, sss, and fff fields show the number of committed bytes in the
serial-to-Ethernet buffer, total number of bytes in this buffer, and the buffer
capacity. Again, buffer capacity is included because it differs depending on the
DS model.
r, d, f, p, and b flags show current serial port setup. This information is useful
because on-the-fly commands (network-side parameters and instructions) can
change serial port communications parameters at any time.
d flag reflects whether the serial port is in the half-duplex or full-duplex mode.
This data may be of interest when the Serial Interface (SI) setting is 2 (auto)
and you need to verify what mode the DS has assumed at startup.
R, C, T, and S flags reflect current status of the RTS, CTS, DTR, and DSR lines
of the serial port. This information may be useful in debugging communications
problems between the DS and the attached serial device.
[V3.54+] iii.iii.iii.iii field- only returned when command version
parameter of >1 is supplied- IP-address of the DS on the PPPoE link. As
explained in PPPoE the DS negotiates a separate and different IP-address for
PPPoE communications.
Optional command version parameter has been introduced in firmware V3.54.
Command version is a decimal number (up to 255). When command version is
omitted it is assumed to be 1. Earlier firmware releases do not support this
parameter and will simply ignore it (result will be the same as having command
Firmware Manuals
123
U
A192.168.100.90/37150/0/8192/0/3/8192/5/OFR*8/R*TS
This means that the data connection is (was/ to be) established with the network
host at 192.168.100.90, port number 37150. No data is currently in the
Ethernet-to-serial buffer, buffer capacity is 8192 bytes. No committed data is in
the serial-to-Ethernet buffer, there are 3 bytes of (uncommitted) data there, and
the total capacity is 8192 bytes. The baudrate is 38400, serial port is opened, uses
full-duplex mode. RTS/CTS flow control is enabled, parity is set to none, data is 8
bits/byte. RTS, DTR, and DSR lines are in the HIGH* state, CTS line is LOW*.
Example #2: here is a command with version parameter**:
-->DS:
U2
DS-->:
A192.168.100.90/37150/0/8192/0/3/8192/5/OFR*8/R*TS
/161.1.1.110
In this reply an additional field is present. This field shows that current IP-address
on the PPPoE link is 161.1.1.110
When issued through the serial port, the Status command returns less data. The
primary use of the serial Status command is to let the attached serial device
inquire the IP-address and port number of the network host with which the
connection is (was/ to be) established (as well as current "PPPoE" IP-address). This
may be used by the serial device, in conjunction with the modem commands
(serial-side parameters and instructions) to control and monitor data connection
establishment and termination by the DS.
* HI and LOW states are described with respect to the serial ports of DS100R,
DS100B, DS202R, EM100-EV, EM120/EM200-EV, EM202-EV. For EM100, EM120,
EM200, EM202, EM1000 the signaling is exactly opposite.
** Encapsulation characters such as IEC, STX, CR, and the command ID field are
not shown.
Command format:
Possible replies:
First introduced:
See also:
Details
Buzz command, when received by the DS, makes the device "play" a
recognizable fast-blinking pattern on its status LEDs. This can be used to match an
IP-address to a physical DS.
124
Command format:
Possible replies:
First introduced:
See also:
Details
Reset Overflow Flags command clears routing buffer overflow flags. Buffer
overflow condition is returned by the Echo (X) command (flags E and S) and also
displayed by the status LEDs of the DS. Overflow flags are cleared automatically
when the data connection to the network host is closed or aborted or can also be
reset manually using the Reset Overflow Flags command.
* Without prior selection using Select In Broadcast Mode (W) command.
Command format:
Ammm.mmm.mmm.mmm.mmm.mmm/pp...p
/iii.iii.iii.iii, where
mmm.mmm.mmm.mmm.mmm.mmmMAC-address of the target DS;
pp...p- password (defined by the Password (PW)
setting);
iii.iii.iii.iii- new IP-address to be assigned to the
DS
Possible replies:
A, D, C, F
First introduced:
See also:
Details
Assign IP-address command is used to set the new IP-address of a certain DS
over the network. Command should be sent in the broadcast mode, the target DS
is referenced by its MAC-address (supplied in the command body). All locally
attached devices receive the broadcast but only the DS with matching
MAC-address reacts to it.
Assign IP-address is a command of immediate authentication typewhich means
that the password (defined by the Password (PW) setting) is supplied in the
Firmware Manuals
125
A0.150.30.213.55.74/pass1/192.168.100.41
A
Note: password field in this command should be present even if the Password
(PW) setting is empty (<NULL>):
-->DS:
A0.150.30.213.55.74//192.168.100.41
New IP-address is saved into the IP-address (IP) setting, just as if the Set
Setting (S) command(i.e. "SIPiii.iii.iii.iii") was executed. Differences with the
Set Setting (S) command are in that the DS starts using the new IP-address
immediately (no rebooting required) and that the target DS is referenced by its
MAC-address.
Rejected (R) reply code is returned if the serial programming mode is in
progress. Denied (D) reply code is returned if the password is incorrect. Error
(C) reply code is returned if command structure is incorrect (a field or field
separator is missing) or if the field data is wrong. Failed (F) reply code is
returned when the DS failed to write new IP-address into the EEPROM. This usually
indicates a hardware malfunction (EEPROM failure). Since this is a broadcast
command no reply is returned if no DS on the network has the MAC-address
specified in the command.
When the Assign IP-address command is issued while the DS has a data
connection in progress this data connection is aborted. No packet (even RST in
case of TCP data connection) is sent to the network host that was communicating
with the DS.
Command format:
Wmmm.mmm.mmm.mmm.mmm.mmm,
where mmm.mmm.mmm.mmm.mmm.mmmMAC-address of the target DS
Possible replies:
First introduced:
See also:
Details
Select In Broadcast Mode command is used to pre-select a certain DS for
subsequent programming via broadcast out-of-band (UDP) commands. Only a
small portion of DS commands (such as Echo (X)) are accepted when sent in
broadcast UDP datagrams. All other commands are only accepted if they address a
specific DS. Such specific addressing normally involves sending UDP datagrams
with the IP-address of the targeted DS as the destination (i.e. non-broadcast
datagrams). This requires the IP-address of the DS to be configured reachable
which is not always possible or convenient.
126
Command format:
Possible replies:
First introduced:
See also:
---
Details
Get Firmware Version command returns current firmware version string.
The version string is always encapsulated in '<' and '>', begins with the version
number in Vx.xx format, and possibly contains a small comment after a space.
Example:
-->DS:
DS-->:
V
A<V3.20 R3 final>
Command format:
Firmware Manuals
127
Possible replies:
A, D, F
First introduced:
See also:
NetLoader
Details
This command is only used on first-generation Devices (i.e. it is
implemented on Release3 firmware only).
Jump To NetLoader command verifies NetLoaderpresence and integrity, then
launches it. NetLoader integrity is verified by calculating the checksum on its code
and comparing this checksum with the stored one. The NetLoader is not launched
if the checksum is found to be invalid.
This command requires prior login using the Login (L) command (programming
session must be opened). Denied (D) reply code is returned if the programming
session is not in progress or if it doesn't belong to the sender of the Jump To
NetLoader command- the DS remembers the IP-address of the network host that
opens the programming session and requires that all subsequent commands (that
require prior login) are sent from the same IP.
Failed (F) reply code is returned if the NetLoader is found to be corrupted.
* Without prior selection using Select In Broadcast Mode (W) command.
Command format:
Possible replies:
A, D, F
First introduced:
See also:
NetLoader
Details
This command is only used on second-generation Devices (i.e. it is
implemented on Release3.5 firmware only).
Set Programming Request Flag command programs a special word of data into
the FLASH memory of the DS. When the DS reboots and the Monitor gains control
it verifies the state of the flag. If the flag is set the Monitor copies new firmware
file from the data FLASH memory of the DS into the program FLASH memory of the
DS. After the programming is finished the Monitor resets the flag automatically.
Before attempting to write into the program FLASH memory the Monitor verifies
integrity of the data in the data FLASH. If the data is found to be corrupted the
Monitor aborts the programming.
Set Programming Request Flag command is supposed to be used after the new
application firmware file is uploaded into the data FLASH memory of the DS using
128
Command format:
Possible replies:
A, D
First introduced:
See also:
NetLoader
Details
This command is only used on second-generation Devices (i.e. it is
implemented on Release3.5 firmware only).
Reset Upload Process command initializes application firmware file upload into
the data FLASH memory of the DS. This command should always be used before
upload itself, which is performed with Upload Data Block (D) command. To
make the DS upgrade the contents of its program FLASH (i.e. copy the application
from the data FLASH into the program FLASH) two other commands should be
used: Set Programming Request Flag (N), followed by Reboot (E).
This command requires prior login using the Login (L) command (programming
session must be opened). Denied (D) reply code is returned if the programming
session is not in progress or if it doesn't belong to the sender of the command- the
DS remembers the IP-address of the network host that opens the programming
session and requires that all subsequent commands (that require prior login) are
sent from the same IP.
* Without prior selection using Select In Broadcast Mode (W) command.
Firmware Manuals
129
Command format:
Possible replies:
A, D, C, S, 0, F
First introduced:
See also:
NetLoader
Details
This command is only used on second-generation Devices (i.e. it is
implemented on Release3.5 firmware only).
Upload Data Block command sends a 128-byte block of data to the data FLASH
memory of the DS. This command is used for application firmware upgrades
through the network.
Upgrade starts with Reset Upload Process (Q) command. After that, Upload
Data Block is used necessary number of times until entire application firmware
file is uploaded block by block. The first command sent should have its nn field set
to 0x00 0x00, next- 0x00 0x01, etc. Each command should supply exactly 128
bytes of data. If the file cannot be split into N full 128-byte blocks the last block
should be padded with any data. Once entire file has been uploaded two additional
commands should be used: Set Programming Request Flag (N), followed by
Reboot (E). After the DS emerges from reset the Monitor will copy new firmware
file from the data FLASH into the program FLASH.
This command requires prior login using the Login (L) command (programming
session must be opened). Denied (D) reply code is returned if the programming
session is not in progress or if it doesn't belong to the sender of the command- the
DS remembers the IP-address of the network host that opens the programming
session and requires that all subsequent commands (that require prior login) are
sent from the same IP.
Error (C) reply code is returned if command length wasn't exactly 131 byte in
length (command code + 2-byte block number + 128 bytes of data). Bad
Sequence (S) reply code is issued if data blocks were not consecutive (for
example, after block 3 came block 5). The DS replies with Out-of-range (O)
reply code if file size has exceeded data FLASH capacity. Failed (F) reply code
is returned if there was an error writing into the data FLASH. OK (A) reply code
is returned when the block is received properly and all is right. This code is always
followed by next block number -- 2 bytes in network byte order (High endian
format).
Upload Data Block command is different from all other commands in that its
fields are of binary type (all other commands are ASCII strings).
* Without prior selection using Select In Broadcast Mode (W) command.
130
Serial port
Command format:
Possible replies:
AC, AD
First introduced:
See also:
Details
Get Cable Status command returns current status of the network cable.
The return value AC means that the network cable is currently plugged in. The
value AD means that the network cable is disconnected. Note that this does not
indicate actual network connection status (see Status (U) command).
Command format:
Possible replies:
First introduced:
V3.32/3.63
See also:
---
Details
Get My IP command is used to determine under which IP address the DS sees the
sender of the command. This is not necessarily the same as the actual IP address
of the sender (for example, there might be a router between the DS and the PC).
The IP address returned by the command can then be used, for instance, to set
the Destination IP address (DI) of the DS.
Note that the fact that the PC (or another command sender) can "reach" the DS
does not automatically mean that the DS can "reach" (connect to) the PC. Network
setups are not always symmetrical!
You can remember this command's mnemonic as the first character of "Tell me
who I am".
Firmware Manuals
131
Send through:
Network
Format:
First introduced:
See also:
Details
Notification message in not a command, it is a message that the DS sends to
the network host when one of the monitored I/O lines of the DS changes its state
(for longer than 20milliseconds). The status of all lines is rolled into a single byte
of data and sent out even when a single I/O line changes its state.
Which I/O lines are being monitored is defined by the current Notification
Bitmask (NB) [setting/ parameter].
Notification messages are only generated when the data connection is in
progress and are sent to the network host with which this data connection is
established. Notification Destination (ND) setting defines which port on this
network host notifications are sent to.
How notifications are sent (out-of-band, inband, etc.) is defined by several factors:
If the Data Login (DL) setting is 1 (enabled), current Transport Protocol
(TP) [setting/ parameter] is 1 (TCP), and the data TCP connection is in the
command phase then notifications are sent via this TCP connection (IEC
character is not used). Otherwise...
If the Inband (IB) setting is 1 (enabled), and the current Transport
Protocol (TP) is 1 (TCP) then notifications are sent inside this TCP connection
as inband messages (IEC character is used). Otherwise...
Notifications are sent as out-of-band UDP datagrams.
The value in each Notification message should be interpreted as a collection of
binary bits, with each position corresponding to a certain I/O line of the DS. Bit
positions are exactly the same as those of the Notification Bitmask (NB)
Setting. Bit values correspond to the states of the I/O lines of Modules. Line states
on the RS232 connectors of Serial Device Servers and Boards that incorporate
RS232 transceivers are inverted relative to the states reported in the notification
message.
Example: supposing, the following Notification message is sent*:
J027
Decimal 27 converts to binary 00011011. This means that:
For devices such as EM100: P2/DSR and P5/RTS lines are LOW; P0, P1, P2/DSR,
and P4/CTS lines are HIGH;
For devices such as DS100: DSR and RTS lines are HIGH; DTR and CTS lines are
LOW.
Notification messages are not commands so they do not require any reply from
the receiving end.
If it is the DS that receives a Notification message from another DS, then the
following happens:
If current Flow Control (FC) [setting/ parameter] on the receiving DS is 0
(disabled) and current Serial Interface is full-duplex then this DS will set its
132
Settings
3.2.4.2
This section contains a reference for all DS settings.
Settings are permanent functioning parameters that are stored in the non-volatile
memory (EEPROM) of the DS. Once programmed, they remain intact even when the
DS is powered off.
Setting description format can be found here.
All settings are divided into four groups:
Network settings include basic set of parameters that define "networking
environment" of the DS. For more information see Ethernet port and network
communications.
Connection Settings define how and in which fashion the DS establishes
connections to and accepts connections from other hosts. For more information
see Ethernet port and network communications
Serial settings define the operation of the DS serial port. For more information
see serial port and serial communications.
Encapsulation settings define what incoming serial data is recorded into the
serial-to-Ethernet routing buffer and when and how this data is combined into the
network packets and sent to the network host. For more information see
serial-to-Ethernet data routing.
Post-initialization value:
Firmware Manuals
133
Overriding parameter:
Relevance conditions:
First introduced:
See also:
Details
Additional information about the setting.
Network Settings
Network settings include basic set of parameters that define "networking
environment" of the DS. For more information see Ethernet port and network
communications.
The following settings belong to this group:
Setting
Owner Name (ON) setting
Description
Defines the owner name identificator
for the DS
Device Name (DN) setting
Defines the device name identificator
for the DS
MAC-address (FE) setting
Defines MAC-address of the DS
DHCP (DH) setting
Enables/disables DHCP for the DS
IP-address (IP) setting
Defines the IP-address of the DS
Port Number (PN) setting
Defines the data port number of the
DS
dDNS Service Registration (DD)
Defines whether the DS will register its
setting
IP-address with dDNS Service of Link
[V3.24/3.54+]
Server at startup
dDNS Service IP-address (LI) setting IP-address for dDNS registration
[V3.24/3.54+]
Port number for dDNS registration
dDNS Service Port (LP) setting
[V3.24/3.54+]
Defines whether and when the DS will
PPPoE Mode (PP) setting
use PPPoE
[V3.54+]
LS Auto-registration (AR) setting
Defines whether, if rejected by the Link
[V3.24/3.54+]
Server, the DS will try to auto-register
Defines login name for PPPoE Access
PPPoE Login Name (PL) setting
Concentrator
[V3.54+]
134
GON
Post-initialization value:
<NULL>
Immediately
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
---
Details
This setting, together with the Device Name (DN) setting forms a name
identificator for the DS. Owner name and device name are returned by the Echo
(X) command.
Owner Name also serves two other purposes:
It is used to form device name supplied to the DHCP server
It is also used for logins onto the Link Server
GDN
Post-initialization value:
<NULL>
Immediately
Firmware Manuals
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
---
135
Details
This setting, together with Owner Name (ON) setting forms a string identificator
for the DS. Owner name and Device name are returned by the Echo (X)
command.
Device Name also serves two other purposes:
It is used to form device name supplied to the DHCP server
It is also used for logins onto the Link Server
SFExxx.xxx.xxx.xxx.xxx.xxx, where
xxx.xxx.xxx.xxx.xxx.xxx is the MAC-address in
the dot-decimal notation (i.e. 0.2.3.4.120.240)
GFE
Post-initialization value:
0.1.2.3.4.5
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
Each DS is shipped from the factory with unique MAC-address already assigned to
it. DO NOT change this address unless you have a good reason to do so. If you do
change the address remember that the first digit of the address must be even!
Since the MAC-address of each DS is unique it may be used for device
identification. It is returned by the Echo (X) command and also used to address
a particular DS in the Assign IP-address (A) command and Select in
Broadcast Mode (W) command.
This setting's mnemonic- "FE"- has to do with the previous name of the setting"Factory Ethernet Address". Mnemonic was preserved to ensure compatibility with
previous firmware versions.
136
GDH
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
DHCP
Details
This setting defines whether the DS will use a fixed IP-address, defined by the
IP-address (IP) setting or will obtain its IP-address from the DHCP server at
powerup. DHCP server must be present on the network for this to work. The DS
will not start normal operation until it receives the IP-address.
IP-address obtained from the DHCP server is saved into the IP-address (IP)
setting thus overwriting the previous setting value that might have been set
manually.
IP-address status (obtained/ not obtained) of the DS is returned by the Echo (X)
command and also displayed by status LEDs of the DS.
In addition to the IP-address configuration, the DHCP server is usually configured
to provide default Gateway IP-address and netmask. If this is the case, then
Gateway IP-address (GI) and Netmask (NM) settings will also be overwritten
by the data from the DHCP server.
GIP
Post-initialization value:
After reboot
Overriding condition:
---
Firmware Manuals
Relevance conditions:
First introduced:
See also:
137
Details
IP-address must be compatible with the network on which the DS is installed.
Many networks have DHCP server, in this case it is better to make the DS obtain
the IP-address automatically on startup (this is enabled by programming the
DHCP (DH) setting to 1 (enabled)).
When DHCP is activated the IP-address obtained from the DHCP server is saved
into the IP-address setting thus overwriting older value that might have been set
before.
Some IP-addresses are not valid in principle. Many devices and operating systems
(including Windows) automatically discard network packets that refer to such
incorrect IPs. The DS will allow such an IP-address to be saved into the EEPROM
but will assume a modified address on startup:
Invalid IP-address
actually use
x.x.x.0
x.x.x.1
x.x.x.255
x.x.x.1
>223.x.x.x
223.x.x.x
GPN
Post-initialization value:
1001
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
138
Details
This setting defines the Data Port on which the DS is accepting incoming data
connections.
For UDP communications, outgoing UDP datagrams are also sent from this port. For
TCP communications the DS accepts incoming data connections on the data port but
establishes outgoing connections from a pool of ephemeral ports in the
10000-10255 range (port number is incremented with each new connection).
Port 65535 is excluded from the allowable range because port 65535 is a
programming port of the DS- command UDP datagrams are sent to this port.
Technically, this only affects UDP communications, TCP connections should still be
able to use this port but the port 65535 was not allowed to be selected as the data
port from the early versions of DS firmware so this restriction is now preserved for
"historical" reasons.
Since programming UDP datagrams can now also be sent to port 32767, this port
cannot be used for UDP data communications when current Transport Protocol
(TP)[setting/parameter] is 0 (UDP). The DS will allow the Port Number to be
programmed to 32767 but all data sent to this port in the UDP mode will be
interpreted as programming commands. Using port 32767 for TCP communications
won't cause any problems.
New telnet programming method introduced in firmware V3.5x uses telnet port 23
for DS programming as well. Any connection established to port 23 of the DS is
interpreted by the DS as a programming connection. Therefore, this port cannot be
used for data connections when the current Transport Protocol (TP) is 1(TCP).
Older firmware does not use port 23 for programming so this restriction does not
apply.
GDD
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
V3.24/3.54
See also:
Details
This setting defines whether the DS will register its IP-address with dDNS Service
Firmware Manuals
139
of the Link Server at powerup. For more information on dDNS see Link Server
Documentation.
dDNS Service registration involves login onto the Link Server and uses the data
from the following settings of the DS: Owner Name (ON), Device Name (DN),
and Password (PW) setting). The password is supplied in the encrypted form so
the registration process is secure.
GLI
Post-initialization value:
127.0.0.1
After reboot
Overriding condition:
---
Relevance conditions:
First introduced:
V3.24/3.54
See also:
Details
This setting defines the IP-address to which the DS will try to connect in order to
register its IP-address with dDNS Service. For more information on dDNS see Link
Server Documentation.
dDNS Service IP-address is irrelevant when dDNS Service Registration (DD)
setting= 0 (disabled).
GLP
Post-initialization value:
6450
After reboot
Overriding parameter:
---
Relevance conditions:
140
V3.24/3.54
See also:
Details
This setting defines the port number to which the DS will try to connect in order to
register its IP-address with dDNS Service. For more information on dDNS see Link
Server Documentation.
dDNS Service Port is irrelevant when dDNS Service Registration (DD) setting=
0 (disabled).
GAR
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
V3.24/3.54
See also:
Details
The DS logs onto the Link Server in two cases: when it needs to register its
IP-address with the dDNS Service (dDNS Service Registration (DD) setting= 1
(enabled)), or when the DS needs to communicate through the Link Service (
current Link Service Login (TL) [setting/parameter]= 1 (enabled)).
When LS Auto-registration is set to 1 (enabled) the DS will attempt to register
on the Link Server if, during login process, the DS is rejected and the reason for
this rejection is that this DS is not yet registered (i.e. Link Server does not
recognize Owner Name (ON) and Device Name (DN)of this DS).
Auto-registration is convenient because it allows the user to avoid manual editing
of the list of client Device Servers on the Link Server.
WARNING! Auto-registration process involves sending DS password
(defined by the Password (PW) setting) to the Link Server. In this
particular case the password is sent "unprotected" (as is) which
constitutes a potential security vulnerability.
Firmware Manuals
141
GPP
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
V3.54
See also:
PPPoE
Details
This setting enables/disables PPPoE and also defines when, if at all, PPPoE login
will be performed. PPPoE Mode only affects communications with network hosts
located on remote network segments (local segment boundaries are defined by
the Netmask (NM) setting). When PPPoE is used all communications with remote
network hosts are effected through PPPoE "channel".
The setting offers three options:
0 (disabled)
1 (on connection) PPPoE is enabled. PPPoE login is performed when the DS needs
to establish a data connection to the remote network host. All
communications with remote hosts are effected through PPPoE
link (Access Concentrator), so default gateway is not used in
any way. PPPoE link is terminated app. 30 seconds after the
data connection is closed.
2 (on powerup)
PPPoE authentication uses PAP protocol (this is the only authentication protocol
currently supported). Login name and password for PPPoE Access Concentrator are
defined by PPPoE Login Name (PL) and PPPoE Login Password (PD) settings.
Notice that PPPoE is only available in firmware V3.54+. This means that
first-generation Devices (EM100-00/ -01/ -02, DS100-00/ -01/ -02) do not support
PPPoE.
142
GPL
Post-initialization value:
<NULL>
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
V3.54
See also:
PPPoE
Details
This setting defines login name for PPPoE Access Concentrator. Login name can be
up to 20 characters long.
This setting is irrelevant when PPPoE Mode (PP) setting is 0 (disabled).
Notice that PPPoE is only available in firmware V3.54+. This means that
first-generation Devices (EM100-00/ -01/ -02, DS100-00/ -01/ -02) do not support
PPPoE.
GPD
Post-initialization value:
<NULL>
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
V3.54
See also:
PPPoE
Firmware Manuals
143
Details
This setting defines login password for PPPoE Access Concentrator. Login name can
be up to 20 characters long.
This setting is irrelevant when PPPoE Mode (PP) setting is 0 (disabled).
Notice that PPPoE is only available in firmware V3.54+. This means that
first-generation Devices (EM100-00/ -01/ -02, DS100-00/ -01/ -02) do not support
PPPoE.
GGI
Post-initialization value:
After reboot
Overriding condition:
Relevance conditions:
First introduced:
See also:
Details
Gateway IP-address defines the IP-address of default gateway through which the
DS will (attempt to) establish a connection to the destination network host at
current Destination IP-address (DI) [setting/ parameter/ instruction] in
case this host is not on the same subnet with the DS.
Whether or not the destination network host is on the local subnet is determined by
comparing the IP-address (IP) setting, current Destination IP-address (DI),
and the Netmask (NM) setting (see this setting's description for details).
Gateway IP-address is irrelevant when the current Routing Mode (RM) [
setting/ parameter] is 0 (server) since in this mode outgoing connections are not
allowed. [V3.54+] This setting is also irrelevant when PPPoE is used i.e. PPPoE
Mode (PP) setting is 1 (on connection) or 2 (on powerup). This is because with
PPPoE all communications with remote hosts go through PPPoE link (Access
Concentrator), not default gateway.
When DHCP is activated (DHCP (DH) setting is 1(enabled)) the Gateway
IP-address obtained from the DHCP server is saved into this setting thus overwriting
older value that might have been set before. This only happens when the DHCP
server is configured to provide gateway IP-address data.
144
GNM
Post-initialization value:
0.0.0.0
After reboot
Overriding condition:
Relevance conditions:
First introduced:
See also:
Details
Netmask defines the boundaries of a local subnet. When establishing an outgoing
connection to the destination network host at current Destination IP-address
(DI) [setting/ parameter/ instruction] the DS compares this address with the
Netmask and its own IP-address (IP) to determine if the destination is on the
local or foreign subnet. The DS will (attempt to) connect directly to the current
Destination IP-address (DI) if the destination host is found to reside on the local
subnet or to the Gateway IP-address (GI) if the destination is found to reside on
a foreign subnet.
Comparison is done as follows:
All four bytes of the IP-address (IP) are ANDed with four bytes of the Netmask.
All four bytes of the current Destination IP-address (DI) are ANDed with four
bytes of the Netmask.
Results of previous two steps are compared: if they are equal then the destination
is on the same subnet with the DS, if different- the destination is on the foreign
subnet and the DS will be connecting through the gateway.
Example: supposing, the IP-address (IP) of the DS is 192.168.100.40
(C0.A8.64.28 in HEX representation), current Destination IP-address (DI) is
192.168.100.90 (C0.A8.64.5A in HEX) and the Netmask is 255.255.255.0
(FF.FF.FF.00 in HEX). Then:
C0.A8.64.28 AND FF.FF.FF.00 will result in C0.A8.64.00
C0.A8.64.5A AND FF.FF.FF.00 will result in C0.A8.64.00
Resulting numbers are the same so the destination is on the same subnet
Here is another way of explaining how the Netmask works. When printed in binary
representation, the Netmask always consists of a number of 1s on the left and the
number of 0s on the right (for the example above the Netmask value is 1111111.
Firmware Manuals
145
11111111. 11111111. 00000000). Positions with 1s (left side) represent the part in
which the current Destination IP-address (DI) must match the IP-address (IP)
of the DS to be considered local. Positions with 0s (right side) represent the range of
IP-addresses belonging to the same subnet. If the Netmask is 255.255.255.0 then
any IP-address that starts with 255.255.255 will be on the same subnet.
Netmask is irrelevant when the Current Routing Mode (RM) [setting/
parameter] is 0 (server) since in this mode outgoing connections are not allowed.
When DHCP is activated (DHCP (DH) setting is 1(enabled)) the Gateway
IP-address obtained from the DHCP server is saved into this setting thus overwriting
older value that might have been set before. This only happens when the DHCP
server is configured to provide netmask data.
GPW
Post-initialization value:
<NULL>
Immediately
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Authentication
Details
Certain network commands require authentication. To authenticate itself the
network host must provide a password that matches the one defined by the
Password setting.
Password setting also serves one other purpose- it is used for logins onto the Link
Server.
Connection Settings
Connection settings define how and in which fashion the DS establishes
connections to and accepts connections from other hosts. For more information
see Ethernet port and network communications.
The following settings belong to this group:
Setting
Connection Timeout (CT) setting
Transport Protocol (TP) setting
Description
Defines connection timeout (in
minutes)
Defines whether UDP or TCP protocol
will be used for data connections
146
GCT
Post-initialization value:
5 (5 minutes)
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
Connection Timeout defines after how many minutes an idle connection is
Firmware Manuals
147
GTP
Post-initialization value:
0 (UDP)
After reboot
Overriding parameter:
Relevance conditions:
---
First introduced:
See also:
Details
Transport Protocol defines which communications protocol- TCP/IP or UDP/IP will
be used by the DS for exchanging data with the network host.
Some aspects of UDP and TCP implementation in the DS are different from standard
or commonly used implementation. See UDP data "connections" and TCP data
connections for more info on the subject.
148
GBU
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
Details
When Broadcast UDP is 1 (enabled), the DS will accept and route the data
received in broadcast UDP datagrams, as if these packets were addressed directly to
this DS. Broadcast packets must still be addressed to the correct Port Number
(PN). DS will ignore broadcast UDP packets when Broadcast UDP is 0 (disabled).
This setting only allows/disallows the reception of broadcast UDP packets and has no
influence over whether the DS can send out its own broadcast UDP datagrams or
not. The DS can be made to send the broadcast packets by setting current
Destination IP-address (IP) [setting/ parameter/ instruction] to
255.255.255.255.
This Setting is irrelevant when current Transport Protocol (TP) [setting/
parameter] is 1 (TCP) because TCP protocol cannot use broadcast packets to carry
data.
GTL
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
Firmware Manuals
149
First introduced:
V3.24/3.54
See also:
Details
This setting defines whether the DS will perform Link Service login procedure after
a TCP data connection with another network host is established. For more
information on Link Service see Link Server Documentation.
Link Service logins use the data from the following settings of the DS: Owner
Name (ON), Device Name (DN), and Password (PW) setting). The password
is supplied in the encrypted form so Link Service logins are secure.
Link Server Login is irrelevant when Current Transport Protocol (TP) [setting
/parameter]= 0 (UDP) because UDP/IP cannot be used for communications with
the Link Server.
GIB
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
Details
Inband Commands setting defines whether inband (TCP) programming is enabled
or disabled.
This Setting is irrelevant when the current Transport Protocol (TP) [setting/
parameter] is 0 (UDP) because inband command passing is only possible when
TCP/IP is used for data connections between the network host and the DS.
Inband Commands setting is also irrelevant when current Link Service Login
(TL) [setting/parameter]= 1 (enabled) because inband commands are always
enabled when Link Service is used.
150
GDL
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
Details
Data Login defines whether command-phase TCP programming is enabled or
disabled.
This setting is irrelevant when the current Transport Protocol (TP) [setting/
parameter] is 0 (UDP) because command-phase programming is only possible
when TCP/IP is used for data connections between the network host and the DS.
Command-phase programming is disabled automatically when current Link
Service Login (TL) [setting/parameter] is 0 (disabled).
GRM
Post-initialization value:
0 (server)
After reboot
Overriding parameter:
Relevance conditions:
---
First introduced:
Firmware Manuals
See also:
151
Details
Routing Mode defines whether the DS will accept incoming connections (passive
opens) and/or establish outgoing connections (perform active opens):
0 (server)
1 (server/client)
2 (client)
GSF
Post-initialization value:
0 (disabled)
After reboot
Overriding param/instr:
Relevance conditions:
First introduced:
V3.24/3.54
See also:
152
GCM
Post-initialization value:
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
Details
Connection Mode defines under which condition the DS attempts to establish an
outgoing connection** to current Destination IP-address (DI) [setting/
parameter/ instruction] and current Destination Port Number (DP) [setting/
parameter/ instruction]:
0 (immediately)
Firmware Manuals
153
2 (on command)
GDI
Post-initialization value:
After reboot
Overriding param/instr:
Relevance conditions:
154
See also:
Details
Destination IP-address serves two purposes:
It defines the IP-address of the network host to which the DS will attempt to
establish an outgoing data connection. Exactly when the DS will attempt to
establish such a connection is specified by the Connection Mode (CM) setting.
Destination port the DS will attempt to connect to is specified by the current
Destination Port Number (DP) [setting/ parameter/ instruction].
[V3.24/3.54+] This address also specifies the only network host from which an
incoming data connection will be accepted when current Source IP Filtering
(SF) [setting/parameter] is 1 (enabled).
Destination IP-address of 255.255.255.255 means "link-level broadcasts". This
is a special case so the following considerations should be taken into account:
For outgoing connections:
When current Transport Protocol (TP) [setting/parameter] is 0 (UDP)
the DS will be sending out its own UDP datagrams as link-level broadcasts i.e.
with destination MAC-address set to 255.255.255.255.255.255. Furthermore,
there will be no destination switchover that happens when UDP datagram is
received from a network host (therefore, the DS will keep sending its
datagrams as broadcasts). For more information see UDP data "connections"
and broadcast UDP communications.
When current Transport Protocol (TP) [setting/parameter] is 1 (TCP) the
DS will not attempt to establish an outgoing connection at all. This is because
TCP is strictly a point-to-point protocol and does not support broadcasting.
[V3.24/3.54+] For incoming connections:
With Destination IP-address set to 255.255.255.255 the DS will accept
incoming connections from any network host even if current Source IP
Filtering (SF) [setting/parameter] is 1 (enabled).
Destination IP-address is irrelevant in the following cases:
For outgoing connections:
When current Routing Mode (RM) [setting/parameter] is 0 (server)
because the DS does not establish outgoing connections in this mode at all
[V3.24/3.54+] For incoming connections:
When current Routing Mode (RM) [setting/parameter] is 2 (client)
because the DS does not accept any incoming connections in this mode at all
When current Source IP Filtering (SF) [setting/parameter] is 0
Firmware Manuals
155
(disabled).
GDP
Post-initialization value:
1001
After reboot
Overriding param/instr:
Relevance conditions:
First introduced:
See also:
Details
Destination Port Number defines the port of the network host to which the DS
will attempt to establish an outgoing connection. When the DS will attempt to
establish a connection to the destination host is defined by the Connection Mode
(CM) setting. Destination IP-address the DS will attempt to connect to is defined
by the current Destination IP-address (DI) [setting/ parameter/
instruction].
Destination Port Number is irrelevant when the current Routing Mode (RM) [
setting/parameter] is 0 (server) since in this mode outgoing connections are not
allowed.
GND
Post-initialization value:
After reboot
Overriding parameter:
---
Relevance conditions:
156
See also:
Details
Notification (J) messages are generated when one of the monitored I/O lines of
the DS changes its state. Which I/O lines are monitored for changes is defined by
the Notification Bitmask (NB) setting. Notifications are only sent when the data
connection is established and are sent to the network host with which this
connection is established. Notification Destination defines which UDP port on the
destination host notifications are sent to when notifications are being sent as UDP
datagrams (out-of-band):
0 (last known port)
Notifications are sent to the UDP port from which the most
recent programming UDP datagram was received. Therefore,
notifications are sent after at least one such datagram is
received (since the data connection is established). This
option is useful when the DS has to send notifications to the
PC. Port number from which PC applications are sending
their programming UDP datagrams are usually ephemeral
which means that they are always changing. Therefore, the
DS will wait for the first programming UDP datagram to
arrive.
1 (port 65535)
Serial Settings
Serial settings define operation of the serial port of the DS. For more information
see serial port and serial communications.
The following settings belong to this group:
Setting
Serial Interface (SI)
setting
Flow Control (FC)
setting
DTR Mode (DT) setting
Description
Selects full-duplex or half-duplex mode for the serial
port of the DS
Enables or disables hardware (RTS/CTS) flow control
for the serial port of the DS
Defines the function of the DTR line of the serial port
of the DS
DTR Startup Mode (DS) Defines the startup mode of the DTR line (High or Low)
setting
[V3.27/V3.57+]
Firmware Manuals
Baudrate (BR) setting
Parity (PR) setting
Bits Per Byte (BB)
setting
Soft Entry (SE) setting
157
GSI
Post-initialization value:
2 (auto)
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
Serial port of the DS can operate in full-duplex or half-duplex mode. "Full-duplex"
and "half-duplex" here refers exclusively to the logical operation of the DS, not to
the hardware implementation of the serial port, which depends on the DS model.
The setting only influences the operation of the serial port in the data routing mode.
When the serial port is in the serial programming mode it is always using the
half-duplex interface- see serial programming for details.
0 (full-duplex)
158
2 (auto)
DS100B
Depends on jumpers
---
Comments
These products
are based on the
EM100; they
only support
RS232 i/f so
CTS/SEL and
ER/WS are left
unconnected
internally
This product is
based on the
EM100; jumpers
"decide"
whether
CTS/SEL and
ER/WS are
interconnected
Firmware Manuals
DS202
EM202-EV
EM120/EM200-EV
Always selected
---
159
These products
are based on the
EM120 or
EM200; they
only support
RS232 i/f so
CTS/SEL and SR
are left
unconnected
internally
* HI and LOW states are described with respect to the serial ports of DS100R,
DS100B, DS202R, EM100-EV, EM120/EM200-EV, EM202-EV. For EM100, EM120,
EM200, EM202, EM1000 the signaling is exactly opposite.
** Whether or not these two lines are interconnected is tested once at powerup.
Connecting or separating these line during device operation will not cause immediate
change of selected interface mode.
GFC
Post-initialization value:
1 (enabled)
Overriding parameter:
Relevance conditions:
First introduced:
See also:
Details
Flow Control setting defines the behavior of the RTS and CTS lines of the DS,
unless overridden by the Flow Control (FC) parameter.
When the Flow Control is 0 (disabled) the status of the CTS input is ignored and
the RTS line is at HIGH* unless changed by the remote host. Remote host can
control the RTS line through Set I/O Pin Status (Sx) instructions or Notification
(J) messages.
When the Flow Control is 1 (enabled) the RTS (output) and CTS (input) lines are
used to regulate the flow of data across the serial cable connecting the DS to the
attached serial device.
RTS is used to regulate the flow of data from the attached serial device to the DS.
When the serial-to-Ethernet buffer of the DS has free space the RTS is HIGH* and
160
GDT
Post-initialization value:
0 (idle)
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
When the DTR Mode is 0 (idle) the DTR line is at HIGH* unless changed by the
remote host. Remote host can control the DTR line through Set I/O Pin Status
(Sx) instructions or Notification (J) messages.
When the DTR Mode is 1 (connection status) the DTR (output) line of the DS
reflects current connection status: the DTR line is LOW* when no data connection is
Firmware Manuals
161
established at the moment and HIGH* when there is a data connection in progress.
Remote host can get current status of the DTR line at any time using the Get I/O
Pin Status (Gx) instruction, regardless of whether the DTR Mode is 0 (idle) or 1
(connection status). Status change monitoring for the DTR line can also be enabled
and Notification (J) messages generated regardless of the value of the DTR
Mode setting.
* HIGH and LOW states are described with respect to the serial ports of DS100R,
DS100B, DS202R, EM100-EV, EM120/EM200-EV, EM202-EV. For EM100, EM120,
EM200, EM202, EM1000 the signaling is exactly opposite.
GDS
Post-initialization value:
Overriding parameter:
---
Relevance conditions:
First introduced:
V3.27/V3.57
See also:
Serial programming
Details
This setting defines the startup voltage of the DTR pin. By default, DTR is LOW* on
startup. By changing this setting, you can have DTR set to HIGH* on startup.
DTR Startup Mode is irrelevant when the DTR Mode (DT) setting is 1
(connection status).
* HIGH and LOW states are described with respect to the serial ports of DS100R,
DS100B, DS202R, EM100-EV, EM120/EM200-EV, EM202-EV. For EM100, EM120,
EM200, EM202, EM1000 the signaling is exactly opposite.
162
GBR
Post-initialization value:
5 (38400bps)
Overriding parameter:
Relevance conditions:
---
First introduced:
See also:
Details
Baudrate setting defines the baudrate of the serial port of the DS.
This baudrate is used by the serial port in the data routing mode (unless overridden
by the Baudrate (BR) parameter) and also in the serial programming mode, but
only if the serial programming mode was entered through the escape sequence. If
the serial programming mode is entered by pressing the setup button the baudrate
becomes 38400bps regardless of the value of the Baudrate setting.
GPR
Post-initialization value:
0 (off)
Overriding parameter:
Relevance conditions:
---
First introduced:
See also:
Details
Parity setting defines the parity mode of the serial port of the DS, unless
overridden by the Parity (PR) parameter.
DS hardware does not have an option of two stop bits. The way around this is to set
the Parity to 3 (mark). Since this means that the parity bit will always be set to 1
and since the parity bit is always transmitted in front of the stop bit, this will have
the same result as having two stop bits.
The DS transmits the serial data with the parity bit correctly set but does not verify
Firmware Manuals
163
GBB
Post-initialization value:
1 (8 bits)
Overriding parameter:
Relevance conditions:
---
First introduced:
See also:
Details
Bits per byte setting defines the bits/byte mode of the serial port of the DS,
unless overridden by the Bits per byte (BB) parameter.
8 bits/byte are always used when the DS is in the serial programming mode.
GSE
Post-initialization value:
0 (disabled)
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
164
1 (type 1)
2 (type 2)
Firmware Manuals
165
It should be noted that attached serial device should parse the data
and double certain characters only for the data it sends to the DS.
Reverse operation is not needed for the data being received by
the serial device from the DS. Characters with ASCII code matching
that of escape character arrive from the DS in a normal way- i.e.
they are not "doubled".
Considerations Regarding RTS Line Status
Notice, that serial escape sequence works even when the serial port of the DS is
closed (i.e. when the Current Routing Mode (RM) [setting/ parameter] is 0
(Slave) and the data connection is not established). "Closed" merely means that
the serial port is not accepting any data into its serial-to-network buffer. The serial
port is still listening for escape sequences even at this time.
When the DS is running with the Flow Control (FC) setting set to 1 (Local) and its
serial port is "closed", the RTS line of the DS will be in the disabled state (thus
indicating to attached serial device that transmission is not allowed). Therefore, if
the serial device needs to transmit an escape sequence it must ignore the state of
RTS signal at that time.
Further behaviour of the RTS line while in serial programming mode is documented
under Serial Programming.
GEC
Post-initialization value:
Overriding parameter:
---
Relevance conditions:
First introduced:
V3.24/3.54
See also:
Serial programming
Details
This setting defines the ASCII code of character used in escape sequence. Which
escape sequence, if any, is used is defined by the Soft Entry (SE) setting.
Escape Character is irrelevant when the
166
GRC
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
When On-the-fly Commands setting is 1 (enabled) the DS will accept on-the-fly
commands (network-side parameters and instructions) from the network host.
When On-the-fly Commands setting is 0 (disabled) the DS will reject on-the-fly
commands from the host (Denied (D) reply code will be returned).
On-the-fly commands do not require prior authentication through Login (L)
command. Password protection specifically for on-the-fly commands can be
enabled through the On-the-fly Password (OP) setting.
On-the-fly commands provide a way of remotely controlling the serial port of the
DS, hence, the name of this setting- "Remote Control".
GOP
Post-initialization value:
0 (disabled)
After reboot
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
Firmware Manuals
167
Authentication
Details
On-the-fly commands (network-side parameters and instructions) do not require
prior authentication through Login (L) command. On-the-fly Password enables
password authentication specifically for on-the-fly commands, i.e. for the
Parameter (P) command that carries them.
When On-the-fly Password is 1 (enabled) and the Password (PW) setting is set
(not <NULL>) the network host must supply a valid password with every
Parameter (P) command it sends (see this command's description for more
information on how to do this).
On-the-fly Password is irrelevant when the On-the-fly Commands (RC) setting
is 0 (disabled) because in this case the DS doesn't accept on-the-fly commands at
all.
GNB
Post-initialization value:
After reboot
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
Notification Bitmask defines which I/O lines are monitored for changes. When the
line being monitored changes its state a Notification (J) message is generated
and sent to the network host with which the DS has an established data connection.
Notification Bitmask is a byte value each bit of which disables (when 0) or enables
(when 1) status change monitoring for a specific I/O line. Bit assignment is as
follows:
Bit position
0 (LSB)
1
168
<Not implemented>
<Not implemented>
CTS (input)
RTS (output)**
<Not implemented>
<Not implemented>
Bit position
EM100
DSR (input)
DTR (output)**
CTS (input)
RTS (output)**
<Not implemented>
<Not implemented>
EM120, EM200
0 (LSB)
P0
<Not implemented>
P1
<Not implemented>
P2/DSR(input)***
P2/DSR(input)***
P3/DTR(output)***
P3/DTR(output)***
P4/CTS(input)***
P4/CTS(input)***
P5/RTS(output)***
P5/RTS(output)***
<Not implemented>
P6
7 (MSB)
<Not implemented>
P7
EM202,
EM202-EV-TM,
EM202-EV-TS
<Not
implemented>
<Not
implemented>
P2/DSR(input)
***
P3/DTR(output)
***
P4/CTS(input)
***
P5/RTS(output)
***
<Not
implemented>
<Not
implemented>
* This data is for the case when you are using RS232 FB9M connector of the
EM120/EM200-EV. If you are using expansion connector (three jumpers removed)
then use I/O data for the EM120 and EM200 Modules
** From firmware standpoint, these are general-purpose I/O lines. These I/O lines,
however, are connected to the CMOS inputs of RS232 (RS422, RS485) transceivers
and that dictates that the lines can only be used as outputs. Therefore, it is
meaningless to enable notifications for such lines
*** These are general-purpose input/output pins. Application firmware uses these
pins to implement specific serial port functionality (shown in blue) and this defines
"logical" direction of the pins
Example: if Notification Bitmask is set to 20 then status change monitoring is
enabled for lines DSR and CTS (binary representation of this value is 00010100, bits
2 and 4 are set, corresponding I/O lines are DSR and CTS).
Be sure to keep the mask bit for unimplemented and reserved lines at 0.
For the line status change to be detected, the new status must be preserved for at
least 20 ms (milliseconds). Shorter "pulses" are ignored.
Note, that there is no bit for line P8 found on EM120 and EM200 Modules.
Encapsulation Settings
Encapsulation settings define what incoming serial data is recorded into the
serial-to-Ethernet routing buffer and when and how this data is combined into the
network packets and sent to the network host. For more information see
serial-to-Ethernet data routing.
Firmware Manuals
169
Description
Defines after how many new
bytes recorded into the
serial-to-Ethernet buffer a
break condition will be
generated
Defines the maximum time gap
between two consecutive
characters recorded into the
serial-to-Ethernet buffer,
exceeding which will trigger a
break condition
Defines whether the (next) data
block can be opened by a
specific character or any
character
Enables or disables the use of
the start character
Defines ASCII code of the start
character
Enables or disables the use of
the stop character
Defines ASCII code of the stop
character
Defines the number of post
characters for the stop
character
GML
Post-initialization value:
255 (bytes)
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
170
GMD
Post-initialization value:
1 (10 ms)
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
Maximum Intercharacter Delay defines the maximum time gap between two
consecutive characters recorded into the serial-to-Ethernet buffer, exceeding which
will trigger a break condition. Break conditions are related to routing the data in the
serial-to-Ethernet direction. See serial-to-Ethernet data routing for more
information.
Intercharacter delay can be set in 10 ms increments. Delay tracking is disabled
when Maximum Intercharacter Delay is set to 0.
Intercharacter delay is not counted when the Flow Control (FC) setting is 1
(enabled) and the DS is holding the RTS line in the LOW* state thus indicating to
the attached serial device that the DS is not ready to receive the data. This is done
to prevent the DS from generating the break conditions on time gaps caused by the
DS itself.
* HIGH and LOW states are described with respect to the serial ports of DS100R,
DS100B, DS202R, EM100-EV, EM120/EM200-EV, EM202-EV. For EM100, EM120,
EM200, EM202, EM1000 the signaling is exactly opposite.
Firmware Manuals
171
GSA
Post-initialization value:
1 (enabled)
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
When Start On Any Character is 1 (enabled) then any character received into the
serial port past the end of the previous serial data block will open a new serial data
block. When the Start On Any Character is 0 (disabled) then only a selected
specific character defined by the Start Character Code (S1) setting (must be
enabled through the Use Start Character (F1) setting) will be able to open the
new serial data block. All data between the end of the previous serial data block and
this start character will be ignored.
Serial data blocks are related to routing the data in the serial-to-Ethernet direction.
For more information see serial-to-Ethernet data routing.
GF1
Post-initialization value:
0 (disabled)
Overriding parameter:
---
Relevance conditions:
First introduced:
172
Details
This setting enables the use of specific character code as the start character that can
open the serial data block. Start character code itself is defined by the Start
Character Code (S1) setting. Serial data blocks are related to routing the data in
the serial-to-Ethernet direction. See serial-to-Ethernet data routing for more
information.
Use Start Character is irrelevant when the Start on Any Character (SA) setting
is 1 (enabled) because in this case the new serial data block is opened by any
character and there is no need to set a specific start character.
Care should be taken not to disable Use Start Character and Start on Any
Character (SA) setting at the same time. No data will ever be accepted into the
serial port of the DS in this case!
GS1
Post-initialization value:
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
Details
This setting defines the ASCII code of the start character that can open the serial
data block. Start character must be enabled separately through the Use Start
Character (F1) setting. Serial data blocks are related to routing the data in the
serial-to-Ethernet direction. See serial-to-Ethernet data routing for more
information.
Start Character Code is irrelevant when the Start on Any Character (SA)
setting is 1 (enabled) because in this case the new serial data block is opened by
any character and there is no need to set a specific start character.
Firmware Manuals
173
GU1
Post-initialization value:
0 (disabled)
Overriding parameter:
---
Relevance conditions:
---
First introduced:
See also:
Details
This setting enables the use of specific character code as the stop character that can
close the serial data block. Stop character code itself is defined by the Stop
Character Code (S1) setting. It is also possible to have the serial data block
closed not on the stop character itself but after a predefined number of characters
after the stop character. This is done through the Number Of Post Characters
(P1) setting.
Serial data blocks are related to routing the data in the serial-to-Ethernet direction.
See serial-to-Ethernet data routing for more information.
If Use Stop Character is 0 (disabled) the serial data block, once opened, never
closes.
GE1
Post-initialization value:
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
174
Details
This setting defines the ASCII code of the stop character that can close the serial
data block. The usage of the stop character must be enabled separately through the
Use Stop Character (U1) setting. It is also possible to have the serial data block
closed not on the stop character itself but after a predefined number of characters
after the stop character. This is done through the Number Of Post Characters
(P1) setting.
Serial data blocks are related to routing the data in the serial-to-Ethernet direction.
See serial-to-Ethernet data routing for more information.
GP1
Post-initialization value:
Overriding parameter:
---
Relevance conditions:
First introduced:
See also:
Details
Number Of Post Characters defines the number of characters received past the
stop character that will still be counted as belonging to the same serial data block.
Serial data blocks are related to routing the data in the serial-to-Ethernet direction.
See serial-to-Ethernet data routing for more information.
Number of Post Characters is irrelevant when the Use Stop Character (U1)
setting is 0 (disabled) because in this case the stop character is disabled.
Parameters
and Instructions
3.2.4.3
This section contains a reference for all DS parameters and instructions.
Parameters are temporary overrides for settings. Parameters are not saved into the
EEPROM and take immediate effect (no rebooting required). Instructions are used
to make the DS perform a certain action.
Parameter and instruction description format can be found here.
All parameters and instructions can be divided into two groups:
Firmware Manuals
175
Possible replies:
Relevance conditions:
First introduced:
See also:
Details
Additional information about the parameter (instruction).
Description
Overrides Flow Control (FC) setting
Overrides Baudrate (BR) setting
Overrides Parity (PR) setting
Overrides Bits Per Byte (BB) setting
Overrides Notification Bitmask (NB)
setting
Reads the status of a certain I/O line of
the DS
176
Possible replies:
A, C, D, R
Relevance conditions:
First introduced:
See also:
Details
Flow Control parameter overrides the Flow Control (FC) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Denied (D) reply code is returned if:
On-the-fly Commands (RC) setting is 0 (disabled).
If no password or incorrect password is supplied while the On-the-fly Password
(OP) setting is 1 (enabled) and the password is set (value of the Password
(PW) setting is not <NULL>).
Rejected (R) reply code is returned if this command is sent while the DS is in the
serial programming mode.
Possible replies:
A, C, D, R
Relevance conditions:
---
First introduced:
See also:
Details
Baudrate parameter overrides the Baudrate (BR) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Denied (D) reply code is returned if:
On-the-fly Commands (RC) setting is 0 (disabled).
If no password or incorrect password is supplied while the On-the-fly Password
(OP) setting is 1 (enabled) and the password is set (value of the Password
Firmware Manuals
177
Possible replies:
A, C, D, R
Relevance conditions:
---
First introduced:
See also:
Details
Parity parameter overrides the Parity (PR) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Denied (D) reply code is returned if:
On-the-fly Commands (RC) setting is 0 (disabled).
If no password or incorrect password is supplied while the On-the-fly Password
(OP) setting is 1 (enabled) and the password is set (value of the Password
(PW) setting is not <NULL>).
Rejected (R) reply code is returned if this command is sent while the DS is in the
serial programming mode.
Possible replies:
A, C, D, R
Relevance conditions:
---
First introduced:
See also:
Details
Bits Per Byte parameter overrides the Bits Per Byte (BB) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Denied (D) reply code is returned if:
On-the-fly Commands (RC) setting is 0 (disabled).
If no password or incorrect password is supplied while the On-the-fly Password
(OP) setting is 1 (enabled) and the password is set (value of the Password
(PW) setting is not <NULL>).
178
Possible replies:
A, C, D, R
Relevance conditions:
---
First introduced:
See also:
Details
Notification Bitmask parameter overrides the Notification Bitmask (NB)
setting. See Notification Bitmask (NB) setting for the bit position assignment
within the bbb value.
Error (C) reply code is returned if the data supplied in the command is invalid.
Denied (D) reply code is returned if:
On-the-fly Commands (RC) setting is 0 (disabled).
If no password or incorrect password is supplied while the On-the-fly Password
(OP) setting is 1 (enabled) and the password is set (value of the Password
(PW) setting is not <NULL>).
Rejected (R) reply code is returned if this command is sent while the DS is in the
serial programming mode.
Possible replies:
Relevance conditions:
---
First introduced:
See also:
Details
Get I/O Pin Status instruction returns the status of the DS I/O line specified by
the x parameter:
Firmware Manuals
Value of x
0
1
2
3
4
5
6
7
8
Value of x
DS100R, EM100-EV
<Not implemented>
<Not implemented>
<Not implemented>
<Not implemented>
CTS (input)
RTS (output)**
<Not implemented>
<Not implemented>
<Not implemented>
EM100
179
P0
<Not implemented>
P1
<Not implemented>
P2/DSR(input)***
P2/DSR(input)***
P3/DTR(output)***
P3/DTR(output)***
P4/CTS(input)***
P4/CTS(input)***
P5/RTS(output)***
P5/RTS(output)***
<Not implemented>
P6
<Not implemented>
P7
<Not implemented>
P8
EM202,
EM202-EV-TM,
EM202-EV-TS
<Not
implemented>
<Not
implemented>
P2/DSR(input)
***
P3/DTR(output)
***
P4/CTS(input)
***
P5/RTS(output)
***
<Not
implemented>
<Not
implemented>
<Not
implemented>
* This data is for the case when you are using RS232 FB9M connector of the
EM120/EM200-EV. If you are using expansion connector (three jumpers removed)
then use I/O data for the EM120 and EM200 Modules
** From firmware standpoint, these are general-purpose lines of the Ethernet
Modules that can be used as inputs. These I/O lines, however, are connected to the
CMOS inputs of RS232 (RS422, RS485) transceivers and that dictates that the lines
can only be used as outputs.
*** These are general-purpose input/output pins. Application firmware uses these
pins to implement specific serial port functionality (shown in blue) and this defines
"logical" direction of the pins
I/O line status (s) returned by the Get I/O Pin Status instruction indicates
current status of the I/O lines of Modules. For Serial Device Servers and Boards that
incorporate RS232 transceivers actual line status on the RS232 connector actual line
status is exactly opposite to the value of s: if s=0 then the line is at HIGH, if s=1the line is at LOW. Notice, that not only inputs, but also outputs can be monitored
using this command.
Error (C) reply code is returned if the data supplied in the command is invalid.
Denied (D) reply code is returned if:
On-the-fly Commands (RC) setting is 0 (disabled).
180
Possible replies:
A, C, D, R
Relevance conditions:
---
First introduced:
See also:
Details
Sets I/O Pin Status instruction allows the network host to remotely set the
status of the DS I/O line. Parameter x specifies the I/O line:
Value of x
0
1
2
3
4
5
6
7
8
Value of x
DS100R, EM100-EV
<Not implemented>
<Not implemented>
<Not implemented>
<Not implemented>
CTS (input)**
RTS (output)
<Not implemented>
<Not implemented>
<Not implemented>
EM100
P0
<Not implemented>
P1
<Not implemented>
<Cannot be set>***
P2/DSR(input)****
P3/DTR(output)****
P3/DTR(output)****
P4/CTS(input)****
P4/CTS(input)****
P5/RTS(output)****
P5/RTS(output)****
EM202,
EM202-EV-TM,
EM202-EV-TS
<Not
implemented>
<Not
implemented>
P2/DSR(input)
****
P3/DTR(output)
****
P4/CTS(input)
****
P5/RTS(output)
****
Firmware Manuals
6
<Not implemented>
P6
<Not implemented>
P7
<Not implemented>
P8
181
<Not
implemented>
<Not
implemented>
<Not
implemented>
* This data is for the case when you are using RS232 FB9M connector of the
EM120/EM200-EV. If you are using expansion connector (three jumpers removed)
then use I/O data for the EM120 and EM200 Modules
** From firmware standpoint, these are general-purpose lines of the Ethernet
Modules that can be used as outputs. These I/O lines, however, are connected to the
CMOS outputs of RS232 (RS422, RS485) transceivers and that dictates that the
lines must only be used as inputs.
*** Hardware limitation
**** These are general-purpose input/output pins. Application firmware uses these
pins to implement specific serial port functionality (shown in blue) and this defines
"logical" direction of the pins
Desired I/O line state (s) corresponds to the status of I/O lines of Modules. For
Serial Device Servers and Boards that incorporate RS232 transceivers actual line
status on the RS232 connector is exactly opposite to the value of s: if s=0 then the
line will be set to HIGH, if s=1- the line will be set to LOW.
Error (C) reply code is returned if the data supplied in the command is invalid.
Denied (D) reply code is returned if:
On-the-fly Commands (RC) setting is 0 (disabled).
If no password or incorrect password is supplied while the On-the-fly Password
(OP) setting is 1 (enabled) and the password is set (value of the Password
(PW) setting is not <NULL>).
Rejected (R) reply code is returned if this command is sent while the DS is in the
serial programming mode.
There are several cases when the Set I/O Pin Status (Sx) instruction is ignored
by the DS:
When the current Flow Control (FC) [setting/ parameter] is 1 (enabled) or
current Serial Interface (SI) is 1 (half-duplex) the DS ignores SP5s commands
(i.e. commands that attempt to set the status of the RTS line). This is because in
this case the RTS line is under the internal control of the DS.
When the DTR Mode (DT) setting is 1 (connection status) the DS ignores SP3s
commands (i.e. commands that attempt to set the status of the DTR line). This is
because in this case the DTR line is under the internal control of the DS.
Note, that in all above cases the DS still returns OK (A) reply code but the
commands are discarded internally.
182
Parameter/ instruction
Transport Protocol (TP) parameter
Link Server Login (TL) parameter
[V3.24/3.54+]
Routing Mode (RM) parameter
Source IP Filtering (SF) parameter
Destination IP-address (DI) parameter
Destination Port Number (DP)
parameter
Establish Connection (CE) instruction
Close Connection (CC) instruction
Description
Overrides Transport Protocol (TP)
setting
Overrides LS Login (TL) setting
Overrides Routing Mode (RM)
setting
Overrides Source IP Filtering (SF)
setting
Overrides Destination IP-address
(DI) setting
Overrides Destination Port
Number (PN) setting
Makes the DS establish data
connection with the network host
Makes the DS close data connection
with the network host, reset buffer
overflow flags
Makes the DS abort data connection
with the network host, reset buffer
overflow flags
Possible replies:
A, C, R
Relevance conditions:
---
First introduced:
See also:
Details
Transport Protocol parameter overrides the Transport Protocol (TP) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Rejected (R) reply code is returned if:
Command is issued while the IP-address of the DS is not properly configured (
DHCP (DH) setting is 1 (enabled) and the DS hasn't yet obtained the IP-address
from the DHCP server).
Current data connection state is not "closed". Transport protocol cannot be
changed while the connection is in progress. Close (or shut) the connection using
the Close Connection (CC) instruction or Abort Connection (CA) instruction
first. Current connection status can be verified using Echo (X) command (c flag).
Firmware Manuals
183
Possible replies:
A, C
Relevance conditions:
First introduced:
V3.24/3.54
See also:
Details
Link Server Login parameter overrides the Link Server Login (TL) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Possible replies:
A, C, R
Relevance conditions:
---
First introduced:
See also:
Details
Routing Mode parameter overrides the Routing Mode (RM) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Rejected (R) reply code is returned if this command is issued while the IP-address
of the DS is not properly configured (DHCP (DH) setting is 1 (enabled) and the DS
hasn't yet obtained the IP-address from the DHCP server).
Possible replies:
A, C
Relevance conditions:
First introduced:
V3.24/3.54
See also:
184
Possible replies:
A, C, R
Relevance conditions:
First introduced:
See also:
Details
Destination IP-address parameter overrides the Destination IP-address (DI)
setting. Notice that this setting's functionality has been extended in V3.24/3.54.
Error (C) reply code is returned if the data supplied in the command is invalid.
Rejected (R) reply code is returned if:
Command is issued while the IP-address of the DS is not properly configured (
DHCP (DH) setting is 1 (enabled) and the DS hasn't yet obtained the IP-address
from the DHCP server).
Current data connection state is not "closed". Destination IP-address cannot be
changed while the data connection is in progress. Close (or shut) the connection
using the Close Connection (CC) instruction or Abort Connection (CA)
instruction first. Current connection status can be verified through Echo (X)
command (c flag).
Firmware Manuals
Possible replies:
A, C, R
Relevance conditions:
First introduced:
See also:
185
Details
Destination Port Number parameter overrides the Destination Port Number
(DI) setting.
Error (C) reply code is returned if the data supplied in the command is invalid.
Rejected (R) reply code is returned if:
Command is issued while the IP-address of the DS is not properly configured (
DHCP (DH) settingis 1 (enabled) and the DS hasn't yet obtained the IP-address
from the DHCP server).
Current data connection state is not "closed". Destination port number cannot be
changed while the data connection is in progress. Close (or shut) the connection
using the Close Connection (CC) instruction or Abort Connection (CA)
instruction first. Current connection status can be verified through Echo (X)
command (c flag).
Possible replies:
A, C, R
Relevance conditions:
First introduced:
See also:
Details
Establish Connection instruction makes the DS establish an outgoing connection
with the network host. Which transport protocol is used (UDP or TCP) is defined by
the current Transport Protocol (TP) [setting/ parameter].
This command has two syntax options: with and without destination IP-address and
destination port number fields. Both fields must be either supplied or not supplied, it
is not possible to have only one of the fields in the command body.
When destination IP-address and destination port number fields are supplied they
are interpreted exactly as data fields in Destination IP-address (DI) parameter
186
PCC
Possible replies:
Relevance conditions:
---
First introduced:
See also:
Firmware Manuals
187
Details
Close Connection instruction makes the DS close current data connection (if
existed) and also reset routing buffers overflow flags (overflows are displayed by
the status LEDs, overflow status is also returned by the Echo (X) command- see S
and E flags).
As a result of Close Connection instruction execution UDP data "connections" are
simply discarded. TCP data connections are properly shut down (using
FIN-ACK-FIN-ACK sequence).
Close Connection instruction can be used at any time, even if the data
connection is already closed and if the data connection was not established by the
DS itself (i.e. it was a passive open).
OK (A) reply code is returned if command is accepted. This does not mean that
the connection has been shut down already, only that the DS has accepted the
command. Actual connection status can be verified at any time using the Echo (X)
command (see c flag).
Another instruction- Abort Connection (CA)- can be used to abort the TCP
connection (using the RST packet). For UDP data "connections" there is no
difference between the Close Connection instruction and the Abort Connection
(CA) instruction.
PCA
Possible replies:
Relevance conditions:
---
First introduced:
See also:
Details
Abort Connection instruction makes the DS end current data connection (if
existed) and also resets routing buffers overflow flags (overflows are displayed by
the status LEDs, overflow status also returned by the Echo (X) command- see S
and E flags).
As a result of Abort Connection instruction execution UDP data "connections" are
simply discarded. TCP data connections are reset (using RST packet).
Abort Connection instruction can be used at any time, even if the data
connection is already closed and if the data connection was not established by the
DS itself (i.e. it was a passive open).
OK (A) reply code is returned if command is accepted. This does not mean that
the connection has been reset already, only that the DS has accepted the command.
Actual connection status can be verified at any time using the Echo (X) command
(see c flag).
Another instruction- Close Connection (CC)- can be used to properly shut down
188
Firmware Manuals
189
Release V3.62
Corrected a bug that was causing the DS to lose (miss) data at 115200bps even
when the RTS/CTS flow control was enabled. Now the DS can sustain full-duplex
data transmission at 115200bps (RTS/CTS still required).
Default IP address of the DS has been changed to 0.0.0.1. Previous default
address of 127.0.0.1 was not a good choice- this IP is standard "loopback" IP of
many operating systems. Our users reported that Linux systems, in particular,
normally discard packets received from the device with IP address of 127.0.0.1.
Default Gateway IP and Destination IP have also be corrected in the similar
matter.
---------Release V3.61
Corrected a bug that sometimes made the last byte of the serial-->Ethernet
transmission get stuck in the serial-->Ethernet buffer.
Added DTR Startup Mode (DS) setting.
Increased the speed of line status change recognition.
---------Release V3.28
Corrected certain aspects of handling broadcast UDP packets. Users of DS
Manager sometimes encountered this situation: you click SETTINGS, the dialog
with progress bar appears, things go normally, and suddenly the progress bar
gets stuck right near the end. This has now been corrected.
Added DTR Startup Mode (DS) setting.
---------Release V3.56
Minor correction related to serial port behaviour at 300bps.
---------Release V3.26
New Cable Status (C) command
---------Release V3.25/3.55
The difference from V3.24/3.54 is in minor corrections in the behavior of the RTS
line.
---------Release V3.24/3.54
Two firmware versions has been released simultaneously: V3.24 for
first-generation devices (EM100-00/ -01/ -02, DS100-00/ -01/ -02) and V3.54 for
second-generation devices (EM120-00, EM200-00, EM202-00, DS202-00). Majority
of all changes was implemented in parallel in both firmware releases. In several
selected cases changes were made to only one of the versions- such changes are
marked with the version label like this one: [V3.24 only].
New: several major new features and corresponding settings/parameters have
been added:
190
Firmware Manuals
191
192
DHCPimplementation
Firmware Manuals
193
194
Firmware Manuals
195
NetLoader Communications
Communications with the NetLoader is effected by sending programming
commands as UDP datagrams to port 65535 of the DS. For each command the
NetLoader sends a reply, also in the form of a UDP datagram. Reply to a particular
command is always sent to the IP-address and the port number from which this
command was received.
Because each command and reply is sent in its own UDP datagram no additional
encapsulation is necessary.
All NetLoader commands have the following format:
C.C.
Optional parameter(s)
C.C. is the command code. Command code always consists of a single ASCII
character. All available commands and their codes are listed in the command table
at available commands.
Optional parameter(s) field contains necessary data if required by the
command.
All NetLoader replies have the following format:
R.C.
Optional data
R.C. is the reply code. Reply codes always consist of a single ASCII character and
inform the sender of the command about the result of command execution.
Optional Data field contains necessary data (if any).
Example: here is a sample exchange between the network host and the DS
running NetLoader. Each line represents the data in a separate UDP datagram.
Host-->DS(NetLoader): V
DS(NetLoader)-->Host: A<NV1.10 Netloader>
This method of exchanging commands and replies is exactly the same as the one
used by the application firmware of the DS where it is called out-of-band (UDP)
programming. UDP communications with the application firmware and the
NetLoader are the same except for the following small differences:
Latest versions of the application firmware accept UDP commands on two ports65535 and 32767. The NetLoader can only accept UDP commands on port
32767.
To speed up command execution the application firmware accepts multiple UDP
commands (this is based on using additional command ID field). The NetLoader
doesn't supports this feature and all commands should be sent strictly
one-by-one i.e. the network host should not intentionally send the next
command without first receiving (waiting for) a reply to the previous command.
196
Firmware Manuals
197
Firmware (E) command to start the newly loaded firmware. The host should
wait about 2 seconds (to allow the firmware to start) before proceeding to the
next step.
As the last step of the procedure it is better to issue the Echo (X) command
again to verify that the new firmware is, indeed, running.
The above procedure is, of course, simplified, as it does not take into account all
kind of possible errors that can potentially arise practically on every step of the
firmware upload. The "entity" performing the upgrade should carefully analyse the
result of every step in the above procedure and correctly react to different error
codes returned by the DS.
Also, the procedure above doesn't show the use of the Select In Broadcast Mode
(W) command that provides a way to program the DS whose IP-address is
unreachable (see broadcadt UDP programming for explanation). The NetLoader
also support a similar command (see Select In Broadcast Mode (W) command
). Important point to realize is that since the NetLoader is a separate firmware
component the Select In Broadcast Mode (W) command should be used twice:
The W command should be used to first time before sending the Login (L)
command and Jump To Netloader (N) command. This will pre-select the DS
for broadcast access while still in the application firmware.*
The W command should be used the second time when the NetLoader starts,
before starting the file upload (Start Over (Q) command, Data Block (D)
commands, and Verify and Start Firmware (E) command)*.
* These commands should, of course, be sent as UDP broadcasts in this case.
Available Commands
Table below lists all available NetLoader commands:
C.C.
X
W
S
D
E
V
B
+
+
Description
Echo command
Select In Broadcast Mode command
Start Over command
Data Block command
Verify And Start Firmware command
Get Firmware Version command
Notes:
C.C.- command codes.
B- '+' in this column indicates that command can be issued in the broadcast mode
(when sent through the network) without the need to pre-select a particular DS
using Select In Broadcast Mode (W) command first.
Command
Description Format
3.3.6.1
All commands in this section are described using the following format:
Function:
Command format:
Possible replies:
198
Details
Additional information about the command.
Echo (X)
command
3.3.6.2
Description (see command description format info here)
Function:
Command format:
Possible replies:
Annn.nnn.nnn.nnn.nnn.nnn/ppppp/m, where
nnn.nnn.nnn.nnn.nnn.nnn- MAC-address of the
DS;
ppppp- fixed at "65535";
m- fixed to 'L' (means that the NetLoader, not the
application firmware is running).
See also:
Details
The primary use of the Echo command is to auto-discover Device Servers on the
network and to verify that the NetLoader is running. When the network host sends
this command in the broadcast mode, it collects the replies from all locally
attached Device Servers (hence, the name of the command). Reply from each DS
contains all necessary information (MAC-address, etc.) that is needed to continue
communicating with each specific DS in a non-broadcast mode. This command has
its counterpart in the application firmware (see Echo (X) command).
Information returned by the Echo command contains the following data:
MAC-address is the most important field that can be used to uniquely identify
each DS! Besides, the MAC-address is used (and, therefore, must be known in
advance) as a reference to the particular DS in the Select In Broadcast Mode
(W) command.
Data port number field is fixed at 65535. The NetLoader doesn't use any data
ports so this field is provided for format compatibility with the Echo (X)
command in the application firmware.
m flag always returns 'L'. This is meant to indicate that the NetLoader is
running. In contrast, when the application firmware is running this flag shows
'N'.
* This is because each DS, like any other Ethernet device, has a unique
MAC-address preset during the production.
Select In
Broadcast Mode (W) command
3.3.6.3
Description (see command description format info here)
Function:
broadcast
Command format:
Ammm.mmm.mmm.mmm.mmm.mmm, where
Firmware Manuals
199
See also:
Details
Select In Broadcast Mode command has exactly the same function as the
Select In Broadcast Mode (W) command of the application firmware.
This command is used to pre-select a certain DS for subsequent firmware upload.
Only few NetLoader commands (such as Echo (X)) are accepted when sent in
broadcast UDP datagrams. All other commands are only accepted if they address a
specific DS. Such specific addressing normally involves sending UDP datagrams
with the IP-address of the targeted DS as the destination (i.e. non-broadcast
datagrams). This requires the IP-address of the DS to be reachable.
Select In Broadcast Mode command provides a way around this. Target DS,
referenced by its MAC-address, is first pre-selected using this command. After
that, all broadcast commands that are normally ignored when sent as broadcasts,
are not ignored and processed by this pre-selected DS.
When Select In Broadcast Mode command is issued all devices whose
MAC-addresses do not match the target MAC-address supplied in the command
body de-select themselves. This means that to switch onto working with another
DS in the broadcast mode you need to send the new Select In Broadcast Mode
command with the new target MAC-address. This will pre-select a different DS
while at the same time de-selecting the DS that was selected before. To de-select
all DS on the network send Select In Broadcast Mode command with no
MAC-address field.
This command only influences which DS responds when it is addressed using
broadcast UDP commands. Command has no influence over commands sent using
normal IP addressing.
The only possible reply to this command is OK (A). It is issued by the DS that has
recognised its MAC-address in the command body. If no DS on the local network
recognizes its MAC then there will be no reply received to this command.
Select In Broadcast Mode command should be issued (when necessary) right
after the NetLoader is started as all subsequent commands, such as Start Over
(Q), Data Block (D), and Verify And Start Firmware (E) won't work when send
as broadcasts without prior pre-selection.
It is important to understand that W command should be used within the
NetLoader even if it has already been used in the application firmware before the
NetLoader was started. This is because the application firmware and the NetLoader
are separate firmware components and the pre-selection made in the application
firmware will not be "passed" to the NetLoader.
Start Over
(Q) command
3.3.6.4
Description (see command description format info here)
Function:
Command format:
200
See also:
Details
Start Over command is used to reset the firmware upload. This resents internal
data block counter of the NetLoader and the first Data Block (D) command will
be expected to carry data block 0.
This command is recommended to be used after the NetLoader is started to make
sure that the upload process is properly initialized.
Data Block
(D) command
3.3.6.5
Description (see command description format info here)
Function:
Command format:
Dnndd...d, where
nn- block number (binary format, two bytes, high
byte first);
dd...d- 128 bytes of file data.
Possible replies:
See also:
Details
Data Block command carries a 128-byte block of application firmware file. Entire
application firmware file is to be uploaded using multiple Data Block commands
and the NetLoader expects that the firmware file size will consist of an integer
number of 128-byte blocks.
The data blocks must be sent in consecutive order i.e. the first block (block 0)
must carry first 128 bytes of the firmware file, block 1 should supply next 128
bytes, etc. Because NetLoader communications is based on UDP commands and
UDP packets can get lost each data block is sent with its own block number. This
way the NetLoader can make sure that all data blocks received are in sequence.
The nn field in the command body carries the block number. The block number is
supplied in a binary form. Since block numbers can exceed 255 two bytes are
needed for the block number. High byte goes first so, for example, to denote block
#300 the first two bytes should be 01H 2CH. Block numbers start from 0.
Following two block number bytes are 128 bytes of firmware file data. Again, the
data is supplied in a binary form, that is, a part of the firmware file is "cut out" and
attached to the command.
Like all other commands, the Data Block command returns an appropriate reply
status code. The difference is that all reply status codes are followed by the
number of the next expected data block. Next data block is present even in replies
indicating that the command was not processed successfully. In this case the next
expected data block simply remains the same (is not incremented). If the
command was completed successfully the nn field in the reply will "point at" the
next data block to be sent. For example, if the nn field in the command was 300
(01H 2CH) and the command was completed successfully the reply will have the
Firmware Manuals
201
nn field of 301 (01H 2DH). If command failed the nn field in the reply will still be
at 300 (01H 2DH).
OK (A) reply status code is returned if the data block was programmed
successfully or if the Data Block command has carried a data block that has
already been programmed. That is, if the NetLoader expects the block number to
be 10 and the network host supplies block 5 the NetLoader will reply with A code
and discard this data block.
Error (C) reply status code is returned if the total length of nn and dd...d fields
in the command is not 130 bytes.
Sequence Error (S) reply code is returned if the NetLoader receives the data
block with nn field greater than the one expected (for example, block 7 when block
6 was expected).
Out-of-range (O) reply code is returned if the total size of the firmware file
received by the NetLoader exceeds the size detected in the beginning of the file
upload. Total file size information is contained in the firmware file itself (in block
1). For example, if the file size was expected to be 40064 bytes then the total
number of data blocks had to be 40064/128=313. Therefore, the range of
expected data block numbers is 0...312. The NetLoader will return the O code if
any data block with the number greater than 312 is received.
Invalid Data (I) reply code is retuned if the NetLoader detects that the file data
sent by the network host is invalid. This can only be generated for data blocks 0
and 1. These blocks contain certain "service" information (such as the total file
size- see above) that the NetLoader checks to make sure that the firmware file
being uploaded is acceptable.
Failed (F) reply code is returned if the NetLoader fails to program the data block
into the FLASH memory of the DS.
We recommend that the network host sends the Start Over (Q) command before
beginning file upload with the Data Block commands.
Verify And
Start Firmware (E) command
3.3.6.6
Description (see command description format info here)
Function:
Command format:
Possible replies:
See also:
Details
Verify And Start Firmware command instructs the NetLoader to verify the
checksum of the application firmware and, if OK, to start application firmware
execution. This command is similar to the Reboot (E) commandof the
application firmware in that it ends the execution of the current firmware
(NetLoader).
Invalid (I) reply code is returned if the checksum is wrong and the NetLoader
continues running. No reply is returned if the checksup is OK, the NetLoader simply
passes control to the application firmware.
202
Get Firmware
3.3.6.7Version (V) command
Description (see command description format info here)
Function:
Command format:
Possible replies:
See also:
Details
Get Firmware Version command returns the version of this NetLoader. This
command is similar to the Get Firmware Version (V) command of the
application firmware.
The version string is always encapsulated in '<' and '>', begins with the version
number in NVx.xx format, and possibly contains a small comment after a space.
"N" in front stands for "NetLoader".
Example:
-->DS:
DS-->:
V
A<NV1.10 Netloader>
Software Manuals
This part of the documentation describes all PC software supplied by Tibbo.
At the moment, two software packages are available:
Device Server Toolkit (DST) software for Windows, currently in its V3.6.6 (
revision history).
Virtual Serial Port Driver for LINUX (VSPDL), current version is 1.0.
LinkServer software, current version is 2.0.
Software Manuals
203
204
DS Manager
Device Server Manager (DS Manager) is a part of the Device Server
Toolkit.
The DS Manager is used to locate, setup, manage, monitor, and
upgrade Tibbo Device Servers ("DS").
Shown below is the screenshot of the DS Manager's main window. Click on the
picture area to jump to the related topic or select the topic from the list under the
screenshot.
Software Manuals
205
DS Status
Icons
4.1.1.1
Status field of the device list (available in the auto-discovery and address book
access modes) displays a status icon for each DS. The status icon reflects current
DS state and is updated each time the Refresh button is pressed. Listed below are
all DS states that may be reflected in the device list.
The following two states can only be displayed in the address book mode:
---
When no icon is displayed for an address book entry then this means that
there was no response to the PING sent by the DS Manager. This indicates
that there is no device whatsoever at the IP-address specified by the address
book entry. For more information see troubleshooting (address book mode).
Unknown device. This icon means that there was a response to the PING
sent by the DS Manager (which proves that there is at least some device at
the specified IP-address) but that the DS Manager cannot make sure that this
is really a Tibbo Device Server. For more information see troubleshooting
(address book mode).
Note. The reason why the above two states can only be encountered in the
address book access mode is because in the auto-discovery mode the device list
only displays Tibbo Device Servers that have actually responded to the refresh.
All remaining icons may be displayed both in the auto-discovery and address book
access modes.
The status icon consists of three parts:
The central part depicts the DS and reflects its general status and well-being:
No status info available. The DS is running old firmware (2.xx or older)
and the status information cannot be obtained remotely.
Normal state. The DS is online and appears to function properly.
Error mode. The DS is running in the error mode and requires initialization;
206
Central, left, and right icon parts described above are combined into a single status
icon.
Example: the following "combination" icon means that the DS is running in the
error mode, data connection is currently established (but no overrun has been
detected), and some form of programming (either serial or network) is in progress:
In addition to different states described above the whole status icon can be
displayed in full color or grayed (see sample icons below). This only applies to local
Device Servers and the auto-discovery mode).
Full color. This means that the DS Manager can communicate with the
DS using "normal" IP addressing.
Grayed**. When the status icon is grayed then this means that the DS
Manager can see the DS but cannot communicate with the DS using
normal IP-addressing. Full details on what this means are provided in the
following topics: broadcast access, troubleshooting (auto-discovery
Software Manuals
207
mode).
Additional (and more full) status information for the selected DS (i.e. the DS whose
line is highlighted in the device list) is displayed in the status area below the device
list. For example, while the status icon may show that some sort of programming is
in progress the status area message will detail that the "UDP network programming
session is in progress". Each status message has a clickable link that opens a
corresponding help topic (all such topics can be found at DS status messages).
Programmer's info:
The DS Manager collects DS status information (and detects DS presence) using
the Echo (X) command.
* More info on network programming sessions can be found in the following topics:
authentication, programming priorities.
** Actually, "watered down" as colors can still be distinguished.
Access4.1.1.2
Modes
The DS Manager has three fundamental modes of operation, called access modes,
that define how it finds, connects to and works with Device Servers. Desired access
mode is selected from the access mode drop-down box, located at the top of the
main window of the DS Manager (see figure below):
208
Software Manuals
209
In the auto-discovery mode the device list has the following fields:
DS status icon. See DS status icons for more information.
MAC-address of the DS. It is the MAC, not the IP-address, that uniquely
identifies each DS in the list.
IP-address of the DS. Comment next to the IP-address shows that this device is
local (same for all devices in the list since auto-discovery mode only shows local
Device Servers). If the DS is running with DHCP enabled the note "DHCP" is also
displayed next to the IP-address (as in line 2 of the screenshot above). As you
can see from the screenshot, correct IP-address is not required for the DS to be
discovered. IP-address in line 4 is invalid yet the DS Manager can "see" this DS
as well.
Owner name and device name fields displays the data from the Owner Name
(ON) and Device Name (DN) settings of the DS. The purpose of these settings
is to simplify distinguishing between the Device Servers in the device list.
Device list of the auto-discovery mode is sorted by MAC-address, then by
IP-address. You can change the sorting order by clicking on any of the headers.
Programmer's info:
When the Refresh button is pressed the DS Manager sends out a broadcast Echo
(X) command. This command reaches all local Device Servers, even the ones with
unreachable IP-address. Devices shown in the device list are those that have
replied to the broadcast
* I.e. the Device Servers located on the same network segment. The definition of
the network segment implies that there are only network hubs (and no routers,
bridges, firewalls, etc.) between the PC and all other devices on the segment.
Broadcast Access
In the auto-discovery access mode the DS Manager can detect and access all local
Device Servers, even those whose IP-address is "unreachable" (incompatible with
the network settings of the PC, conflicts with the same IP-address set on another
Ethernet device, etc.).
Device Servers with unreachable IP-address are accessed using broadcast
210
Software Manuals
211
mode the DS Manager can only "see" Device Servers on the same network
segment as your PC (local Device Servers). Remote Device Servers located
behind routers (firewalls, etc.) cannot be accessed. Use address book access
mode to work with remote Device Servers.
Firewall software on your PC may be preventing communications between the DS
Manager and Device Servers. This communications relies on UDP traffic between
port 65534 of the PC and port 65535 of the Device Servers. Make sure that your
firewall software does not ban this traffic! Our experience shows that many Users
are not aware of the firewall software installed on their own PCs! Some firewalls
come as part of larger "protection" suites (anti-virus, anti-intrusion, etc.
programs). Some operating systems, such as Windows XP, include the firewall
software too!
If your DS is running an older firmware (V2.xx) then it will not be accessible
through the network and visible to the DS Manager in the following cases:
When the DS is in the serial programming mode
(status LEDs of the DS "play" the pattern as shown on
the left)**;
When the DS is in the error mode (status LEDs of the
DS "play" the pattern as shown on the left)**.
This does not apply to the Device Servers running DS firmware V3.xx or higher.
In this firware the DS is visible on the network at all times.
If there are many devices shown in the device list the DS you are looking for
may actually be in the list! A very useful buzz feature allows you to match device
list entries to their actual physical Device Servers. Use this function and you will
probably "find" your DS (buzz feature is only supported by DS firmware V3.xx or
higher).
Here is why the DS may be shown in the device list as having an
unreachable IP-address:
Because the IP-address of the DS is really unreachable. This means that it is
outside of the IP-address range defined for the subnet to which your PC is
connected. For example, if the IP-address of your PC is 192.168.100.30 and the
netmask is 255.255.255.0 then your local subnet has the IP-address range from
192.168.100.1 to 192.168.100.254***. So, if you connect the DS to the local
network segment and set its IP-address to 192.168.100.40 then the DS Manager
will be able to access this DS. If you set the IP-address to 192.168.10.40 then
your PC will decide that this IP-address is on some other subnet and will relate
all communications (related to this IP) to the "default gateway". This means that
network packets addressing this DS won't even be released into the network to
which the DS is physically connected.
Because the DS Manager has cached a different MAC-address for the IP-address
currently assigned to the DS in question. This can happen if you connect
different Device Servers one by one to the same network segment and then
assign the same IP-address to each Device Server. This is often reported by our
Users that want to pre-program or test several Device Servers. What happens
here is that after the first DS is detected/accessed by the DS Manager the PC
finds out the MAC-address that corresponds to the IP-address of the DS****. If
you quickly connect another DS in place of the first one and assign the same
IP-address to it the PC won't bother to "resolve" the IP-address again and will
attempt to communicate with the "cached" MAC-address instead. Since MACs are
unique for each DS the DS Manager won't be able to communicate with the new
212
Address book access mode is selected by choosing the "Address Book" tab in DS
Manager's main window.
In this mode the DS Manager displays a manually created list ("the address book")
of Device Servers. Each entry in the list specifies the IP-address (and port number)
at which the DS is (supposed to be) located or through which the DS can be
accessed. The address book is edited using three buttons - Add, Remove, and Edit.
You can also divide the book into Device Groups, which can be managed via the
Groups button.
Address book mode allows the DS Manager to communicate both with local and
remote Device Servers (i.e. located behind the routers)*. Since local Device
Servers can easily be accessed using the auto-discovery access modethe primary
use of the address book mode is to access remote Device Servers.
Modern routers offer a bewildering array of routing arrangements and security
(firewall) options. To adjust for all this complexity the address book mode provides
a flexibility of defining access parameters separately for each entry in the list. This
Software Manuals
213
includes, apart from the IP-address, the access method and the access port
number.
In the address book mode the device list always displays all entries from the
currently active group in the address book (this is different from the auto-discovery
mode which only shows online devices). Each time Refresh button is pressed the
DS Manager verifies which Device Servers are online and reflects this by displaying
an appropriate icon for each entry in the list. Status area under the device list
displays extended status information for the DS selected in the list.
In the address book mode the device list has the following fields:
Group listbox allows you to select and manage Address Book device groups.
See Managing Address Book Groups (Groups button).
DS status icon. See DS status icons for more information. Since the address
book consists of addresses, not actual devices, there is no guarantee that there
is definitely a functioning DS at each specified location. On the sample
screenshot above no device is found at location specified by line 3 (no status icon
displayed) and unknown device (not a Tibbo Device Server) is found at location
specified by line 4 ( is displayed).
IP-address of the DS itself or the forwarding IP-address on the router through
which this DS can be accessed (this depends on the router setup**). Comment
next to the IP-address shows whether the DS is local (otherwise it is remote). If
the DS is running with DHCP enabled the note "DHCP" is also displayed next to
the IP-address.
Access method and programming port number of the DS itself or the
forwarding port on the router through which this DS can be accessed (this
depends on the router setup**). Access parameters for the address book mode
topic provides detailed info on the subject.
Owner name and device name fields displays the data from the Owner Name
(ON) and Device Name (DN) settings of the DS. The purpose of these settings
is to simplify distinguishing between the Device Servers in the device list.
Comment field (unlike owner name and device name) is associated with the
address book entry and is stored on the PC.
Device list of the address book mode is not sorted and is kept in the original order
of entry. You can sort the list by clicking on the field headers (Status, IP, Access,
214
Software Manuals
215
point the DS Manager will attempt to establish a TCP connection to the DS and
find out if the DS is accessible. This will be reflected in the device list.
For the inband access to work the DS must be preset in a certain way firstread preparing the DS for inband access for step-by-step instructions.
It is not possible to access the DS using inband access method when the DS is
already engaged in a data TCP connection with another application and/or
network host. Since inband commands are, by definition, the commands that
are passed within the data connection itself the DS Manager actually
establishes a data TCP connection with the DS in order to program it (this is
why this connection is made to the data port of the DS, not the command
port). The DS only allows for a single data connection at a time, so if it is
already engaged in a data connection with another application and/or network
host the DS Manager will be rejected.
When telnet TCP access method is selected the DS Manager performs
programming through a TCP connection established to port 23 of the DS (see
telnet TCP programming). Unlike inband access method, this does not require
any prior setup of the DS side but will only work with newer Device Servers
that run on firmware V3.50 or higher.
* Here we touch on a very complicated subject. Modern routers offer a bewildering
array of setup options. We will attempt to cover this in details in our upcoming
white papers.
216
"No response" status is displayed when the DS Manager cannot PING the
IP-address specified in the address book entry.
Here is why you may get "no response" status:
Software Manuals
217
218
Software Manuals
219
Therefore, you must connect the serial port of the DS to the unused COM of your
PC using a DS-to-PC cable (like WAS-1455 supplied by Tibbo).
In the COM access mode the device list displays all physical COM ports of your PC.
The DS Manager is not able to determine which COM the DS is connected to so you
have to make a correct selection by yourself.
For the DS Manager to access the DS the latter must be in the serial programming
mode. To put the DS into this mode press the setup button*.
Note:
Status LEDs of the DS are playing a serial programming
mode pattern (shown on the left) when the serial port
of the DS is in the serial programming mode (click here
to see all available patterns).
* On EM100, EM120, EM200, EM202, EM1000- pull the MD line LOW for at least
100ms.
220
Functions
4.1.1.3
This section lists all "functions" (features) of the DS Manager. These functions are
associated with the function buttons located in the DS Manager's main window.
When the settings dialog is opened it reads out current values of all settings
available on the DS and displays them in a setting table. All settings are divided
into groups and each group is placed on its own group tab. Dialog caption displays
the version of firmware running on this DS. If "+N" is displayed next to the version
number then this means that the NetLoader is present and the firmware of this DS
Software Manuals
221
222
Software Manuals
223
100ms.
224
Software Manuals
225
* On-the-fly commands are used, for instance, by Virtual Serial Ports (VSPs) to
change serial port configuration of the DS. This way PC application that has opened
the VSP can change the setup of the DS serial port as needed.
226
Software Manuals
227
228
It allows you to create, edit and delete groups (the buttons are self-explanatory). A
group has just one attribute -- a name.
Once you create a group, you can assign Device Servers to it using the Address
Book Entry dialog. You can rename a group after you have filled it with devices. The
devices will still be mapped to that group.
DS Status Messages
This section provides additional information on the status messages displayed in
the status area of the DS Manager's main window.
The list of messages is arranged in the alphabetical order.
Description
Message text:
Details
This status means that some settings on this DS are invalid and require
initialization. The DS should not be allowed to operate in this condition and must
be reinitialized as soon as possible.
Programmer's info:
The DS Manager collects DS status information (and detects DS presence) using
Software Manuals
229
the Echo (X) command. Whether or not the DS is in the error mode is determined
from the state of the e flag in the command response.
Description
Message text:
Details
This status means that the DS is running the NetLoader. NetLoader is a separate
firmware component that facilitates application firmware upgrades over the
network. Normally, this icon is displayed during the network firmware upgrade.
After the network upgrade is finished the DS Manager reboots the DS and after that
the DS is supposed to start running the newly loaded firmware.
If the DS enters the firmware upgrade mode unexpectedly and if this mode
"persists" then this means that DS firmware is corrupted, or that incorrect firmware
file was uploaded, or that the upload was incomplete.
Programmer's info:
The DS Manager collects DS status information (and detects DS presence) using
the Echo (X) command. This command is supported both by the application
firmware and by the NetLoader. Whether the DS is running its application firmware
or is in the firmware upgrade mode is determined from the m flag in the command
response (it is 'N' for the application firmware and 'L' for the NetLoader).
Description
Message text:
Details
This status means that the DS is running with DHCP enabled (DHCP (DH) setting
is 1 (enabled)) and the DS hasn't yet received its IP-address from the DHCP server.
The DS attempts to configure its IP-address after the powerup and won't perform
its routing function until IP configuration is completed. Typically, IP configuration
takes only 1-2 seconds to complete. If the DS is "stuck" in this state for much
longer then this means that DHCP service may not be available on your network.
Programmer's info:
The DS Manager collects DS status information (and detects DS presence) using
the Echo (X) command. IP configuration status is determined from the state of
the i flag in the command response.
230
Details
See troubleshooting (address book mode) for a list of hints on why you might be
getting no reply for this address book entry.
Programmer's info:
---
Description
Message text:
Details
In the V3.xx firmware the DS returns its status information along with the response
to the echo request, sent by the DS Manager during the refresh. In older firmware
versions (V2.xx) the response from the DS does not contain any status information.
You are recommended to upgrade your firmware to the latest version.
Programmer's info:
The DS Manager collects status information (and detects DS presence) using the
Echo (X) command. In the old firmware versions this command only returned the
first two fields (nnn.nnn.nnn.nnn.nnn.nnn and ppppp).
Description
Message text:
Software Manuals
231
Details
Three separate status messages are displayed for three possible forms of DS
programming: serial, out-of-band (UDP), and inband (TCP). Serial programming is
considered to be in progress whenever the serial port of the DS is in the serial
programming mode. Out-of-band (UDP) or inband (TCP)programming session is
considered to be in progress after the network host has logged in using a
corresponding access method (out-of-band or inband)- see authentication*. Inband
(TCP) access method is only used in the address book mode (see access
parameters for the address book mode).
All three forms of programming are mutually exclusive- see programming priorities.
Programmer's info:
The DS Manager collects DS status information (and detects DS presence) using
the Echo (X) command. Whether or not any form of programming is in progress
is determined from the state of the s flag in the command response. Network logins
are performed using the Login (L) command.
* Just sending commands that do not require prior login does not constitute a
programming session.
Description
Message text:
Details
These messages are displayed when one or both routing buffer overflow is
detected. Routing buffers are used for temporary data storage when routing data
between the Ethernet and serial ports of the DS.
In general, do the following to avoid overflows:
For Ethernet-to-serial buffer: using TCP/IP transport protocol (see Transport
Protocol (TP) setting) guarantees that this buffer never overflows.
For serial-to-Ethernet buffer: using RTS/CTS flow control (see Flow Control
(FC) setting) guarantees that this buffer never overflows*.
Programmer's info:
The DS Manager collects DS status information (and detects DS presence) using
the Echo (X) command. Buffer condition is determined from the state of the E
and S flags in the command response.
* Naturally, attached serial device must also support RTS/CTS flow control for this
to work.
232
Details
See troubleshooting (address book mode) for a list of hints on why you might be
getting this status for an address book entry.
Programmer's info:
---
Description
Message text:
Corresponding status icon:
May appear in:
Details
This status means that the DS Manager has detected the DS on the local network
segment but is unable to communicate with this DS by using a "normal" IP
addressing. See troubleshooting (auto-discovery mode) for a list of hints on why
this could happen.
Programmer's info:
---
Software Manuals
233
Details
This message means that the DS Manager cannot communicate with the DS using
a normal IP-addressing. Possible reasons for why this could happen are outlined in
troubleshooting (auto-discovery mode).
The DS Manager can access local Device Servers even when normal IP
communications is impossible. This is done through a so called broadcast access.
This functionality, however, is only supported by DS firmware V3.xx or higher.
The way out of this situation is to make normal IP communications possible or/and
to upgrade the DS firmware to V3.xx or higher. Depending on how old the DS
firmware is you may not be able to upgrade the firmware over the network and will
need to do this through the serial port of the DS (in the COM access mode).
Programmer's info:
Broadcast access is based on the Select In Broadcast Mode (W) command that
was only introduced in firmware V3.xx.
Description
Message text:
Details
When inband (TCP) access method is specified for a particular address book entry
and the DS Manager needs to access the DS it must establish a TCP connection to
this DS first. This message indicates that TCP connection could not be established.
Read troubleshooting (address book mode) for hints on what might be causing the
problem.
Programmer's info:
---
Description
Message text:
Details
--Programmer's info:
The DS Manager verifies whether the DS is engaged in a data connection by
234
Description
Message text:
Details
After having changed the IP-address the DS Manager makes sure that the DS is
online and using the IP-address that was just assigned. This message appears when
the DS has confirmed that command was accepted but later could not be found
among local Device Servers. This situation is not normal and may indicate that the
new IP-address is (for some reason) blocked by your PC or network equipment.
Note, that this is more serious than the case when the IP-address turns out to be
unreachable (this situation is reported by the unreachable IP-address status
message). If this was the case the DS Manager would still be able to detect the DS
on the network. Watch out for some special firewall settings of your PC or similar
reasons why communications with a certain IP-address might be blocked (also see
troubleshooting (auto-discovery mode)).
Programmer's info:
IP-address is changed using Assign IP-address (A) command. This message
means that OK (A) status code was actually received for this command but the
DS could not be found during subsequent refresh operation.
Description
Message text:
Details
Firmware upgrades over the network are facilitated by a separate firmware
component called the NetLoader. To upgrade the application firmware over the
network the DS Manager makes the DS switch to the NetLoader first.
When control is passed to the NetLoader, it attempts to read the values of
IP-address (IP) and MAC-address (FE) settings and use these values. This way
the switchover to the NetLoader is "seamless" and the DS is still accessible at the
same IP and MAC as when it was running the application firmware.
In selected cases, the readout of those two settings can fail (for instance, when
one or both of these settings is/are invalid). In this case the DS will replace the
invalid value(s) with a default one: 127.0.0.1 for the IP-address, 0.1.2.3.4.5 for
the MAC-address.
Software Manuals
235
If you are accessing the DS using the address book mode and the DS assumes
these default values you may not be able to access it (at least temporarily). We
recommend you to connect the DS to the same network segment with your PC and
use the auto-discovery access mode.
Programmer's info:
---
Description
Message text:
Details
The cause of this message is similar to that of the DS lost (after entering
NetLoader) message (but "in reverse"). After the NetLoader has finished working
and the DS was rebooted its IP-address and/or MAC-address have probably
changed. To the DS Manager this will look like "disappearance" of the DS from the
network.
To "find" the DS connect it to the same network segment as the PC and run the DS
Manager in the auto-discovery access mode. To find out which device in the list is
the one you are looking for either disconnect all other Device Servers from the
network (this will leave only one DS in the list) or use the Buzz function to locate
the DS.
Programmer's info:
--Description
Message text:
Details
After having performed the initialization the DS Manager makes sure that the DS is
online. Network initialization does not change the IP-address unless the IP-address
(IP) setting were found to be invalid. The default factory value for this setting is
127.0.0.1*, so see if there is a DS now that has this IP-address. If so then this may
be your "lost" Device Server!
Programmer's info:
--* Unless another default value has been defined through a custom profile.
236
Details
Each DS in the address book is identified by the combination of the IP-address,
access port number, and the access method (see access parameters for the address
book mode). This message means that your input matches another address book
entry that already exists.
Programmer's info:
--Description
Message text:
Details
This message appears when you attempt to open the settings dialog while the DS
is in the error mode. Because some settings are invalid the DS Manager is unable
to read out their values and display them in the settings dialog.
Once the error mode is detected it is better to initialize the DS as soon as possible.
Continuing DS operation is this state may lead to incorrect (unexpected) DS
behavior and also exposes the DS to unauthorized access- password protection is
disabled when the DS is in the error mode!
Programmer's info:
The DS Manager verifies whether the DS is running in the error mode by sending
the Echo (X) command and analysing the status of the e flag in the reply.
Description
Message text:
Details
Firmware upgrades through the network are facilitated by a separate firmware
component called the NetLoader. When you click Upgrade button the DS Manager
instructs the application firmware of the DS to pass the control to the NetLoader.
Before doing this application firmware checks if the NetLoader is actually loaded.
This message is displayed when the NetLoader appears to be absent.
Software Manuals
237
Details
Network upgrade mode is a separate mode of operation facilitated by an
independent firmware component called the NetLoader. The NetLoader allows you
to upgrade the main application firmware of the DS over the network. Naturally,
when the NetLoader is running the DS is not executing the application firmware
and all functions related to the "normal" operation of the DS are not available. The
only available function in this mode is Upgrade.
Programmer's info:
--Description
Message text:
Details
This message means that the firmware on a particular DS you are accessing is
outdated (earlier than V3.xx). The function you have requested requires firmware
V3.xx or higher.
238
Details
Login password is the one you have set by clicking on the Password button in the
settings dialog. You cannot access the DS through the network without this
password.
If you have forgotten the password then you can either:
Access the DS in the COM access mode (this does not require password), or...
Quick-initialize the DS- this will erase the password (only supported by firmware
V3.xx or higher).
Programmer's info:
Login password is the one defined by the Password (PW) setting of the DS. Also
see authentication topic.
Description
Message text:
Details
This message appears when the DS initialization fails. Initialization restores all DS
settings to their default values and, therefore, "repairs" invalid settings that caused
the DS to enter the error mode. It is not normal that the DS is still in the error
mode after the initialization and may indicate DS hardware failure.
Programmer's info:
The DS Manager verifies whether the DS is running in the error mode by sending
the Echo (X) command and analysing the status of the e flag in the reply.
Software Manuals
239
Description
Message text:
Details
This message is only shown when inband (TCP) access method is selected for a
particular address book entry. Inband TCP access to the DS is only possible when
the Inband (IB) setting is 1 (enabled) and the Transport Protocol (TP)
setting is 1 (TCP). Default value of these settings is 0*. Therefore, initialization
would result in the inability to access this DS using inband communications!
To initialize this DS find some other way to communicate with it:
Temporarily connect the DS to the same network segment with your PC and
initialize the DS in the auto-discovery access mode (this mode always uses
out-of-band (UDP) access method).
Temporarily connect the serial port of the DS to the COM port of your PC and
initialize it in the COM access mode.
Programmer's info:
--* Unless another default value has been defined through a custom profile (the DS
Manager won't detect this and will still disallow the device to be initialized while
accessing using inband commands).
Description
Message text:
Details
Newly loaded firmware may have new or different settings that have never been
initialized on this particular device. After the DS has started running the newly
loaded application firmware it has detected that these settings contain invalid
values and entered the error mode. You are recommended to initialize the DS as
soon as possible.
Programmer's info:
The DS Manager verifies whether the DS is in the error mode by sending the Echo
(X) command and analysing the status of the e flag in the reply.
240
Details
Login password is the one you have set by clicking on the Password button in the
settings dialog. You cannot access the DS through the network without this
password.
If you have forgotten the password then you can either:
Access the DS in the COM access mode (this does not require password), or...
Quick-initialize the DS- this will erase the password (only supported by firmware
V3.xx or higher).
Programmer's info:
Login password is the one defined by the Password (PW) setting of the DS. Also
see authentication topic.
Description
Message text:
Details
This message means that either you tried to upload an invalid file or that there was
a communications error. Check the file you are trying to upload, your serial
connection (cable, baudrate, etc.) and try again.
The firmware file you are supposed to upload into the DS depends on the DS model
number and also on the way you are performing the upgrade- through the network
(auto-discovery and address book modes) or through the serial port (COM access
mode). Firmware download page at <%WEB%> provides complete info on what file
to choose. Be sure you understand this information and select a correct firmware
file.
Programmer's info:
--Description
Message text:
Software Manuals
241
Details
When the DS powers up its internal "operating system" verifies if the application
firmware is loaded and correct (this is done by verifying the checksum). If the
firmware is found to be corrupted the operating system checks if the NetLoader is
present. When this is so, control is passed to the NetLoader so you have a chance
to upload correct application firmware.
When this message is displayed this means that the firmware upload process has
completed successfully and the DS was rebooted with the intention to launch the
newly loaded application firmware but has emerged from reboot in the firmware
upgrade mode again.
If you are sure that the firmware upgrade has completed successfully then you
must have uploaded a wrong file. Firmware download page at <%WEB%> provides
complete info on what file to choose.
Programmer's info:
--Description
Message text:
Details
Certain IP-addresses are invalid in principle and should never be used. Many devices
and operating systems (including Windows) automatically discard network packets
that refer to such invalid IPs. Assigning an invalid IP to the DS can make it
inaccessible over the network.
Here is the list of IP-addresses that should not be used:
x.x.x.0 (i.e. 0 in the last number, as in 192.168.100.0).
x.x.x.255 (i.e. 255 in the last number, as in 192.168.100.255).
>223.x.x.x (i.e. a number that is more than 223 in the first number, as in
224.168.100.40).
Latest firmware versions of the DS prevent such invalid IPs from being used- the DS
will automatically assume a modified and correct IP-address if invalid one is set
(see IP-address (IP) setting for more information). Older firmware versions did
not have this protection so the DS Manager itself also prevents invalid IP-addresses
from being set.
Programmer's info:
IP-address is changed using the Assign IP-address (A) command.
Description
Message text:
242
Details
This message indicates that the DS manager has aborted the upload of a firmware
file. Typically, this happens when the DS has detected an error in the data being
uploaded. This means that you are trying to upload an incorrect firmware file.
The firmware file you are supposed to upload into the DS depends on the DS model
number and also on the way you are performing the upgrade- through the network
(auto-discovery and address book modes) or through the serial port (COM access
mode). Firmware download page at <%WEB%> provides complete info on what file
to choose. Be sure you understand this information and select a correct firmware
file.
Programmer's info:
--Description
Message text:
Details
When you attempt to set new login password the DS Manager asks you to input the
same password twice. This is to make sure that you know what password you have
entered. This message appears when the password you have entered the first time
does not match the password you have entered the second time.
Programmer's info:
Login password is the one defined by the Password (PW) setting of the DS. Also
see authentication topic.
Description
Message text:
Details
This message indicates that the DS Manager has attempted to access the DS
(using out-of-band (UDP) programming commands) but did not get any reply. The
reasons for this depend on the selected access mode: see troubleshooting
(auto-discovery mode) and troubleshooting (address book mode).
Programmer's info:
---
Software Manuals
243
Description
Message text:
Details
This message indicates that the DS Manager has attempted to access the DS
through the serial connection (serial port of the DS to the COM port of the PC) but
did not get any reply back. See troubleshooting (COM access mode) for the list of
hints on why this might happen.
Programmer's info:
---
Description
Message text:
Details
When you click Settings, Upgrade, Initialize, or Change IP button the DS Manager
needs to login before it can execute requested operation (see authentication).
Login is required even if the login password is not set and is only accepted if no
programming with the same priority level is already in progress.
Programmer's info:
Before executing any of the operations listed above the DS Manager attempts to
login using the Login (L) command. This message is displayed when the response
to this command is Rejected (R).
Description
Message text:
Details
This message means that the inband (TCP) access method is selected for this
244
Details
You have pressed OK without entering any password string. This means that no
password will be set and the password protection for this DS will be disabled.
Programmer's info:
Login password is the one defined by the Password (PW) setting of the DS. Also
see authentication topic.
Description
Message text:
Details
This message is shown when the Change IP function is used while the IP-address of
the DS appears to be configured through the DHCP (which means that DHCP (DH)
setting is 1 (enabled) and IP-address appears to have been successfully received
from the DHCP server i.e. the DS is not in the IP-address not obtained state)*.
Technically, the DS will work fine when you assign an IP-address manually (while
the network has the DHCP service) as long as you find an unused IP-address**.
The problem is that the DHCP server will not know that you have occupied this IP
and may assign it to some other device in the future***.
Finally, keep in mind that the IP-address you set manually may be changed next
time the DS reboots. This is because, when the DHCP (DH) setting is 1 (enabled),
the DS negotiates its IP-address with the DHCP server each time it powers up or
reboots and the DHCP server may assign a different IP-address at this time. This
new IP will be saved into the IP-address (IP) setting thus overwriting the value
you may have set.
Programmer's info:
The DS Manager verifies whether the IP-address of the DS is configured through
the DHCP by sending the Echo (X) command and analysing the status of the i
flag in the reply. If the flag is set to 'I' then this means that the DHCP is enabled
and the DHCP server is actually present on the network.
Software Manuals
245
* In other words, the DS Manager does not detect the presence of DHCP server
directly but instead relies on the "indirect evidence" from the DS. Unfortunately,
this means that the DS Manager won't be able to alert you when the DHCP server is
actually present but DHCP (DH) setting is 0 (disabled) on the DS.
** This can always be done by PINGing different IPs on the local subnet. No reply
means that the IP is probably unused.
*** Unless you have specifically banned the DHCP server from using this
IP-address (this can usually be done).
Description
Message text:
Details
Powering the DS up while keeping the setup button pressed puts the DS into the
serial upgrade mode.
Programmer's info:
--* On EM100, EM120, EM200, EM202, EM1000- pull the MD line LOW and power up
while holding this line LOW.
Description
Message text:
Details
The DS can be programmed through the serial port only when the latter is in the
serial programming mode. To switch the serial port into the serial programming
mode press the setup button*.
Programmer's info:
--* On EM100, EM120, EM200, EM202, EM1000- pull the MD line LOW for at least
100ms.
Description
Message text:
246
Details
After the serial upgrade the DS is not able to reboot by itself. You need to power it
off and back on again to test the newly uploaded firmware. Since the new firmware
can have new or different settings that were not present on a previous one the DS
may require initialization (watch out for the error mode after the DS reboots).
Programmer's info:
--Description
Message text:
Details
Setting description files (SDFs) contain the list of all settings found on a specific
firmware version of the DS. During the installation SDFs are copied into the /SDF
subfolder inside the target installation folder of the Device Server Toolkit (DST).
This message indicates that the SDF file required to correctly display the settings
dialog for a particular DS firmware appears to contain invalid information. This
problem can be corrected by reinstalling the software.
Programmer's info:
--Description
Message text:
Details
Setting description files (SDFs) contain the list of all settings found on a specific
Software Manuals
247
firmware version of the DS. During the installation SDFs are copied into the /SDF
folder inside the target installation folder of the Device Server Toolkit (DST). This
message indicates that the /SDF folder is empty. This problem can be corrected by
reinstalling the software.
Programmer's info:
--Description
Message text:
Details
The NetLoader is a separate firmware component that facilitates application
firmware upgrades through the network. This message indicates that the NetLoader
was entered but firmware upload could not be started because of an unexpected
reply from the DS.
This message should not appear under normal circumstances. Please, contact us if
the problem persists!
Programmer's info:
--Description
Message text:
Details
After assigning new IP-address the DS Manager performs an automatic refresh and
verifies that the DS is still online. This message appears when the DS is detected to
be online but the DS Manager is unable to communicate with this DS using a
"normal" IP addressing (see broadcast access for details).There are actually several
reasons why this may be so- see troubleshooting (auto-discovery mode).
Programmer's info:
--Description
Message text:
Details
248
The VSPD is a driver and is running in the very "guts" of the Windows OS. Its
presence is only manifested by the VSPs available to Windows applications.
The VSP Manager is an application that allows you to add, remove, and setup VSPs
. The VSPD and the VSP Manager are different entities (one is a driver, another
one- a setup utility). This Manual offers combined description of the two and all
VSPD features are explained "through" the VSP Manager.
Closely related to the work of the VSPD is the Port Monitor, another member of
the DST, that is used to log the activity of the VSPs.
Software Manuals
249
How VSP
Works
4.1.2.1
When designing the VSPD we have attempted to emulate the work of a standard
serial port driver as closely as possible. All system calls supported by the COM
driver were carefully ported into the VSPD and the behavior of the VSPs closely
mimics that of COMs.
250
VSP Manager
4.1.2.2
VSP Manager is used to add, remove, and setup VSPs. It looks like this:
Software Manuals
251
VSP Properties
The VSP Properties window contains the following tabs:
252
The VSP name drop-down box shows the list of available port names. On the
screenshot above COM3 is not listed- this happens when the VSP with this name
already exists. Notice, however, that ports COM1 and COM2 are not excluded from
the list and are marked with icons identifying them as "real" COMs**. Even though
these port names are "occupied" the VSP Manager can still "grab" them. For
example, if you select COM1 the VSP Manager will automatically substitute a
standard COM port driver with the VSPD and assign the name "COM1" to this VSP.
From this moment on the COM1 will cease working as a regular COM and will start
working as a VSP. Substitution may be necessary when you are dealing with an old
application software that only provides a choice of COM1 and COM2 which are
usually occupied by real COMs.
When you delete the VSP that substituted a standard COM port the VSP Manager
Software Manuals
253
will attempt to restore the original driver. This mostly works but on some systems
you may encounter problems (especially under Windows ME). We have conducted
an extensive "research" into the port substitution, only to conclude that it just
doesn't work reliably on all systems!
We recommend that you do not use port substitution unless absolutely
necessary!
All VSPs appear under the Ports section of the device manager's device list (Control
Panel--> System Properties--> Device Manager)***:
* We could extend the number even further but feel that the current range is
sufficient for all practical purposes.
** This is system-dependent. Some modern PCs don't have any real COMs.
*** VSP properties cannot be edited from within the device manager
Transport Protocol
Transport protocol drop-down box selects which communications protocolTCP/IP or UDP/IP will be used by the VSP for data communications with the DS.
For the data connection with the DS to work the same transport protocol must be
selected on the DS side- see the Transport Protocol (TP) setting.
Unless you have a specific reason why the UDP should be used (very rare!) we
recommend you to stick to the TCP/IP. The TCP/IP is a "reliable delivery" protocol
that makes sure that no data is lost "in transit" between the VSP and the DS. The
UDP, on the contrary, does not guarantee data delivery.
Some considerations and additional info on the TCP and UDP implementation in
the VSP can be found in the next topic.
254
Software Manuals
255
On-the-fly Commands
On-the-fly commands are used to change the serial port configuration of the DS as
needed (i.e. "on the fly"). Serial port configuration made through the on-the-fly
commands overrides the permanent one, defined by the serial port settings of the
DS. The difference between the changes made using on-the-fly commands and
changes made through altering DS settings is that, unlike serial settings, on-the-fly
commands have immediate effect and do not require the DS to be rebooted in
order for the new values to be recognized.
With on-the-fly commands enabled, the serial port of the DS is always setup as
required by the PC application that communicates with this DS through the VSP.
When the PC application opens the VSP (or some communications parameters are
changed) the application informs the VSP about required changes* and the VSP
relates this information to the DS by sending on-the-fly commands.
Additionally, on-the-fly commands are used by the VSP to control the RTS and DTR
outputs of the DS serial port. The status of the CTS and DSR input of the DS serial
port can be passed to the VSP too- this is done using so-called "notification
messages". For more information see handling of RTS, CTS, DTR, and DSR signals.
On-the-fly commands drop-down box provides four choices:
Disabled
Out-of-band
Inband
256
On-the-fly commands are not sent, but the VSP treats all
incoming and outgoing data as if inband mode was used
(i.e. it doubles all "escape" characters (ASCII code 255)
in the data sent by the application and expects all escape
characters to be doubled in the data stream sent by the
DS). See disabled (with FF escape) mode of the VSP for
details.
Software Manuals
257
mode is "server".
Additionally, parameter block is sent each time the data connection is
established (no matter whether this was an incoming or outgoing connection).
Parameter block includes all communications parameters needed by the serial port,
such as the baudrate, parity, etc.
In addition to sending parameter blocks the VSP also sends individual commands
whenever some parameter is changed within the application. For example, if the
User chooses a different baudrate (while the application is already running and the
VSP is opened) the VSP won't send out entire parameter block again but will
instead send just the on-the-fly command to change the baudrate of the DS.
Such individual on-the-fly commands are sent immediately after the serial
communications parameters are changed in the software application, except for the
case when the routing mode is "server" and no data connection is established at
the moment. In this case the VSP will have to wait until it receives an incoming
connection, and this will trigger an entire parameter block to be sent, as described
above.
Here is an example log from the Port Monitor detailing one "cycle" of the VSP
operation (out-of-band on-the-fly commands are enabled, routing mode is not
"server"):
--- application is started --12/15/03 14:22:47 - COM3 (INFO): Port opened
--- beginning of parameter block (this block is sent because the VSP has been opened) --12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: get DSR pin status...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: get CTS pin status...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set DTR to high...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set RTS to high...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set baud rate to 38400 bps...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set parity to none...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set data bits to 8 bits...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set flowcontrol to RTS/CTS...success
12/15/03 14:22:47 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: enabling line change notification for
DSR...success
--- end of parameter block ------- connection is established (i.e. because the application sends data) --12/15/03 14:22:54 - COM3 (INFO): Established TCP connection with node 192.168.100.92:1001
--- beginning of parameter block (this block is sent because the connection has been established) --12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: get DSR pin status...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: get CTS pin status...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set DTR to high...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set RTS to high...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set baud rate to 38400 bps...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set parity to none...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set data bits to 8 bits...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set flow control to
RTS/CTS...success
12/15/03 14:22:54 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: enabling line change notification for
DSR...success
--- end of parameter block ------- the following commands are sent in response to the User changing the baudrate within the application --12/15/03 14:22:56 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set baud rate to 19200 bps...success
12/15/03 14:22:58 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set baud rate to 9600 bps...success
12/15/03 14:22:59 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set baud rate to 19200 bps...success
12/15/03 14:23:00 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set baud rate to 9600 bps...success
--- application is closed --12/15/03 14:23:02 - COM3 (INFO): TCP connection closed
12/15/03 14:23:02 - COM3 (INFO): Port closed
A slightly different behavior is observed when the inband mode is selected for
on-the-fly commands. Since inband commands are passed within the TCP data
connection, the VSP establishes such a connection in case it needs to send
on-the-fly command(s) and no connection is established at the moment. Again,
258
Software Manuals
259
12/16/03 10:05:06 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set DTR to low...success
12/16/03 10:05:06 - 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 10:10:18 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set flowcontrol to none...success
12/16/03 10:10:18 - 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 10:10:20 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: set flowcontrol to RTS/CTS...success
12/16/03 10:10:20 - COM3 (INFO): "On-the-Fly" command for 192.168.100.92: enabling line change notification for
DSR...success
260
Example 2: mark and space parity bits are used by the serial device to distinguish
between the address and data bytes transmitted by the PC.
In most RS485 systems (where there are multiple serial devices attached to the
serial bus) the PC needs to select a particular "node" it wants to communicate with
by transmitting the address of this node. Such systems often use the parity bit to
Software Manuals
261
distinguish between the node address and the actual data, i.e. (parity= mark
means an address byte, parity= space means a is data byte, or vise versa).
Since a standard COM driver does not allow the application software to control the
parity bit directly, such software uses the following algorithm to transmit the node
address followed by the data:
Change the parity to mark.
Send the node address.
Change the parity to space.
Send the data for this node.
The point here is that changes in the parity mode must be synchronized with the
data being sent out.
How the use of VSP affects synchronization
The operation of the VSP is more asynchronous than that of a standard serial port.
When the application sends out the data the VSP just puts this data into the Tx
buffer and returns control back to the application. To the application this means
that the data has been sent out. Obviously, this is not so and there will be a
certain delay before this serial data actually comes out of the serial port on the DS
side.
Out-of-band commands (such as the command that tells the DS to change the
state of the RTS line) are sent separately from the data. For example, when the
application tells the VSP to change the state of the RTS line the VSP sends a
required out-of-band command immediately.
For the example 1 the above means that the pulse on the RTS line will be
completely out of sync with the serial data itself (the diagram below illustrates
this). For the example 2 this means that the switching of the parity mode will occur
at wrong (and unpredictable) times and, therefore, there is no guarantee that the
address byte will be output with mark parity bit and the data byte will be output
with space parity bit!
262
The solution
Fortunately, there is a solution to this problem- use inband mode when trying to
achieve full synchronization between the Tx data and on-the-fly commands!
Because inband on-the-fly commands are mixed into the data stream itself there is
no chance that these commands will somehow "pass over" the data. The DS will
receive the data and corresponding on-the-fly commands in exactly the same order
as generated by the application.
Software Manuals
263
Connection Timeout
Connection timeout parameter sets the timeout (in minutes) for the data
connections between the VSP and the DS. If no data is transmitted across the data
connection (TCP or UDP) for a specified number of minutes the VSP aborts the
connection.
Setting connection timeout parameter to 0 disables the feature and the connection
is never closed on timeout.
Notice, that this feature will work even when the connection mode is set to
"immediately". When the timeout comes the VSP closes the connection first and
immediately reopens it (timeout counter is reloaded). This provides additional
reliability since hanged connections are automatically "repaired".
Connection timeout parameter works like the Connection Timeout (CT) setting
of the DS.
Routing Mode
Routing mode defines whether the VSP will accept incoming connections (passive
opens) and/or establish outgoing connections (perform active opens).
Routing Mode drop-down box provides three choices:
Server
Server/client
Client
Routing mode option works like the Routing Mode (RM) setting on the DS.
Connection Mode
Connection mode defines when the VSP attempts to establish an outgoing
connection to the destination, specified in the destination section of the dialog.
Connection mode drop-down box provides two choices:
Immediately
264
Connection mode option is irrelevant when the routing mode is "server", since in
this mode outgoing connections are not allowed in principle.
Connection mode option works like the Connection Mode (CM) setting of the DS
(modes 0 and 1 only).
Listening Port
Listening port parameter defines the listening port number that will be associated
with this VSP.
Listening port usage is slightly different for TCP/IP and UDP/IP transport protocols:
For TCP/IP transport protocol this parameter defines a listening port on
which incoming connections are to be accepted. Listening port is closed and
irrelevant when the routing mode is "client", since in this mode incoming
connections are not allowed in principle. Outgoing connections, when allowed
(i.e. in the "client" and "server/client" routing modes), are established from an
"automatic" port, so the listening port number has nothing to do with this.
For UDP/IP transport protocol the situation is as follows:
When the routing mode is "client" (incoming "connections" are not allowed) the
listening port parameter is irrelevant and the VSP sends it own UDP datagrams
from an "automatic" port.
When the routing mode is "server" or "client/server" the listening port
parameter defines the listening port on which incoming UDP datagrams are
accepted and is also used as the port from which outgoing UDP datagrams are
sent.
Listening port parameter is similar to the Port Number (PN) setting of the DS.
Destination Modes
The VSP has two "destination" modes that define which destination the VSP will
attempt to connect to*:
In the single-destination mode there is only one destination specified either
by its IP-address or MAC-address.
In the multi-destination mode the VSP maintains a table of destinations. The
VSP switches between these destinations basing on the data sent by the
application. Multi-destination mode is a "logical" equivalent of a "multi-node"
RS485 network.
* When outgoing connections are allowed in principle, i.e. in the client or
client/server routing mode.
Software Manuals
265
Single-destination Mode
Single-destination mode is selected by choosing "single destination" from the
destination mode drop-down box (see the screenshot below). Single destination
mode allows you to specify one particular DS to which the VSP will be establishing
its outgoing connections (when allowed by the routing mode and according to the
connection mode option).
In the above example the IP-address of the DS has changed between the
"communications sessions" but the VSP was able to connect to the same DS by
using the MAC-->IP mapping.
Because the VSP is using broadcast UDP communications to "find" the DS with
matching MAC-address, the MAC-->IP mapping feature only works for local Device
Servers, i.e. devices located on the same network segment* with the PC (running
VSP).
Also specified in the destination section of the VSP properties dialog is the port
number on the DS. This must be the same number as the one specified in the Port
Number (DP) setting of the destination DS.
Instead of entering the destination data manually, you can press the Select Device
Server from the list... button and choose the DS from the list. The button brings up
the dialog, similar to the main window of the DS Manager. In fact, it is the DS
Manager, with the following two differences:
266
Multi-destination Mode
Multi-destination mode allows you to communicate with several Device Servers
(and the serial devices behind them) through a single VSP. To understand the
usefulness of this feature consider the following example:
Example
Let's assume there is a multi-drop (RS485) network with several serial data
terminals connected to it (see diagram below). The RS485 "bus" is attached to the
PC's COM port via a 485-to-232 converter. An application software on the PC
(App.) can address each terminal individually by sending a formatted command
that contains a "node address" of the terminal. All terminals on the RS485 bus
receive the command but only the one with a matching node address will respond
to the command. This is a very common way of multi-drop communications. The
PC acts as a "master" and the terminals act as "slaves".
Software Manuals
267
The formatted command typically has a start character (STX, ASCII code 2 in this
example), followed by the node address (transmitted, for example, as two ASCII
characters representing the number, i.e. "01", "02", etc.). The address characters
are followed by the command contents and some sort of end character (for
example, CR, ASCII code 13):
STX
Addr1 Addr2
Command contents
CR
Now let's suppose that you need to network-enable this system. The simplest way
to do so would be to connect the RS485 bus to the DS, create a VSP on the PC and
let the application software access the terminals through the VSP and the DS.
This will work, but only if the distance between the terminals is small. If the
terminals are to be located far away from each other the RS485 network
connecting them would have become very long thus defying the purpose of
network-enabling this system! Much better solution would be to connect each
terminal individually to its own DS (see figure below). This way there would be no
RS485 network whatsoever.
The problem here is that each DS (and hence, each terminal) will now have its own
IP-address and this means that a single VSP will have to switch between these IPs
as needed (remember that on the original RS485 system the application software
communicated with all terminals on the RS485 bus through a single COM port!).
The solution
The multi-destination mode of the VSP allows you to define several destination
Device Servers and switch between these destinations basing on the outgoing data
stream sent by the PC application. As explained above, the multi-drop RS485
system (almost) always has some form of node addressing and the VSP can be
programmed to filter out this addressing information and automatically switch
between the destinations.
The data in the outgoing data stream the VSP reacts to is divided into two
portions:
268
Destination IP-address
192.168.100.40
192.168.100.41
192.190.0.15
Once the VSP detects the prefix string in the data stream sent by the application
software it starts checking if the subsequent data will match one of the defined
switch strings. When the match is detected the VSP closes current data connection
(if any) and switches to the new destination, corresponding to the detected switch
string.
Here is how this is reflected in the log of the Port Monitor:
12/18/03 10:39:49 - COM3 (INFO): Port opened
12/18/03 10:40:04 - COM3 (INFO): Switching to 192.168.100.40:1001 ("01")...
12/18/03 10:40:04 - COM3 (INFO): Established TCP connection with node 192.168.100.40:1001
12/18/03 10:40:15 - COM3 (INFO): TCP connection closed
12/18/03 10:40:15 - COM3 (INFO): Switching to 192.168.100.41:1001 ("02")...
12/18/03 10:40:15 - COM3 (INFO): Established TCP connection with node 192.168.100.41:1001
Software Manuals
269
The prefix string is entered into the Prefix (ASCII) or Prefix (Hex) textboxes. These
textboxes are synchronized with each other. Prefix (ASCII) texbox records the
characters as you type them. For example, if you press <A> key this will be
interpreted as ASCII character 'A'. The Prefix (Hex) texbox will reflect the ASCII
HEX code of this character- 41. Typing "02" (ASCII code of the STX character) into
the Prefix (Hex) textbox will cause the image of this character (smiley face) to
appear in the Prefix (ASCII) textbox. Special characters, such as STX, can also be
entered in the Prefix (ASCII) textbox using the <CTRL> key (<CTRL>+<B> for
STX).
Available destinations are entered into the destination table- there are Add, Edit,
and Delete buttons. Pressing Add or Edit button opens the Edit destination entry
dialog (see the screenshot below).
Switch (ASCII) and Switch (Hex) textboxes are used to enter the switch string for a
particular destination.
Substs (ASCII) and Subst (Hex) textboxes provide additional functionality that
haven't been mentioned yet. If the data is entered into those fields then the VSP
270
J01ABC
J00ABC
The destination portion of the Edit destination entry dialog is similar to that
displayed in the VSP properties dialog in the single-destination mode. The
destination DS can be defined by its IP-address or by its MAC-address, depending
on whether the MAC-->IP mapping option is enabled or not. Destination port must
match the one specified by the Port Number (DP) setting of the destination DS.
Instead of typing in the data manually, you can press the Select Device Server
from the list... button and choose the DS from the list.
How multi-destination errors are handled
If, after the VSP is opened, the application starts sending "random" data without
sending a prefix and a switch string first, or if the data after the prefix does not
match any switch string, the VSP will be discarding this data until a valid prefix
and switch are detected.
If, after a valid prefix and switch have already been detected and the VSP has
established a connection with a certain destination DS, the VSP receives the
prefix string that is not followed by any valid switch string, then the VSP will
keep sending the data across the existing data connection.
Specify Destination By
The Specify by drop-dox box allows you to select one of three methods to specify
the VSP's destination:
IP-address: Select the destination of the VSP by specifying its IP address. When
using this option, the IP address should be static and not be dynamically
assigned by DHCP.
Host name: Specify the destination by DNS host name. The destination should
be registered in DNS for this to work. Registration in DNS can be performed
manually (using your DNS server administration interface) or using an interface
between DHCP and DNS.
MAC-address: Select the destination by specifying its MAC address. This is
useful for destinations which are located in the current (local) network segment,
whose IP address may change (i.e, when the IP address is dynamically assigned
by DHCP).
Software Manuals
271
272
Use WinSock
4.1.2.3for transport
Use WinSock for transport checkbox enables or disables working via WinSock.
On some PCs, a program called WinSock Proxy (WSP) Client is installed. This client
modifies the way Windows handles IP routing.
When working with such a PC with the VSP in default mode (with the Use
WinSock for transport checkbox unchecked), the VSPD will not be able to
connect to remote IP addresses (addresses beyond the scope of the current
subnet), but will be able to connect to local addresses.
When something like this happens, you should mark this checkbox and thus
instruct the VSPD to use WinSock for transport, rather than the default mechanism
(called TDI, Transport Device Interface).
Unsupported
4.1.2.4Features and Limitations
This topic describes existing limitations of the VSP.
Password protection for on-the-fly commands. On the DS side this feature
is enabled through the On-the-fly Password (OP) setting. The VSP does not
support this yet so the password protection for on-the-fly commands must be
disabled on the DS.
Password protection for data connections. On the DS side this feature is
enabled through the Data Login (DL) setting. The VSP doesn't support data
logins yet and so the password protection for data connections must be disabled
on the DS.
Software Manuals
273
Warnings
and Messages
4.1.2.5
This reference section contains additional information on the warning and error
messages displayed by the VSP Manager.
Details
Listening port is the port number the VSP is accepting incoming connections on*.
This message appears when the VSP attempts to open this port (which usually
happens when the VSP is opened) and the port is already in use by another
application (possibly, another VSP).
To solve this problem select another number for the listening port and try again.
* When incoming connections are allowed by the routing mode.
Details
This message appears when you are closing the start/stop characters dialog and
you haven't defined any start characters while the start on any character option is
disabled. This means that there are no conditions whatsoever that will open the
data block and no data will ever be accepted from the application.
Details
This message appears when you select the port name for the VSP that is currently
in use by the real COM port. Typically, these are "COM1" and "COM2" port names.
For more information on the subject see VSP name selection.
274
VSP Is in Use
Description
Message text:
Details
You can only edit VSP properties or delete a VSP when it is not currently opened
(i.e. not in use by another application).
Port Monitor
Port Monitor is a parts of the Device Server Toolkit.
The Port Monitor is used to log the activity of Virtual Serial Ports
(VSPs) installed on your Windows system.
When the Port Monitor is running its icon appears in the system tray, as shown on
the screenshot below.
Double-clicking on the Port Monitor's icon in the system tray brings up the main
window:
The main window displays the log of registered events. The simplest way to
observe the work of the Port Monitor is to open the VSP from some application
program and check what kind of data appears in the Monitor (sample output is
shown on the screenshot above).
You can erase all data in the Port Monitor's window by choosing File--> Clear log
from the main menu or clicking clear monitor log button (shown below).
You can also copy the log data into the clipboard by first selecting the desired part
of the data in the Port Monitor's window and then choosing File--> Copy from the
main menu or clicking copy button (shown below).
Software Manuals
275
All events logged by the Monitor can be divided into informational, warning, and
error events. Preferences dialog (general and event tabs) defines which events are
logged, what format is used to displays those events, and what action the Monitor
will take when an error event is encountered.
The Monitor also features a dump function which can be used to track the data
passing through a particular VSP.
Preferences
Dialog (General Tab)
4.1.3.1
General tab of the preferences dialog (shown on the screenshot below) offers a
number of options that define how the Port Monitor logs events. To display the tab
choose File-->Preferences from the main menu of the Port Monitor or click
Preferences button (shown below).
Preferences button
Event prefix format defines how each event in the log will look like. There are
three fields that can be added to each event line:
Port name placeholder (%p). Adding %p to the format string will make
the Monitor print the VSP name (i.e. "COM3", "COM4") for which the event was
generated.
Timestamp placeholder (%t). Adding %t to the format string will make the
Monitor print current date and time stamp for each event line (i.e. "12/30/03
14:57:13").
Message type placeholder (%m). Adding %m to the format string will
make the Monitor print the type of event (i.e. "INFO", "WARNING", "ERROR")
for each event line.
You can combine the placeholders, for example: "%t- %p (%m):". This will
make the Wizard print all events like this:
276
Preferences
Dialog (Event Tab)
4.1.3.2
Events tab of the preferences dialog (shown on the screenshot below) allows you to
enable/disable logging of and set the font for individual events and event groups.
To display the tab choose File-->Preferences from the main menu of the Port
Monitor (or click Preferences button), then click events tab.
Preferences button
When the Monitor is installed all events are enabled and three different font types
are selected for the informational, warning, and error events:
12/30/03 15:44:45 - COM3 (INFO): Port opened <---- info event
12/30/03 15:44:48 - COM3 (WARNING): "On-the-Fly" command for 192.168.100.95: get DSR pin status...timed out,
still trying... <---- warning event
Software Manuals
277
12/30/03 15:44:54 - COM3 (ERROR): "On-the-Fly" command for 192.168.100.95: get DSR pin status...timed out
<---- error event
To enable/disable entire event group click on the option box next to the group
name. To change the font for the entire group select the group name in the list and
press Change font button.
To enable/disable individual event "expand" the event group (by clicking on the
"+" sign or double-clicking on the group name), then click on the option box next
to the event name. To change the font for an individual event select this event in
the list, deselect the inherit font option, then press Change font button.
Data Dump
Feature
4.1.3.3
The Port Monitor can be used to capture the "serial data" passing through the VSP.
The data is displayed in the Hex dump window, both in the HEX and ASCII format,
as shown on the screenshot below:
To see the hex dump, click View--> RX/TX Data from the main menu of the Port
Monitor- the choose VSP to monitor dialog will open. Select desired VSP and click
OK.
The only two functions available in the Hex dump window are save (to save all
captured data into a data file) and clear (to erase all data).
The Data Dump feature works using the Tibbo Service, which is an
auxiliary service providing several functions for the VSP and VSP
Monitor. If this service isn't running, the Data Dump feature will not
work.
278
Connection Wizard
Connection Wizard is a part of the Device Server Toolkit.
Connection Wizard assists you in setting up typical data links
involving Tibbo Device Servers and Virtual Serial Ports (VSPs).
Shown below is the welcome screen of the Connection Wizard.
Connection Wizard offers a selection of jobs that help you setup several kinds of
typical data links involving Tibbo Device Servers and Virtual Serial Ports (VSPs).
For example, a VSP-to-DS job helps you create a VSP on the PC, and then
configure this VSP and the Device Server (DS) of your choice to work with each
other.
Creating a VSP-to-DS link through the Wizard produces the same effect as when
you manually set up the VSP using the VSP Manager and then configure the DS
with the DS Manager. The difference is that after you have answered several
simple questions the Wizard does all necessary adjustments automatically. As a
result you save tremendously in terms of time and debugging effort spent on
setting up this data link. After you have familiarized yourself with the Wizard you
can expect to complete typical data links in under 1 minute! Even when the link
you need to create is not exactly the one this Wizard can help you with, you still
can run the closest Wizard job, then make remaining setup changes manually.
This Manual follows the actual "flow" of Wizard steps. Pressing Next in the welcome
screen of the Wizard moves you to the next step, on which you choose the kind of
data link you want to create. Likewise, the next topic of this Manual (choosing the
Wizard job) details this next step.
Choosing
the Wizard Job
4.1.4.1
On this step you choose the kind of job you want the Connection Wizard to
perform.
Software Manuals
279
VSP-to-DS
Link
4.1.4.2
This job is selected by choosing create a link between a Virtual Serial Port and a
Device Server from the list of available jobs.
When performing this job the Connection Wizard creates a VSP (on the PC the
Wizard is running on) and then configures this VSP and the DS of your choice to
work with each other. Use this job if you want to make your "serial" PC software*
communicate with the serial device through the VSP and the DS. This way your PC
software and the serial device can communicate with each other as if they were
still interconnected by a normal serial cable. This is a fast and economical way of
network-enabling a legacy serial system that you are unwilling or not able to
modify- both the PC software and the serial device will require no modification
whatsoever to work through the network.
* I.e. the software that can only communicate through COM ports. If your software
supports communications through TCP/IP networks use direct-to-DS connection.
280
Choosing select existing VSP option displays the list of VSPs that are already
found on your system (i.e. the ones that have been created before).
Choosing create new VSP option displays the list of unused VSP names (shown
above). The number of ports you can have in Windows is virtually unlimited- the
Connection Wizard lets you create any port in the range between COM1 and
COM255*.
There are no rules on what VSP name to choose but some considerations are
provided here.
* We could extend the number even further but feel that the current range is
sufficient for all practical purposes.
On the screenshot above COM3 is not listed- this is because the VSP with this
Software Manuals
281
name already exists. Notice, however, that ports COM1 and COM2 are not excluded
from the list and are marked with icons identifying them as "real" COMs*. This is
because even though these port numbers are "occupied" the Connection Wizard
can still "grab" them. For example, if you select COM1 the Wizard will
automatically reassign COM1 to be a VSP (from this moment on COM1 will seize
working as a normal COM port and will start working as a VSP). Substitution may
be necessary when you are dealing with an old application software that only
provides a choice of COM1 and COM2 which are usually occupied by real COMs.
When you delete the VSP (this can be done through the VSP Manager) that
substituted a standard COM port the VSP Manager will attempt to restore the
original driver (make this port become a normal COM again). This mostly works
but on some systems you may encounter problems (especially under Windows ME).
We have conducted an extensive "research" into the port substitution, only to
conclude that it just won't work reliably on all systems!
We recommend that you do not use port substitution unless absolutely
necessary!
* This is system-dependent. Some modern PCs don't have any real COMs.
Target DS
On this step you select the DS that the VSP (selected on the previous step) will be
communicating with.
282
Software Manuals
283
284
Notice, that asking "who will be the first to send the data?" is not the same as
asking "which side will be establishing the data connection to the other side?"*
When making your choice imagine that there is no network at all and the serial
device is attached to the COM port of the PC directly. Now, which side sends the
data first?
There are three choices:
Virtual Serial Port. Select this option if it is the application software that will be
sending the first data. This is typical for the kind of serial devices that we, at
Tibbo, came to call "slave terminals". Such terminals communicate with the PC
software using some sort of command-reply communication protocol and it is the
PC software that usually plays the role of a "master": the terminal won't send
any data unless the PC sends a command first (and this is the "first data"!).
Device Server. Select this option if it is the serial device that will be sending the
first data. This is typical for the kind of serial devices that we call "scanners"
(readers)**. This class of serial devices differs from "slave terminals" in that
they send out the data spontaneously, without any prior prompt from the PC
software.
Any side. In some systems the data may first come from any side. For example,
there are some "active terminals" out there that can send out the data
spontaneously and at the same time respond to the commands from PC. Also
choose this option if you are not sure which side of your system sends the data
first.
* Although these two questions are connected- see how the Wizard decides which
side open the connection.
** Meaning barcode scanners or magnetic card readers.
Software Manuals
285
The gateway and netmask need only be set when two conditions are
observed:
The DS may need to (or must) establish data connections to the PC (this is
determined by the Wizard).
The DS and the PC are located on different network segments (there is at least
one router between the PC and the DS).
Setting gateway and netmask information for the DS that only accepts incoming
connections is not necessary*. If the DS is local there are no routers between this
DS and the PC, so the gateway and netmask are not necessary even if the DS has
to connect to the PC.
How to set the gateway and netmask
There is no straight way of finding out what data to enter. You need to obtain this
information from somebody with a knowledge of your network's topology. Here is
one hint, though.
If the IP-address of the target DS is configured through DHCP (DHCP (DH)
setting is 1 (enabled)), then the DHCP server might have configured this Device
Server's gateway and netmask as well. When you reach this step of the Wizard the
Gateway IP-address and the Netmask fields are filled with the data from the
Gateway IP-address (GI) and Netmask (NM)settings of the target DS**. This
data may already be correct!
What if the PC is not visible from the DS
When the PC and the DS are located on different network segments it may well be
that the PC is not "visible" from this DS. This is normal as many networks are not
symmetrical. For example, if the DS has a public (real) IP-address and the PC is
286
Software Manuals
287
Which
side
sends the
first data
Routing
Mode on
the VSP
Connect
ion
Mode on
the VSP
Routing
Mode on
the DS
Application
Client
On data
Server
Serial
device
Server
---
Any side
Server/clie
nt
Application
Client
On data
Server
On
dat
a
On
dat
a
---
Serial
device
Client
Immediate
ly
Server
---
Any side
Client
Server
---
Application
Server
Immediate
ly
---
Client
Serial
device
Server
---
Client
Any side
Server
---
Client
Im
me
diat
ely
On
dat
a
Im
me
diat
ely
1
2
Client
(server/clien
t)
On data Server/clien
t
Co
nn
ec
tio
n
M
od
e
on
th
e
D
S
---
The situation becomes more complicated when only one side of the connection can
"see" the other side. Consider the case in line 5 of the table. The serial device has
to send the data first, but it cannot "see" the VSP. Therefore, even when the DS
receives the first data into its serial port it will be unable to establish a connection
to the VSP and send this data!
The way out is to have the VSP connect to the DS as soon as the VSP is opened
(so, connection mode for the VSP is set to "immediately"). This way, by the time
the DS needs to send the first data to the VSP the connection is already
established. This kind of connections are called "reverse".
A special comment should be made on line 2 of the table, where the Routing Mode
on the DS is designated to be either "client" or "server/client". The Wizard chooses
"client" if DS programming is effected using out-of-band access method (you have
selected this on the target DS step of the Wizard). If inband access method was
selected the Wizard will set the mode to "server/client". This is because choosing
288
In general, we recommend you to stick to the TCP/IP, unless you have a good
reason (which is very rare!) to use UDP/IP protocol.
There is one case when the UDP/IP selection is not available and the TCP protocol
is pre-selected for you- this is when you have specified an inband access method
on the target DS step of the Wizard. Since inband access requires a TCP/IP data
connection with the DS you must use TCP/IP transport protocol!
Under What Circumstances Transport Protocol & Port Selection Is Disabled
As noted above, when you use Inband access mode for the wizard, you must use
TCP/IP as the transport protocol. Also, port selection will be disabled in this case.
At this stage of the Connection Wizard you are already in communication with a
DS. The communication is done via the data transport channel of the DS (as
opposed to a separate command channel, like in Telnet or out-of-band mode).
Software Manuals
289
The DS is usually far away (somewhere on a WAN), otherwise you would not use
inband access to reach it. Thus, there are all sorts of firewalls and gateways
between yourself and the DS. Firewalls only allow traffic on certain ports to go
through, and UDP packets are often dropped on WANs.
If you change the protocol to UDP now, or change the listening port on the DS, you
may render it completely inaccessible. The change will occur, because the Wizard is
in communication with the DS (on the proper port which you configured in the
beginning). But at the end of the Wizard run, you'll have an unpleasant surprise the DS may suddenly disappear.
Thus, when selecting Inband Access mode in the beginning of the Wizard, you
cannot later change the Transport Protocol or Listening Port.
Listening ports
This screen also provides an option of entering the port number on the listening
side(s) of the VSP-to-DS link. By now the Wizard has already decided which side
opens the connections. Connecting side needs to know the number of the listening
port on the other side. For example, if it is the VSP that will always be connecting
to the DS, then you only have to specify the listening port on the DS side.
Consequently, the listening port on the DS textbox will be enabled, and the
listening port on the PC textbox will be disabled. If both sides will need to establish
the connection, then you have to specify the listening ports on both sides too, and
both textboxes will be active.
There is one case when the listening port on the DS side is fixed and pre-selected
for you- this is when you have specified an inband access method for this DS. In
this case you have already specified the listening port (as the access port) on the
target DS stepof the Wizard (listening port and the access port are the same for
inband mode).
Once the listening port on one side is known, the Wizard sets the destination port
on the other side accordingly. If the VSP will need to connect to the DS the
destination port on the VSP will be the same, as the value of the Port Number
(PN) setting on the DS side. Likewise, if the DS will have to connect to the VSP
the Destination Port (DP) setting on the DS will be the same as the local port
number on the VSP.
How the listening port numbers are chosen
In most cases the choice of listening ports is automatic so when you get to this
step suggested port numbers are already entered by the Wizard.
On the VSP side the number is calculated as 998+ the number of COM. For
example, if you are dealing with COM3 then the Wizard will suggest the number of
998+3=1001*. Tying the listening port number to the VSP name provides a simple
and effective way of making sure that all VSPs on your system use a different
listening port (listening port cannot be shared between the VSPs).
On the DS side you can choose any port of your liking, except the 65535 (65535 is
a special command port). What the Wizard is showing you by default is the default
value of the Port Number (PN) setting of the DS (1001).
The only reason to change suggested port numbers is if your network's firewall
bans most of the traffic so only specific ports are opened for communications. In
this case you may need to adjust the port numbers to the requirements of your
network.
290
On-the-fly Commands
On this step you decide whether the PC application will be controlling the setup of
the serial port of the DS.
The VSP-to-DS connection can be arranged in such a way that the serial port of the
DS is always setup as required by the "serial" application. For example, if the
application that opens the VSP selects the baudrate of 9600 bps, then the baudrate
of the DS serial port is immediately set to this baudrate as well.
This functionality is delivered through the so-called on-the-fly commands (or, more
officially, network-side parameters). Just like programming commands, on-the-fly
commands can be sent using out-of-band or inband access method, so you have a
total of three choices:
No, disable on-the-fly commands. On-the-fly commands are not sent at all,
the DS is not aware of the serial port settings required by the application and is
running with "permanent" serial parameters defined through the serial settings.
For example, even if the application requires 9600 bps, but the Baudrate (BR)
setting of the DS is programmed to 5 (38400 bps), the serial port of the DS will
be running at 38400.
Yes, enable on-the-fly commands, use out-of-band access method.
On-the-fly commands will be sent as UDP datagrams to the command port
65535 of the DS. This access method is suitable for all local Device Servers. It
will also work with remote Device Servers unless the UDP traffic is banned by the
network routers (firewalls, etc). We suggest that you select this option whenever
possible.
Yes, enable inband on-the-fly commands, use inband access method.
On-the-fly commands will be sent through the TCP connection established to the
data port of the DS (this is the port number defined by the Data Port Number
(PN) setting). This method can be used in situations when out-of-band
on-the-fly commands cannot get through.
Software Manuals
291
292
Values entered on this screen are saved into the serial settings of the DS. Once
set, they remain unchanged even after the DS is switched off. The serial port of the
DS will always use these values unless temporary overriding parameters are
received from the VSP (in the form of the on-the-fly commands- if you have
enabled them on the previous step).
The screen with permanent serial port values is shown in two cases:
You have disabled on-the-fly commands on the previous step of the Wizard. This
means that the DS won't be aware of the serial parameters required by the
application and will use the permanent values you are to set now.
You have enabled on-the-fly commands, but the Wizard has decided earlier that
the Routing Mode (RM) setting of the DS is to be either 2 (client) or 1
(server/client). This deserves an explanation- see below for details.
The empty screen is shown when on-the-fly commands are enabled and the
Routing Mode (RM) setting of the DS is to be 0 (server). Follows is the
explanation on why this is so.
When the "permanent" serial port parameters are relevant or irrelevant
When the DS is in the server Routing Mode its serial port is not opened until an
incoming data connection is received from the network host (VSP in our case)*.
When on-the-fly commands are enabled the VSP sends on-the-fly commands to
the DS as soon as the VSP is opened**. Therefore, the serial port of the DS is
configured with on-the-fly commands right when it is opened. This means, that the
"permanent" values defined by the serial settings are never actually used.
It's a different story when the Routing Mode of the DS is server/client or client. In
this case the serial port of the DS is opened right from the moment the DS is
powered up*. This means, that the serial port is opened before the VSP is opened
and the on-the-fly commands are sent to the DS. Therefore, there is a chance that
the DS will receive some serial data before the serial port is configured by the VSP.
This is why the parameters defined by the serial settings are not irrelevant***!
* This is described in the opened and closed states of the serial port topic.
Software Manuals
293
** Unless the VSP is in the server routing mode but this cannot be so for the case
in question: if the DS is in the server routing mode then the VSP has to be in the
client or client/server mode!
*** Of course, when the VSP is opened it will still send the on-the-fly commands
and the data received before that can simply be ignored by the application. In this
case you can still say that it doesn't matter what the permanent settings of the
serial port are.
Programming Inaccessible DS
If this screen is shown then you have specified on the target DS step step that the
Device Server is not accessible from this PC. Now you have to decide how you will
setup this DS.
294
Application-to-DS
Link
4.1.4.3
This job is selected by choosing configure a Device Server for direct
communications with an application on this PC from the list of available jobs.
When performing this job the Connection Wizard configures the DS of your choice
to work with the "network" software application* on this PC. Use this job if you
want to make your PC application communicate directly with the DS and the serial
device behind it.
When working on this job the Wizard can only setup the DS side of the link. It is
your responsibility to setup the software as needed (expected by the Wizard).
* I.e. an application that is capable of communications through the TCP/IP
networks. If your application can only communicate through COM ports use the
VSP-to-DS connection instead.
Target DS
On this step you select the DS that the application on this PC will be
communicating with. Notice, that the Wizard can only setup the DS side of the link.
It is your responsibility to correctly setup the PC application!
Software Manuals
295
296
Notice, that asking "who will be the first to send the data?" is not the same as
asking "which side will be establishing the data connection to the other side?"*.
There are three choices:
Your application. Select this option if it is the application software that will be
Software Manuals
297
sending the first data. This is typical for the kind of serial devices that we, as
Tibbo, came to call "slave terminals". Such terminals communicate with the PC
software using some sort of command-reply communication protocol and it is the
PC that usually plays the role of a "master": the terminal won't send any data
unless the PC sends a command first (and this is the "first data"!).
Device Server. Select this option if it is the serial device that will be sending the
first data. This is typical for the kind of serial devices that we call "scanners"
(readers)**. This class of serial devices differs from "slave terminals" in that
they send out the data spontaneously, without any prior prompt from the PC
software.
Any side. In some systems the data may first come from any side. For example,
there are some "active terminals" out there that can send out the data
spontaneously and at the same time respond to the commands from PC. Also
choose this option if you are not sure which side of your system sends the data
first.
* Although these two questions are connected- see how the Wizard decides which
side open the connection.
** Meaning barcode scanners or magnetic card readers.
The gateway and netmask need only be set when two conditions are
observed:
The DS may need to (or must) establish data connections to the PC (this is
determined by the Wizard).
The DS and the PC are located on different network segments (there is at least
298
Software Manuals
299
It is your responsibility to set the application side as expected by the Wizard. For
the discussion below we will assume that the application also has "imaginary"
routing and connection options, similar in function to the ones found in VSP. Here
is what this means:
VSP properties
Server routing mode
Which
side
sends the
first data
Routing
Mode on
the
appl**.
Connecti
on Mode
on the
appl**.
Routing
Mode on
the DS
Application
Client
On data
Server
Co
nn
ec
tio
n
M
od
e
on
th
e
D
S
---
300
Serial
device
Server
---
Client
(server/clie
nt)
Server/clie
nt
Any side
Server/clie
nt
On data
Application
Client
On data
Server
On
dat
a
On
dat
a
---
Serial
device
Client
Immediatel
y
Server
---
Any side
Client
Server
---
Application
Server
Immediatel
y
---
Client
Serial
device
Server
---
Client
Any side
Server
---
Client
Im
me
diat
ely
On
dat
a
Im
me
diat
ely
The situation becomes more complicated when only one side of the connection can
"see" the other side. Consider the case in line 7 of the table. The application has to
send the data first, but it cannot "see" the DS. Therefore, even when the
application needs to transmit the data it will be unable to establish a connection to
the DS!
The way out is to have the DS connect to the PC (application) as soon as the DS is
powered (so, the Connection Mode (CM) setting is 0 (immediately)). This way,
by the time the application needs to send the first data to the DS the connection is
already established. This kind of connections are called "reverse".
A special comment should be made on line 2 of the table, where the Routing Mode
on the DS is designated to be either "client" or "server/client". The Wizard chooses
"client" if DS programming is effected using out-of-band access method (you have
selected this on the target DS step of the Wizard). If inband access method was
selected the Wizard will set the mode to "server/client". This is because choosing
"client" would cause it DS to reject all incoming connections in the future and this
means that you wouldn't be able to program the DS using inband access in the
future!
* This is the case when you have specified that "the Device Server is not accessible
from this PC" on the target DS step, or that "the PC is not accessible from this
Device Server" on the netmask and gateway for the DS step of the Wizard.
** "Imaginary" options of the PC application.
Software Manuals
301
302
Software Manuals
303
Unlike with the VSP-to-DS link, the serial port parameters of the DS, involved in
the application-to-DS link, cannot be adjusted via on-the-fly commands. You have
to define fixed parameters that will be used by the DS at all times.
Programming an Inaccessible DS
If this screen is shown then you have specified on the target DS step step that the
Device Server is not accessible from this PC. Now you have to decide how you will
setup this DS.
304
DS-to-DS
Link
4.1.4.4
This job is selected by choosing create a link between two Device Servers from the
list of available jobs.
When performing this job the Connection Wizard configures two Device Servers of
your choice to communicate with each other. This effectively creates a "virtual
serial cable" that interconnects the serial ports of these two Device Servers. Not
only the serial data, but also the state of the RTS, CTS, DTR, and DSR signals can
be seamlessly transmitted across this virtual cable!
There are two possible applications for the DS-to-DS link:
To interconnect two non-PC devices (shown on the diagram above).
To interconnect a serial device with a non-Windows PC software. Tibbo Virtual
Serial Portscan only work under Windows so if you have a case where you need
to network-enable a system involving a non-Windows software (i.e. DOS, etc.)
you can do this by using a second DS located on the PC side.
In this case the software still communicates through a real COM port, but the DS
on the PC side connects this COM to the network. This is effectively the same kind
of "virtual serial cable" connection. Device Servers do not know (nor care) what
kind of serial devices are communicating through them.
To setup the DS-to-DS link through the Wizard you need to use a Windows PC the
Wizard will run on (shown on both diagrams as "configuration" PC). Once the link
is created this PC is no longer needed as it is not directly participating in the data
link.
One limitation that the Wizard applies to the DS-to-DS link is that at least one of
the Device Servers in the link must reside on the same network segment* as the
configuration PC. The other DS may be located anywhere (be local or remote).
* I.e. there must be no routers (firewalls, etc.) between the configuration PC and
Software Manuals
305
the DS.
DS #1 (Must be Local)
On this step you select the first DS in the DS-to-DS link (it is called the "DS #1").
As explained earlier, the DS #1 must be local, i.e. it must be located on the same
network segment as the PC on which this Wizard is running (DS #2 can be local or
remote). Because of that, the accessibility option is fixed at Device Server is
assessable from this network segment (if the DS is local it is definitely must be
accessible).
Several access options that exist for the DS are also disabled because they are only
necessary when you are dealing with the remote DS and the DS #1 cannot be
remote.
The only editable option is the IP-address of the DS. You can input this IP-address
manually or select the DS from the list:
Click Select DS button and choose the DS from the list. The button brings up the
dialog, similar to the main window of the DS Manager. In fact, it is the DS
Manager, with the following two differences:
There is an additional Select button. To select a particular DS single-click on
the DS in the device list (in the auto-discoveryaccess mode) and press Select.
Alternatively, you can double-click on the DS in the device list.
The address book and COM access mode are not available. The DS #1 must be
local and so you must be able to find it in the auto-discovery mode.
Click Next.
When you click Next the Wizard attempts to contact the target DS and makes sure
that the DS is local and reachable*. If everything is OK the Wizard reads out all
current setting values of this DS.
* The DS Manager and the Connection Wizard have the ability to "see" local Device
Servers even if the IP-address of these devices is unreachable (this is done by
using broadcast communications- read about this here). The reason why the
306
Software Manuals
307
308
Notice, that asking "who will be the first to send the data?" is not the same as
asking "which side will be establishing the data connection to the other side?"*
When making your choice imagine that there is no network at all and that two
serial devices are interconnected via the serial cable. Now, which side sends the
data first?
There are three choices:
Device Server #1. Select this option if the first data will be sent by the serial
device connected to the DS #1.
Device Server #2. Select this option if the first data will be sent by the serial
device connected to the DS #2.
Any side. In some systems the first data may come from any side. Also choose
Software Manuals
309
this option if you are not sure which side of your system sends the data first.
* Although these two questions are connected- see how the Wizard decides which
side open the connection.
The gateway and netmask need only be set when two conditions are
observed:
The DS #1 may need to (or must) establish data connections to the DS #2.
The DS #1 and the DS #2 are located on different network segments (there is at
least one router between them).
Setting gateway and netmask information for the DS that only accepts incoming
connections is not necessary*. If both Device Servers are located on the same
network segment, the gateway and netmask are not necessary even if the DS #1
has to connect to the DS #2.
How to set the gateway and netmask
Since the DS #1 is located on the same network segment with this PC the gateway
and netmask values that need to be set for this DS are probably the same as the
ones set for the PC. Clicking Set as on the PC button copies the gateway and
netmask information from the PC.
If the IP-address of the DS #1 is configured through DHCP (DHCP (DH) setting is
1 (enabled)), then the DHCP server might have configured this Device Server's
gateway and netmask as well. When you reach this step of the Connection Wizard
the Gateway IP-address and the Netmask fields are filled with the data from the
Gateway IP-address (GI) and Netmask (NM) settings of the target DS. This
310
The gateway and netmask need only be set when two conditions are
observed:
The DS #2 may need to (or must) establish data connections to the DS #1.
The DS #2 and the DS #1 are located on different network segments (there is at
least one router between them).
Software Manuals
311
Setting gateway and netmask information for the DS that only accepts incoming
connections is not necessary*. If both Device Servers are on the same network
segment, the gateway and netmask are not necessary even if the DS #2 has to
connect to the DS #1.
How to set the gateway and netmask
There is no straight way of finding out what data to enter. You need to obtain this
information from somebody with a knowledge of your network's topology. Here is
one hint, though.
If the IP-address of the DS #2 is configured through DHCP (DHCP (DH) setting is
1 (enabled)), then the DHCP server might have configured this Device Server's
gateway and netmask as well. When you reach this step of the Connection Wizard
the Gateway IP-address and the Netmask fields are filled with the data from the
Gateway IP-address (GI) and Netmask (NM) settings of the DS #2**. This
data may already be correct!
What if the DS #1 is not visible from the DS #2
When two Device Servers are located on different network segments it may well be
that the DS #1 is not "visible" from the DS #2. This is normal as many networks
are not symmetrical. For example, if the DS #2 has a public (real) IP-address and
the DS #1 is located on a firewalled network segment then the DS #1 can connect
to the DS #2, but the DS #2 cannot connect to the DS #1.
To provide for this situation the option box at the top of this step's screen allows
you to specify that the DS #1 is not accessible from the DS #2. Choose the option
if this is so and if the option is available.
The option to specify that the DS #1 is not accessible from the DS #2 is disabled
(not allowed to be chosen) when you have previously specified (at the DS #2 step)
that the DS #2 is not accessible from the DS #1. The reason is obvious: at least
one side of the connection must be able to "see" the other side!
After you have completed this step the Wizard has enough information to decide
which side of the DS-to-DS link will be responsible for establishing the data
connections.
* We found that some people hold a passionate belief that these parameters are
necessary in any case. This is not true! If your network device doesn't have to
establish outgoing connections you never have to bother about the gateway and
netmask!
** Unless you have specified that "the Device Server is not accessible from this
network segment" at the DS #2 step of the Wizard, in which case the Wizard
cannot obtain this information.
312
Which
side
sends the
first data
Routing
Mode on
the DS
#1
Connecti
on Mode
on the
DS #1
Routing
Mode on
the DS
#2
DS #1
Client
On data
Server
DS #2
Server
---
Any side
Server/clie
nt
On data
Client
(server/clie
nt)
Server/clie
nt
see the DS
DS #1
Client
On data
Server
On
dat
a
On
dat
a
---
see the DS
DS #2
Client
Server
---
see the DS
Any side
Client
Server
---
see the DS
DS #1
Server
Immediate
ly
Immediate
ly
---
Client
DS #2
Server
---
Client
Any side
Server
---
Client
Im
me
diat
ely
On
dat
a
Im
me
diat
ely
1
2
4 Only DS #1 can
#2
5 Only DS #1 can
#2
6 Only DS #1 can
#2
7 Only DS #2 can
#1
Co
nn
ec
tio
n
M
od
e
on
th
e
D
S
#
2
---
The situation becomes more complicated when only one side of the connection can
"see" the other side*. Consider the case in line 5 of the table. The DS #2 has to
send the data first, but it cannot "see" the DS #1. Therefore, even when the DS #2
receives the first data into its serial port it will be unable to establish a connection
to the DS #1 and send this data!
Software Manuals
313
In general, we recommend you to stick to the TCP/IP, unless you have a good
reason (which is very rare!) why you have to use UDP/IP protocol.
There is one case when the UDP/IP selection is not available and the TCP protocol
is pre-selected for you- this is when you have specified an inband access method
on the DS #2 step of the Wizard. Since inband access requires a TCP/IP data
connection with the DS you must use TCP/IP transport protocol, or the
configuration PC won't be able to access the DS #2 in the future.
314
Software Manuals
315
network.
When this feature is enabled, a change in the state of the CTS (DSR) input on one
DS causes a corresponding change on the RTS (DTR) output of the other DS. In
effect, this achieves compete emulation of the serial cable over the network: not
only the serial data is seamlessly transmitted between the serial ports of two
Device Servers, but also the control lines appear to be interconnected.
Exchange of signal states is enabled separately for the RTS/CTS and DTR/DSR
signal pairs (there are two checkboxes- exchange the state of RTS and CTS lines
and exchange the state of DTR and DSR lines).
If you enable the status exchange for the RTS and CTS lines you won't be able to
enable RTS/CTS flow control for the serial ports of the DS (on parameters for the
serial port of the DS #1 and parameters for the serial port of the DS #2 Wizard
steps.
Control line status exchange and the connection mode of the DS
Exchange of the control line states is done through Notification (J) Messages
sent between the Device Servers. Notification messages are sent only when the
data connection is already established. This means that if there is no data
connection between the Device Servers remote exchange of control line states
doesn't work too. This may be a problem on some serial system that may need to
exchange the state of control lines even before any data is sent.
To avoid this problem the Wizard will program the Connection Mode (CM)
setting of one of the Device Servers to 0 (connect immediately) whenever control
line status exchange is enabled for at least one of the signal pairs (RTS/CTS or
DTR/DSR). "Connect immediately" option makes the DS establish a data
connection with its destination as soon as this DS is switched on. Connection is
then maintained at all times and control line status exchange will also work at all
316
Unlike with the VSP-to-DS link, the serial port parameters of the DS, involved in
the DS-to-DS link, cannot be adjusted via on-the-fly commands. You have to
define fixed parameters that will be used by this DS at all times.
If you have previously enabled status exchange for the RTS/CTS signal pair then
the RTS/CTS flow control option will be pre-set and fixed at disabled or remote.
This is because the remote exchange and "local" flow control are mutually
exclusive options.
Software Manuals
317
Unlike with the VSP-to-DS link, the serial port parameters of the DS, involved in
the DS-to-DS link, cannot be adjusted via on-the-fly commands. You have to
define fixed parameters that will be used by this DS at all times.
If you have previously enabled status exchange for the RTS/CTS signal pair then
the RTS/CTS flow control option will be pre-set and fixed at disabled or remote.
This is because the remote exchange and "local" flow control are mutually
exclusive options.
Programming an Inaccessible DS
If this screen is shown then you have specified on the DS #2 step that the Device
Server is not accessible from this network segment. Now you have to decide how
you will setup this DS.
318
Finishing
a Remote Job
4.1.4.5
This job is selected by choosing "Finish remote job" from the list of available jobs.
This feature allows you to finish the programming of the DS that was marked as
inaccessible from the "programming" PC when running one of the three connection
jobs.
Inaccessibility of the DS from the "programming" PC is not an uncommon situation
in wide-area networks (WANs). Such WANs are often not symmetrical i.e. only one
Software Manuals
319
side of the data link can "see" the other side. For example, in the VSP-to-DS link
the DS may be able to "see" (and connect to) the PC (VSP) but the PC (VSP) won't
be able to "see" the DS. The Wizard easily deals with this kind of networks by
correctly identifying which side of the link will be responsible for establishing data
connections with the other side.
The problem, however, is that if the DS is not visible from the PC, then the Wizard
cannot configure it through the network as well! The way out is either to program
the DS via its serial port immediately or generate configuration script file that can
be used later (you have been offered this choice on the programming inaccessible
DS step* of the Wizard). "Later" programming of the DS is done by choosing Finish
remote job on the Wizard job step of the Wizard.
320
Software Manuals
321
Reviewing
Setup Details
4.1.4.6
On this step you can review the setup this Wizard is about to apply to both sides of
the connection. There is nothing to select or decide on here- the step is provided
for your information only. Screenshot below shows the configuration of the VSP
and the target DS for the VSP-to-DS link.
Once you click Next the Wizard starts configuring the link.
Final Screen
4.1.4.7
If you got to this screen then this means that the Wizard has successfully
configured your connection. Clicking on the internet-style links in the middle of the
screen opens configuration dialogs for the "participants" of this connection.
322
For example, if you've just finished the VSP-to-DS job then you will see two links
as shown on the screenshot above. The first one opens the VSP properties dialog,
the second one- DS settings dialog. This provides a comfortable way of reviewing
the setup and making changes (if necessary) right from inside the Wizard.
Click Finish if you want to close the Wizard. Click Restart to run another Wizard
job.
Warnings
and Messages
4.1.4.8
This reference section contains additional information on the warning and error
messages displayed by the Connection Wizard.
Details
This message was displayed because the Connection Wizard has determined that
the DS you've specified is local (i.e. located on the same network segment as this
PC) yet you have opted to program this DS using inband (TCP) access method.
The primary method of programming Device Servers is by using out-of-band (UDP)
access method. This method always works and should be used for all local Device
Servers. Inband programming is meant as an alternative method for remote Device
Servers that cannot be accessed using out-of-band method.
Software Manuals
323
Details
MAC-->IP mapping option was created as a means to avoid communication
problems with Device Servers that run with DHCP (DH) setting programmed to 1
(enabled). The IP-address of such Device Servers is configured by the DHCP server
and there is no guarantee that this IP-address won't change in the future. When
this happens the VSP won't be able to communicate with the DS since the target
IP-address specified for this VSP will no longer belong to this DS.
The solution is to reference the DS by its MAC-address, which is done by enabling
the MAC-->IP mapping option. More on the subject can be found here: additional
info on accessing the DS.
If you choose to not enable the mapping the data connection will work, but only
until the DHCP server assigns a different IP-address to the DS.
DS #1 Must be Local
Description
Message text:
Details
This is a limitation imposed by the Connection Wizard. When you are creating a link
between two Device Servers the Wizard requires that at least one of the Servers is
located on the same network segment as the PC on which the Wizard is running.
Another DS may be local or remote.
Details
When you choose a port number for the listening port on the VSP side you can
input any number in the 1-65535 range. Port 0 is a special number that instructs
the PC to choose an actual port automatically. Since the port number of the
listening port must be fixed and known you are not allowed to input "0".
Port is in Use
Description
Message text:
324
Details
When the VSP is opened by another application its properties are locked and cannot
be changed.
Details
This message is displayed in the cause of the DS-to-DS connection job when you
select the same DS on both DS #1 and DS #2steps of the Wizard.
Details
Wizserial.sdf contains the list of settings related to the serial port of the DS. During
the installation this file is copied into the /SDF folder inside the target installation
folder of the Device Server Toolkit (DST). This message indicates that there is no
such file in the /SDF folder. This problem can be corrected by reinstalling the
software.
Invalid IP-address
Description
Message text:
Software Manuals
325
Details
This message is displayed when the Connection Wizard has determined that local
DS of your choice cannot be communicated with using normal IP-addressing.
As explained in broadcast access, a local Device Server can be accessed for
programming even if its IP-address is not configured properly. Therefore, the
Connection Wizard itself would be able to access and program any local Device
Server, even if the IP-address of this DS is unreachable. Data communications with
the DS, however, require the IP-address to be reachable. For example, the VSP
won't be able to connect to the DS with a "wrong" IP-address. This is why the
Wizard demands that you assign a proper IP-address to the DS before continuing
with the connection job.
There are several reasons why the IP-address of the Device Server may (appear to)
be unreachable. See troubleshooting (auto-discovery mode) for more information.
Details
This message means that the Wizard has verified if the target Device Server is
located on the same network segment with this PC and has determined that the DS
is not local, i.e. located on some other network segment and there is at least one
router (firewall, bridge, etc.) between this PC and the DS.
Understanding whether the target DS is local or remote is important for several
Wizard steps that will follow.
If you believe that the DS is actually local press Retry to make the Wizard re-check
the location of the DS.
You must make sure that your application won't send any
characters with ASCII code 255 (FF).
Details
This message is displayed when you have specified inband access method for the
target DS. Inband access method is usually utilized when out-of-band access is not
possible (i.e. because of restrictions on the network). To allow future programming
of the target DS the Wizard will preserve inband access in the DS and this means
that the Inband (IB) setting of the DS will be kept at 1 (enabled).
When the Inband (IB) setting of the DS is at 1 (enabled) the DS can accept
commands sent by the remote host across the data connection and ASCII character
with code 255 (FF Hex) is used as an "escape" character that signifies the
beginning of a command and two FF characters need to be sent to transmit one
data FF character (see inband programming for details).
If your application sends any FF characters the DS will interpret this as a beginning
of an inband command, which is obviously a problem as all subsequent data will
326
Details
After you have selected a particular DS in the Connection Wizard the latter attempts
to detect whether this DS is local or remote. This is done by sending an Echo (X)
command as UDP broadcast. Only locally attached Device Servers will receive the
broadcast, as broadcast packets cannot pass through the routers. Therefore, if the
DS you have selected replies to the broadcast then this DS is local, otherwise it is
remote.
This message means that the Wizard is unable to send the broadcast because local
port from which the broadcast is supposed to be sent is currently opened by some
other program.
This situation is extremely rare. If you encounter it please contact Tibbo for
instructions on how to change the port from which the Wizard is sending the
broadcasts! By default, the port number used for the purpose is 65534.
Software Manuals
327
It was possible to run the DS Manager, VSP Manager, and/or Connection Wizard
at the same time (wrong!) on slower PCs. Now corrected. Only one of those
components can run at any given time.
In the Connection Wizard, it was possible to create several identical VSPs by
rapidly clicking on FINISH button.
DS firmware upgrade from the DS Manager could crash when performed in the
background.
---------Release V3.6.6
New feature in VSP Manager. The Manager is now based on a COM object. You
can interact with this object from within your application software. This provides
a way for a full control programmatic control over creation, setup, and deletion
of Virtual Serial Ports.
New feature: additional options for serial (port control) lines CTS, DSR, and DCD
(see serial lines tab).
New feature: default serial property page (see default serial settings tab).
Bug correction in VSPD. In previous VSPD versions some special characters (such
as XOFF, ESC) when sent by a DOS-based program (running under Windows
NT/2000/XP) were incorrectly handled by the VSP. The problem has now been
corrected.
Bug correction: VSP properties could not be opened from within Windows Device
Manager. This problem has now been corrected. Under Windows98 you will see
default serial property page only. Under Windows NT/2000/XP you will see all
VSP properties- just like with VSP Manager.
Several other minor bugs and problems have been corrected.
---------Release V3.56 [baseline for this revision history]
328
Software Manuals
329
Installation
The VSPDL is supplied in two different versions:
TAR archive.
RPM package.
To install VSPDL you will need the following:
LINUX system (kernel 2.2.x-2.6.x).
GNU C compiler.
Linux kernel headers/sources of the Linux kernel you are running now.
make-3.74 or above.
binutils-2.7.0 or above.
bash
libc.so.6
libexpat.so.0
libgcc_s.so.1
libm.so.6
libstdc++.so.5
Further, you will need either
gunzip-1.2.4 or above to process TAR archive, or
RPM tool of your choice to process RPM package.
The Virtual Serial Port Driver for LINUX (VSPDL) distribution includes the
following:
VSPModule - Linux kernel module that creates Virtual Serial Ports (VSPs) on
your system (in lib/* of your distribution).
VSPDaemon - interacts with the VSPModule, facilitates data transfers between
the VSPs and the network (in sbin/* of your distribution).
Documentation - current documentation set in HTML format (in man/* of your
distribution).
Sample configuration files (in etc/* of your distribution).
VSPModule/VSPDaemon startup scripts ( in bin/vspm, bin/vspd of your
330
Software Manuals
331
332
* Some comments found in the actual vspd.conf that comes with the driver were
omitted. Default values for optional parameters are shown in purple
Sample4.2.5.1
Configuration File
Here is a sample configuration file (some optional parameters are at default values
and were included for clarity):
<!-- **** VIRTUAL SERIAL PORT DRIVER FOR LINUX (VSPDL) CONFIGURATION FILE **** -->
<vspdconfig>
<!-- ==================== GENERAL CONFIGURATION ==================== -->
<!-- Root directory for the daemon -->
<root dir="/usr/local/vsp"/>
Software Manuals
333
configuration -->
path="var/vspd.log"/>
path="var/vspd.log"/>
path="var/vspd.log"/>
path="var/vspd.log"/>
path="var/vspd.log"/>
path="var/vspd.log"/>
path="var/vspd.log"/>
<!-- ======= CONFIGURATION OF INDIVIDUAL VIRTUAL SERIAL PORTS (VSPs) ======= -->
<!-- ==================== VSP0 CONFIGURATION ==================== -->
<!-- VSP number -->
<vsp num="0">
<!-- HOST AND PORT TO BIND -->
<bind host="192.168.100.40" port="3500"/>
<!-- Connection parameters -->
<connection rmode="server/client" proto="tcp" conmode="ondata" timeout="2"
onthefly="outofband" clogin="pwd" dlogin="pwd"/>
<!-- Destination device parameters -->
<destination ip="192.168.100.90" port="1001" cport="32767"/>
<!-- Outbound packet generation options -->
<packets maxlen="255" maxdelay="0" starton="any"/>
<!-- Event logging configuration for this VSP -->
<log type="file" level="EMR" path="var/vspd.log"/>
<log type="file" level="ALR" path="var/vspd.log"/>
<log type="file" level="CRT" path="var/vspd.log"/>
<log type="file" level="ERR" path="var/vspd.log"/>
<log type="file" level="WRN" path="var/vspd.log"/>
<log type="file" level="NTC" path="var/vspd.log"/>
<log type="file" level="INF" path="var/vspd.log"/>
</vsp>
<!-- ===================== END OF VSP0 CONFIGURATION ==================== -->
</vspdconfig>
<!-- **** END OF VIRTUAL SERIAL PORT DRIVER FOR LINUX (VSPDL) CONFIGURATION FILE ****
-->
General4.2.5.2
VSPDL Configuration
General configuration options define the configuration of the VSPDL as a whole.
The format for the VSPDL configuration header is as follows (purple marks default
values that will be used if corresponding parameter is omitted):
<!-- **** VIRTUAL SERIAL PORT DRIVER FOR LINUX (VSPDL) CONFIGURATION FILE **** -->
<vspdconfig>
<!-- ==================== GENERAL CONFIGURATION ==================== -->
<!-- Root directory for the daemon -->
<root dir="directory"/>
<!-- Path and prefix for device files -->
<devprefix value="value"/>
334
</vspdconfig>
<!-- **** END OF VIRTUAL SERIAL PORT DRIVER FOR LINUX (VSPDL) CONFIGURATION FILE ****
-->
Software Manuals
335
level="EMR|ALR|ERR|WRN|NTC|INF|DBG" [
Type parameter defines the output destination for the event. If type is set to
"syslog", all events are logged to a syslog facility "USER". If omitted, this
parameter defaults to "syslog".
Level parameter defines the type of event for which this entry is created. Standard
level names are used.
Path parameter is only needed when type="pipe" or "file" and defines the file to
which events will be saved or a program that will accept events into its STDIN.
Because each entry in the format shown above specifies logging only for one type
of events (level) the configuration file can have several entries, for example:
<log
<log
<log
<log
<log
<log
<log
type="file"
type="file"
type="file"
type="file"
type="file"
type="file"
type="file"
level="EMR"
level="ALR"
level="CRT"
level="ERR"
level="WRN"
level="NTC"
level="INF"
path="var/dev.0.log"/>
path="var/dev.0.log"/>
path="var/dev.0.log"/>
path="var/dev.0.log"/>
path="var/dev.0.log"/>
path="var/dev.0.log"/>
path="var/dev.0.log"/>
In general, we recommend you to keep the list of logged events like the one shown
above. Logging "DBG" events is not necessary.
VSP Configuration
(<vsp> Section)
4.2.5.3
VSP configuration options define individual functioning parameters for each VSP.
Each VSP has to be described in the following format (purple marks default values
that will be used if corresponding parameter is omitted):
<!-- -------------------- VSP0 CONFIGURATION -------------------- -->
<!-- VSP number -->
<vsp num="0">
<!-- HOST AND PORT TO BIND -->
<bind host="ip_address" port="port"/>
<!-- Connection parameters -->
<connection [rmode="client|server|server/client"] [proto="udp|tcp"] [conmode="
336
Click on the links above to jump to parameter group and individual parameter
description topics.
Relevance conditions:
---
See also:
Num (VSP number) parameter defines the number for the VSP. The number can be
in the 0-127 range.
This parameter is similar to the port name of the VSP for Windows.
<bind ...
host="[IP_address]"/>
Software Manuals
337
---
See also:
Host parameter selects the IP-address to which this VSP will "bind". LINUX servers
often have several network interfaces (with each interface having its own
IP-address) and it may be necessary to specify which interface this particular VSP
will work on.
This parameter must not be omitted. Defining Host="" makes the VSP bind to the
"general" bind IP-address.
<bind ...
Parameter is mandatory
Relevance conditions:
rmode="server" or "server/client"
See also:
port="[port]"/>
Port parameter specifies the port number on the PC that will be associated with
this VSP. This port serves as a "listening port" for incoming data connections, when
such connections are allowed by the routing mode of the VSP. Additionally, in case
of UDP transport protocol and server/client routing mode, the port is also used to
send outgoing UDP datagrams. For more details see additional info on UDP and
TCP connections.
This parameter must be specified and cannot be omitted.
Port parameter works like the Port Number (PN) setting of the DS and
portoption of the VSP for Windows.
listening
338
"server"
Relevance conditions:
---
See also:
Rmode (routing mode) parameter defines whether the VSP will accept incoming
connections (passive opens) and/or establish outgoing connections (perform active
opens).
The following choices are available:
"server" (default) Only incoming connections are accepted, the VSP never
attempts to establish an outgoing connection to the DS. There
is no restriction on which DS can connect to the VSPconnection from any IP-address will be accepted as long as the
DS is connecting to the correct bind port using correct
transport protocol.
"client"
"server/client"
Rmode parameter works like the Routing Mode (RM) setting on the DS and the
Routing Mode option of the VSP for Windows.
"udp"
Relevance conditions:
---
See also:
Software Manuals
339
340
"ondata"
Relevance conditions:
See also:
Conmode (connection mode) parameter defines when the VSP attempts to establish
an outgoing connection to the destination, specified in the destination section of the
configuration file.
Connection mode drop-down box provides two choices:
"ondata" (default)
"immediately"
Connection mode option is irrelevant when the routing mode is "server", since in
Software Manuals
341
5 minutes
Relevance conditions:
---
See also:
Timeout (connection timeout) parameter sets the timeout (in minutes) for the
data connections between the VSP and the DS. If no data is transmitted across the
data connection (TCP or UDP) for a specified number of minutes the VSP aborts the
connection.
Setting connection timeout parameter to 0 disables the feature and connection
never times out. If omitted, this parameter defaults to 5 minutes.
Notice, that this feature will work even when the connection mode is set to
"immediately". When the timeout comes the VSP closes the connection first and
immediately reopens it (timeout counter is reloaded). This provides additional
reliability since hanged connections are automatically "repaired".
Connection timeout parameter works like the Connection Timeout (CT) setting
of the DS and the connection timeout option of the VSP for Windows.
"outofband"
Relevance conditions:
---
See also:
On-the-fly commands are used to change the serial port configuration of the DS as
needed (i.e. "on the fly"). Serial port configuration made through the on-the-fly
commands overrides the permanent one, defined by the serial port settings of the
DS. The difference between the changes made using on-the-fly commands and
changes made through altering DS settings is that, unlike serial settings, on-the-fly
commands have immediate effect and do not require the DS to be rebooted in
order for the new values to be recognized.
With on-the-fly commands enabled, the serial port of the DS is always setup as
required by the PC application that communicates with this DS through the VSP.
When the PC application opens the VSP (or some communications parameters are
changed) the application informs the VSP about required changes and the VSP
relates this information to the DS by sending on-the-fly commands.
Additionally, on-the-fly commands are used by the VSP to control the RTS and DTR
342
"inband"
"disabled"
Software Manuals
343
If omitted:
Relevance conditions:
See also:
Clogin (command login) parameter specifies the password that should be added to
the on-the-fly commands. On-the-fly commands can be sent without prior login
using Login (L) command. Instead, the password can be added to each
command individually (see out-of-band (UDP) programming). On-the-fly
Password (OP) settingon the DS must be programmed to 1 (enabled) to make
the DS check the password. Password specified by the clogin parameter must
match the one defined through the Password (PW) setting of the DS.
When clogin parameter is omitted all on-the-fly commands are sent without
password. This parameter is only relevant when on-the-fly commands are not
disabled.
If omitted:
Relevance conditions:
proto= "tcp"
See also:
Dlogin (data login) parameter specifies whether a "data login" procedure will be
performed when a TCP connection is established between the VSP and the DS.
When the data login is required the VSP cannot start exchanging the data with the
DS immediately, but needs to login with a valid password first. This provides a
password protection for the data connection with the DS. on the DS side, data
logins are enabled through the Data Login (DL) setting(additional info on data
logins can be found in command-phase (TCP) programming).
Password specified by the clogin parameter must match the one defined through
the Password (PW) setting of the DS.
Note, that omitting dlogin parameter is not the same as and specifying dlogin=""!
In the first case the VSP will expect to be able to start the data exchange with the
DS as soon as the connection is established. In the second case the VSP will still
perform a data login procedure with NULL password.
Dlogin parameter is irrelevant when the transport protocol is "udp" because data
logins are only supported for TCP connections.
344
<destination ...
If omitted:
Relevance conditions:
See also:
---
ip="IP-address"/>
<destination ...
If omitted:
Relevance conditions:
See also:
mac="MAC-address"/>
Software Manuals
345
This parameter is irrelevant when the routing mode is "server" because in this
mode the VSP never establishes outgoing connections.
MAC->IP mapping works just like the one on the VSP for Windows (see
single-destination mode).
* I.e. Device Servers located on the same network segment with the PC. The
definition of the network segment implies that there are only network hubs (and no
routers, bridges, firewalls, etc.) between the PC and all other devices on the
segment.
<destination ...
"1001"
Relevance conditions:
See also:
port="port"/>
Port (Destination data port) parameter specifies the port number on the DS to
which the VSP will try to connect when establishing outgoing connections. If
omitted, this parameter defaults to port 1001.
For the connection to work, the port number specified by this parameter must
match the one defined by the Port Number (PN) setting of the DS.
This parameter is irrelevant when the routing mode is "server" because in this
mode the VSP never establishes outgoing connections.
Port option works like the port parameter of the VSP for Windows (see
single-destination mode).
<destination ...
"65535"
Relevance conditions:
onthefly= "outofband"
See also:
cport="cport"/>
Cport (command port) parameter specifies the port number on the DS to which
the VSP will send its on-the-fly commands (when commands are sent in the
out-of-band mode). If omitted, this parameter defaults to port 65535.
Cport parameter allows you to set any command port number but the DS itself
actually accepts out-of-band UDP commands on two fixed ports: 65535 and 32767
(either port can be used). For more information see out-of-band (UDP)
programming.
346
255 bytes
Relevance conditions:
---
See also:
Maxlen (maximum packet length) parameter breaks the large chunks of data sent
by the application into smaller portions. Once the number of bytes in the TX buffer
reaches the limit defined by the maxlen parameter the VSP sends all the data in
the buffer to the DS. This does not close the data block and all subsequently
received data is still considered to be a part of the same data block. If omitted this
parameter defaults to 255 bytes.
For the UDP transport protocol this parameter directly defines the (maximum)
packet size of each UDP packet sent by the VSP. In TCP there is no guarantee that
individual packets won't occasionally carry larger chunks of data.
Maxlen option works like the Maximum Packet Length (ML) setting of the DS.
Software Manuals
347
Relevance conditions:
---
See also:
When the data block is already opened the VSP sends out all the data in its TX
bufferwhen no new data is received from the application for a period of time
defined by the maxdelay parameter (in milliseconds). This does not close the data
block and all subsequently received data is still considered to be a part of the same
data block. If omitted, this parameter defaults to 0 milliseconds, which means that
the data is sent out as soon as it is received from the application.
By using this option you can combine the data that is sent by the application in
"rapid succession" into a larger packets (but still not exceeding the maximum
packet length).
Maxdelay option works like the Maximum Intercharacter Delay (MD) setting of
the DS.
"any"
Relevance conditions:
---
See also:
Starton (start on character) parameter defines what will constitute the beginning of
the data block:
"any" (default)
"char"
This option works like the Start On Any Character (SA) setting of the DS.
348
Relevance conditions:
starton= "any"
See also:
Startchar (start character code) parameter defines the ASCII code of the
character that will open the data block in case the starton parameter is "char".
Parameter is irrelevant if starton= "any".
This option works like the Start Character Code (S1) setting.
If omitted:
Relevance conditions:
---
See also:
Stopchar (stop character code) parameter defines the ASCII code of the character
that will close the data block. If the stop character is not defined the data block is
never closed (although it is still subdivided using "breaking" parameters maxlen
and maxdelay).
This option works like the Stop Character Code (E1) setting.
level="EMR|ALR|ERR|WRN|NTC|INF|DBG" [
Type parameter defines the output destination for the event. If type is set to
"syslog", all events are logged to a syslog facility "USER". If omitted, this
parameter defaults to "syslog".
Level parameter defines the type of event for which this entry is created. Standard
level names are used.
Path parameter is only needed when type="pipe" or "file" and defines the file to
which events will be saved or a program that will accept events into its STDIN.
Because each entry in the format shown above specifies logging only for one type
of events (level) the configuration file can have several entries, for example:
<log
<log
<log
<log
type="file"
type="file"
type="file"
type="file"
level="EMR"
level="ALR"
level="CRT"
level="ERR"
path="var/dev.0.log"/>
path="var/dev.0.log"/>
path="var/dev.0.log"/>
path="var/dev.0.log"/>
Software Manuals
349
In general, we recommend you to keep the list of logged events like the one shown
above. Logging "DBG" events is not necessary.
LinkServer Software
Tibbo LinkServer is an integration software that helps you connect to your remote
Device Servers. The LinkServer saves costs and simplifies setup when trying to
create a network of Device Servers and computers (hosts) which are spread over a
wide-area network (WAN) or the Internet (which is just a large WAN).
In a WAN environment your Device Servers may be distributed over multiple
network segments, located behind firewalls, routers, bridges, etc. To connect to
such Device Servers you will usually need to obtain and assign real and static
IP-addresses -- and these are quite expensive and difficult to manage. Often, you
will also have to perform special configuration changes on your firewalls and
gateways to allow incoming connections, etc.
Tibbo LinkServer solves this problem by acting as a middle-man. Instead of
communicating with your remote Device Servers directly, you do so through the
LinkServer. As will be explained in the introduction this eliminates the need to
350
Introduction
What is Tibbo LinkServer?
This section explains an overall purpose of the LinkServer software. To better
understand the need the system serves, let us review the existing scene.
The basic assumption of the LinkServer system is that you have a WAN which
contains many Device Servers. Naturally, to use these Device Servers, you would
have to communicate with them. The LinkServer allows you to do so, in a simple
and flexible way.
Next topic- The Problem- explains why it is often difficult to connect to your Device
Servers distributed across a WAN. Subsequent topics- Solution 1: Link Service and
Solution 2: Dynamic DNS (dDNS) Service- explain how the LinkServer helps you
overcome the difficulties.
Software Manuals
351
The Problem
4.3.2.1
352
Solution4.3.2.2
1: Link Service
As explained in The Problem, it is usually much easier for a network host to
connect out than to accept an incoming connection. Unfortunately, with a normal
link, at least one side must accept an incoming connection.
Tibbo LinkServer provides a workaround for this problem by letting both sides of
the link to communicate through a "middle-man" (Link Service), to which they both
can establish outbound connections.
When you and your friend use ICQ or MSN, you both connect to a central server.
Neither of you typically has a static IP address, but the server has a static IP -- and
this is what lets the "magic" happen. Both parties make outbound connections, so
no firewalls have to be configured and neither side needs a static IP.
The Link Service is a very similar solution, only it is tailor-made for Tibbo Device
Servers! Your Device Servers in the field connect to the Link Service (make
outbound connections). Hosts that wish to communicate with Device Servers also
connect to the LinkServer using outbound connections. Both sides meet 'at' the
LinkServer and can thereby communicate through it. For more information on the
Link Service click here.
Software Manuals
353
The Device Server logs on to the LinkServer using its device name, owner name
and password. Typically, the DS is preset to do so immediately when it boots
(starts up). The LinkServer has a single port for Device Server logons -- 6450 by
default. Because Device Servers are uniquely identified by their device name,
owner name and password, a single login port for all Device Servers is sufficient.
A "client" host who wishes to communicate with a particular Device Server
establishes a connection to the LinkServer, to the specific port that was assigned to
this Device Server during registration. The link is thus created and both sides may
exchange data.
A client host does not need any special login procedure to create this connection to
the Device Server via the LinkServer. Instead of connecting to the IP address and
port of the DS directly, it connects to the IP address of the LinkServer and to the
port associated with a particular DS-- the difference is in parameter values only.
Unique "client-side" ports assigned to Device Servers are selected from a range of
available ports as defined by three dedicated LinkServer configuration options
(lowest number of port assigned to Device Servers, highest number of port
assigned to Device Servers, list of ports never assigned to Device Servers).
Solution4.3.2.3
2: Dynamic DNS (dDNS) Service
The Link Service is the most universal and easiest way to connect. The downside is
that it is slower than direct connection, because all the data must go through the
LinkServer.
This isn't critical for systems that do not produce a lot of traffic per each node.
Still, there are times where you might want to create a direct connection to a
device (for the sake of speed), but the IP address of this device changes from time
to time (this is the case with most ADSL connections).
You need a way to track the device down -- a way to overcome this and connect to
one 'stable' address. You need to know that this address belongs to the Device
Server you want, and be able to rely on it.
This is where the LinkServer dDNS Service comes in. With dDNS Service each of
354
Since actual connection is established directly to the Device Server you would have
to be able to reach it -- i.e, if it has a firewall protecting it, you must configure the
firewall appropriately. Configuration would be more complex than with the Link
Service, but you would gain an increase in communications speed.
DS.
Resulting host names are no different from any other host name (or URL) that you
have ever used. Input such a name as a destination in any software that can
connect to your Device Server and this name will be automatically resolved into
current IP-address of this Device Server! This functionality is based on an
industry-standard DNS protocol, so special drivers or software are required for this
to work.
Software Manuals
355
Only those Device Servers that are registered at the LinkServer can connect to
the dDNS Service. Each DS is identified by the LinkServer through a combination
of data in its Device Name (DN), Owner Name (ON), and Password (PW)
settings.
Difference between Internal and External Addresses
The difference between the two types of addresses is rather simple. Usually the DS
connects to a WAN through a router (firewall) which, in effect, "masks" the IP of the
DS. So the DS can be, for instance, at 192.168.2.100 within its network segment
(this is its "internal" IP), but the outside world sees it under a different IP address.
This is the "external" IP of the DS. So, to recap:
The "internal" IP is the actual IP address of the DS itself, such as 192.168.1.40.
It is used within that specific network segment.
The "external" IP is the IP of the router which is set to forward the data to the DS
on the inside.
To reach a DS from outside of its network segment you would need to use the
external IP address. However, if you connecting from the same network segment
you will need to know the device's "internal" IP address. This is why the LinkServer
employs two types of dDNS records.
LinkServer
Installation
4.3.3.1
This chapter describes installation of the LinkServer software. Before installing the
software be sure to check installation requirements and procedure.
356
Requirements
The LinkServer can potentially run under virtually any flavor of Windows, Linux,
FreeBSD, etc. At the time of writing, the LinkServer has been tested and verified to
correctly run under the following OS versions:
Windows 2000/XP "line"
Linux (V2.4 kernel)
FreeBSD
The LinkServer needs the following software for proper functioning:
Java Virtual Machine (JVM)
JVM is the only absolute requirement to run the LinkServer. The JVM can be
pre-installed on the target system or bundled with the installer itself (see
installation). Minimal version of JVM required to run the LinkServer is 1.4 (J2RE
1.4).
Relational Database Management System (RDBMS)
The LinkServer requires an RDBMS to operate. Distribution packages supplied by
Tibbo include a simple database engine that is used by default. For large-scale
systems we recommend using "industrial-grade" stand-alone RDBMS. The
LinkServer is compatible with a wide range of such third-party database servers:
Oracle
Microsoft SQL Server
Sybase
DB2
MySQL
Informix
PostgreSQL
and many others..
The LinkServer and the RDBMS don't have to be installed on the same server. Is is
also possible to configure the LinkServer to work with remote database, but in this
case its performance will depend on the network conditions.
Domain Name System (DNS) Server
To use the Dynamic DNS Service you need an RFC-2136 compliant DNS Server.
This can be local or remote server. RFC-2136 (Request For Comments)
specification is called "Dynamic Updates in the Domain Name System". Dynamic
updates are supported by most present-day DNS Servers, including an
industry-standard BIND and Windows 2000/2003 DNS service.
Installation
Tibbo supplies pre-packaged installation files for the following operating systems:
Windows 98, NT, 2000, XP, and 2003 Server
Different versions of Linux
Generic UNIX package (for FreeBSD/OpenBSD/NetBSD and other Unices)
To install the product, just run the installer executable file and follow the
instructions. On some systems, you need to make the installation package
'executable' before running it.
Installation can run in GUI or console mode. GUI mode is selected by default, to
switch to console mode installer should be launched with '-console' parameter.
Console mode is suitable for installation on systems that have no graphical user
interface (this is the case with most UNIX servers).
Software Manuals
357
There are two flavors of LinkServer distribution for each operating system:
Package with bundled Java Virtual Machine (JVM)
Package without JVM
The first flavor installs JVM during the setup process. This JVM is used to run the
LinkServer. In this case, the JVM is also removed when the LinkServer is
uninstalled. Second version requires JVM to be pre-installed on the target system.
Normally, JVM is detected and automatically used by the installer, but you can also
specify the JVM path explicitly. This is done by adding -is: javahome <path_to_JVM>
command line switch.
Additional installer options:
-is:tempdir <dir>
-is:log <file>
-is:extract
-is:nospacecheck
The Launcher can be added to the auto-start sequence of the OS. This is also an
OS-dependent operation. For example, under Windows you put a shortcut to the
LinkServer Launcher in the Startup folder. Under FreeBSD, you create a simple
shell script executing LinkServer.sh in background and put it to /usr/local/etc/rc.d/
directory. For further details, please see your operating system documentation.
The LinkServer Launcher accepts a number of command line parameters. These
parameters are divided into two groups: The first group is interpreted by the
launcher itself and the second is passed directly to the LinkServer application. For
more info, please see Launcher command line parameters and LinkServer
command line parameters.
358
Please note that there is no space before the argument for each switch.
i.e, the correct form would be -pjohndoe/123and not -p johndoe/123. This is
different from Launcher command line parameters.
Net Admin
Net Admin is a feature used to shut down or restart the server when the Web
Admin interface becomes unavailable for some reason, and the System Tray icon is
also unavailable (i.e. on a system without graphical user interface).
Net Admin is accessed using Telnet or any other Telnet-like software. You have to
telnet from the PC on which the LinkServer is running. You cannot access the
Net Admin from any other host.
To access the Net Admin:
Make sure you are working on the server actually running LinkServer.
Telnet to 127.0.0.1 (localhost ), port 6440
. You should get a connection, and no
prompt.
To shut the server down: Type S and hit Enter.
To restart the server: Type Rand hit Enter.
If the command was successful, you will get an A(Ack).
If the command failed, you will get an E(Error).
The Net Admin interface is enabled by default. It is used during
automatic upgrade or uninstallation of the LinkServer. If untrusted
users have local access (by Unix shell or physical access) to the
host running LinkServer, this feature should be disabled for
security reasons. It can be disabled using the Web Admin interface.
Software Manuals
359
The options in the menu are self-explanatory. They allow the you to easily open
the Web Admin interface, restartthe server or stop it.
Account Types
The LinkServer is built as a multi-user server. This means that usually one person
installs and manages the LinkServer, and numerous other persons use the Product
to access their Device Servers. These users can all belong to the same company, or
they can be paying customers who purchase LinkServer access from a vendor who
installed LinkServer on his own servers.
The person in control of the system is called Administrator. This person has full
control over every aspect of the system. There can be several administrators for
each LinkServer installation, though this is not recommended.
Regular users access the server through their user accounts. The users can see
their own settings, register Device Servers they wish to communicate with, etc.
They cannot change settings for other users or perform any administration
operation which will affect the whole system (such as shutting the server down or
restarting it). User accounts are completely independent. Device Servers registered
to one account are not visible from other accounts.
Summary of Permission Levels
All users of the LinkServer Web Admin are granted certain access permissions:
None. No permissions assigned for this user. It is a special permission level that
is assigned for any user who is browsing the Web Admin pages but isn't logged
in. This permission level allows browsing only the home, login, and registration
pages.
User. This is the default permission level for all registered users. Any Web
Admin client must log in to gain user permissions. This permission level allows
all "normal" activities like registering Device Servers, changing account info, etc.
Admin. This permission level allows the execution of any administrative actions:
make changes to LinkServer global configuration, create/edit/remove user
accounts etc. Immediately following LinkServer installation, the default
administrator account login and password are:
Login: admin
Password: admin
360
In the login dialog that will appear, enter the following default username and
password for administrator account:
Login: admin
Password: admin
For security reasons, it is highly recommended to change the password
for this account as soon as possible following installation.
AuthKey
One of the challenges in setting up a communications channel over a WAN is
authenticating the other side. Legacy interfaces, such as RS232, rarely made any
provisions for authentication.
In a WAN scenario, the authentication factor gains importance. What if someone
'hijacked' the connection to your devices, so that your serial data went to a 'fake'
server?
Similarly, it is necessary for the LinkServer to know that the Device Servers it is
communicating with are "genuine" -- meaning, they're the actual devices from
which data is expected. If there is no way to know this for sure, it might be
possible for a third party to 'inject' false data into your system.
Such security breaches may have serious consequences in a production
environment. This is why Tibbo LinkServer system incorporates a powerful
authentication mechanism, implemented in hardware -- The AuthKey. The
authentication itself is done by the "black box"-- the AuthKey -- which makes it
impossible to spoof or reverse-engineer the authentication process by analysing
LinkServer operation or its source code.
Software Manuals
361
The AuthKey is similar in appearance to the DS202 Device Server, but its housing is
red (magenta, actually). In terms of hardware, it is the DS202 with certain
enhancements. The AuthKey is used to run a totally different firmware, which
handles the authentication procedure. Regular "stock" DS202 can be converted into
a "trial" AuthKey.
The authentication procedure is performed every time a Device Server logs onto the
LinkServer to start communicating. At this point the DS sends certain identification
parameters to the LinkServer. Instead of verifying these parameters directly, the
LinkServer passes the data on to the AuthKey. The AuthKey then verifies this
information, and answers back to the LinkServer if it's OK to establish a connection
or not.
The DS also verifies authenticity of the LinkServer and AuthKey. This two-way
authentication mechanism makes sure that both the Device Server and the
LinkServer/AuthKey are "genuine".
The AuthKey also plays a role of a licensing keythat enforces the maximum number
of Device Servers connected to your LinkServer (The price for the LinkServer
depends on the number of Device Servers that can be used with it).
362
Licensing Details
LinkServer license cost varies according to the maximum number of "simultaneous"
Device Server connections allowed. No more than a certain number of Device
Servers can be connected to your LinkServer at any given moment. This limit is
enforced by the AuthKey.
The AuthKey does not actually track connection itself -- it does not constantly
check to see if a certain Device Server is still connected to the server. The AuthKey
only takes note of Device Servers when they are logging in. Connection is
considered to last from the moment the DS logs in and for the next 24
hours after that.
This means that when the Device Server logs in to the LinkServer, the AuthKey
takes note of this and starts a 24-hour timer for this specific Device Server. If this
Device Server disconnects and reconnects within the next 24 hours since previous
login the timer is restarted. If this Device Server disconnects and does not
re-connect for 24 hours or more, then this Device Server is no longer considered to
be connected and another Device Server can "take its place".
Example:
Supposing, you have a license for 5 connections.
A Device Server called "DS1" connects. Now you have 4 connections available.
After two hours, "DS1" disconnects. You still only have 4 connections available.
22 more hours pass, and "DS1" does not try to connect again. Now you have 5
connections available.
Device Server called "DS2" connects. You have 4 available connections left.
"DS1" connects again. You have 3 connections left.
"DS2" disconnects. You still have 3 connections left.
It is noteworthy that one AuthKey can serve several servers running LinkServer
software. This is possible, legal, and does not change the total number of Device
Servers that can be simultaneously connected to all servers that rely on this single
AuthKey.
Software Manuals
363
The list of settings available on the AuthKey is very different from that of a regular
Device Servers. To view AuthKey settings correctly your DST installation should
include a special file called v10-00.sdf (sdf files are configuration templates, you can
read about them here). DST installation files include v10-00.sdf starting from DST
version 3.6.5.
Device name
MAC-address
IP-address
Port
364
In the caption of the Settings dialog you will see a Serial Number of your
AuthKey. Send this number to Tibbo.
You will receive an email in reply, which will confirm the number of simultaneous
connections for which you have purchased the license. You will also receive a
License Verification String.
Enter the number of units for which you have obtained the license in the Desired
Software Manuals
365
LinkServer
Configuration
4.3.3.2
This section is a LinkServer configuration guide. There are two ways to configure
the LinkServer:
Through the web-interface using standard browser like Internet Explorer or
Mozilla Firefox.
Using an XML file.
Normally, the first method should be used. File-based configuration helps to
correct one or two settings when LinkServer can't start and web-interface is not
available.
For details about both configuration methods, see:
Web-based configuration
File-based configuration
Web-based Configuration
LinkServer Web Admin is available immediately after startup. Its default URL is
https:// xxx.xxx.xxx.xxx:8443, where xxx.xxx.xxx.xxx is the IP address of any network
interface of the server. Note, that the protocol used is HTTPS, not HTTP, because
LinkServer accepts only secure connections. Default port number is set to 8443
because the default HTTPS port (443) is often occupied by another web server. You
can always change port number back to 443 if this port is not busy- then you don't
have to explicitly specify the port when accessing the LinkServer: https://
xxx.xxx.xxx.xxx.
If it is not convenient to access LinkServer Web Admin by the IP address of its
host, you can define one or more host names for it. You may add a DNS record
defining a host name that points to the IP address of the server running the
LinkServer software. After that, you can access Web Admin using a URL such as
https://linkserver.serv1.com . For more info, see Web Admin settings.
366
File-based Configuration
File-based configuration should be used if LinkServerfails to start and its
web-interface is not available. LinkServer accepts two command line options
responsible for reading and writing configuration files:
-s[ filename]
-l[FILENAME]
Software Manuals
367
Usually you do not need to add options to this file manually. File structure is
generated automatically by the LinkServer. The only thing you need to do is to
change value field in the correct <entry> nodes (as indicated by their names, which
are contained in the key fields).
Configuration options are divided hierarchically into several groups. The root group
("node", in XML terms) is called linkserver and highlighted in italics in the listing
above. Its options are contained in another node- <map>and represented by the
<entry> elements. Each <entry> element includes a "key" field which contains the
name of the option, and a "value" field which contains a value for this option. The
root node contains sub-nodes, which are also encapsulated by <node>
elements.
The structure of each sub-node reproduces the structure of the root node. For
example, the option group called "Database" is contained in an element marked as
<node name="Database">
(marked in italics on listing).
You can find detailed description of options and option groups under Global
configuration.
Configuring Logging
As with most server software, the primary method to report all events and
activities of the LinkServer is logging. The LinkServer has an advanced logging
facility which is easily configurable through an ordinary text file. One of the key
advantages is that logging configuration can be changed at runtime without
restarting the LinkServer.
LinkServer uses Apache Log4J logging library for log output. It is highly
customizable and allows multiple levels and sources of logging information along
with numerous log destinations. Logging output can be redirected to:
Console
Text files
XML files
Windows event logs
UNIX syslog
Database
Remote network server
E-mail messages
Java Message Service (JMS)
And many other destinations..
368
Logging Levels
LinkServer uses five predefined logging levels:
Fatal
logging level is used to report only the most severe messages. The
LinkServer usually stops if a fatal error is detected and reported.
Error
Warning
Software Manuals
369
Debug
Change the priority value entry (info above) to the logging level you want to specify.
Restart the LinkServer (this step is recommended but not mandatory).
The string priority value= appears in other sections of the file. Most
importantly, it appears under the section </root>. Modifying this value
under the section root (especially to higher logging levels, such as debug
)
may affect performance considerably, and even cause the LinkServer to
halt or freeze.
370
Navigating
the Web Admin Interface
4.3.4.1
The following screenshot shows the Web Admin interface as it appears after an
administrator has logged on:
Click on the links below to jump to a detailed description of a specific menu item:
Device Servers- this item displays a list of all Device Servers currently
registered to this account.
Events- displays event log.
Settings- contains configuration options, personal profile info (such as contact
details), etc.
Administration- contains global configuration options for the LinkServer. This
section of the interface is visible only to administrators.
The LinkServer dynamically generates each webpage when this page is
accessed for the first time after the LinkServer was installed. This causes a
slight delay when any page is first opened. This only happens once for each
page after LinkServer installation.
Web Admin
Page Reference
4.3.4.2
This section provides a description for each menu item (and page) of the
LinkServer Web Admin interface.
The topics are laid out according to the hierarchy in the Web Admin main menu.
Please note that not all pages are visible at all times. Certain pages maybe not
available because of your current login status, permissions, or LinkServer
configuration settings.
Software Manuals
371
To get around the Web Admin interface, use the Navigation Bar at the top of the
window:
Home
Registration
Login
Device Servers
Events
Settings
Logout
Home
Full page path:
Home
Permission level:
none
This page is the starting point for LinkServer Web Admin. It contains a Welcome
frame with the LinkServer logo, version number, and operating system details.
This is what you see when you first log in.
Notes:
When LinkServer is restarted using Web Admin, the current user is redirected to
the Home page. Login and session information is discarded so all users need to
login again. Server startup may take considerable time and the Web Admin
application will stay unavailable for this period.
The user is also redirected to the home page in case of successful login.
372
Registration
Full page path:
Registration
Permission level:
none
This page contains new user registration form. It is available for anybody who is
browsing Web Admin pages, as long as users self registrationoption is enabled.
To register a new user account, perform the following steps:
Enter new account name into the Username field.
Enter the password for this account into the Password field.
Reenter the password into the Repeat password field.
Click Save
If registrations is successful you will be redirected to the login page. Enter the
username and password specified during registration to log into this new
LinkServer account.
Notes:
Username (also referred to as login) must contain between 4 and 32 characters
and include only letters, numbers and underscore ("_") sign. It must also be
unique within this LinkServer installation. All Device Servers that will be registered
to this account must have their Owner Name (ON) setting programmed with the
same name.
Password must contain between 4 and 32 characters as well.
Login
Full page path:
Log in
Permission level:
none
This page allows you to log onto your account. Enter your account name (a.k.a.
login name and user name) and password in the Authorization frame and click
Log in".
Software Manuals
373
If the LinkServer has just been installed and no accounts have been registered yet
there is only one default account available: this is the administrator account. You
can login to it using the following name and password:
Login: admin
.
Password: admin
.
For security reasons, it is higly recommended to change the password
for this account as soon as possible following installation.
Device Servers
Full page path:
Device Servers
Permission level:
user
This page shows a list of Device Servers registered to this account. The following
info is shown for each Device Server:
Current status (offline, online, etc.).
Device Server name (from the Device Name (DN) setting).
Port number associated with this Device Server (see Link Service: further details
).
Date and time of the most recent login by the Device Server.
IP address and port number from which this Device Server has establish the
most recent connection (logged in).
Click on the column header to sort the list by this column. Click on the same
header once again to reverse sort order (ascending vs. descending).
Click on Device Server's name to view detailed information for this Device Server.
Device servers
Permission level:
user
374
This page shows detailed information for the selected Device Server.
There are two command links at the top of the page:
Edit Device Server
Remove Device Server
Click on the Remove link to remove this Device Server from current account. Once
you do this the Device Server will be disconnected immediately (if it was connected
to the LinkServer at that time).
Permission level:
user
To add (register) new Device Server, go to Device Servers > Add Device Server
.
To edit an existing Device Server click on the name of a device on the Device
Servers page, then click edit on the view Device Serverpage.
The following fields are available:
Device server name
Software Manuals
375
Server.
Device server password
Blocked
Inband commands allowed for client Inband commands are used for Device
Server setup. This option needs to be
enabled if the "client" will need to send
inband commands to the Device Server.
Data buffering enabled
376
Events
Full page path:
Events
Permission level:
user
Time column notes the most recent date/time when certain event
has happened. The time is formatted according to the current
user's date/time configuration (Regional Settings under Windows,
for instance).
Date/time listed are adjusted for the current accounts timezone. For
example, the server is located in London (GMT+0) and the user is located
in Denver (so his account specifies GMT-7). An event occurs at 17:30
(U.K. time). Local time for the user in Denver is 10:30. When the user in
Denver opens the log, that event will be shown as having occurred at
10:30.
Device Server
Event
Settings
Full page path:
Settings
Permission level:
user
This page contains a "General Account Info" frame. The fields are self-explanatory.
Two sub-menu items available on this page are:
User profile
Software Manuals
General settings
User profile
Full page path:
Permission level:
user
The first table includes the following data about the account:
Username
First name
Last name
E-mail
Company
Department
Comments
Time zone
Contact Info:
377
378
Fax no.
Address 1
Address2
City
Region / State / Province / Area
ZIP / Postal code
Country
Permission level:
user
This page contains a form allowing the user to change the following fields:
First name
Last name
E-mail
Company
Department
Comments
Local Time Zone
Permission level:
user
This page contains a form allowing the user to change the following fields:
Software Manuals
379
Phone no.
Fax no.
Address 1
Address 2
City
Region / State / Province / Area
ZIP / Postal code
Country
Permission level:
user
This page contains a form used to change the current user's password. Enter
password and password confirmation in the form and click Change password.
There's no need to re-login after changing password.
General Settings
Full page path:
Permission level:
user
Date/time format
Administration
Full page path:
Administration
Permission level:
admin
380
Global Configuration
Full page path:
Permission level:
admin
This page contains a list of LinkServer configuration options. Edit one or more
options and click on the Save configuration and restart server button. LinkServer
will be rebooted and all changes will take effect.
The following setting groups are available:
General settings
Database settings
Web Admin settings
Dynamic DNS settings
AuthKey settings
Description:
General settings
linkserver
Software Manuals
381
This option defines login port number for Device Servers, i.e. port to which
Device Servers should establish connections (login). All Device Servers login to
the same port, as described here.
Lowest number of port assigned to Device Servers
Key name in the configuration file: DeviceServerPortRangeMin
Value type: Integer
Possible values: 1-65535
Default value: 50000
This option defines the lowest port number that can be assigning to Device
Servers being registered on the LinkServer. As explained in Link Service: further
details each Device Server is assigned (upon registration) a port on the
LinkServer to which clients that wish to communicate with this Device Server
should connect.
Highest number of port assigned to Device Servers
Key name in the configuration file: DeviceServerPortRangeMax
Value type: Integer
Possible values: 1-65535
Default value: 60000
This option defines the highest port number that can be assigning to Device
Servers being registered on the LinkServer. As explained in Link Service: further
details each Device Server is assigned (upon registration) a port on the LinkServer
to which clients that wish to communicate with this Device Server should connect.
Comma-separated list of ports never assigned to Device Servers
Key name in the configuration file: DeviceServerPortRangeExceptions
Value type: String
Possible values: 1-65535
Default value: "" (empty)
This option defines the list of ports that may not be assigned to Device Servers
being registered on the LinkServer. This option allows you to exclude certain ports
(that are used by other software on your server) from being occupied by the
LinkServer. As explained in Link Service: further details each Device Server is
assigned (upon registration) a port on the LinkServer to which clients that wish to
communicate with this Device Server should connect.
Enable users self-registration
Key name in the configuration file: UsersSelfRegistration
Value type: Boolean
Possible values: true or false
Default value: true
If this option is enabled, anybody who has access to Web Admin can register a
user account, log in and use LinkServer Services. When this option is disabled
only an administrator can add new user accounts.
Enable gui mode (yes, no, or auto)
382
Description:
Database settings
linkserver/Database
Database driver
Key name in the configuration file: DatabaseDriver
Value type: String
Possible values: Any Java class name corresponding to a JDBC driver
Software Manuals
383
Database URL
Key name in the configuration file: DatabaseUrl
Value type: String
Possible values: Database-dependent path string
Default value: jdbc:hsqldb:file:db/linkserver
Database URL is a database-specific string that defines database type, network
or local filesystem path to a database containing LinkServer data tables, and any
additional options. Consult JDBC driver documentation to find out the proper
value. Default value for this option means that embedded HSQL database is used
to store data using ordinary text files placed in db/ subdirectory of LinkServer
installation.
Database username
Key name in the configuration file: DatabaseUsername
Value type: String
Possible values: Any username suitable for the database server
Default value: sa
This option defines which username is used to log on to the database server. The
default value allows to connect to the database server embedded into the
LinkServer.
Database password
Key name in the configuration file: DatabasePassword
Value type: String
Possible values: Any password suitable for the database server
Default value: "" (empty)
This option defines which password is used to log on to the database server.
Default value allows to connect to the database server embedded into the
LinkServer.
Database SQL dialect
Key name in the configuration file: DatabaseSqlDialect
Value type: String
Possible values:
384
Database
server
DB2
DB2 AS/400
DB2 OS390
PostgreSQL
MySQL
Oracle (any
version)
Oracle 9/10g
Sybase
Sybase
Anywhere
Microsoft SQL
Server
SAP DB
Informix
HypersonicSQL
Ingres
Progress
Mckoi SQL
Interbase
Pointbase
FrontBase
Firebird
Description:
linkserver/WebAdmin
Software Manuals
385
linkserver/DynamicDNS
386
The result is prepended to the zone name to form a fully qualified domain name.
Host pattern for registering internal IPs
Key name in the configuration file: HostPatternForInternalIPs
Value type: String
Possible values: String containing special tokens
Default value: %n.%o.int
Defines host name pattern to use for registering internal IP addresses of Device
Servers. Value of this option is parsed and the following substitutions are made:
%n
is changed to the device name of a particular Device Server
%o
is changed to the owner name of a particular Device Server
The result is prepended to the zone name to form a fully qualified domain name.
IP address of DNS server
Key name in the configuration file: ServerIP
Value type: String
Possible values: Any IP address
Default value: "" (empty)
Defines IP address of the DNS server used for Dynamic DNS updates.
Port number on DNS server to communicate with
Key name in the configuration file: ServerPort
Value type: Integer
Possible values: 1-65535
Software Manuals
387
Default value: 53
Defines destination port number on DNS server used for Dynamic DNS updates.
Enable Transaction Signature (TSIG) keys
Key name in the configuration file: UseTSIGKeys
Value type: Boolean
Possible values: true or false
Default value: false
This option enables using Transaction Signature (TSIG) keys destined for making
communication with DNS server secure.
TSIG key name
Key name in the configuration file: TSIGKeyName
Value type: String
Possible values: Any string value conforming to the Dynamic DNS specification
Default value: "" (empty)
Defines name of key to be used for Transaction Signatures.
TSIG key value
Key name in the configuration file: TSIGKeyValue
Value type: String
Possible values: Any string value conforming to the Dynamic DNS specification
Default value: "" (empty)
Defines value of key to be used in Transaction Signatures.
Enable TCP mode
Key name in the configuration file: TCPMode
Value type: Boolean
Possible values: true or false
Default value: true
If this option is set to true, TCP protocol is used for DNS updates, otherwise all
transactions are performed using UDP.
Timeout for DNS operations, seconds
Key name in the configuration file: Timeout
Value type: Integer
Possible values: Any integer number
Default value: 10
Defines timeout for DNS update operations. If no answer is received from the
DNS server within this time, DNS update operation is considered unsuccessful.
TTL for new DNS records, seconds
Key name in the configuration file: TTL
Value type: Integer
Possible values: Any integer number
388
AuthKey settings
AuthKey
Software Manuals
389
User Management
Full page path:
Permission level:
admin
This page shows a list of all user accounts. Each account entry includes the
following details:
Username for this account
First and Last name of the account owner
E-mail address
Click on any column header to sort the list by this column. Click on the same
header once again to reverse sort order.
Click on a username to view user information.
Permission level:
admin
This option allows an administrator to create user accounts. You can only create
account itself but not set any of the profile details (such as name, address, etc).
Only this account's owner can set those details.
Permission level:
admin
390
This page shows a table with all the details about selected user account. This table
is divided into three parts, and each part has an Edit link which leads to a
corresponding edit info page.
The last part of the table, Settings, allows you to also change user permissions and
allow him to automatically register Device Servers.
The top of the table also contains a remove user link. Clicking this link causes the
selected account to be removed and all of its Device Servers to be disconnected
immediately.
Full page path:
General Settings > Edit
Permission level:
admin
Permissions
Value type: String
Possible values: none, user, adm in
Default value: user
Software Manuals
391
This allows you to make the user into an administrator, thus giving him full
control over the server, or to disable his account (similar to deleting the
account), by setting permissions level to none
.
Local Time Zone
This allows you to configure the timezone for this account. This influences time
displayed in logs within the Web Admin interface.
Date/time format
This allows you to configure the user's current locale, used for correctly
formatting the date and time when displaying logs.
Enable automatic registration of Device Servers
This lets the user's Device Servers automatically register with the LinkServer as
soon as they try to log on. It is described in further details under Device server
auto-registration.
Restart Server
Full page path:
Permission level:
admin
Selecting this menu item causes the server to be restarted. After you select this
link the LinkServer displays the message "Server is being restarted." All current
communications sessions are dropped and all logged users are disconnected.
Connections may resume once the server has restarted.
The server can also be restarted using the System Tray Icon menu.
Stop Server
Full page path:
Permission level:
admin
Selecting this menu item causes the server to be stopped. After you select this link
the LinkServer displays the message "Server is being stopped". All current
communications sessions are dropped and all logged users are disconnected.
Exercise caution when stopping the server remotely- the Web Admin
interface won't be available after that so you won't have an easy way to
start the LinkServer again.
392
Logout
Full page path:
Log out
Permission level:
user
Select logout to log off your account. You will be automatically redirected to the
login page.
Troubleshooting LinkServer
Something went wrong? Please read below. Also, check our Knowledge Base to see
if your issue appears there.
And if all else fails, you can always ask for Technical Support.
Errors in
Accessing AuthKey
4.3.5.1
When trying to load the AuthKey's settings the "normal" way (using the DS Manager
), you may get an error looking like this:
And when clicking the link here, you will get a dialog similar to this:
This means that you're missing a file, called v10-00.sdf. This file should be located in
the sdf subfolder of the Device Server Toolkit folder. If you are indeed missing this
file, please download the most recent version of the Device Server Toolkit from the
Tibbo website. If for some reason this fails, request the sdf from the technical support
team.
Once this file is properly located, you will no longer get an error, and will instead get
the normal settings for the AuthKey, which look like this:
Software Manuals
393
These settings are more fully described under Setting up AuthKey using DS Manager.
DS Has4.3.5.2
Trouble Connecting to Server
Here is a list of error patterns that you might encounter if there is a problem with
your setup:
IP address not obtained. This has nothing to do with
Dynamic DNS itself. It just means that your Device
Server is configured to obtain its IP from the DHCP
server and for some reason this is not working
properly. The Device Server will only attempt to
register at tibbo.net after it has successfully
configured of its own IP.
Sending ARP. You have specified an incorrect
Gateway IP-address/ NetMask or your network router
is not setup correctly.
TCP connection is being opened. You have entered
incorrect dDNS Server IP-address or your network
router is not setup correctly.
TCP connection reset by the network host. You have
specified incorrect dDNS Server Port/ dDNS Server
IP-address.
Login failed. LinkServer has rejected login from your
Device Server. Make sure that Owner Name= Unique
User ID, Device Name= Device Name, and Login
Password= Login Password.
User Forgot
His Password
4.3.5.3
It sometimes happens that a user, or even the administrator of the system, forgets
his password. In such a case, the user must alert the system administrator, who
will re-set his password.
Resetting the password is done using the -p command line option. The syntax for
/ <password>
this option is -p<username>
.
So, assuming the user johndoe forgets his password and alerts the administrator,
here's what the administrator would do to reset johndoe's password to foobar:
Shut down LinkServer (see Stop Server).
394
Server 4.3.5.4
not Responding
Sometimes, there may be situations where the server cannot be accessed, but is
still running. You can see that the process is running, but when trying to access
the Web Admin interface, the request times out.
This means that the LinkServer is running, but with errors. You have two options to
resolve this:
Using Net Admin
This is the recommended option. Access the Net Admin interface via telnet to port
6440
, and use it to shut the server down (S command) or restart it (Rcommand).
Manually kill the processes
This option is not recommended, as it might kill other Java processes running on
the host. To use it, you must kill the server and the JVM (Java Virtual Machine)
processes manually, and then start the server again.
Under Windows, the processes to kill are Linkserver.exe, and java.exe. Kill all
instances of these processes using the Task Manager (Ctrl+Shift+Esc under Windows
2000/XP).
Under Unix, the processes to kill are linkserver.sh and java. There are many Java
processes active at any one time. Kill the process with the lowest PID (Process
ID). This is important. Killing another process will not resolve the problem.
There are specific instances where one should kill another process than the one
with the lowest PID, but these are special cases, which depend on specific server
configurations. Killing the process with the lowest PID will most likely resolve this
situation.
Only 5 4.3.5.5
Devices Can Connect
If you bought over 5 licenses but only 5 devices can connect to the LinkServer,
there is probably a mismatch between the license verification string setting and
the desired license limit setting in the AuthKey.
To resolve this, please browse to Setting up AuthKey using DS Manager.
Application Notes
This part contains all our Application Notes in chronological order:
AN001. Customization options in our Products
AN002. Practical advice on integrating EM Module into your device
AN003. Time delays when the DS is opening TCP connection to the PC
AN004. How to send the same data to several DS
AN005. Remotely controlling I/O lines on the DS
Application Notes
395
396
Application Notes
397
To hide settings simply remove corresponding lines from the .sdf file.
398
Application Notes
399
always present.
It is not enough to just change the file tdst.ini. You need to "sign it up" in order for
the installation program to recognize this changed file. See below for more
information.
Replace default name and logo (bitmap) with your own name and logo in
the installation program
When you distribute the DST as part of your own system you may wish to display
your own Company name and logo in the installation screens.
You can achieve this by editing the data in the tdst.ini file. To see the tdst.ini file
download the .zip archive of our distribution to your PC and unzip this archive into
a separate folder. Open the file using any simple text editor (i.e. Notepad). You will
see that the file contains the following data:
companyname = Tibbo Inc.
companyshortname = Tibbo
productname = Device Server Toolkit
setupimage = Tibbo.bmp
setupimageparams = 1;;;255,0,255
...
Companyshortname and productname define the default installation directory of
the software. Directory is:
.../Program Files/companyshortname/productname
So, if your Company name is "XYZCorp" and you wish the software to be called
"DST" then input the following data:
companyshortname = XYZCorp
productname = DST
In this case the default installation directory for the software will be:
.../Program Files/XYZCorp/DST
Productname is also shown during the software installation. You can define your
own setupimage as well. This is a bitmap that is displayed in the installation
screens. Unfortunately, there is no way to define the position of this bitmap in the
window- InstallShield software used to generate installation files doesn't provide
this flexibility. So, the bitmap position is fixed. The only thing you can do is define
if this bitmap will contain a transparent color.
Setupimageparams line has several parameters. The first one specifies if there is a
transparent color (1 for "yes" and 0 for "no"). Last three numbers specify which
color is to be transparent. For example, if you don't want any transparency then
set setupimageparams=0;;;0,0,0. And if you want the white color to be considered
transparent then set setupimageparams=1;;;255,255,255.
400
Application Notes
401
Position the Module as close as possible to the RJ45 connector, do proper layout
Make sure you supply good power at required current
Proper reset is a must!
Provide status LEDs, prog/init button, and serial access connector
Let your main CPU control the Module...
...Or let the EM Module control your main CPU
402
Another important point. Do not create a ground plane in the vicinity of the RJ45
connector and RX-, RX+, TX-, and TX+ lines. The ground plane should "wrap
around" the RJ45 area, but not cross any of the 4 interface wires. This is very
important! Providing a ground plane beneath the connector area will make your
device very susceptible to the ESD.
Make sure you supply good power at required current
Tibbo EM Modules are just like IC chips- they require a regulated DC power source,
5V nominal, +/- 5% deviation. Some Modules (such as EM202) consume relatively
high current (~230mA)! We provide this data in our Documentation and yet we
still have cases where our Customers use "bad" power supplies. So, this advise is
simple: make sure you supply regulated 5V DC and that your power supply can
offer necessary current.
Proper reset is a must!
Tibbo EM Modules do not have internal reset circuits so you must provide an
external power-on reset. It is not enough to just tie the RST pin to VCC, this won't
work! We also do not recommend using a simple RC-circuit. Such circuits are not
reliable because they do not monitor the supply voltage and won't work properly
under many circumstances.
For example, if you have a power supply that "starts slowly" (i.e. its voltage rises
slowly after the powerup) then the reset pulse generated by the RC circuit may end
before the VCC comes to within 5V-5%. Another problem condition is a "brownout"
(this is when the VCC momentarily goes below 5V-5%). Brownouts can cause the
EM Module to hang up. Use a proper reset IC instead- this will give you a very
reliable reset both on startup and in case of a brownout. Some reset ICs (for
example MAX810 from MAXIM) have a very attractive price now (about USD0.5).
Reset IC you use must have the following spec: (1) active high reset, (2) reset
pulse of at least 100ms, (3) reset threshold of around 4.7V. If your device already
has a matching reset IC then you can use its output for the EM Module as well.
Another possible reset arrangement is to use a free I/O pin of your device's main
CPU. I/O pins of most CPUs default to HIGH state upon hardware reset. For
example, supposing that your device is based on the x51 microcontroller. You
already have a reset circuit for this microcontroller so why would you add yet
another one to reset the EM Module? You can connect an unused I/O pin of the x51
to the RST pin of the EM. On startup the x51 will receive a proper reset from the
reset circuit and its I/O pins will be in the HIGH state. This will provide a reliable
reset to the EM. You can modify the code of your main microcontroller to switch the
"reset" I/O pin to LOW after a delay of, say, 100ms.
We recommend you to use this "CPU-controlled reset" approach whenever possible.
Not only it lowers your cost (no need for an extra reset IC) but also gives your
Application Notes
403
main CPU the ability to reset the EM Module at any time. This, as we will show
later, can come very handy if you want to enable your CPU to program the settings
of the EM and/or upgrade its internal firmware. Of course, it is not always possible
to control the reset from the main CPU (no spare I/O lines may be available, it may
be impossible to modify the firmware of the main CPU, etc.). In this case just go
with a proper reset IC.
Provide status LEDs, prog/init button, and serial access connector
Note: part about LEDs applies to all Modules except EM202 which has all status
LEDs built-in.
Tibbo EM Modules have four LEDs control lines (ER, EG, SR, SG). We strongly
recommend you to provide these LEDs on your board. Not having them leaves you
"blind". Supposing, the EM in your device is not working as expected. If you have
those LEDs then you can solve the problem much easier. SR and SG LEDs display
many different signal patterns so one glance at them can tell you a lot about the
current EM status. ER and EG LEDs tell you about the Ethernet connection, which is
also important.
Ideally, you should make those LEDs visible from the outside (left figure). This way
your Users can also see them. If this is impossible then at least provide these LEDs
on your board so they can be observed when your device's cover is removed (right
figure).
404
By providing the jumpers you are leaving a back-door access to the EM AND to the
serial port of your main CPU. This may prove very useful during repairs, field
service, etc. One final note: if you thing that jumpers are too unreliable or you
simply don't have enough space for them on the board then you can use solder
jumpers instead.
Let your main CPU control the Module...
One other important suggestion: let your main CPU control the EM Module. Under
"control" we understand the following: (1) ability to reset (restart) the EM at any
time, (2) ability to program the EM, (3) ability to upgrade internal firmware of the
EM. Implementing this is optional but so easy to do that there is no real reason
why you shouldn't (if you can). True, the EM doesn't have to be programmed
through the serial port, you can do all the programming through the network using
the DS Manager. But this is not always consistent with the rest of your device's
features.
Here is an example: your device has an LCD screen and a keypad and there is a
setup mode that allows you to set all the functioning parameters (time, date, etc.).
To be consistent, you should include EM-related settings into this onscreen setup
as well (for example, IP-address of the device). For this, you must provide a way
for your main CPU to put the EM into a serial programming mode.
Another possibility is to have the main CPU upgrade the firmware of the EM. Again,
EM Module can be upgraded through the network using the DS Manager, and in
those few cases when the network upgrade is not possible you can just use the
"plug-in cable" method described in the previous section. Still, it is much more
"neat" if the firmware can be upgraded by your main CPU itself. We have had a
case in which the EM was used in a terminal device that also was
field-upgradeable. Our Customer has implemented a system, under which the
upgrade file for the main CPU contained the firmware of the EM as well (EM
firmware file was merged into the firmware file of this "host" device). After the
terminal was loaded with the new firmware it automatically initialized itself and
also downloaded the new firmware into the EM! This gave the Users an overall
feeling of "one-ness" of the device they use.
Application Notes
405
To achieve all this flexibility you only need to have your main CPU control two
extra lines: RST and MD (because TX and RX lines are already there, right?). We
have already discussed how to connect the RST line. MD line is connected in this
same fashion. So, you only need two extra CPU I/O lines.
Note, that we still recommend you to provide all the bits and pieces that we have
suggested in the previous section. This means that we suggest you to have the MD
line of the EM connected to your main CPU and the setup button at the same time.
Many CPUs and microcontrollers have the I/O pins that allow them to be driven low
externally and high internally at the same time (for example, the x51
microcontroller is like that). In this case you can simply parallel the CPU output
and the setup button (Fig. 4a). If this is not permissible you can use two (Shottky)
diodes to separate the I/O pin from the button (Fig. 4b).
In some cases it is not possible, of course, to have the main CPU control the RST
and MD lines. You may have no spare I/O pins or interconnection between PCBs in
your device may have no spare wires to carry RST and MD signals. In this case you
won't be able to put the EM into the firmware upgrade mode but you can still have
your main CPU program the EM's settings whenever necessary. There is an
alternative method (two methods, actually) of putting the EM into the serial
programming mode- by sending a so-called escape sequence.
The only complication is that appropriate escape sequence must be enabled for this
to work. This is defined by the Soft Entry (SE) setting, which defaults to the
post-initialization value of 0 (escape sequence disabled). Yes, you can manually
enable this by using the DS Manager but if the EM gets initialized the escape
sequence will stop working and you will have to manually edit the SE setting
again!
To avoid this situation you can define your own post-initialization setting values.
Instead of going with the factory default of 0(disabled), you can choose to have the
EM default to 1 or 2 (escape sequence type1 or type2). Our Application Note 1
("Customization options in our Products") explains how to do this.
...Or let the EM Module control your main CPU
And here is a complete reversal of the idea: sometimes it may be better to have
the EM Module control the main CPU in your device. We have had a case in which
an EM100 was used in a very simple serial machine. This machine also had a
firmware upgrade feature. The User had to press a special button, then power the
device up and upload the firmware through the serial port. After we have added
the EM100 the serial port of the device was connected to the serial port of the
EM100. Of course, new firmware could be loaded into the device through the
EM100 (hence, through the network) as well. This could have allowed for the
remote firmware upgrades if it wouldn't have been for a small problem- the
"upgrade" button still had to be pressed on the machine itself- and this killed the
whole "remote upgradeability" idea.
To solve this we have connected the download line of the device's main CPU to a
general-purpose I/O pin of the EM100. By remotely controlling the state if this I/O
406
Application Notes
407
the DS is trying to "re-connect" after an abrupt reboot (i.e. due to power loss). This
Application Note explains why this happens and what can be done to counter the
problem.
Contents:
- How connection delay happens
- Using "connect immediately" mode to let the DS handle reconnects
- Using modem commands and DTR line to monitor connection status and repair
connections
How connection delay happens
Connection delay problem is related to how "TCP stack" on the PC handles existing
TCP connections. We will explain this on the example of one frequent
communications scenario:
The DS establishes a TCP connection to the PC (for example, because it has
some serial data to send). Connection is accepted immediately. PC identifies this
connection by a combination of three parameters: remote host's IP (i.e.
IP-address of the DS), remote host's port (i.e. port number on the DS from which
this connection was established- 10001 by default), and local port on the PC to
which this connection was established (i.e. "listening" port of your application or
VSP).
The DS suddenly reboots, for instance due to power loss. Your PC doesn't know
about this so it thinks that this TCP connection is still alive.
The DS is powered on again and makes an attempt to connect to the PC. Once
again, it tries to open a connection from port 10001. PC responds with "ACK", as
if this was a regular data packet. Basically, PC just ignores this connection
attempt. Long time needs to pass before PC realizes that this connection is dead
already.
The DS notices that the PC did not respond to the connection request and sends
"RST" packet to reset the connection. At the same time, the DS discards the data
it was going to send to the PC and goes to "IDLE" state.
When new serial data is received by the DS the latter makes another attempt to
make a connection. This time the source port on the DS is 10002, not 10001.
This is because source port from which the DS is establishing its TCP connection
is incrementing with each connection attempt (this is normal, PC does this too).
PC gets this new connection attempt and treats it as a completely new
connection. This is because in the unique combination of source IP + source port
+ destination port something is now different: the source port number has
changed. Because of this, PC accepts this new connection immediately.
The following network log made by WinDUMP sniffer software illustrates the above
scenario. The DS is at 192.168.100.97 and the PC is at 192.168.100.90.
==========
*** DS makes an attempt to connect to the PC ***
192.168.100.97.10001 > 192.168.100.90.1002: S 640000:640000(0) win 1024
<mss 255> (DF)
192.168.100.90.1002 > 192.168.100.97.10001: S 10461646:10461646(0) ack
640001 win 8415 <mss 1460> (DF)
192.168.100.97.10001 > 192.168.100.90.1002: . ack 1 win 1024 (DF)
408
Application Notes
409
c flag is unexpectedly returns to "*" then your serial device can conclude that the
DS has returned to idle mode because the PC did not respond to the connection
establishment request.
Then, the serial device can quickly issue another Establish Connection (CE)
instruction and, again, monitor connection status via Echo (X) command.
After the Echo command shows that connection is established (c flag="C") the
serial device uses Logout (O) command to make the DS exit the serial
programming mode. Data exchange can start after that.
The above procedure, although seemingly lengthy, takes only a fraction of a
second to complete.
One remaining question is: how to detect that connection has been broken while
being in the "normal mode". Indeed, when the DS in the serial programming mode
connection status can be verified at any time through an Echo command. But
how to do this when the DS is in the data mode and Echo command cannot be
issued?
This is done by programming the DTR Mode (DM) setting to 1 (connection
status). In this case the DTR line of the DS shows whether network connection is
established or not. Once the line is "dropped" the serial device will know that
something has happened to the connection. At this time the serial device should
force the DS into the serial programming mode and use modem commands to
"repair" the connection.
410
Application Notes
411
You probably know that every DS model we manufacture contains some number of
lines that can be used as remote I/O. For example, the serial port of our DS100R
Serial Device Server contains RTS (output) and CTS (input) serial lines. From the
serial port's standpoint, RTS and CTS have a specific serial port-related function
but at the same time they can be used as generic output and input!
Other "external" Serial Device Servers, such as DS100B and DS202 also have DTR
(output) and DSR (input) lines. Together with RTS/CTS, this brings the total
number of available lines to two outputs and two inputs.
Most embedded Modules such as EM100 and EM200 have even larger number of
I/O lines, some of which are not related to the standard serial port control lines in
any way. For example, in addition to RTS, CTS, DTR, and DSR the EM200 has five
additional I/O lines- P0, P1, P6, P7, P8. All 9 lines can be used as universal
inputs/outputs- on the Module level there are no dedicated "input only" or "output
only" pins*.
Controlling I/O lines through a Virtual Serial Port
The simplest way to control I/O lines of the DS is through a Virtual Serial Port.
Naturally, this will be limited to setting the status of RTS and DTR lines and
sensing the status of CTS and DSR lines. Extra lines such as P0, P1, etc. cannot be
controlled this way. Additionally, RTS/DTR will only work as outputs and CTS/DSRas inputs, even on embedded Modules whose I/O pins are bi-directional (see
above). The advantage of using VSP is in simplicity- you don't need to write a lot of
additional code.
To test how VSP works with I/O lines of the DS you can create a simple application
in Visual Basic. Use MSComm ActiveX control to work with the VSP. Remember,
that same rules that apply to a regular COM port of the PC also apply to the remote
control of the serial port on the DS:
If you want to set RTS and sense CTS you need to set
MSComm.Handshaking="None". If you set handshaking to "ComRTS" your
VB program won't be able to work with RTS/CTS directly.
After you set MSComm.Handshaking="None" you can control RTS through
MSComm.RTSEnable and sense CTS state through MSComm.CTSHolding.
Likewise, DTR state can be controlled through MSComm.DTREnable while DSR
state can be sensed through MSComm.DSRHolding.
To be able to control DTR remotely, you need to program the DTR Mode (DT)
setting of the DS to 0 (idle). Also, to have the DSR work as a pure input line
program do not set Connection Mode (CM) to 3 (on command or DSR=HI).
These two settings will be taken care of automatically by the Connection Wizard
when you use it as described below.
Before you can make this test you need to have a proper setup for the VSP and DS.
Run Connection Wizard and make the following choices. Important points:
Job: choose to create a link between the Virtual Serial Port and the Device
Server.
Initiator of data exchange: Virtual Serial Port.
On-the-fly commands: yes, enable on-the-fly commands, use out-of-band access
method.
(all remaining choices are obvious or irrelevant).
After the Wizard has done its job and is at the last screen you need to do the
412
As you can see from this log, an individual command is sent from the VSP to the
DS when it is necessary to change the state of a particular output. A notification
containing the status of both inputs are sent from the DS to the VSP when at least
one of the inputs (DSR or DTR) is found to have changed the state. Notifications
are explained below (see "using notifications to get the status of I/O lines").
Setting and sensing the status of I/O lines using on-the-fly commands
Virtual Serial Port works with RTS, CTS, DTR, and DSR lines using so-called
on-the-fly commands. On-the-fly commands are officially known as "network-side
parameters and instructions". As the name implies, these commands are sent
through the network. The word "on-the-fly" refers to the fact the sending any
command causes an immediate corresponding change in the serial port or I/O pin
of the DS.
Related to the discussion of controlling I/O lines are two instructions:
Set I/O Pin Status (Sx) instruction
Get I/O Pin Status (Gx) instriction
For these instructions to work, the DS must be preset to accept them. This is done
by setting On-the-fly Commands (RC) setting to 1 (enabled).
On-the-fly commands are send just like all other network programming commands
which means that delivery method can be out-of-band, inband, etc. Out-of-band
on-the-fly commands can be optionally password-protected by programming
On-the-fly Commands (RC) setting to 1 (enabled) and defining a password in
the Password (PW) setting.
If you are planning to work with P2(DSR), P3(DTR), P4(CTS), or P5(RTS) lines you
need to disable their "special" functions to turn them into "pure" I/O lines. When
Application Notes
413
414
This message means that Windows Firewall has detected certain network activity
that is currently not allowed. Application name is "Run DLL as an App" and, believe
it or not, this is how Windows sees the DS Manager (yes, DS Manager is a "DLL"
but Windows should be smart enough to understand its "real name".... alas, it isn't
that smart). Click Unblock and the DS Manager will be able to auto-discover local
Device Servers again.
If, when you run the DS Manager (click Refresh), the warning is not displayed (and
the DS Manager is still unable to find Device Servers) then this may be because
the Firewall is not allowing "exceptions" and/or firewall notifications are not
enabled.
Run the Firewall (Start--> Control Panel--> Windows Firewall) and make sure that
Don't allow exceptions checkbox is unchecked (clear):
Application Notes
415
Next, click on the Exceptions tab and make sure that Display a notification when
Windows Firewall blocks a program checkbox is checked:
After you "unblock" the DS Manager the Firewall puts it into the list of "exceptions"
i.e. programs whose traffic is allowed to pass through the Firewall:
416
Input any meaningful name into the Name textbox (i.e. "DSMan bcast"- this is
because what we are opening here is a port for DS Manager's auto-discovery
broadcasts to work). In the Port number textbox input 65534- this is the port
number that must be opened on your PC. Finally, select UDP- this is a protocol the
DS Manager is using to find Device Servers on the network. Click OK when
finished.
New entry will appear in the list of exceptions and the DS Manager will start
working properly:
Application Notes
417
418
Notice, that you only need to open ports if your DS is going to connect to your PC.
If it is the VSP (or application) on your PC that is going to connect to the DS then
you don't need to setup the Firewall. This is because the Firewall doesn't block any
connections that originate from within the PC.
Application Notes
419
The Device Servers connect to port 6450, which is the default LinkServer login port
for Device Servers. The remote host connects to port 50002, which is one of the
ports assigned to Device Servers within the LinkServer, so it actually reaches a
Device Server through this connection (via the LinkServer).
Notice that no port forwarding has to be set up for the AuthKey --the AuthKey
communicates directly with the host running the LinkServer, and does not need
direct communication with the outside world.
420
Application Notes
421
Extract the file -- it contains a BIN file (firmware) and a README. Note the
location of the BIN file.
Run DS Manager.
Under Access Mode, select Device Servers attached to the COM port.
Click Upgrade.
Select the BIN file.
422
Now press the SETUP button on the DS202. After pressing the button, connect
the power cable.
The firmware will start transferring over to the DS202, and you will see a
progress bar.
Once you get a message that the process is done, disconnect the DS202 from
the power.
Power the DS202 again. Wait for a few seconds. Now you have to initialize it by
Application Notes
423
Quick Initialization -- press the setup button, release it, and then press it again
for 4 seconds.
That's it! Don't forget to set an IP address for the AuthKey, and you're ready to
move on.
The first thing you should do is configure the AuthKey. Without a properly
configured AuthKey, your Device Servers will not be able to connect to the server.
Perform the following:
In the top bar, click Administration.
Under Administration, click Global configuration.
Go to the bottom of the screen, and find the section titled AuthKey settings:
424
Adding a DS as User
Before a Device Server can communicate with the LinkServer, it must be registered
with the LinkServer. There are two ways to register a DS: Automatically and
manually. For our purposes, we will use the manual method:
Before you begin, make sure you're logged on as the user you've created in the
previous step. In our examples, this user will be called johndoe.
Once logged on as johndoe, click Device Servers in the top bar.
Next, click "Add Device Server" (Also on the top bar, one line below the main
commands).
The Device Server Info screen will appear:
Select a name for the Device Server which you will be able to easily recognize in
the list. Note down this name for later.
Select a password you will remember (for our example, this is Vlf6Lr!). It has to
be at least 4 characters long. Remember this password, as you will need it in the
next step (Configuring a Device Server).
Leave the other entries at their default values.
Application Notes
425
Click Save.
You will now find yourself back at the Device Servers page, and your device will
show up on the list. Note down the number under the port column. You will
need it for later (for Configuring a Virtual Serial Port).
Set Owner name to the same name as your account in the previous step (Adding
a DS as User). In our example, this is johndoe.
Set Device name to the same name as your Device Server in the previous step.
In our example, this is dev1.
Don't forget to make sure your Device Server has a valid IP -- by enabling DHCP,
or setting a valid IP address manually.
Set Gateway IP-address to the correct gateway for your subnet, so the Device
Server could get reach the LinkServer (assuming the LinkServer is not on the
local subnet).
Click the Password button and set a password for the DS. This has to be the
same password you configured for it in the previous step. In our example, this is
Vlf6Lr!.
Now, click the Connection tab:
426
Application Notes
427
Set the serial settings according to your device (RTS/CTS flow control, DTR
mode, Baud rate, Parity, Data bits)
Set On-the-Fly commands to Disabled.
Click OK to apply the settings and close the dialog.
DS Manager will reset the Device Server.
Assuming you did everything correctly up to here (including all previous steps),
the DS should now blink the green LED a few times and then light it steadily.
This means that a connection has been established. If you get another LED
pattern, find out what it is under Status LED Signals and try to troubleshoot it
from there.
If you now log-on to your account in the LinkServer, you will see the Device
Server as Online under Device Servers.
428
On the PC where you have configured the Virtual Serial Port, run HyperTerminal.
Do this by clicking Start > Programs > Accessories > Communication >
HyperTerminal.
Choose a name for the connection.
in the next screen, under "connect using", select the Virtual Serial Port you have
created (such as COM6).
On the next screen select any serial settings you would like, but make sure Flow
Control is set to None.
Click OK. You should now get a white screen where you can type:
Application Notes
429
Type any text on the keyboard. You should see it on-screen now. If you see what
you type, it means that the following sequence happens:
The HyperTerminal session sends the data to the Virtual Serial Port.
The Virtual Serial Port sends the data to the LinkServer.
The LinkServer sends the data to the Device Server.
The DS gets the data and immediately sends it back (using the loopback
we created in the beginning of this step).
The LinkServer gets the data from the DS and sends it back to the host
running HyperTerminal.
The Virtual Serial Port gets the data back, and passes it to HyperTerminal.
You see the data you type on-screen.
The simplest way to make sure that this is really what happens, is to remove the
loopback from the DS. You will continue sending data but you will not get anything
back -- this means it worked!
430
Basically, HyperTerminal lets you type characters (or send files in specific
protocols) from your computer, which is acting as a TERMINAL (computer
originating or receiving communications), to another computer or device (such as a
DS100) which is connected to it.
Communication Methods
The 'classic' use of a terminal program is for serial communications. And indeed,
the 'natural' use of HyperTerminal is for serial communications, and it is best
suited for this purpose. However, with time, HyperTerminal was greatly extended,
and today allows also for TCP/IP communication (telnet) in addition to serial and
modem communication.
Think of the TCP/IP mode as 'extended functionality'. Any instructions in this
Application Note which relate to this mode of communication, can also be
performed using any regular telnet program. They do not utilize any 'special'
capabilities of HyperTerminal -- it just serves as a generic telnet program.
The following diagram illustrates the typical two uses of HyperTerminal in relation
to Device Servers. We have a workstation, running HyperTerminal. HyperTerminal
is used to communicate with a nearby DS202 over a serial cable, and it can also be
used to communicate, through a firewall, with a remote DS100 which is connected
to the Internet and has a serial Barcode reader attached to it (the user can even
access the output of the Barcode reader using HyperTerminal with this
configuration).
Application Notes
431
One very important thing to note about HyperTerminal is that you do not
see what you type on the screen. What you type is sent to the other end
of the line, and the screen is used to show incoming data from the other
end of the line -- i.e, you only see the replies you get (if you're getting
any replies).
However, this default behaviour can be changed. The procedure for
changing it is described under Setting Optional Parameters.
432
Running HyperTerminal
There are two common ways to launch HyperTerminal:
Using the Run Dialog:
Click Start.
Select Run.
Type Hypertrm.exe
Press Enter.
Using the Start Menu:
Click Start.
Go to Programs > Accessories > Communications > HyperTerminal
In Windows 2000/XP: HyperTerminal would run.
In Windows 9x (95, 98, etc): A program group called HyperTerminal would open.
Click HyperTrm to run HyperTerminal.
Setting5.8.2.1
Correct Parameters on Startup
If this is the first time you're running HyperTerminal, Windows will ask several
questions regarding your location. Your answers are later used for modem
connections -- these settings aren't necessary for direct serial or TCP/IP
communication (the types of communication used for the Device Server).
After answering the questions regarding location (or if the location is already
configured), you might get the following dialog:
As covered above, HyperTerminal can be used for telnet communications, and can
also be the system default for telnet communication (i.e, the program which the
system runs by default whenever telnet is needed). This setting, too, isn't vital to
our purposes. Select whichever setting seems appropriate to you.
Application Notes
433
The next dialog is often the first dialog, in systems which are already configured. It
is titled Connection Description, and looks like this:
Here you can select a descriptive name for your connection (such as "To DS100"),
and also an icon for the connection. Select these settings and click OK.
The next dialog, Connect To, is used to configure the communication method and
destination for this connection:
434
Establishing
5.8.2.2a Serial Connection with a Device Server
This section covers connecting the Device Server serially to the computer, using a
cable, and configuring HyperTerminal to connect to it.
Selecting The Correct Cable
The cable used for direct serial communication with the Device Server should be a
cross cable. This means pin #2 goes to pin #3 on the other end. And #3 goes to
#2, and #7 goes to #8, and #8 goes to #7:
Like so. Both of the connectors for this cable should be "female". Tibbo makes
exactly such a cable, called WAS-P0005(B) DS-to-PC Serial Cable.
Configuring HyperTerminal
After connecting the proper cable to the Device Server and to your computer, it's
time to continue configuring HyperTerminal. We continue from where we left off
on Setting Correct Parameters on Startup. In the next window, open the Connect
using drop-down, and select COM1 (assuming you connected the DS to COM1):
The next screen deals with serial settings. Here you have to select the correct
serial parameters.
What are the correct serial parameters?
When talking about correct serial parameters, it is important to understand two
things:
Application Notes
435
1) If you would like to program the DS serially, the correct settings are 38400,
8, N, 1 (like in the screenshot below). These are the correct settings for the Serial
Programming method.
2) If you would like to simply communicate using the DS, the correct settings
are those which were configured using the DS Manager or Connection Wizard for
this DS. They can be 38400, 8, N, 1 but they can also be different.
After setting the correct parameters, click OK. That's it! You've now established a
serial connection with the DS100. Continue on to Sending Commands To the
Device Server or Using HyperTerminal to Test a Connection.
Establishing
5.8.2.3a Connection Through a Virtual Serial Port
In this section, you will see how to create a Virtual Serial Port using the Connection
Wizard, associate it with a DS, and then connect to it using HyperTerminal.
Click Start > Programs > Tibbo > Connection Wizard:
436
Click Next.
Select Create a link between a Virtual Serial Port and a Device Server. Click Next.
Application Notes
Select Create new VSP and select the Port name. Remember what port you
created, you will need it for later. Click next.
437
438
Select the DS you would like to work with. If its IP address is invalid (it says so
on the status bar), click Change IP.
Having made sure the IP of the device is correct, select the DS in the list, click
Select to go back to the Wizard, and click Next.
Application Notes
439
Select TCP/IP transport protocol. Don't change the port, but remember it's 1001.
You'll need this for later.
440
Application Notes
441
The next screen deals with serial settings. Here you have to select the correct
serial parameters. In this case it's not so important what you choose, but keep in
mind the following:
If you're going to connect a serial device for testing with HyperTerminal, of
course the settings you choose here much be compatible with this device.
If you are going to perform a loopback test, set Flow control to None:
After setting the desired parameters, click OK. That's it! You've now established a
connection with the DS100 via the Virtual Serial Port. Continue on to Using
HyperTerminal to Test a Connection.
Establishing
5.8.2.4a TCP/IP Connection with a Device Server
Setting up the Device Server for TCP/IP Communication
The simplest and most reliable way to set the DS up for TCP/IP communication is
using the Connection Wizard.
Click Start > Programs > Tibbo > Connection Wizard:
442
Click Next.
Application Notes
443
Select the DS you would like to work with. If its IP address is invalid (it says so
on the status bar), click Change IP.
444
Having made sure the IP of the device is correct, select the DS in the list, click
Select to go back to the Wizard, and click Next.
Application Notes
445
Select TCP/IP transport protocol. Don't change the port, but remember it's 1001.
You'll need this for later.
Set whatever serial parameters you need. Just remember what you set here, as
you might need it for later (or for Establishing a Serial Connection with a Device
Server). If you are going to perform a loopback test, set RTS/CTS flow control to
Disabled or remote.
446
Next, enter the IP address and the port number we got earlier from the DS
Manager:
Application Notes
447
Setting5.8.2.5
Optional Parameters
Having established the connection, you may now configure HyperTerminal so that
it would display the characters you are typing, and also add automatic line feed
characters (i.e, move one line down) whenever necessary, to make the
communication easier to read.
This is also useful for making sure you're sending the correct commands.
Otherwise, when the DS returns an error code, you may be left wondering what
went wrong. Enabling a local echo of sent commands will show you exactly what
the DS received just before it returned an error code.
To enable local echo, perform the following steps:
After establishing a connection (as described in the previous sections), go to File
> Properties:
448
In the ASCII Setup dialog, mark the options Send line ends with line feeds, Echo
typed characters locally and Append line feeds to incoming line ends:
Press OK to confirm all of the different dialogs, until you reach the main screen
again.
You can also save your current configuration, so that next time you wouldn't
have to set it up again. Do this by clicking File > Save. Next time, run
HyperTerminal using the file created by the saving process (it is named after
your current session name -- TestConnection in our example).
Application Notes
449
Two HyperTerminal
Windows, one DS
5.8.3.1
Here, we will connect one DS to a computer, using two separate cables; Thus, both
ports of the DS (LAN and serial) will be connected to their respective ports on the
computer. Follow these steps:
Take a Device Server. If it's a model capable of several serial protocols (such as
the DS100-B, who is also RS422/RS485 capable), make sure it's set to RS232.
Power it on.
Take a serial cable and follow the steps described in Establishing a Serial
Connection with a Device Server. Return to this section once done.
Now, connect the same Device Server to the same computer using a cross LAN
cable, or to the network segment the computer currently belongs to (using a
straight cable to a hub, etc).
Follow the steps described in Establishing a TCP/IP Connection with a Device
Server or in Establishing a Connection Through a Virtual Serial Port. Return to
this section once done.
That's it! Now, whatever you type in the window connected to the serial end, will
show up in the window connected to the network end. And vice versa. If you can
see this, you've performed all of the above correctly!
Creating
a Loopback for Testing
5.8.3.2
A loopback connection is one where the signal being sent also comes back to the
sender -- similar to an echo. This allows you to test a line (including the devices on
it) to verify its correct operation.
Creating a loopback with a Device Server is rather simple. You just have to make
sure you're working on RS232 (if your Device Server is also capable of other serial
protocols) and connect serial pin #3 (TX, output) to serial pin #2 (RX, input), like
so:
450
Sending
a Command (Command Format)
5.8.4.1
Now is the time to really get down to business. How do you actually send a
command? Well, there are two major things you have to know:
Basic Command Format
The basic format for a command is:
STX
Command/reply
CR
<STX> means "Start of Text". This character sometimes looks like a small
smiley. To create it, press CTRL+B
on your keyboard.
<CR> means "Carriage Return" -- or, simply put, this is what the Enter key on
your keyboard usually does. The create it, just hit Enter after typing the
command.
Logging In
Sometimes you have to be logged in to the Device Server in order to send the
Application Notes
451
command. This is done by first making sure the Device Server is listening (i.e, is in
a programming mode, like the ones described below) and then sending the Login
(L) command command as the first one.
To know when exactly you have to be logged on (for what commands), see the L
column of this table.
Logging Out
Programming methods which require you to log in will also require you to log out.
This is done using the Logout (O) command as the last command in your
programming session.
Serial Programming
5.8.4.2
There are two major method to get to serial programming mode. The main
difference is that in one of them you need to press the RESET button (that's the
whole method, basically) and in the other one, you need to send a string of
characters.
The first method is used for troubleshooting and testing (similar to what we are
doing here), and the second method is used by 'smart' RS232 devices, to control
the Device Server. Both methods are documented in detail here.
This is the procedure for using the "regular" method of pressing the button:
Perform the instructions under Establishing a Serial Connection with a Device
Server. Select 38400, 8 bit, no parity.
Press the SETUP button.
The LEDs should start alternately blinking (green and red).
Go to the Programming Exercise and start programming the device.
To know all there is to know about serial programming, please read Serial
Programming in the full manual.
Serial Parameters
(Modem Commands)
5.8.4.3
Modem commands are used to control the DS from the serial side. If your serial
device is 'smart', it could change the destination address or port, or establish a
connection, etc, from the serial side.
To Test Modem Commands Using HyperTerminal
Run DS Manager and open the settings dialog for the DS to which you wish to
connect, and switch to the 'Serial Port' tab:
452
Application Notes
453
454
Telnet Programming
5.8.4.4
This method of programming is enabled only for firmware version 3.51 and up,
which runs on Tibbo second-generation devices, such as EM120, EM200, EM202,
and DS202.
To enter telnet programming, establish a connection using HyperTerminal to the IP
address of the device, but to port 23. Once the connection is established, you are
in Telnet Programming mode. Perform the following steps:
Send the first command, to login. As with all commands, you will not see what
you send, but only what you receive:
Hit Ctrl+B.
Type L (capital L -- type l while pressing SHIFT
)
Hit Enter.
You should get an STX (Smiley) and A. This means you are now logged on. It
Application Notes
looks like this:
455
Command-Phase
5.8.4.5 TCP
This is considered to be an advanced method, and is slightly more complex
than the others. Usually there is no need for command-phase TCP
programming. This example merely illustrates the capabilities of this mode
-- do not feel compelled to try it, if you have no use for this feature in your
actual environment.
In command-phase programming, every network communication session starts
with a programming session. So, to actually get to your device and start
communicating with it, you would have to send the Logout (O) command first.
And to be able to send this command (and log out), you would first have to be
logged in. This is accomplished using the Login (L) command.
Now, to actually test this method of programming, do the following:
Run DS Manager.
Open the settings for the DS you want to configure.
Make sure its IP address is valid for your network, and note it down for later.
Switch to the Connection tab.
Make sure Transport protocol is TCP and that Routing Mode is Server (Slave).
Set Data login to Enabled. Both of these settings can be seen below:
456
Programming
5.8.4.6 Exercise
If at any time during this procedure you get a D reply (looks like
need to login again. Just send the Login (L) command again, as
described here.
) you
We are assuming you are already connected to the device server (and also logged
on, if your connection method requires logging on). If this isn't so, please read the
previous sections and create a working connection first.
Getting the IP Address
Send the second command, to get the current IP address of the Device Server:
Hit Ctrl+B.
Type GIP(In caps. This is the Get (G) command with the IP-address (IP)
setting as an argument).
Hit Enter.
You should get an STX character, A, and the current IP address, like this:
Application Notes
457
Type SFC0
(Set (S) command with the Flow Control (FC) setting as an
argument, 0 = disabled).
Hit Enter.
You should get an STX character and A.
Now let's check again the Flow Control (FC) setting to see if it is indeed
disabled:
Hit Ctrl+B.
Type GFC
.
Hit Enter.
You should get an STX char, an A(ack) and 0 (i.e, flow control is disabled).
Logging Out
The last thing we will do is log out of the programming session:
Hit Ctrl+B.
Type O(Logout (O) command).
Hit Enter.
You will not see anything sent back to you, because the session has just
ended.
That's it. You've now successfully performed a demo programming session. Well
done!
458
What Is a WAN
A WAN is, quite simply, a network which covers a large geographical area. It
connects several physically remote locations one to the other.
The simplest way to think of a WAN is by thinking of a wide area network we
already know: The public telephone system. When you think about it, the
telephone system we all know and use in our day-to-day life is simply one huge
network, connecting remote geographical locations. I.e, it is a Wide Area Network!
Since this analogy is so simple yet relatively accurate, we will use the phone
system as an analogy throughout this text. Let us first begin with two diagrams,
showing the telephone network next to a computer WAN (notice the similarities).
The Phone System:
The term PBX stands for Private Branch eXchange. It is the internal phone
system of a business. In our diagrams, we refer to the "brain" of the system
(the main box from which all lines come out) as the PBX, but in fact, the
whole system (including the extensions) can also be called a PBX.
A Wide Area Network:
Application Notes
459
There is actually another common type of WAN that we all know to some
degree -- the Internet. However, the inner workings of the Internet may be
unfamiliar to readers who are not already proficient in networking, and so,
we will not use the Internet to explain WAN concepts here.
However, rest assured that once you are done reading this text, you will
have a much better grasp of the inner workings of the Internet, as well.
What Is a LAN
A LAN is a Local Area Network. This is a network which exists in one specific
location, and is relatively small. You can think of a LAN like you think of the
internal phone system of an office. Every employee has an extension, but it is only
an internal extension -- it is not a "real" phone line which is connected only to his
own phone. To call from one extension within the office to another extension, you
only have to dial two or three digits -- it is an "internal" call. It does not go
through the public telephone system, and it will actually work even if the office
has no external phone lines at all.
This is exactly the same also for a LAN. To get from one computer on a LAN to
another computer on the same LAN, you do not have to go through any other
network. It is a private network.
Below, you can see what is a LAN, in relation to a WAN (as previously explained):
There are certain types of communication which are unique to a LAN. One such
type is called 'broadcast' communication. This is where one node (station, host,
computer) on the LAN 'shouts out' so that all other nodes hear the message. This is
similar to pressing the 'announcement' button on an office telephone, and using all
the phones connected to the system to broadcast a message to all employees
(through the speaker of the phone).
Naturally, such a feature would not be practical with the national telephone
system. The system would simply collapse. The same is true for broadcast requests
in a computer network -- they work only on a LAN, and will not go out to the whole
WAN.
460
Subnets
In the phone system, we have one large network, spanning a whole country. We
could also say that this network is subdivided into smaller, sub-networks -- one for
each city, approximately.
So, when we have several phone numbers, how can we tell if they are from the
same geographical area, or sub-network? We get this information from the area
code. When we have two numbers, such as (323) 337-5578 and (323) 823-8461,
we can immediately tell they're both from the same town, or from the same part of
the country.
The same goes for IP addresses, but with a slight twist.
Every IP address is composed of two parts -- The network identifier and the host
identifier. The network identifier is the left side of the address. For instance, in the
address 192.168.0.1, the first three octets (parts) are the network identifier. So,
the addresses for all hosts (computers) on the same network will start with
192.168.0.x.
This can be referred to as a subnet. A subnet is a portion of a network which
shares a common network identifier. So, all computers which are (A) on the same
network (physically interconnected) and (B) whose addresses start with the same
host identifier, belong to the same subnet. Just like (323) 337-5578 and (323)
823-8461 belong to the same area code, so do 192.168.0.1 and 192.168.0.72
belong to the same subnet.
How Many Hosts Can a Subnet Contain?
With a local telephone number, we can quite easily tell the theoretical limit. If we
have 7 unique digits per phone number (excluding the area code, which is shared
by all numbers), we can theoretically have up to 9,999,999 phone numbers in the
same area code.
Of course this isn't accurate -- if we have emergency numbers such as
911, we lose significant portions of this range. You cannot have any
number which starts with the digits 911 -- so you lose 9,999 potential
numbers, which now cannot be assigned.
With IP addresses, the limitation is slightly different. Each octet in an IP address
can range from 0 to 255. This is because an octet is composed of 8 bits. In binary
notation, 8 bits can be any combination between 00000000 and 11111111. When
you convert these values to decimal notation, 00000000 remains 0 (naturally), and
11111111 equals 255. Hence, our range -- 0 to 255 per octet.
So, if we selected a network identifier composed of 3 octets -- such as 192.168.0.x
-- we have just one octet left for the host identifier. The host identifier must be
unique for each host on the network. This means we can have up to 256 hosts per
each such subnet.
What if we want to have more than 256 hosts in our subnet? In this case, we must
use a network identifier which is composed of less octets. If we use only the first
two octets as the network identifier, and use the last two octets as the host
identifier, we can have up to 65,536 hosts on the same subnet.
Subnet Masks
Application Notes
461
Subnet masks are used to denote which part of the IP address is designated as the
network identifier and which part is designated as the host identifier.
A typical subnet mask is 255.255.255.0. This means the first three octets contain
the network identifier and the last octet contains the host identifier.
For the purposes of this application note, what you need to know is that in a
subnet mask, when an octet contains the number 255, that octet is supposed to
contain a portion of the network identifier. When an octet contains a 0 in a subnet
mask, then that octet is supposed to contain a portion of the host identifier.
It may happen that an octet in a subnet mask will contain a number
which is somewhere between 0 and 255 (such as 224). This is relatively
rare, and further limits the number of available addresses in the subnet.
However, this is beyond the scope of this application note.
The following table lists the most common subnet masks, along with their names
and number of hosts available for each subnet mask.
Subnet Mask
255.0.0.0
255.255.0.0
255.255.255.0
Number of Hosts
16,777,216
65,536
256
Network Designation
Class A Network
Class B Network
Class C Network
462
Start Address
End Address
192.168.0.0
172.166.0.0
10.0.0.0
192.168.255.255
172.31.255.255
10.255.255.255
Number of Individual
IP Addresses
65,536
1,048,576
16,777,216
External Addresses
The term external address refers to an IP address which is not restricted to the
local LAN. This is an address which can be reached from all parts of the WAN. It is
sometimes also called a "real" IP address -- as it is not an internal address, but is
leased and officially assigned to one specific host on the WAN (this assignment
may not be permanent, but more on that in the next section).
You can think of the external address like an actual phone number -- this is an
address which is used to identify a specific host in the context of the whole WAN,
and not just internally in a LAN. Just like phone numbers, these addresses are
managed and assigned by licensed companies -- you don't just "take" whichever
address you want. They are guaranteed to be unique for every host on the whole
network -- no two hosts will have the same "real" IP address at the same time,
across the whole width and breadth of the Internet (or any other WAN for that
matter).
Application Notes
463
The internet isn't the only place where dynamic IP addresses can be of use. Some
corporations run very large internal networks (whether LANs, in one large
installation, or WANs, connecting several remote places). When you have
thousands of hosts connected to the same network, manually assigning an IP
address for each and every one of them can be quite a hassle. It is also error prone
-- what if you happen to assign the same IP address to two hosts? Or what if you
made a typo?
Thus, dynamic IP addresses are often used also for LANs. Once you perform the
initial setup, the system 'runs itself', and every host gets a correct address
automatically.
The protocol by which a host asks to be assigned an IP address, and gets
that dynamic IP address, is called DHCP, which stands for Dynamic Host C
onfiguration Protocol.
Disadvantages of Dynamic Addresses
So far we've come to see that dynamic IP addresses seem to save quite a lot of
money and manual labor. So -- what could possibly wrong with them?
Let's say you wish to talk to a friend. You both know each other's number, so you
call each other. One day, you get a new mobile phone, and your old number is no
longer valid. Until you let your friend know your new number -- only you can call
him. He won't be able to call you, as he doesn't have your number.
Now, what happens if before you've had a chance to call your friend and let him
know you have a new number, he got a new number as well? Now, neither one of
you can call the other!
That is the main drawback of using dynamic addresses. If the computer you're
trying to reach has an IP address which sometimes changes, you can never be sure
it will be there next time you'll want to access it.
For reliable communication, each connection must have at least one end which is
fixed. The dynamic end of the connection will be able to reach the fixed end. If
both ends are fixed, they will of course be able to freely originate communications
to each other (just like when calling your friend from above).
Static Addresses
As covered above, static addresses are mostly needed for internet servers. When
you need to be able to reach a certain host on the network, that host needs a static
IP address! You need to know where it is, to reach it. Static IP addresses can be
leased from any ISP.
What Is a Gateway
What a Gateway Is and What It Does
"Internal" IP addresses in a LAN are exactly like internal phone extensions in an
office phone system. You can use them to call out, but nobody can reach you
directly from the outside. If someone calls the office and wants to talk to you, one
of two things may happen: (1) the receptionist manually transfers the call to your
extension, or (2) you have a special outside number which is mapped to your
internal extension, so whoever dials the external number is automatically
forwarded to your extension.
464
So, as can be seen above, a gateway has two addresses -- one on each network.
And it can be very easily used for making an outbound connection. But -- what
happens when you want to make an inbound connection?
Application Notes
465
The gateway then modifies the packets, so as to make them appear as if:
It (the gateway) has originated them itself.
The packets come from one specific port in the gateway (and not necessarily
the port from which they originally came). This port is actually mapped to the
LAN host which originally sent the packet. The gateway now knows that
packets arriving to port 30189 (for example) should be forwarded internally to
host 192.168.0.17 and to port 80 (for example).
The gateway sends the packets on their way.
The packets arrive at their remote destination host.
The remote host replies, and directs the reply to the IP address and port of the
router which previously sent the packets.
The router gets the reply (to port 30189 in our example), modifies the packet
and forwards it internally to the host which originally made the outbound
c/connection.
A colon (:) mark at the end of an IP address refers to the port for that
address. So, the designation 64.233.187.107:80 refers to port 80 of the IP
address 64.233.187.107.
Many Hosts Can Originate Outbound Connections
The biggest advantage of using NAT is in limiting the amount of "real" IP addresses
you need. You can have hundreds of computers communicate with various hosts on
the internet, using just one "real" IP address. This translates into significant
466
Application Notes
467
How NAT
Applies To Device Servers
5.9.7.1
This topic adds no new information; It merely provides an explicit demonstration of
what happens when you put a Device Server inside of a LAN, behind a NAT
gateway.
IMPORTANT NOTE: establishing the connection isn't the same as using
the connection!
When one side establishes the connection, both sides can then use it. It
does not mean that only the side who established the connection can now
talk, and that the other side must listen.
Think of it like a phone call -- when you call your friend, both of you can
talk, even though it's you who made the call. This is important.
Establishing an Inbound Connection
An image is worth a thousand words:
As can be seen above, when you have a DS in a LAN, behind a NAT router, you
cannot simply establish a connection from outside. The port isn't mapped
anywhere, so the router drops the packet.
There are three solutions for establishing a connection with a DS which is behind a
NAT router:
Solution 1: The DS Establishes The Connection
Here, the DS initiates the connection. As covered above, there's no problem in
setting up an outbound connection from behind a NAT router. In effect, it looks like
this:
468
Points of attention:
The routing mode for the DS, as configured in Routing Mode (RM) setting,
must be Client Only or Client Or Server.
The destination of the DS, as configured in Destination IP-address (DI)
setting, must be actually reachable from within the NAT. Meaning, it cannot be
behind another NAT router. You need to be able to ping it. See the diagram
above -- the Remote Host can be reached directly and has a "real" IP address.
It is advisable to set the Connection Mode (CM) setting as Immediate (on
Power-up), so that the DS would establish the outgoing connection immediately
when it's turned on.
Solution 2: Use Tibbo LinkServer
The Tibbo LinkServer is a product developed to answer this exact need. What if
both the remote host and the DS (or multiple Device Servers) are behind a NAT
router, and you cannot allow inbound access for either one of them?
In this case, you use a middle man. You need a server in the middle, to which both
the remote host and the DS could reach, and 'meet' there. Such a scenario would
look like this:
This solution is discussed in detail in the LinkServer user manual, under Solution 1:
Link Service. It does require one static IP address, and the purchasing and
configuration of a separate product (The LinkServer).
Solution 3: Configure The Router for Inbound Access
It is possible to configure a NAT router so it would allow certain inbound traffic,
Application Notes
469
and would correctly route it to a host within its LAN. This is done using Port
Forwarding.
Port Forwarding
Port Forwarding is a feature present on many modern routers. In essence, it allows
you to map a certain outside port of the router to a specific address and port in the
LAN.
This means, for example, that every packet sent to port 9732 on the router from
the WAN side is forwarded by the router to 192.168.0.44:1001 on the network:
As you can see, this is a static configuration. This is configured on the router
itself -- it is not related to any Tibbo equipment. The diagram above shows
the setup itself -- no connection is in progress, but the router knows what to do
when it gets data to port 9732.
After properly configuring port forwarding on the router, every time a connection is
established to a specific port on the "real" IP address of the router, the data is
forwarded to a specific host and port on the LAN. Hence:
470
This shows the same set-up as above, but with a connection in progress. As you
can see, the remote host can actually initiate a connection to the Device Server
inside the network, because the router knows what to do with the data. Contrast
the above diagram with the diagram on How NAT Applies To Device Servers.
Notes on Setting Up Port Forwarding
In order for port forwarding to work, several conditions must be true:
Internally, in the LAN, the DS must use a static IP address. The router knows it
should forward the packets to 192.168.0.44 -- so if the DS suddenly becomes
192.168.0.53, it doesn't get the packets. So its address must be static.
The external ("real") IP address of the router must also be static. Otherwise, the
Remote Host (212.68.157.9 in the diagram above) will not know where to
connect.
The router must be properly configured for port forwarding, using its internal
configuration interface. The way to do this varies from router to router, and is
documented in the manual for your specific router.
The internal port and the external port aren't necessarily the same -- just
because you set the router to forward incoming connections from port 1001,
doesn't mean it would forward them inside the network to port 1001. You have
to set this correctly.
Remember -- establishing the connection isn't the same as using the connection.
This is covered in detail under Important Note above.
The DS must accept incoming connections. That means the Routing Mode (RM)
setting must be set to "Server" or "Server/Client".
In some cases (depending on the application), it may be possible to obviate
the requirement for a static IP on the external side of the router by using
Dynamic DNS. This, however, is beyond the scope of this application note.
To learn more, read the Wikipedia article titled Dynamic DNS.
Application Notes
471
effect, this means that your serial device would have to be 'tailored' for working
with the DS. It would have to speak in a language the DS understands -- i.e, send
the serial commands the DS could understand.
Since these commands are used specifically to communicate with Device Servers
from Tibbo, standard serial devices don't come with the option to send them
already built in. So, you have to be able to modify the firmware for your serial
device to have it send these commands. Usually manufacturers can do this, but
some serial devices are very flexible, and allow even an end user to perform such
modifications (especially Linux-based devices, etc).
Topics In This Application Note
Specifically, we will take up the following topics:
Benefits of Modem Commands
Issuing Commands
Establishing a Connection
Terminating a Connection
Finding Out Connection Status (X)
Finding Out Connection Details (U)
Exiting Serial Programming Mode
DSR/DTR
Real-World Example
472
Issuing Commands
Entering the Serial Programming Mode
Before issuing commands, the DS must listen (i.e, be in programming mode).
There are two ways to enter Serial Programming mode, and they are both
described under Serial Parameters (Modem Commands) in AN008. Using
HyperTerminal.
Once you enter Serial Programming mode, you can start issuing commands. Basic
command format is described under Sending a Command (Command Format).
Commands are Asynchronous
One of the most important things to remember about commands is that they are
asynchronous. In simple terms, this means that when you issue a command and
get back an A (Ack) response, the command has not necessarily been executed.
The A means that the DS has received your command and has started executing it.
This is most prominent when issuing instructions to establish or close connections.
When sending such instructions, the A reply comes immediately -- the DS takes
very little time to receive and 'understand' the instruction. But having understood
it, it now has to execute it -- and that sometimes takes time.
The time it takes to establish a TCP connection varies according to the topology of
the network the DS is in. Thus, after issuing an instruction such as the Establish
Connection (CE) instruction, you must check the DS status to see when the
connection has actually been established. For this, use the Echo (X) command.
This is described in detail under Finding Out Connection Status (X).
A complete listing of modem commands which can be issued appears under
Modem (Serial-Side) Parameters & Instructions. The text below only
highlights several commands with specific implementation details.
Application Notes
473
Establishing
a Connection
5.10.2.1
A connection is established using the Establish Connection (CE) instruction.
This instructions can be sent with no parameters, or with parameters specifying the
destination IP and port.
Option One: With Parameters
With parameters, a CE instructions looks like this:
<STX>PCE192.168.0.5/1001<CR>
The parameters are the IP address and the port to which the DS has to connect.
Option Two: With No Parameters
The CE instruction can be issued simply as <STX>PCE<CR>
. In this case, the DS
infers the parameters according to the most recent Destination IP-address (DI)
parameter and Destination Port Number (DP) parameter it has received.
However, if since the last PDI/PDP instructions, another network host has opened
a connection to the DS, the DS then uses the Destination IP-address (DI)
setting and Destination Port Number (DP) setting and attempts to connect to
the destination host defined by these settings.
How to Prevent Another Host From Opening a Connection to The DS
To prevent another host from connection to the DS while you are sending it
parameters and instructions to configure an outbound connection, use the Routing
Mode (RM) parameter to set it to 2 (Client Only). Thus, a typical connection
establishment sequence could go like this (bold lines are commands sent to DS).
Set the DS to work as Client Only, thus denying incoming connections:
<STX>PRM2<CR>
DS acknowledges command:
<STX>A<CR>
DS acknowledges command:
<STX>A<CR>
DS acknowledges command:
<STX>A<CR>
DS acknowledges command:
<STX>A<CR>
DS acknowledges command:
474
Terminating
a Connection
5.10.2.2
There are two ways to terminate a connection using modem commands: You can
close the connection, or abort it. The two are not the same, when it comes to TCP
connections.
Closing a Connection
The Close Connection (CC) instruction uses the proper termination sequence for
TCP connections (FIN-ACK-FIN-ACK), and thus closes the connection in an orderly
fashion. It is recommended to use this instruction.
Aborting a Connection
The Abort Connection (CA) instruction uses an RST packet to terminate a TCP
connection. This is one-sided termination, and is usually less recommended.
Terminating UDP "Connections"
UDP is a connectionless protocol. The data "connection" the DS uses is merely a
stream of packets, as described under UDP Data "Connections". Thus, you can
either abort or close such a "connection" -- the action performed is identical in both
cases.
Remember! Commands are asynchronous -- just because you told the
DS to terminate the connection, and it answered back "A" doesn't mean
the connection has actually been terminated. See Finding Out Connection
Status (X).
For now, we only care about the bold c which appears near the middle of the
command (it is the 6th character). You can read about the meaning of the other
letters in the command manual page. The c stands for "data connection status".
This is just a position in the reply string of this command -- it does not actually
say c in the command (otherwise, how could it be used to detect a status?
Naturally, it must change.) Thus, this position in the reply string for the command
can contain one of the following characters:
Application Notes
475
yet closed).
U
moment.
F
A Practical Example
Let's say you have a serial device and wish to make an outbound connection to a
server. To do so, you need to first check if it is safe to try and connection (i.e, that
there isn't an active data connection at the moment). Then, you have to issue the
connection command. Then, you have to check that the connection has indeed
been established, and continue checking periodically until the connection is
established.
Such a programming session could look like this (bold lines are commands sent to
DS):
Checking -- is there an established data connection?
<STX>X<CR>
The 6th char (c) is an asterisk - Data connection currently closed. Proceeding:
<STX>ANS*I**/**<CR>
DS acknowledges command:
<STX>A<CR>
The 6th char (c) is O- Data connection being established. We are still not
connected:
<STX>ANS*IO*/**<CR>
DS acknowledges command:
<STX>A<CR>
476
Application Notes
477
Addd.ddd.ddd.ddd/ppppp[/iii.iii.iii.iii]
ddd.ddd.ddd.dddStands for the IP address the DS is currently communicating with (or
In essence, this command allows you to see who the DS is communicating with,
once you have used the Echo (X) command and have found out that a connection
is established.
DSR/DTR
Until now, we have touched topics which involve sending and receiving ASCII data
to and from the device. However, sometimes a simpler method is needed. This is
true especially in the case of establishing and dropping connections, which is one
of the simplest functions of any communication device, and is often used.
Thus, the advanced usage options for the DSR and DTR lines. Correct use of these
lines will allow your serial device to find out the current connection status, and
control it, without even entering programming mode or sending a single command.
See below:
DTR - Detecting Data Connection Status
The DTR Mode (DT) setting controls the behaviour of the DTR line.
Assuming this setting is set to 1 (connection status), the DTR line will be LOW
when no data connection is established, and HIGH when a data connection is
established. Thus, you can have your serial device directly sense the status of the
data connection, without using the Echo (X) command.
DSR - Controlling Data Connection Status
If the Connection Mode (CM) setting is set to 3 (on command or DSR=HI), the
DS will establish an outbound data connection whenever the serial device sets the
DSR line to HIGH for at least 20ms. This is, of course, only relevant if the Routing
Mode [setting/parameter] is not 0 (when it is 0, the DS will not make an
478
Real-World Example
Fallback to a Secondary Server
Let us say we have a fire detection system in a large building. This system is
connected to a remote server (say, at a security company) via a DS. It sends out a
heart-beat signal every minute, to report its status.
If the remote server at the security company fails, communication with the fire
detection system will be lost, and the security company will not know what's going
on in the building (and probably, in many other buildings). This cannot happen.
Thus, modem commands can be used to detect that there is no connection to the
remote server, and change the destination address of the DS to a secondary
server. Thus, if the primary server fails, the DS falls back to a secondary server,
and all works well. Such a communication session will go like this:
Checking -- is there an established data connection?
<STX>X<CR>
The 6th char (c) is an asterisk - Data connection currently closed. Proceeding:
<STX>ANS*I**/**<CR>
DS acknowledges command:
<STX>A<CR>
The 6th char (c) is O- Data connection being established. We are still not
connected:
<STX>ANS*IO*/**<CR>
The 6th char (c) is an asterisk - Data connection is closed. Could not get to server:
<STX>ANS*I**/**<CR>
DS acknowledges command:
<STX>A<CR>
The 6th char (c) is O- Data connection being established. We are still not
connected:
<STX>ANS*IO*/**<CR>
Application Notes
479
DS acknowledges command:
<STX>A<CR>
480
Notes:
U1 (MC35063) is a very popular power IC manufactured by ON Semiconductor.
R1 is very important. It is just 1 (one!) Ohm, but we really do not recommend the
user to omit it.
R2 and R3 are "1% tolerance" (high-precision) because they define the output
voltage of the power supply.
C1 and C3 capacitors: Do not use SMD capacitors -- use regular through-hole
aluminum capacitors. This really helps reduce noise produced by the power
supply.
This is an analog circuit, so layout matters. Apply reasonable "good layout" effort.
Note that it is not necessary to try and obtain the exact capacitors, diodes, etc that
Tibbo currently employs. The part numbers are for reference only.
Ideally, one should use an oscilloscope to see what sort of "square wave"
the PSU generates, both at low and high input voltages. R1 can be adjusted
to achieve a better (cleaner) square wave signal on a particular PCB layout.
There are no recipes here -- just try and see what works for your circuit.
Update history
This topic details update history for this document system.
---------02MAR2007 release
Updated EM1000 picture in the EM1000 BASIC-programmable Ethernet Module
topic.
New EM1000-00 and -01 topic explains the difference between these two
EM1000 versions.
Updated EM1000 diagram in the I/O Pin Assignment and Pin Functions topic.
Updated Ethernet Port Lines (of the EM1000) topic: the information on how to
change the host PCB to accommodate new EM1000-...-01 parts was corrected.
Updated EM1000-EV Evaluation Board topic.
New EM1000-EV-00 and -01, Converting EM1000-EV-00 into -01 topics.
---------15FEB2007 release
Updated "Specifications" topic for the following devices: EM100, EM120, EM200,
EM202, DS100, and DS202.
Update history
481
Updated "Ethernet port lines" topic (add schematic diagrams for connecting
magnetics and RJ45 socket) for the following devices: EM120, EM200.
Corrected an error on the diagram for the Ethernet port of the EM202 -- Built in
RJ45 Ethernet Connector topic.
Updated the following topics related to the EM1000 module: EM1000
BASIC-programmable Ethernet Module, I/O Pin Assignment and Pin Functions,
Ethernet Port Lines, Real-time Counter, Mechanical Dimensions, Specifications
and EM1000 Modifications.
---------07NOV2006 release
Documented new Cable Status (C) command.
Documented new Get My IP (T) command.
Updated Firmware Revision History.
---------08AUG2006 release
Small changes corrections related to the release of new 3.31 firmware.
---------07AUG2006 release
Small corrections related to the release of new 3.30 and 3.62 firmware.
---------24JULY2006 release
Corrected buffer size for non-programmable ("device server") firmware of
EM120/EM200/EM202 modules (Comparison Chart for Ethernet-to-Serial Modules
). Correct buffer size is 8KBytes in each direction.
Setting up AuthKey Using DS Manager -- corrected a small typo.
---------06JULY2006 release
A whole new section has been added- EM1000 BASIC-programmable Ethernet
Module.
These topics have been updated to reflect the fact that the product can work with
"device server: firmware OR TiOS firmware (that executes BASIC application):
EM120 Ethernet-to-Serial Module, EM200 Ethernet-to-Serial Module, EM202
Ethernet-to-Serial Module.
Corrected DTR Startup Mode (DS) setting description. It erroneously stated that
this setting was not available on V3.5x branch of firmware, which is not true.
In the new firmware, line status changes are recognized much faster- it only
takes 20ms instead of 0.5s. The following topics have been updated to reflect
this change: Notification Bitmask (NB) setting, Notification (J) message,
Handling of RTS, CTS, DTR, and DSR Signals.
---------26JUNE2006 release
Corrected documentation error in Telnet TCP Programming topic. When Transport
Protocol is TCP and Port Number is 23 telnet programming is impossible, as any
TCP connection to port 23 will be interpreted as data connection. Previously, we
have erroneously stated that in this case all connections to port 23 will be
interpreted as programming, not data connections.
20June2006 release
Updated Installation procedure for VSPDL
----------
482
Update history
483
484
New topics:
PPPoE [V3.54+]
Link Server support
DS powerup procedure
Data connection establishment procedure
Set Programming Request Flag (N) command [Release 3.5]
Reset Upload Process (Q) command [Release 3.5]
Upload Data Block (D) command [Release 3.5]
dDNS Service Registration (DD) setting
dDNS Service IP-address (LI) setting
dDNS Service Port (LP) setting
LS Auto-registration (AR) setting
PPPoE Mode (PP) setting [V3.54+]
PPPoE Login Name (PL) setting [V3.54+]
PPPoE Login Password (PD) setting [V3.54+]
Connection settings
Link Server Login (TL) setting
Update history
485
486
Update history
Netmask (NM) setting
Update history (this very topic)
---------01JUL2004 ("base") release
Updates are tracked from this point
487
488
Index
- A -
- E -
access modes
207
Address Book
212
Auto-Discovery
208
COM port
218
Address Book
212
Application firmware
84
Application-to-DS Link
294
AuthKey
360
Auto-Discovery Access Mode
- B barcode
479
Broadcast Access Mode
buzz
225
168
- F 208
firmware
upgrading
194
firmware components
81
Application firmware
84
Monitor
81
NetLoader
194
- C cable
crossover Ethernet
76
serial
75
straight Ethernet
76
Change IP
225
COM Access Mode
218
commands
111
connection delay
406
connection settings
145
Connection Wizard
278
control loads
410
crossover Ethernet cable
76
customization options
395
208
EM100 2, 4
EM100-EV
46
EM120 2, 10
EM120/200-EV
48
EM200 2, 16
EM202 2, 23
EM202-EV
51
encapsulation settings
error messages
232
188
- G gateway
457, 463
- H HyperTerminal
430
- I initialize
110, 223
integration
400
- L 202
label
479
LinkServer
349
installing and configuring
355
Linux
327
loads
control
410
Index
Settings Button
220
SP2 413
SP-to-DS Link
279
status icon
205
Status Messages
228
subnet
457
explained
460
- M messages
111
modem commands
example
478
181, 471
Module integration
400
Monitor
81, 274
monitor sensors
410
mount
DIN Rail
78
wall
78
- N NAT
464
NetLoader
194
Network Address Translation
Network settings
133
- V 464
Virtual Serial Port
248
VSP Manager
248, 250
VSPD
248
VSPDL
327
- O On-the-fly
175
- W -
- P PIC
406
Port Forwarding
469
Port Monitor
274
power adaptor
78
Programmable Interrupt Controller
programming
101
example
456
223
409
406
489