network/computer switchable DC power

The parallel port solution is the most obvious - but not a simple connection to it.

Simply send two words out of the parallel port, in sequence. The first is an "address code". That gets latched into a comparator and only if it matches the set 8 bit word is the latched output port read-enabled.

If the address code sent as the first word matches, the second word is latched into the output port.

If you are happy with 7 lines, you can use one bit to uniquely identify that the word is a control word. That way, if a reboot/crash does happen between sending the first and second words, the electronics will recognise that the control word is set and disable the data port write cycle.

Of course you could do all this with discrete logic chips. But a PIC will be far, far easier and cheaper.

An alternative, again easier with a PIC, is to connect up a UART to the serial port and write its output word to the output port latch. Easy enough to do.

Another alternative if you want a LAN or remote facility, is to use a very inexpensive cheap print server, either serial or parallel. Then connect that to the PIC. Simply print a text file in raw data mode and having solected a vanilla ASCII printer. Arrange a preamble in the text file, that will be identified by the PIC as preceding the data, then output a character with the appropriate ASCII code.

Another alternative is to get a USB /parallel/serial output unit from the likes of Maplin:

or Quasar:

etc, etc, etc.

The Universe is your mollusc...

Get contactors rated at least 10 A, 24 VDC, with 120VAC coil. Wire the coils to your HTTP / SNMP power strips and thereby control power to your DC loads.

Why not plug the wall warts into the interfaced AC power strip?

Ben Miller

| The parallel port solution is the most obvious - but not a simple | connection to it. | | Simply send two words out of the parallel port, in sequence. The first | is an "address code". That gets latched into a comparator and only if | it matches the set 8 bit word is the latched output port read-enabled. | | If the address code sent as the first word matches, the second word is | latched into the output port. | | If you are happy with 7 lines, you can use one bit to uniquely identify | that the word is a control word. That way, if a reboot/crash does happen | between sending the first and second words, the electronics will | recognise that the control word is set and disable the data port write | cycle. | | Of course you could do all this with discrete logic chips. But a PIC | will be far, far easier and cheaper.

I'm not wanting to build anything complicated. This solution would only be viable if there's a product to do it _and_ that product ensures that the signals that the PC BIOS sends out absolutely never cause any switch events.

| Another alternative if you want a LAN or remote facility, is to use a | very inexpensive cheap print server, either serial or parallel. Then | connect that to the PIC. Simply print a text file in raw data mode and | having solected a vanilla ASCII printer. Arrange a preamble in the text | file, that will be identified by the PIC as preceding the data, then | output a character with the appropriate ASCII code.

Hmmm.

| Another alternative is to get a USB /parallel/serial output unit from | the likes of Maplin: | |

Requires their DLL (so I guess it won't run on Linux).

| or Quasar: |

They definitely document the issue I see with parallel ports. But their serial port box looks interesting.

|> -- |> |---------------------------------------/----------------------------------| |> | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address |> below | |> | first name lower case at ipal.net / |> snipped-for-privacy@ipal.net | |> |------------------------------------/-------------------------------------| | | Get contactors rated at least 10 A, 24 VDC, with 120VAC coil. Wire | the coils to your HTTP / SNMP power strips and thereby control power | to your DC loads.

That would be a last ditch solution as it would have so many wires and it would also involve connecting with 120V.

| | Why not plug the wall warts into the interfaced AC power strip?

That is what we have now. There are problems with some the cheaper wall warts not providing steady startup power.

This approach, using a print server, really does have a lot of potential - used with the Quasar Serial driver unit, for example.

The serial one is just a simple PIC-based solution as I described.

| This approach, using a print server, really does have a lot of | potential - used with the Quasar Serial driver unit, for example.

Once I have serial port control, I don't need much else as the PC in control will be in close proximity.

I found a bunch of boards at this site:

For doing all kinds of controllign using parallel port I have provided instructions here

Just wire a suitable numebr of relays to parallel port, and use the relay contacts to drive the DC loads you need to control.

There are many serial port or USB controllable I/O devices. Use those to drive a set of relays that conrol your load.

Far too much junk comes with the above link. Who wants to be the 99999999th visitor and win a handfull of blinking ads?

On 18 Feb 2007 12:47:40 +0200 Tomi Holger Engdahl wrote: | snipped-for-privacy@ipal.net writes: | |> There are network switchable AC power strips available with HTTP and/or SNMP |> interfaces that can be used to control the power on and off. But what I am |> looking for is something that can do the same for DC up to 60 watts, with a |> voltage range up to 24 volts and a current range up to 8 amps. The protocol |> to control it can be anything that I would be able to manage from a computer |> running my software. | | For doing all kinds of controllign using parallel port I have provided | instructions here |

| | Just wire a suitable numebr of relays to parallel port, and use | the relay contacts to drive the DC loads you need to control.

No info on how to deal with the issue of the PC BIOS jiggling the state of the parallel port lines if the PC reboots (I don't want a reboot of the PC to reset the controlled devices).

| There are many serial port or USB controllable I/O devices. | Use those to drive a set of relays that conrol your load.

I found them with the relays included (some to as much as 20A 250V AC).

There are many solutions:

1) Put an RC network on the data lines from the parallel port, so that the input has to be sustained, say for 2 seconds, before a relay will energise. The relays will not respond to the short transients during reboot.

2) Use the 8th relay N/C contacts to provide power to the other 7 relay circuits. Ensure that this bit is low under normal circumstances. As this line will go high during the reboot, it will prevent any other relay from closing. You will need to put a few mSec RC network on the 7 data lines, to ensure that the 8th relay always operates first. You will only be able to control 7 devices.

3) etc..

On Tue, 20 Feb 2007 18:00:08 GMT Palindrome wrote: | snipped-for-privacy@ipal.net wrote: |> On 18 Feb 2007 12:47:40 +0200 Tomi Holger Engdahl wrote: |> | snipped-for-privacy@ipal.net writes: |> | |> |> There are network switchable AC power strips available with HTTP and/or SNMP |> |> interfaces that can be used to control the power on and off. But what I am |> |> looking for is something that can do the same for DC up to 60 watts, with a |> |> voltage range up to 24 volts and a current range up to 8 amps. The protocol |> |> to control it can be anything that I would be able to manage from a computer |> |> running my software. |> | |> | For doing all kinds of controllign using parallel port I have provided |> | instructions here |> |

|> | |> | Just wire a suitable numebr of relays to parallel port, and use |> | the relay contacts to drive the DC loads you need to control. |> |> No info on how to deal with the issue of the PC BIOS jiggling the state |> of the parallel port lines if the PC reboots (I don't want a reboot of |> the PC to reset the controlled devices). | | There are many solutions: | | 1) Put an RC network on the data lines from the parallel port, so that | the input has to be sustained, say for 2 seconds, before a relay will | energise. The relays will not respond to the short transients during reboot.

I don't want my intended signals delayed like that.

| 2) Use the 8th relay N/C contacts to provide power to the other 7 relay | circuits. Ensure that this bit is low under normal circumstances. As | this line will go high during the reboot, it will prevent any other | relay from closing. You will need to put a few mSec RC network on the 7 | data lines, to ensure that the 8th relay always operates first. You will | only be able to control 7 devices.

I think serial port is going to be more reliable. That and there are products available for it that are not too expensive.

I addressed the implied question, "No info on how to deal with the issue of the PC BIOS jiggling the state of the parallel port lines if the PC reboots (I don't want a reboot of the PC to reset the controlled devices)."

The serial solution is more complex and uses more components - although much of that complexity is hidden within the PIC. You are reliant on the author of this embedded software getting it correct and bug-free. The parallel solution does not use a bespoke component, such as a PIC, and isn't reliant on third party developed software over which you have no visibility and no control. So, the parallel solution is intrinsically more reliable.

The two solutions will behave differently in the event of the computer failing. The serial solution will normally retain the last set state, indefinately. The parallel soultion will normally default to all relays off. If this is important, you may have to allow for it by modifying the design.

| The serial solution is more complex and uses more components - although | much of that complexity is hidden within the PIC. You are reliant on the | author of this embedded software getting it correct and bug-free. The | parallel solution does not use a bespoke component, such as a PIC, and | isn't reliant on third party developed software over which you have no | visibility and no control. So, the parallel solution is intrinsically | more reliable.

In a hardware perspective, yes. But the PC parallel printer port is not usable for that purpose. Some other kind of parallel port device is what is needed to make effective use ... something the BIOS knows nothing of.

| The two solutions will behave differently in the event of the computer | failing. The serial solution will normally retain the last set state, | indefinately. The parallel soultion will normally default to all relays | off. If this is important, you may have to allow for it by modifying the | design.

The parallel method will need some tri-state output ... a way to set OFF, a way to set ON, and a way to just make no change.