Navigate
Projects
Legal
lang:en   lang:de

 
 
 
Switch To switch a few low voltage sources you can use high voltage switch with SNMP support or this smal box and control it via USB

Abstract

The block diagram is very small. Main part is the microcontroller (here IO-Warrior). This device would be able to do more than switching these few GPIOs. But more is not need here in this application. But programming this device is an ugly job. Its SDK and the examples are in "Industrial Code Quality"... But all rigth one can work with it.
 

Schematics

The schematic is like the block diagram very small. Nothing magically inside. But note: Its an hirachical design.

Main page as Postscript
USB subpage as Postscript
Relais-Amps subpage as Postscript
Relais subpage as Postscript

Printed Conductor Board

The board file is an Eagle Layout file.

Board file
Library file

The Bill of Materials

These devices are required
Type Value Footprint Quantity Name(s)
CAPACITOR 100n C0805 1 C3
CAPACITOR 10n C0805 1 C1
CAPACITOR 10u ELC-2.5 2 C2 C4
DIODE 1N4148 MINIMELF 8 D1 D2 D3 D4 D5 D6 D7 D8
LED 2 mm LED2 8 D10 D11 D12 D13 D14 D15 D16 D9
74xx TTL 74573 DIL20S 1 IC2
CONNECTOR STL(Z) 1550
2 poles
conn2 8 X10 X11 X12 X13 X14 X15 X16 X17
PNP_TRANSISTOR BC556 TO-92-CBE 8 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
RELAIS G6D-1A G6D1A 8 X2 X3 X4 X5 X6 X7 X8 X9
RESISTOR 10k R0805 8 R10 R12 R14 R16 R18 R4 R6 R8
RESISTOR 1k3 R0805 1 R1
RESISTOR 1R R0805 1 R2
RESISTOR 3k3 R0805 8 R11 R13 R15 R17 R3 R5 R7 R9
RESISTOR 470R R0805 8 R20 R21 R22 R23 R24 R25 R26 R27
RESISTOR 4k7 RN-9 1 R19
CONNECTOR USB-B-001 USB-B 1 X1
USB-slave IO-Warrior24 DIL24 1 IC1
Aluminium case AKG 105 30 none 1  

The Box

The case is a simple aluminium case for cards with the (half) euro format. You can by them mostly cheap. You can choose the one from the material list or one for a full euro card (160 mm by 100 mm) and cut it in its middle (that's what I did).
 

The Software

Vendor's examples to handle the IO-Warrior where not very helpful. All right, it was possible to compile and use them. But they where ugly, you see what they do, but (like in the most cases) you don't see why they are doing it in this way. Somebody called this "Industrial Code Quality": It seems to work and do so most of the time.
At first you fight against the effect, the IO-Warrior only sometimes sends its port status. The small demo program minimum_read0 sometimes hangs for 10 seconds and after a timeout it outputs an error message. Sometimes the IO-Warrior answers if you send a message through pipe 0, sometimes only when you send a command to pipe 1.
At the end I do not read back the port status, as its value is useless for the next setting turn. And there are no atomic commands to set or clear dedicated port bits. So the protocol driver now stores the last sent value locally on the host. I'm unhappy about this solution. But it works...
Why storing it locally on the host? Because this tool is not a program that runs forever. Its a command, that is called whenever something should happen at switcher's side. And so the current settings are required to create the next setting and send it to the device.
Commands usage should look like that:
$ switcher --on backup

In this example the function backup should be activated. Goal of this tool should be to separate the function (here backup) and what should happen with it (here --on) from what to be done in the background to make it happen.
The switcher command only knows how to communicate with the IO-Warrior. The parameters what to communicate it reads in from a config file:
# /etc/switcher.conf
# setup each function and how to control them
#
# Function: backup
# Handled by an external switch based on the IO-Warrior USB device
#
# Connected is a USB harddisk, that needs 5V and 12V
# to work. Both supplies are controlled via this switch.
# bit 6+7 are switching the relais 1+2
# bit 8+9 are switching the LEDs 1+2
#
function backup
{
   protocol = iowarrior
   node = /dev/usb/iowarror0
   only_user = { }
   only_group = { }
}
# What to do, to switch this function OFF
action backup_off
{
   set = { 6, 7, 8, 9 }
}
# What to do, to switch this function ON
action backup_on
{
   clear = { 6, 7, 8, 9 }
}

In this file is listed what switcher must send to switch a specific function on or off.
I.e. to switch on function backup bits 6, 7, 8 and 9 must be cleared. To switch it off bits 6, 7, 8 and 9 must be set.
This config file is using a format to support more than one external device, that can switch things on and off with a simple bit pattern. So there is only one config file required to handle all such devices. Its not restricted to the IO-Warrior. Section function provides subsystem's name (protocol) and a device node to gain access to it. With the latter one its possible to handle more than one device with the same protocol.
Additionally root can restrict some functions to specific users or groups. In the example above the brackets are empty, so there is no restriction for backup function usage.

The sources

The source can be loaded here. It uses the autotools for configuration and should be build and installed with the regular three steps configure/make/make install.
If you have any trouble to build or use the software, drop me a note: switcher at kreuzholzen dot de