Table of Contents
Advertisement
Why should I stick on this number?
For what could I use this information?
All tools, however, also the actual PC-
hostprogramms communicate and
administer the assemblies with this
number. Now there is no more "address
DCC XX", but the cmmand is sent into the
knots *Unique-ID X* and his port.
The reverse is that for the configuration of
a new action at the output of a decoder
(e.g., LightControl) or the allocation of a
dispatch rider in the rail picture (e.g.,
GBM), the program must be informed
about the suitable Unique-ID of the BiDiB
assembly.
Hardware-serialnumber:
The stuck serialnumber with S/N at the back of the assembly is a hardware-
serialnumber and nothing deals with the Unique-ID serialnumber for the
BiDiB assemblies. With this number your assembly is registered with us.
Where is the Unique-ID stored on the assembly?
Here the procedure is bipartite a little bit. In the Flash/EEPROM-firmware file the VID and PID are already
integrated and are transmitted to the sassembly, however, no serialnumber is included. Hence, the
firmware files can be loaded easily in the processor or can be also updated. Besides, an already available
serialnumber will not be overwritten. If the sassembly still recognises no loaded serialnumber while
starting, a error code flashes and the use of the assembly is blocked.
Without serialnumber the firmware does not run!
(Exception with the master GBMboost: here a Notfall-S/N is generated with the sign: 0100. These S/N can
be overwritten any time with the upload of the valid S/N)
The serialnumber is always postpushed as the third act of the introduction and lands as first in the
EEPROM of the assembly.
Manual to build the SMD pre fitted Hardware
manual-Version V1.4-en
page 5
Advertisement
Table of Contents
