Specifications

NetLinx Security within the Web Server
121
NetLinx Security - Web Server
With program defined/static binding, the developer specifies a permanent binding between an
application device and a physical port, such as a particular serial or IR port. At run-time, any device
detected on that port is automatically associated with the designated application device. This
binding type would be used when the developer wants to hard code what port is used for a device,
but does not know what manufacturer's device will actually be connected. Static binding is not
available for IP connected devices, since the IP Address value of a device is subject to change due
to IP network topology.
 An example of its use would be if DHCP is enabled for the peripheral device. A
hard-coded IP Address within the NetLinx "glue-code" would be inadequate due to the
nature of the dynamically acquired DHCP IP Addresses. Only actual NetLinx D:P:S
values are allowed for static binding of physical ports.
With run-time defined/dynamic binding, the application device and the physical port are
completely disassociated (in a program sense). The developer defines the application devices and
their associated SDK class but does not specify what physical port they are bound to. At run-time,
as those devices are discovered, the new physical devices are then bound to an application device
either automatically or via the Master's Web access. Dynamic binding is the only binding option
available for IP-connected peripheral devices due to the dynamic nature of IP Addresses as
discussed earlier.
Manage Other Devices - Manage Device Bindings
To access this page, click on the Manage Device Bindings button (from within the Manage Other
Device page). This page is used to configure application-defined Duet virtual devices with
discovered physical devices. The on-screen table (FIG. 81) displays a list of all application-defined
devices (including the defined "friendly name"), the Duet virtual D:P:S, and the associated Duet
Device SDK class (indicating the type of the device). This information would have been pre-coded
into the NetLinx file currently on the target Master (FIG. 80).
Configuring application-defined devices
Elements such as
DUET_DEV_TYPE_DISC_DEVICE and DUET_DEV_POLLED are defined within the
NetLinx axi. The latest version of the NetLinx.axi file contains both the new API definitions, as
well as the pre-defined constants that are used as some of the API arguments
(ex:
DUET_DEV_TYPE_DISC_DEVICE). Sample code can be found within the DEFINE_START
section seen in FIG. 80:
PROGRAM_NAME='DDD'
DEFINE_DEVICE
COM1 = 5001:1:0
COM2 = 5001:2:0
dvRECEIVER1 = 41000:1:0
dvDiscDevice = 41001:1:0
DEFINE_CONSTANT
DEFINE_TYPE
DEFINE_VARIABLE
Physical device names are typically prefixed with "dv" and Virtual device names are
typically prefixed with "vdv". It is recommended that anyone working with these
modules should become familiar with this naming convention.