Re: Power cycling Mark IV

[hjohnson@pluto.njcc.com (Herbert R Johnson)]

On Wed, 27 Sep 2000 13:15:01 -0700 (PDT), Ron Wickersham <rjw@alembic.com> wrote:
*>
*>On Wed, 27 Sep 2000, Herbert R Johnson wrote:
*>
*>> So the idea of a wire that would in effect LOOK for a big spike to reset
*>> either the Stamp or the whole camera strikes me as a bad idea. It would
*>> be a shame to mess up a camera run with a "reset" caused by a power surge.
*>
*>the "break" signal on an async line is not a special spike, but a 
*>legal signal _level_ that is longer in duration than allowed for any
*>legal character, so the "break" detector would not be more susceptable
*>to power surges than sending characters.

Sounds reasonable, depending on how the "break detector" is actually
implemented. I don't know what the Stamp offers in that regard.
I'd only add that a bad bit in a character bit stream would likely
generate an error response (some clever thinking could assure that) rather
than the "wrong" response. In any case this is the kind of dialog I
wanted to generate on this issue.

*>>[I offered some hardware-store type AC on/off timers or AC remotes
*>>such as X10 or radio controlled units]
*>
*>the present problem is to get Arne's box easier for there probably wouldn't
*>be an issue if it were only a ninety foot walk to manually reset, so my
*>guess is that it is a [pain?] pina to reset since you can't walk directly the
*>way the 90 foot cable is run.

Some of the RF remotes may work within 90 feet. X-10 generally requires
both the controller and the controlled device to be on the same AC "service":
Arne's setup suggested that may not be the case. There are all kinds
of RF remote services both on the market and upcoming.

*>while a manual remote reset is ok for an attended site, our original specs
*>called for completely unattended operation at at least some sites, so we
*>can't expect an X10 in Redondo Beach to power cycle a camera on Mt. Wilson.
*>but for Arne's present situation, perhaps the power supply for the Stamp
*>could be controlled with an X10 module to force a reset of the Stamp.

All I know is that the current camera is connected to the current computer
by a big cable. I don't know if the idea of a camera connected to the
controlling PC computer via EtherNet ever got past the talking stage. Presumably
any "truely" remote operation would be via networking the the controlling
*computer*, not by "networking" the *camera* hardware; so I presume conventional
PC networking solves that problem. That brings the control issue back to
the 90-foot distance between camera hardware and its controlling computer...

*>Chris' breadboard setup is closer to the ultimate configuration with only
*>an ethernet umbilical to the net, so we do need to think about remote 
*>reset of the stamp and also the control computer.  Arne brings up the

...with the capacity to also control some of these same features via
remote operation of the contolling computer - presumably a matter of
software not hardware.

*>issue of controlling the chiller and pumps and other auxiliaries such
*>as the shelter opening/closing which don't want to be cycled just to
*>reset the Stamp.

Additional control of "auxiliary" equipment via the camera's computer
could be done with off-the-shelf digital control cards from a number
of vendors. Many of them include the AC and DC "relays" on card, some
cable from the PC card to a set of such cards. Another class of solution:
a "programmable logic controller" (PLC) run from either a serial connection
or even an EtherNet connection to the camera's computer: some of these
are only a few hundred dollars. Electronic engineer's trade magazines
carry ads for these; some of the computer magazines and electronics hobby
magazines also advertize these. The "PLC" solution offers reliable remote
operation via (another!) cable between the controlling PC and the site
where the PLC is connected to the pumps and sensors. I'm amazed at how
low-cost some of these PLC's are - a few hundred dollars COMPLETE!

To cut to the chase, I'd say "auxiliary" control is a per-site issue.
If the "camera software" has reasonable programming hooks for control inputs
and outputs, then each site can buy hardware and write software accordingly.
This is of course merely my opinion, I think such work will be evolutionary
from the sites, not pre-specified beforehand and then implemented. The
trick will be the Mark IV "driver" software ability to supply these
control points (control data) from the camera hardware for site software
to process.

*>although you can reboot a system that is still communicating remotely,
*>if the system is not communicating to the internet, then we want to
*>have it at least attempt to reset after some period of time.  so we
*>probably want to have some sort of heartbeat that will reboot after
*>say 15 minutes of no pings being answered, or if you think you want
*>it to at least complete a nights' run if isolated, then reboot after
*>x hours.

A 24-hour timer AC timer would cycle the PC and camera once a day, for
instance. But Ron's idea, also called a "keep-alive" timer, is a good
consideration, many control systems have such features.

I don't have much more to add than this, as I'm not working closely on
Mark IV hardware. My interests are primarily Mark III. However, some
issues (and practices) of Mark III seem to be similar to Mark IV's.
And I have done some controls engineering some years ago. It's a lot
cheaper and easier now.

Herb

Herbert R. Johnson              http://pluto.njcc.com/~hjohnson
hjohnson@pluto.njcc.com         voice 609-771-1503, New Jersey USA
             amateur astronomer and astro-tour guide
           S-100 computer parts, manuals as "Dr. S-100"
    reseller of 68K Macs & accessories for your computing pleasure