Prev: Simple hack to get $500 to your home.
Next: Opening for Device Driver Developers
From: Phil on 3 Jun 2010 21:26
On Jun 1, 11:11 pm, D Yuniskis <not.going.to...(a)seen.com> wrote:
> It *seems* like the only realistic AND INTUITIVE protocol
> for "recovery" is to sequence power to the devices in
> question.  Ideally, to *every* device at a node -- though
> remembering to do so may be a problem (so I need to deal
> with the possibility that some devices might get reset while
> others aren't).

Interesting problem and you've clearly given it some thought.

I'd worry about both the order of power on or whether you need
everything to be
powered off at some instant. Someone running between rooms is going to
cycle
each switch in turn, not turn them all off and then all back on. That
might be
implicit in your description, but it's something to consider.

At the risk of stating the obvious, power strips will help for units
that happen
to be close to each other. You might consider remote power controls
for distant
units and cycle them under processor control. X10 power modules
aren't perfect, but
they are cheap, available, and might well get the job done for you.

Cheers,
-- Phil

Phil Koopman -- koopman(a)cmu.edu -- http://www.ece.cmu.edu/~koopman
Author of: Better Embedded System Software, Drumnadrochit Press 2010

From: Philip Koopman on 4 Jun 2010 15:30
D Yuniskis <not.going.to.be(a)seen.com> wrote:

>1) turn off everything.
>2) power up the processor
>3) if a display is present WITH A SEPARATE POWER SWITCH,
> power up the display
>4) if a barcode scanner is present WITH A SEPARATE POWER
> SWITCH, power up the scanner
>5) if a ....

It may or may not be practical for your installations, but a
human-centric approach to this would be to put large number signs on all
the relevant power switches in a group (1, 2, 3, ...) and tell them to
turn them off in order, then back on in order. A little easier to know
if you missed one that way. But this isn't a miracle cure to be sure,
and depends on someone doing the install who can do that for you. I
don't know the context of your installs.

>> X10 power modules aren't perfect, but
>> they are cheap, available, and might well get the job done for you.
>
><doublefrown> My experience with X10 has been that they
>make more problems than they solve. In an industrial
>environment, I think they would probably give up the
>ghost too readily :-/

You're right; depends upon the operating environment.

I'd say your idea of having a processor present at each local equipment
site is probably going to be the way to go. As to the rest ... I don't
see any easy answers.

Cheers,
-- Phil


Phil Koopman -- koopman(a)cmu.edu -- http://www.ece.cmu.edu/~koopman
Author of: Better Embedded System Software, Drumnadrochit Press 2010
From: D Yuniskis on 4 Jun 2010 16:16
Hi Phil,

Philip Koopman wrote:
> D Yuniskis <not.going.to.be(a)seen.com> wrote:
>
>> 1) turn off everything.
>> 2) power up the processor
>> 3) if a display is present WITH A SEPARATE POWER SWITCH,
>> power up the display
>> 4) if a barcode scanner is present WITH A SEPARATE POWER
>> SWITCH, power up the scanner
>> 5) if a ....
>
> It may or may not be practical for your installations, but a
> human-centric approach to this would be to put large number signs on all
> the relevant power switches in a group (1, 2, 3, ...) and tell them to
> turn them off in order, then back on in order. A little easier to know
> if you missed one that way. But this isn't a miracle cure to be sure,
> and depends on someone doing the install who can do that for you. I
> don't know the context of your installs.

The problem there is the order will vary with the "node".
E.g., a site without a display will have:
#1 CPU
#2 Barcode scanner
#3 ...
While a site *with* a display would have:
#1 CPU
#2 Display
#3 Barcode Scanner
#4 ...
And a site without a barcode scanner:
#1 CPU
#2 Display
#3 ...

*If* you can force people to "read the numbers"
(regardless of what they *think* the numbers
*were* -- at some other node!), then youo just
have to ensure the numbers get updated wach
time you add or remove equipment from a node.

<frown>

>>> X10 power modules aren't perfect, but
>>> they are cheap, available, and might well get the job done for you.
>> <doublefrown> My experience with X10 has been that they
>> make more problems than they solve. In an industrial
>> environment, I think they would probably give up the
>> ghost too readily :-/
>
> You're right; depends upon the operating environment.
>
> I'd say your idea of having a processor present at each local equipment
> site is probably going to be the way to go. As to the rest ... I don't
> see any easy answers.

Yeah, I think the solution sucks -- though anything else I come
up with seems to suck *more*! :<

Things would be a lot easier if folks designed devices more
intelligently -- with an eye towards integration and the issues
that it poses -- instead of just designing in a vacuum...
From: Frnak McKenney on 5 Jun 2010 12:00
On Fri, 04 Jun 2010 13:16:23 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote:
> Philip Koopman wrote:
>> D Yuniskis <not.going.to.be(a)seen.com> wrote:
>>
>>> 1) turn off everything.
>>> 2) power up the processor
>>> 3) if a display is present WITH A SEPARATE POWER SWITCH,
>>> power up the display
>>> 4) if a barcode scanner is present WITH A SEPARATE POWER
>>> SWITCH, power up the scanner
>>> 5) if a ....
>>
>> It may or may not be practical for your installations, but a
>> human-centric approach to this would be to put large number signs on all
>> the relevant power switches in a group (1, 2, 3, ...) and tell them to
>> turn them off in order, then back on in order. A little easier to know
>> if you missed one that way. But this isn't a miracle cure to be sure,
>> and depends on someone doing the install who can do that for you. I
>> don't know the context of your installs.
>
> The problem there is the order will vary with the "node".
> E.g., a site without a display will have:
> #1 CPU
> #2 Barcode scanner
> #3 ...
> While a site *with* a display would have:
> #1 CPU
> #2 Display
> #3 Barcode Scanner
> #4 ...
> And a site without a barcode scanner:
> #1 CPU
> #2 Display
> #3 ...
>
> *If* you can force people to "read the numbers"
> (regardless of what they *think* the numbers
> *were* -- at some other node!), then youo just
> have to ensure the numbers get updated wach
> time you add or remove equipment from a node.
>
><frown>

If y'all don't mind a comment or three from someone who missed the
start of this thread...

It appears that the OP's concern is powering devices up and down
in a particular order, with minimal or no required delay between
when devices receive power as long as it occurs in the proper order.

Are these all 115VAC-powered devices (I'm including wall-warts and
power bricks here)? If so, could all the power cords (or extensions
for the 115VAC end of the wall-warts) be run into a common switch
box like hte one on my desk with 7(?) switches labelled MAIN, CPU,
MONITOR, PRINTER, etc. work? Sounds like the OP might want larger
and different labels, but at least the order would be left->right
or right->left, and even _I_ might get that right most of the
time. <grin!>

But perhaps the OP has seen me attempting to work at 0300 after a
long day and has concerns about my always getting the power-on order
correct. (Emergencies are seldom properly scheduled. <grin!>)

In that case, it wouldn't be too hard to rewire a power-
distribution box like mine so each switch provided power to one
outlet AND to the next switch. Throw "1" then "3" and neither "2"
or "3" get power. The down side is that when the person throwing
switches (pushing buttons) realizes it and hits "2" with "3" still
in the ON position, "2" and "3" get power simultaneously. Or
worse: "Hm... 1, 2, 3, 4, 5, 6, ... oops! I didn't press 2 hard
enough... 2!" (add possible spitzensparken sound effects here)

If you have to deal with devices with multiple power sources and
voltages (say 5V at 300A, plus 115VAC, plus 230VAC) then you'll
have to come up with some method of providing common signalling
and control, a whole 'nother barrel of monkeys.

Hm. I know there are delayed-on and delayed-off relays (and one
assumes solid-state equivalents exist these days). If you have the
resources, ONE box with ONE switch, multiple outlets, and a bunch
of such relays might do the job:

ON provides power to device 1 and the dealayed-ON relay for
device 2.
When device 2 gets power, that also turns on the delayed-ON
relay for device 3...

For power OFF, the OFF position doesn't really -- it just starts
a cascade of delayed-OFFs which occur in the proper order. You
still have to ensure that the devices are plugged into the box's
outlets in the correct order.

Oh, and if you want to get really fancy, add in power-sensing
circuits as well so "3" can't get power if "2" isn't powered
on already. That'll help catch cases where someone switched off
a device using its own powere switch or the device is unplugged
(or has blown a fuse).

There's probably alreayd a high-priced (and reliable) commercial
device that does most or all of this, with some fancy name like
"sequenced power distribution box", but I haven't looked.

Did I miss the discussion of what happens if the devices come on in
a "wrong" order, and how much delay (usec? msec? seconds? minutes?)
is required between each device being powered on? (There's probably
a maximum as well -- external SCSI boxes that power up 15 minutes
after the host scans the bus looking for devices usually doesn't
work all that well. <grin!>)

>>>> X10 power modules aren't perfect, but
>>>> they are cheap, available, and might well get the job done for you.
>>> <doublefrown> My experience with X10 has been that they
>>> make more problems than they solve. In an industrial
>>> environment, I think they would probably give up the
>>> ghost too readily :-/

Gack. X-10 is a noise-prone multiple-command-send environment with
most switches/devices providing no feedback or status information (the
kind of situaiton where you use "shadow registers" and hope for the
best).

[...]

> Things would be a lot easier if folks designed devices more
> intelligently -- with an eye towards integration and the issues
> that it poses -- instead of just designing in a vacuum...

If 100% if all potential users submitted detailed descriptions of each
and every situation where a given device would ever be used, the
manufacturers might be able to do this, but anyone attempting this
should have decades of experience in Advanced Cat Herding before taking
this one on. <grin!>

Good luck...


Frank McKenney
--
Applying computer technology is simply finding the
right wrench to pound in the correct screw.
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)
From: D Yuniskis on 5 Jun 2010 14:19
Frnak McKenney wrote:
>> Things would be a lot easier if folks designed devices more
>> intelligently -- with an eye towards integration and the issues
>> that it poses -- instead of just designing in a vacuum...
>
> If 100% if all potential users submitted detailed descriptions of each
> and every situation where a given device would ever be used, the
> manufacturers might be able to do this, but anyone attempting this
> should have decades of experience in Advanced Cat Herding before taking
> this one on. <grin!>

Not at all. If that were the case, you couldn't buy *any* devices
that "talked to" other devices. E.g., how is it that you can use
an SRAM in a variety of applications without the manufacturer
having to know "detailed descriptions of each and every situation
where [that] given device would ever be used"?

You *can* use an SRAM because the interface is well defined
and encompasses (nearly?) everything that an "other" device
would need to be able to ascertain presence, functionality,
size, etc. of that device.

Dealing with the "serial" devices in my example, all that is
required of the designer is:
- strictly define the syntax and content of valid messages
so you (it) can determine if it has received a valid
message (i.e., if it misses the start of a message, it
doesn't treat the *tail* of the message as some other
EQUALLY VALID message). For example:
HANDSHAKING
and
NO HANDSHAKING
would be bad choices for configuration commands as the second
can be "accidentally" recognized as the first *if* the device
happened to miss the initial portion of the (second) message.
Note that adding a checksum also gives you this protection
but increases the work that the "other device" has to do
in order to form valid messages. I.e., you couldn't
simply do:
fprintf(serialout, "BAUDRATE %d.\n", baudrate);
as the checksum would need to be injected -- and *computed*
as a function of "baudrate".
- provide acknowledgements of "commmands" -- so the "other
device" has some assurance that you *did* receive the
command and it was the command that was intended. I.e.,
you need a FDX link (or some creative hardware signaling)
- don't act on anything that STRICTLY SPEAKING fails any
syntax/semantic check (e.g., "BAUDRATE 19199")
- after a long break, begin an autobaud/autoconfig sequence
abandoning any previous link configuration. Expect *any*
valid message to immediately follow (perhaps prefaced with
a fixed character sequence to allow simpler devices to
more easily lock onto the correct baudrate -- e.g., " ".

I suspect I may have left a hole unplugged someplace. But,
just these few things (all of which are trivial to implement)
would allow the "other device" to converse with the device
in question without fear of: something being "missed" *or*
something being "misinterpreted".
 |  Next  |  Last
Pages: 1 2
Prev: Simple hack to get $500 to your home.
Next: Opening for Device Driver Developers