drive.web

Frequently Asked Questions

Below are the answers to common questions about

drive.web

. If your question is not addressed, please email drive.web support or call U.S. Toll Free, 1-888-667-7333 (1-888-ON SPEED), International +1-410-604-3400.

Security Warning?

Q:

When I download savvy via Java Web Start, I get a Security Warning. Why does this happen?

A:

This is a normal warning that appears when you first download code from the Internet via Java Web Start - it is there to protect you. The warning should state that the code is signed by Bardac and authenticated by Thawte Server CA. More detailed info is available at the software download security page.

Protocols and Ports?

Q:

What protocols and ports does

drive.web

use?

A:

DIX Ethernet, ARP, UDP/IP, ICMP, IGMP, multicast address 224.0.0.189, and registered port 48556 (com-bardac-dw)

Why switching hubs?

Q:

Why do I need to use an Ethernet switching hub for

drive.web

?

A:

If you use a standard (i.e. non-switching) hub, the devices have to contend for access to the network using Ethernet's CSMA/CD technique (carrier sense multiple access with collision detection). If multiple collisions occur, a frame can be delayed 10's or even 100's of milliseconds which could disrupt control loops (note that multiple collisions can occur even on lightly loaded networks). If you use a switching hub, collisions can never occur since each device has a dedicated connection to the switching fabric within the switching hub.

Q:

Isn't it possible for switching hubs to drop frames?

A:

Yes, this can occur if the amount of traffic bound for a device exceeds the bandwidth of the connection. However, the

drive.web

protocols are designed to (i) prevent over-subscription of bandwidth and (ii) tolerate lost frames.

Internet Security?

Q:

Aren't you worried about hackers breaking into the drives & drive.web products and wreaking havoc?

A:

Drives that are used on a real machine should never be directly accessible over the Internet. Obviously, the consequences of someone cracking into a drive system could be very serious - system integrators and users must carefully consider the accessibility versus security tradeoffs.

drive.web

systems should either be protected behind a network firewall or not connected to the Internet at all.

If remote Internet accessibility is required, Bardac recommends the use of a high-quality VPN (virtual private network) device and/or software. These products can provide strong cryptographic security and can also help manage IP addresses. Contact Bardac for more information.

If remote accessibility is required for systems that are not connected to the Internet, Bardac offers a LAN modem which provides dial-up access over standard phone lines. Contact Bardac for more information.

Ethernet Cable?

Q:

What sort of Ethernet cable do you recommend?

A:

Bardac recommends Belden 7924A or equivalent cable to interconnect

drive.web

devices and switching hubs. This is 24AWG stranded UTP (unshielded twisted pair) category 5e industrial ethernet cable that is compatible with RJ-45 connectors.

How is drive.web on Ethernet deterministic?

Q:

For years, many have said that Ethernet is not appropriate for real-time control as it is not deterministic. How does

drive.web

overcome this drawback?

A:

'Classic' Ethernet uses CSMA/CD or Carrier Sense Multiple Access with Collision Detection on a broadcast medium (e.g. coaxial cable or the circuitry inside an ethernet hub). In this system, devices that need to transmit data wait until the medium not being used (i.e. there is no carrier detected), then start transmitting their data. If two or more devices transmit at the same time, the data 'collides' and is unusable. Collisions are detected by all devices on the medium: the transmitting devices stop transmitting and any received data is discarded. The transmitting devices then use an algorithm to 'backoff' and retry their transmission. The problem with this scheme is that collisions can occur repeatedly and the data can be delayed by 10's or even 100's of milliseconds - this delay can cause real-time control systems to fail.

Switching hubs eliminate collisions by providing a dedicated communications channel between each device and the switching hub. This works roughly as follows: a received data frame is examined by the switching hub and sent immediately to its destination; if the destination is busy receiving another data frame, the data is FIFO buffered and delivered as soon as possible. The 'switching fabric' inside the switching hub allows multiple data frames to be simultaneously transmitted to different destinations. There are no collision delays and data frames are delivered as quickly as the communications channel bandwidth allows.

Note that with a switching hub, it is possible for the communications channel to be overloaded - e.g. multiple devices can send to a single device or a 100baseTX connection can overload a 10baseT connection. If a port is overloaded, the switch will throw away data frames.

The

drive.web

configuration tools avoid over-subscription of bandwidth by statically validating all connections. In addition, the

drive.web

protocols are tolerant of lost data frames.

So, as long as you use switching hubs,

drive.web

over Ethernet is an appropriate choice for a real-time control network.