C
L E A R
P
A T H
- S C
U
S E R
M
A N U A L
R
E V
.
1 . 3 6
4 7
T
EKNIC
,
I
NC
. T
EL
.
(585)
784-7454
B
RAKE
C
ONTROL
C
IRCUIT
The figure below shows a schematic fragment of one of the Brake Control
circuits (Brake Control 0). See the Schematics appendix for complete SC
Hub circuit drawings.
1
2
10k
R37
12
1k
R34
3
1
BAS21
CR3
2
1
4
3
NZT560
Q9
2
1
Brake 0
1
2
LED2
1
2
7
6
5
MOC207R2M
U9
3
1
BZX84C47
CR4
GND2
24V
1
2
470
R35
5V
24V
00
BRAKE 0
BRAKE 0
1
2
1
2
470
R35
5V
1
2
2k
0.5W
R36
Brake coil energized = Brake released
Motion allowed
Brake coil de-energized = Brake engaged
Motion disallowed
Control signal from ClearView
or user application software
Brake
(24V power-off type)
SC Hub internal
LED turns on when
brake is released and
motion is allowed
Schematic: Brake Control 0
C
AUTION
:
B
RAKE
C
ONTROL
S
AFETY
N
OTE
In order to function, the brake control circuitry, by design, is accessible to
the host operating system (e.g., Windows). Because of this, however, when
your ClearPath-SC application code does not have control of the host’s
communication port (USB or serial), it is possible for the operating system
to inadvertently release the brake. This can happen, for example, if the
operating system scans its connected hardware (like during a port “auto-
discover” function).
To eliminate inadvertent motion, your SC application should
position all brake-fitted axes to their lowest potential energy
state before exiting (i.e. before releasing the port back to the operating
system). For example, position a vertical axis at the bottom of its motion
range if it could otherwise fall when acted upon by gravity.
Whenever movement of any brake-fitted axis could result in a safety
hazard, the brake outputs should be wired in series with an interlock
switch circuit to all guard mechanisms preventing unsafe operator access,
whether directly or through a safety controller. Note: any safety circuit
of this type must go open circuit when unsafe access is
attempted to assure brake actuation.
