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.
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
A:DIX Ethernet, ARP, UDP/IP, ICMP, IGMP, multicast address 126.96.36.199, and registered port 48556 (com-bardac-dw)
Why switching hubs?
Q:Why do I need to use an Ethernet switching hub for
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.webprotocols are designed to (i) prevent over-subscription of bandwidth and (ii) tolerate lost frames.
Q:Bardac has two drives and a distributed process controller that are on the Internet at speedy-sp.bardac.com, speedy485.bardac.com and smarty.bardac.com - aren't you worried about crackers breaking into the drives and wreaking havoc?
A:Well, yes! It is possible that a cracker might break in and mess around with these drives. However, the motors that these drives control are not connected to anything dangerous and the high-voltage power is usually turned off (except when they are being demonstrated).
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.websystems 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.
Q:What sort of Ethernet cable do you recommend?
A:Bardac recommends Belden 7924A or equivalent cable to interconnect
drive.webdevices 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.webovercome 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.
drive.webconfiguration tools avoid over-subscription of bandwidth by statically validating all connections. In addition, the
drive.webprotocols are tolerant of lost data frames.
So, as long as you use switching hubs,
drive.webover Ethernet is an appropriate choice for a real-time control network.