"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
"RogerN" fired this volley in
m:

Perhaps as part of the program you could have it
record how much adjust time of the curtains accumulated over a day.
Try to tune the algorithm for best temperature control with minimal
winch run time.


Roger, a decent PID algorithm accommodates changes in conditions, and
"learns" the lead/lag characteristics of the system. Most of the even
most-basic PID controllers (ready made) have that capability.

LLoyd

It's been a while since I messed with my Basic Stamp but IIRC they used 8
bit integer math. My Basic Stamp 1 had only about 16 bytes ram, I'm not
sure that would do a PID control, maybe. I think the BS2 has about twice
that amount of ram. I'm not to great at working with integer math,
especially 8 bit.

RogerN

On Sun, 6 Dec 2009 19:31:56 -0600, "Karl Townsend"
wrote:

My first winter project is on my new high tunnel (greenhouse) High
temperature control by ventilation is critical for good growing. I will be
ventilating by using a rollup side curtain. I plan to automate the process
by using a small 12 volt DC gear motor and wench. I've settled on my
mechanical design and plan to order parts tomorrow.

My query is on control. KISS is the order of the day here. I plan on two
thermostats - Hi and Lo. Also two limit switches - full open and full
closed. The control is simple - if you make Hi; roll up for a few seconds
and go to delay timer. If you make Lo unroll a few seconds and go to delay
timer. Stop on limit switches. Repeat 24X7.

I'm thinking this is PLC territory. I know nothing about them. Is there an
inexpensive simple to program unit that runs on 12 volt DC? Alternatively, I
can see a way to do it with a timer that continuously does a few seconds on
then several minutes off continuously.

Karl

If outdoor temp is higher than your minimum, if the temp ever got high
enough to open the curtain it'd stay open until outdoor temp drops.

If outdoor temp is lower than your min but there's enough sun to heat
the space to above max with curtain closed, then the system would
cycle, alternately opening and closing.

If outdoor temp is lower than min and there's not enough sun to reach
max temp, then the curtain would stay closed.

If you only partially move the curtain and then go to a delay timer
for a while to see if that move drops temp below max, might it take
unacceptably long to fully open on a high temp condition? The time
constant will be quite different on calm days vs windy days.

A PID controller with a temperature sensor would provide better
temperature stability, but at the expense of battery life because the
curtain would be making small moves very often. You'd need curtain
position feedback too.

On Mon, 7 Dec 2009 21:00:58 -0600, "Karl Townsend"
wrote:

For that your parts would be 1 solid state relay to turn motor ON/OFF and
1 electromechanical 4PDT relay motor direction UP/DOWN (2 Poles) and the
other 2 poles to jump the limit switches (UP jumps down L/S and DOWN jumps
up L/S). Or if you have and would prefer to use 4 SSR's that should work
great too.

Will a basic stamp power a 4PDT relay coil directly? I haven't checked, but
I assume it won't. If it will, do you set up the controller to sink the
relay? Or can it also source?

Specs are on their website. You'll need drive transistors to operate
relays. Someone suggested TIP120, a good suggestion. Holler if you
want some help with that.

"Karl Townsend" wrote in message
tanews.com...


You described the exact issue. Mechanically, I've got it geared down to
raise/lower 12"/minute with a total travel of 60 inches. Gets hard to gear
it much slower. My "plan A" is two stats so you have a dead band, then
play with % run to get response without oscillation. I suppose if you knew
exactly what percent on/off was optimum you could just gear it for 100%
on.

You can't know that because it will change significantly with cloud
cover, sun angle, wind, etc.

On Tue, 08 Dec 2009 21:08:33 -0600, RogerN wrote:

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
"RogerN" fired this volley in
m:

Perhaps as part of the program you could have it record how much
adjust time of the curtains accumulated over a day. Try to tune the
algorithm for best temperature control with minimal winch run time.


Roger, a decent PID algorithm accommodates changes in conditions, and
"learns" the lead/lag characteristics of the system. Most of the even
most-basic PID controllers (ready made) have that capability.

LLoyd

It's been a while since I messed with my Basic Stamp but IIRC they used
8 bit integer math. My Basic Stamp 1 had only about 16 bytes ram, I'm
not sure that would do a PID control, maybe. I think the BS2 has about
twice that amount of ram. I'm not to great at working with integer
math, especially 8 bit.

RogerN

Ouch. That's pretty restrictive. You'd need at least 16 bits to do PID
in this sort of thing, and mo is better.

--
www.wescottdesign.com

Tim Wescott wrote:
On Tue, 08 Dec 2009 21:08:33 -0600, RogerN wrote:

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
"RogerN" fired this volley in
m:

Perhaps as part of the program you could have it record how much
adjust time of the curtains accumulated over a day. Try to tune the
algorithm for best temperature control with minimal winch run time.


Roger, a decent PID algorithm accommodates changes in conditions, and
"learns" the lead/lag characteristics of the system. Most of the even
most-basic PID controllers (ready made) have that capability.

LLoyd
It's been a while since I messed with my Basic Stamp but IIRC they used
8 bit integer math. My Basic Stamp 1 had only about 16 bytes ram, I'm
not sure that would do a PID control, maybe. I think the BS2 has about
twice that amount of ram. I'm not to great at working with integer
math, especially 8 bit.

RogerN

Ouch. That's pretty restrictive. You'd need at least 16 bits to do PID
in this sort of thing, and mo is better.



'splain why?

The timing is closer to hours than milliseconds.
A real time interrupt (external 555?) for the long delay?

8 bits of temperature is 256 value spread.

The AtoD function can be external hardware, or an external mux if
an internal AtoD is there. One bit to select from two sources,
two bits for 4.

Motor control is one bit for direction, one for Go.
An eight bit count for run time to position the vent.



Too much bloatware in the world today.

What we need are more Assembly Programmers!

On Wed, 09 Dec 2009 00:53:28 -0600, cavelamb
wrote:

Tim Wescott wrote:
On Tue, 08 Dec 2009 21:08:33 -0600, RogerN wrote:

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
"RogerN" fired this volley in
m:

Perhaps as part of the program you could have it record how much
adjust time of the curtains accumulated over a day. Try to tune the
algorithm for best temperature control with minimal winch run time.


Roger, a decent PID algorithm accommodates changes in conditions, and
"learns" the lead/lag characteristics of the system. Most of the even
most-basic PID controllers (ready made) have that capability.

LLoyd
It's been a while since I messed with my Basic Stamp but IIRC they used
8 bit integer math. My Basic Stamp 1 had only about 16 bytes ram, I'm
not sure that would do a PID control, maybe. I think the BS2 has about
twice that amount of ram. I'm not to great at working with integer
math, especially 8 bit.

RogerN

Ouch. That's pretty restrictive. You'd need at least 16 bits to do PID
in this sort of thing, and mo is better.



'splain why?

The timing is closer to hours than milliseconds.
A real time interrupt (external 555?) for the long delay?

8 bits of temperature is 256 value spread.

The AtoD function can be external hardware, or an external mux if
an internal AtoD is there. One bit to select from two sources,
two bits for 4.

Motor control is one bit for direction, one for Go.
An eight bit count for run time to position the vent.



Too much bloatware in the world today.

What we need are more Assembly Programmers!

Are you volunteering to assist?

Don Foreman wrote:
On Wed, 09 Dec 2009 00:53:28 -0600, cavelamb
wrote:

Tim Wescott wrote:
On Tue, 08 Dec 2009 21:08:33 -0600, RogerN wrote:

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
"RogerN" fired this volley in
m:

Perhaps as part of the program you could have it record how much
adjust time of the curtains accumulated over a day. Try to tune the
algorithm for best temperature control with minimal winch run time.


Roger, a decent PID algorithm accommodates changes in conditions, and
"learns" the lead/lag characteristics of the system. Most of the even
most-basic PID controllers (ready made) have that capability.

LLoyd
It's been a while since I messed with my Basic Stamp but IIRC they used
8 bit integer math. My Basic Stamp 1 had only about 16 bytes ram, I'm
not sure that would do a PID control, maybe. I think the BS2 has about
twice that amount of ram. I'm not to great at working with integer
math, especially 8 bit.

RogerN
Ouch. That's pretty restrictive. You'd need at least 16 bits to do PID
in this sort of thing, and mo is better.


'splain why?

The timing is closer to hours than milliseconds.
A real time interrupt (external 555?) for the long delay?

8 bits of temperature is 256 value spread.

The AtoD function can be external hardware, or an external mux if
an internal AtoD is there. One bit to select from two sources,
two bits for 4.

Motor control is one bit for direction, one for Go.
An eight bit count for run time to position the vent.



Too much bloatware in the world today.

What we need are more Assembly Programmers!

Are you volunteering to assist?



Well, maybe...

If I got a "development system" for christmas?

"Don Foreman" wrote in message
...
On Sun, 6 Dec 2009 19:31:56 -0600, "Karl Townsend"
wrote:

My first winter project is on my new high tunnel (greenhouse) High
temperature control by ventilation is critical for good growing. I will be
ventilating by using a rollup side curtain. I plan to automate the process
by using a small 12 volt DC gear motor and wench. I've settled on my
mechanical design and plan to order parts tomorrow.

My query is on control. KISS is the order of the day here. I plan on two
thermostats - Hi and Lo. Also two limit switches - full open and full
closed. The control is simple - if you make Hi; roll up for a few seconds
and go to delay timer. If you make Lo unroll a few seconds and go to delay
timer. Stop on limit switches. Repeat 24X7.

I'm thinking this is PLC territory. I know nothing about them. Is there an
inexpensive simple to program unit that runs on 12 volt DC? Alternatively,
I
can see a way to do it with a timer that continuously does a few seconds
on
then several minutes off continuously.

Karl

If outdoor temp is higher than your minimum, if the temp ever got high
enough to open the curtain it'd stay open until outdoor temp drops.

If outdoor temp is lower than your min but there's enough sun to heat
the space to above max with curtain closed, then the system would
cycle, alternately opening and closing.

If outdoor temp is lower than min and there's not enough sun to reach
max temp, then the curtain would stay closed.

If you only partially move the curtain and then go to a delay timer
for a while to see if that move drops temp below max, might it take
unacceptably long to fully open on a high temp condition? The time
constant will be quite different on calm days vs windy days.

A PID controller with a temperature sensor would provide better
temperature stability, but at the expense of battery life because the
curtain would be making small moves very often. You'd need curtain
position feedback too.


I was wondering if he could use a string pot on the curtain for position
feedback? I've never eBayed for them but I don't think they are very cheap
new.

RogerN

RogerN wrote:
"Don Foreman" wrote in message
...
On Sun, 6 Dec 2009 19:31:56 -0600, "Karl Townsend"
wrote:

My first winter project is on my new high tunnel (greenhouse) High
temperature control by ventilation is critical for good growing. I will be
ventilating by using a rollup side curtain. I plan to automate the process
by using a small 12 volt DC gear motor and wench. I've settled on my
mechanical design and plan to order parts tomorrow.

My query is on control. KISS is the order of the day here. I plan on two
thermostats - Hi and Lo. Also two limit switches - full open and full
closed. The control is simple - if you make Hi; roll up for a few seconds
and go to delay timer. If you make Lo unroll a few seconds and go to delay
timer. Stop on limit switches. Repeat 24X7.

I'm thinking this is PLC territory. I know nothing about them. Is there an
inexpensive simple to program unit that runs on 12 volt DC? Alternatively,
I
can see a way to do it with a timer that continuously does a few seconds
on
then several minutes off continuously.

Karl
If outdoor temp is higher than your minimum, if the temp ever got high
enough to open the curtain it'd stay open until outdoor temp drops.

If outdoor temp is lower than your min but there's enough sun to heat
the space to above max with curtain closed, then the system would
cycle, alternately opening and closing.

If outdoor temp is lower than min and there's not enough sun to reach
max temp, then the curtain would stay closed.

If you only partially move the curtain and then go to a delay timer
for a while to see if that move drops temp below max, might it take
unacceptably long to fully open on a high temp condition? The time
constant will be quite different on calm days vs windy days.

A PID controller with a temperature sensor would provide better
temperature stability, but at the expense of battery life because the
curtain would be making small moves very often. You'd need curtain
position feedback too.


I was wondering if he could use a string pot on the curtain for position
feedback? I've never eBayed for them but I don't think they are very cheap
new.

RogerN




I would think a simple timing loop would do it.
Run the device and see how long it takes to go from one end
to the other. Divide that by 256 for max resolution, or more
likely by 16 - plenty of resolution for a vent.

I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be needed.

On Tue, 08 Dec 2009 22:06:17 -0600, Don Foreman
wrote:




"Karl Townsend" wrote in message
ctanews.com...


You described the exact issue. Mechanically, I've got it geared down to
raise/lower 12"/minute with a total travel of 60 inches. Gets hard to gear
it much slower. My "plan A" is two stats so you have a dead band, then
play with % run to get response without oscillation. I suppose if you knew
exactly what percent on/off was optimum you could just gear it for 100%
on.

You can't know that because it will change significantly with cloud
cover, sun angle, wind, etc.




It ain't hard, it just ain't cheap. I used a double reduction
Sumitomo cycloid drive of 3400:1 to drive the continuous filter I
invented. Web movement maximum was 60"/hour, min was close to zero.
I'd mark the web, go have a cup of coffee, come back and stick a ruler
on it to make sure it was working.

Pete Keillor

Too much bloatware in the world today.

What we need are more Assembly Programmers!

Are you volunteering to assist?

Well, maybe...

If I got a "development system" for christmas?




I talked this project over with my crop consultant today. He said I should
apply for a research grant and thinks I'd probably win. In that case, this
device needs better EE than I can do. A ways down the road, but would you
like to help design phase two?

Karl

Karl Townsend wrote:
Too much bloatware in the world today.

What we need are more Assembly Programmers!
Are you volunteering to assist?
Well, maybe...

If I got a "development system" for christmas?




I talked this project over with my crop consultant today. He said I should
apply for a research grant and thinks I'd probably win. In that case, this
device needs better EE than I can do. A ways down the road, but would you
like to help design phase two?

Karl


Sure Karl,

You get some grant money for research and development, I'm your geek.

It would be fun. I haven't done a control project in ages.

I have a little CMOS Z80 controller board worked up that should run on
about 25 milliamps (not counting off board I/O interfaces, of course).

Personally, I'd go that way and just write in Z80 Assembly, or Tiny C, or
as fast as this thing would run maybe even BASIC. Once it's up and running,
anybody could then tinker with the software quite easily.

It would be a little overkill, but if I'm writing code, I'd prefer to do
it on something I already know.

Fewer surprises.

And, like Roger pointed out, the little controllers are, well, little(!)

Richard

Don Foreman fired this volley in
:

You'd need curtain
position feedback too.


I said that too, earlier, then realized that you don't need position
feedback.

A PID loop outputs a signal proportional to the amount of correction
required. One could position the curtain according to the correction
signal, and not require that the position be fed back to the controller.

That would still require more complex drive controls than simply "on-
off/up-down", but the position controlling mechanism could be part of the
curtain drive itself, rather than feeding back to the controller. Think
of how a PWM model aircraft servo works.

The receiver never "knows" the position of the servos. It merely outputs
a pulse width proportional to the position desired, and the servo goes
there - then nulls - on its own.

A string pot and a comparator could comprise the basics of such an auto-
positioning mechanism. In use, the controller would not have to output
on-off, or up-down outputs, just an analog signal or pulse width
modulated signal that represented the desired absolute curtain position.

LLoyd

Pete Keillor wrote:
On Tue, 08 Dec 2009 22:06:17 -0600, Don Foreman
wrote:


"Karl Townsend" wrote in message
anews.com...
You described the exact issue. Mechanically, I've got it geared down to
raise/lower 12"/minute with a total travel of 60 inches. Gets hard to gear
it much slower. My "plan A" is two stats so you have a dead band, then
play with % run to get response without oscillation. I suppose if you knew
exactly what percent on/off was optimum you could just gear it for 100%
on.
You can't know that because it will change significantly with cloud
cover, sun angle, wind, etc.


It ain't hard, it just ain't cheap. I used a double reduction
Sumitomo cycloid drive of 3400:1 to drive the continuous filter I
invented. Web movement maximum was 60"/hour, min was close to zero.
I'd mark the web, go have a cup of coffee, come back and stick a ruler
on it to make sure it was working.

Pete Keillor


Well, not to be contradictory, but it is both easy and cheep - in software.

Once you have the drive running that can handle the mechanical loads,
controlling the speed is simple stuff.

Richard

In article ,
cavelamb wrote:

[snip]

I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be needed.

I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.

The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn

On Wed, 09 Dec 2009 07:06:14 -0600, cavelamb
wrote:

Pete Keillor wrote:
On Tue, 08 Dec 2009 22:06:17 -0600, Don Foreman
wrote:


"Karl Townsend" wrote in message
anews.com...
You described the exact issue. Mechanically, I've got it geared down to
raise/lower 12"/minute with a total travel of 60 inches. Gets hard to gear
it much slower. My "plan A" is two stats so you have a dead band, then
play with % run to get response without oscillation. I suppose if you knew
exactly what percent on/off was optimum you could just gear it for 100%
on.
You can't know that because it will change significantly with cloud
cover, sun angle, wind, etc.


It ain't hard, it just ain't cheap. I used a double reduction
Sumitomo cycloid drive of 3400:1 to drive the continuous filter I
invented. Web movement maximum was 60"/hour, min was close to zero.
I'd mark the web, go have a cup of coffee, come back and stick a ruler
on it to make sure it was working.

Pete Keillor


Well, not to be contradictory, but it is both easy and cheep - in software.

Once you have the drive running that can handle the mechanical loads,
controlling the speed is simple stuff.

Richard

Yeah, you're right if discontinuous works, as in this case. I wanted
continuous motion in the case I described.

Pete Keillor

Joseph Gwinn wrote:
In article ,
cavelamb wrote:

[snip]
I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be needed.

I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.

The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn


There is an old saying that,
"If engineers built bridges the way programmers write software,
the first wood pecker than comes along could destroy civilization".

And there is some truth in that.

But no, I'd not design an autonomous system that need manual oversight.

IIRC, Karl said his vent was about 6 feet long.

My first fantasy was a fabric tape/shade (wide enough to cover the vent slot)
that rolls up on rollers at each end. Maybe it has some shaped supports
to keep it snug against the enclosure(?). But there is nothing to jam into
at the end of the run.

So all I'd be doing is rolling the shade up or down.

The computer can monitor the drum and tell, within reason, where the opening
is at any time. If we are rolling up on a fairly small shaft, just count
turns. If it's a big drum, maybe glue some magnets around the drum and count
them with a Hall effect sensor.

You don't see that kind of proactive defense in other mechanical devices.
Printers, Plotters, Flight simulator motion platforms, CARS.

But you do have to be careful about writing any wood peckers into your code.


Richard

Pete Keillor wrote:
On Wed, 09 Dec 2009 07:06:14 -0600, cavelamb
wrote:

Pete Keillor wrote:
On Tue, 08 Dec 2009 22:06:17 -0600, Don Foreman
wrote:

"Karl Townsend" wrote in message
anews.com...
You described the exact issue. Mechanically, I've got it geared down to
raise/lower 12"/minute with a total travel of 60 inches. Gets hard to gear
it much slower. My "plan A" is two stats so you have a dead band, then
play with % run to get response without oscillation. I suppose if you knew
exactly what percent on/off was optimum you could just gear it for 100%
on.
You can't know that because it will change significantly with cloud
cover, sun angle, wind, etc.


It ain't hard, it just ain't cheap. I used a double reduction
Sumitomo cycloid drive of 3400:1 to drive the continuous filter I
invented. Web movement maximum was 60"/hour, min was close to zero.
I'd mark the web, go have a cup of coffee, come back and stick a ruler
on it to make sure it was working.

Pete Keillor

Well, not to be contradictory, but it is both easy and cheep - in software.

Once you have the drive running that can handle the mechanical loads,
controlling the speed is simple stuff.

Richard

Yeah, you're right if discontinuous works, as in this case. I wanted
continuous motion in the case I described.

Pete Keillor


Pulse width modulate.

The motor will integrate that into continuous motion.

If the requirements get REAL slow, you may have to pulse both ways.
Drive forward Tx
Drive backwards Tc-n

Keep the motor energized so it doesn't wander off position.

In article ,
cavelamb wrote:

Joseph Gwinn wrote:
In article ,
cavelamb wrote:

[snip]
I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be needed.

I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.

The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn


There is an old saying that,
"If engineers built bridges the way programmers write software,
the first wood pecker than comes along could destroy civilization".

Yes, plus the sayings about "If Microsoft built xxx".


And there is some truth in that.

But no, I'd not design an autonomous system that need manual oversight.

IIRC, Karl said his vent was about 6 feet long.

My first fantasy was a fabric tape/shade (wide enough to cover the vent slot)
that rolls up on rollers at each end. Maybe it has some shaped supports
to keep it snug against the enclosure(?). But there is nothing to jam into
at the end of the run.

So all I'd be doing is rolling the shade up or down.

Well, the shade may tear. One may decide to simply clean up afterwards
if this happens, but I would think it would prove to be a big nuisance,
enough to justify some limit switches.

Given that shade replacement is manual, manual-reset limit switches (a
pair of normally-closed microswitches in series with the motor power)
may make sense, as reset is far easier and perhaps cheaper than shade
replacement.


The computer can monitor the drum and tell, within reason, where the opening
is at any time. If we are rolling up on a fairly small shaft, just count
turns. If it's a big drum, maybe glue some magnets around the drum and count
them with a Hall effect sensor.

You don't see that kind of proactive defense in other mechanical devices.
Printers, Plotters, Flight simulator motion platforms, CARS.

The usual solution is to make sure that the motor will stall without
harm to anything. Also using a pipsqueak motor saves money on the motor
and its power supply. But it takes a lot of engineering to achieve this
kind of balance, and so is worthwhile only for production items, not for
one-off projects.

Industrial gearmotors have *lots* of torque, so unless it doesn't matter
if the motor keeps on running forever, explicit limit switches or some
kind of mechanical torque limiter or mechanical fuse (like a shear bolt)
are necessary.


But you do have to be careful about writing any wood peckers into your code.

Even with care, one hears the pecking from time to time.

For an extreme example, fly-by-wire bet-your-life avionics code is
developed to the DO-178B standard, which increases the cost per line of
the resulting code by a factor of about ten over the process used to
develop for instance radar signal and data processing code.

The resulting avionics code is very reliable, and yet bugs are still
found from time to time, even in systems with many flight hours to their
names.


Joe Gwinn

Joseph Gwinn wrote:
In article ,
cavelamb wrote:

Joseph Gwinn wrote:
In article ,
cavelamb wrote:

[snip]
I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be needed.
I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.

The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn

There is an old saying that,
"If engineers built bridges the way programmers write software,
the first wood pecker than comes along could destroy civilization".

Yes, plus the sayings about "If Microsoft built xxx".


And there is some truth in that.

But no, I'd not design an autonomous system that need manual oversight.

IIRC, Karl said his vent was about 6 feet long.

My first fantasy was a fabric tape/shade (wide enough to cover the vent slot)
that rolls up on rollers at each end. Maybe it has some shaped supports
to keep it snug against the enclosure(?). But there is nothing to jam into
at the end of the run.

So all I'd be doing is rolling the shade up or down.

Well, the shade may tear. One may decide to simply clean up afterwards
if this happens, but I would think it would prove to be a big nuisance,
enough to justify some limit switches.

Given that shade replacement is manual, manual-reset limit switches (a
pair of normally-closed microswitches in series with the motor power)
may make sense, as reset is far easier and perhaps cheaper than shade
replacement.


The computer can monitor the drum and tell, within reason, where the opening
is at any time. If we are rolling up on a fairly small shaft, just count
turns. If it's a big drum, maybe glue some magnets around the drum and count
them with a Hall effect sensor.

You don't see that kind of proactive defense in other mechanical devices.
Printers, Plotters, Flight simulator motion platforms, CARS.

The usual solution is to make sure that the motor will stall without
harm to anything. Also using a pipsqueak motor saves money on the motor
and its power supply. But it takes a lot of engineering to achieve this
kind of balance, and so is worthwhile only for production items, not for
one-off projects.

Industrial gearmotors have *lots* of torque, so unless it doesn't matter
if the motor keeps on running forever, explicit limit switches or some
kind of mechanical torque limiter or mechanical fuse (like a shear bolt)
are necessary.


But you do have to be careful about writing any wood peckers into your code.

Even with care, one hears the pecking from time to time.

For an extreme example, fly-by-wire bet-your-life avionics code is
developed to the DO-178B standard, which increases the cost per line of
the resulting code by a factor of about ten over the process used to
develop for instance radar signal and data processing code.

The resulting avionics code is very reliable, and yet bugs are still
found from time to time, even in systems with many flight hours to their
names.


Joe Gwinn


Ok, but make the limit switches DPXX types so I can monitor the status
in software. If something did go wrong bad enough to trip the mechanical
limits I want the software to know about it.

On Wed, 09 Dec 2009 00:53:28 -0600, cavelamb wrote:

Tim Wescott wrote:
On Tue, 08 Dec 2009 21:08:33 -0600, RogerN wrote:

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
"RogerN" fired this volley in
m:

Perhaps as part of the program you could have it record how much
adjust time of the curtains accumulated over a day. Try to tune the
algorithm for best temperature control with minimal winch run time.


Roger, a decent PID algorithm accommodates changes in conditions, and
"learns" the lead/lag characteristics of the system. Most of the
even most-basic PID controllers (ready made) have that capability.

LLoyd
It's been a while since I messed with my Basic Stamp but IIRC they
used 8 bit integer math. My Basic Stamp 1 had only about 16 bytes
ram, I'm not sure that would do a PID control, maybe. I think the BS2
has about twice that amount of ram. I'm not to great at working with
integer math, especially 8 bit.

RogerN

Ouch. That's pretty restrictive. You'd need at least 16 bits to do
PID in this sort of thing, and mo is better.



'splain why?

The timing is closer to hours than milliseconds. A real time interrupt
(external 555?) for the long delay?

8 bits of temperature is 256 value spread.

The AtoD function can be external hardware, or an external mux if an
internal AtoD is there. One bit to select from two sources, two bits
for 4.

Motor control is one bit for direction, one for Go. An eight bit count
for run time to position the vent.



Too much bloatware in the world today.

What we need are more Assembly Programmers!

Because that's what you always end up needing, that's why!

If you are really using an integrator, either for the integrator or (more
likely) because you're band-limiting the differentiator, then you need
more bits to store the state than you have bits in the input. If you use
an 8-bit number for temperature, you need more bits for the state -- and
in an 8-bit processor, "more than 8" is 16.

Be glad -- many applications I end up doing need more than 16, in
assembly this means you have to decide between 24 and 32.

You may be able to do this effectively with Karl's original algorithm,
which will work fine with 8-bit math. But the advantage of a PID-type
controller is that (if everything comes together) you can maintain a much
more constant temperature inside the greenhouses instead of the constant
up/down you'd get from a hysteresis controller cycling all the time.

--
www.wescottdesign.com

On Wed, 09 Dec 2009 08:24:15 -0600, cavelamb wrote:

Pete Keillor wrote:
On Wed, 09 Dec 2009 07:06:14 -0600, cavelamb
wrote:

Pete Keillor wrote:
On Tue, 08 Dec 2009 22:06:17 -0600, Don Foreman
wrote:

"Karl Townsend" wrote in message
anews.com...
You described the exact issue. Mechanically, I've got it geared
down to raise/lower 12"/minute with a total travel of 60 inches.
Gets hard to gear it much slower. My "plan A" is two stats so you
have a dead band, then play with % run to get response without
oscillation. I suppose if you knew exactly what percent on/off was
optimum you could just gear it for 100% on.
You can't know that because it will change significantly with cloud
cover, sun angle, wind, etc.


It ain't hard, it just ain't cheap. I used a double reduction
Sumitomo cycloid drive of 3400:1 to drive the continuous filter I
invented. Web movement maximum was 60"/hour, min was close to zero.
I'd mark the web, go have a cup of coffee, come back and stick a
ruler on it to make sure it was working.

Pete Keillor

Well, not to be contradictory, but it is both easy and cheep - in
software.

Once you have the drive running that can handle the mechanical loads,
controlling the speed is simple stuff.

Richard

Yeah, you're right if discontinuous works, as in this case. I wanted
continuous motion in the case I described.

Pete Keillor


Pulse width modulate.

The motor will integrate that into continuous motion.

If the requirements get REAL slow, you may have to pulse both ways.
Drive forward Tx
Drive backwards Tc-n

Keep the motor energized so it doesn't wander off position.



....Monitor the motor position so you can actively control it (speaking of
bloatware).

--
www.wescottdesign.com

On Wed, 9 Dec 2009 06:13:30 -0600, "Karl Townsend"
wrote:

Too much bloatware in the world today.

What we need are more Assembly Programmers!

Are you volunteering to assist?

Well, maybe...

If I got a "development system" for christmas?




I talked this project over with my crop consultant today. He said I should
apply for a research grant and thinks I'd probably win. In that case, this
device needs better EE than I can do. A ways down the road, but would you
like to help design phase two?

Karl

Sure! I have development systems and C compilers for PIC and Atmel
AVR. Cavelamb is probably more competent, so include us both!

On Wed, 09 Dec 2009 07:03:31 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:

Don Foreman fired this volley in
:

You'd need curtain
position feedback too.


I said that too, earlier, then realized that you don't need position
feedback.

A PID loop outputs a signal proportional to the amount of correction
required. One could position the curtain according to the correction
signal, and not require that the position be fed back to the controller.

That would still require more complex drive controls than simply "on-
off/up-down", but the position controlling mechanism could be part of the
curtain drive itself, rather than feeding back to the controller. Think
of how a PWM model aircraft servo works.

Then the feedback is in a local loop. Position sensing is still
required, and is provided by the servo mfr. PID provides a signal
proportional to error (and the integral of error, with some
differential modification). In a temperature control situation this
works: if cold, supply more heat. In this app, curtain position is
the time integral of motor excitation. Curtain position is the signal
required to be compared against setpoint to produce an error signal
that PID can use.

The receiver never "knows" the position of the servos. It merely outputs
a pulse width proportional to the position desired, and the servo goes
there - then nulls - on its own.

Yes, because the servo has internal position sensing feedback.

A string pot and a comparator could comprise the basics of such an auto-
positioning mechanism. In use, the controller would not have to output
on-off, or up-down outputs, just an analog signal or pulse width
modulated signal that represented the desired absolute curtain position.

LLoyd

On Tue, 8 Dec 2009 20:54:22 -0600, "Karl Townsend"
wrote:


"Mark Rand" wrote in message
.. .
On Mon, 7 Dec 2009 10:09:26 -0600, "Karl Townsend"
wrote:


Think simple greenhouse exept $/sq.ft. must be lower. Usually no to
limited
electric. Most important crops are planted in soil. The aim is to produce
a
crop such as tomato, etc. that harvests much earlier in the season.

Karl


Yabbut what's the difference between "High tunnel" and plain ordinary
polytunnel greenhouses?

Expiring minds want to know :-)

Mark Rand
RTFM

If you're looking at the structure the difference is blurred. Few
greenhouses use natural ventilation - large exhaust fans. most high tunnel
have huge natural vent opening.

The main difference is application. Greenhouse grow plant for resale in some
sort of medium normally on shelves. High tunnel grows fruit and vegetables
in the soil.

Karl



Ok, That's what I'd know as polytunnels (not the same as the home vegetable
plot variety though...)


regards
Mark Rand
RTFM

Don Foreman fired this volley in
:

Yes, because the servo has internal position sensing feedback.

That still doesn't make the entire system a cybernetic loop. The error
signal generating equipment derives no feedback from the effector. It's a
"dead reckoning" system; the controller tells the curtain to "move to x",
and only assumes it has happened.

LLoyd

On Tue, 08 Dec 2009 21:51:02 -0600, Don Foreman wrote:

On Sun, 6 Dec 2009 19:31:56 -0600, "Karl Townsend"
wrote:

My first winter project is on my new high tunnel (greenhouse) High
temperature control by ventilation is critical for good growing. I will
be ventilating by using a rollup side curtain. I plan to automate the
process by using a small 12 volt DC gear motor and wench. I've settled
on my mechanical design and plan to order parts tomorrow.

My query is on control. KISS is the order of the day here. I plan on two
thermostats - Hi and Lo. Also two limit switches - full open and full
closed. The control is simple - if you make Hi; roll up for a few
seconds and go to delay timer. If you make Lo unroll a few seconds and
go to delay timer. Stop on limit switches. Repeat 24X7.

I'm thinking this is PLC territory. I know nothing about them. Is there
an inexpensive simple to program unit that runs on 12 volt DC?
Alternatively, I can see a way to do it with a timer that continuously
does a few seconds on then several minutes off continuously.

Karl

If outdoor temp is higher than your minimum, if the temp ever got high
enough to open the curtain it'd stay open until outdoor temp drops.

No problem.

If outdoor temp is lower than your min but there's enough sun to heat
the space to above max with curtain closed, then the system would cycle,
alternately opening and closing.

I'm not so sure -- Karl's control rule as stated could possibly find a
sweet spot.

If outdoor temp is lower than min and there's not enough sun to reach
max temp, then the curtain would stay closed.

Which is the best you could expect, unless you want an alarm to ring so
that Karl knows he's got to go install heaters.

If you only partially move the curtain and then go to a delay timer for
a while to see if that move drops temp below max, might it take
unacceptably long to fully open on a high temp condition? The time
constant will be quite different on calm days vs windy days.

This is what Karl is describing, and you share your concern with me. I
think it could be alleviated considerably with tapered vents -- when it's
cold and/or windy the vents would stay mostly closed, so make sure that
the vents are narrow there, such that an incremental opening of the
curtain doesn't open the vent up much.

A PID controller with a temperature sensor would provide better
temperature stability, but at the expense of battery life because the
curtain would be making small moves very often.

Possibly. A controller with a bit of built-in hysteresis wouldn't. Or
Karl may find that really small motions don't drain the battery badly
enough for it to be a concern.

You'd need curtain position feedback too.

I don't think you do, necessarily, beyond limit switches. The motor/
curtain system will just act like an integrating plant; this means that
Karl really only needs a PD controller, probably, or a P-double D (ick).

Position feedback on the curtain would help if you were really going for
low power and/or precise temperature control, however. So would a
monitor on the outside temperature, for that matter.

--
www.wescottdesign.com

On Wed, 09 Dec 2009 09:06:23 -0500, Joseph Gwinn wrote:

In article ,
cavelamb wrote:

[snip]

I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent. But if the device has
comfortable "over-run" areas, it might not be needed.

I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.

The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn

With a DC system it's easy to set up limit switches that'll prevent a
motor from driving any further into a stop, but will let it drive out.

And even though I write embedded code, too, I still prefer to have
mechanical safety devices -- for when someone else starts maintaining my
bug-free code, of course.

--
www.wescottdesign.com

On Wed, 09 Dec 2009 10:11:34 -0600, Don Foreman wrote:

On Wed, 9 Dec 2009 06:13:30 -0600, "Karl Townsend"
wrote:

Too much bloatware in the world today.

What we need are more Assembly Programmers!

Are you volunteering to assist?

Well, maybe...

If I got a "development system" for christmas?




I talked this project over with my crop consultant today. He said I
should apply for a research grant and thinks I'd probably win. In that
case, this device needs better EE than I can do. A ways down the road,
but would you like to help design phase two?

Karl

Sure! I have development systems and C compilers for PIC and Atmel
AVR. Cavelamb is probably more competent, so include us both!

So long as you each buy a copy of my book.

--
www.wescottdesign.com

Tim Wescott wrote:
On Wed, 09 Dec 2009 10:11:34 -0600, Don Foreman wrote:

On Wed, 9 Dec 2009 06:13:30 -0600, "Karl Townsend"
wrote:

Too much bloatware in the world today.

What we need are more Assembly Programmers!
Are you volunteering to assist?
Well, maybe...

If I got a "development system" for christmas?




I talked this project over with my crop consultant today. He said I
should apply for a research grant and thinks I'd probably win. In that
case, this device needs better EE than I can do. A ways down the road,
but would you like to help design phase two?

Karl

Sure! I have development systems and C compilers for PIC and Atmel
AVR. Cavelamb is probably more competent, so include us both!

So long as you each buy a copy of my book.



I was afraid you were going to over complicate things, but your articles
are pretty clear and readable.

Joseph Gwinn wrote:

In article ,
cavelamb wrote:

[snip]

I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be needed.

I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.


Diodes across the limit switch, so it can only run the other
direction. This was common on Sat dish steering motors, and trailer
jacks. You hit the limit, and the switch opens, but the diode will allow
it to be backed off.



The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn


--
Offworld checks no longer accepted!

On Wed, 09 Dec 2009 14:21:09 -0600, cavelamb wrote:

Tim Wescott wrote:
On Wed, 09 Dec 2009 10:11:34 -0600, Don Foreman wrote:

On Wed, 9 Dec 2009 06:13:30 -0600, "Karl Townsend"
wrote:

Too much bloatware in the world today.

What we need are more Assembly Programmers!
Are you volunteering to assist?
Well, maybe...

If I got a "development system" for christmas?




I talked this project over with my crop consultant today. He said I
should apply for a research grant and thinks I'd probably win. In
that case, this device needs better EE than I can do. A ways down the
road, but would you like to help design phase two?

Karl

Sure! I have development systems and C compilers for PIC and Atmel
AVR. Cavelamb is probably more competent, so include us both!

So long as you each buy a copy of my book.



I was afraid you were going to over complicate things, but your articles
are pretty clear and readable.

You want things just complicated enough -- in my life I've unwound
innumerable vast snarls of kluges that were wound around core functions
that were just too simple. When you can double the complexity of the
core, make it work _right_, and as a consequence take out five times as
many lines of code and/or circuitry from the periphery, then you
understand that there is such a thing as _too_ simple.

This is why I'm kind a torn in Karl's case -- he may well be able to get
it working with a simple state machine implemented with hysteresis and
timing. Unfortunately, the only way to know for sure is to try it out.
But fortunately, if he starts with a processor that can absorb the
necessary algorithms then he can also start out simple and see how it
goes without being married to a too-simple core algorithm from the outset.

--
www.wescottdesign.com

On Wed, 09 Dec 2009 11:16:46 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:

Don Foreman fired this volley in
:

Yes, because the servo has internal position sensing feedback.

That still doesn't make the entire system a cybernetic loop. The error
signal generating equipment derives no feedback from the effector. It's a
"dead reckoning" system; the controller tells the curtain to "move to x",
and only assumes it has happened.

LLoyd

Agreed, the entire system isn't a cybernetic loop --unless you include
the operator as part of the cybernetic loop. Either way, there is a
position feedback pot in the servo. The servo is a subsystem with
feedback.

You are also correct that the process varible of interest here is
temperature, so the primary loop sensor for PID control would be a
temperature sensor -- not a curtain position sensor.

That said, curtain position is the time integral of output (motor
drive) so that creates a big fat pole in the system response. If a
secondary loop made curtain position a fn of the PID's output the
system might be both more responsive and easier to stabilize. Curtain
position determines rate of heat loss which the PID control then
matches to rate of (solar) heat input to minimize error from setpoint.
But it seems to me that Karl isn't trying to control to setpoint, he
just wants to try to prevent excursions above a max or below a min. So
a more "fuzzy" approach might be a lot simpler, more responsive and
stable with a simple algorithm something like:

start
if temp_too_high then open_curtain_a_smidge
else if temp_too-low then close_curtain_a_smidge
waitabit
goto start

On Wed, 09 Dec 2009 11:22:30 -0600, Tim Wescott
wrote:

On Tue, 08 Dec 2009 21:51:02 -0600, Don Foreman wrote:

On Sun, 6 Dec 2009 19:31:56 -0600, "Karl Townsend"
wrote:

My first winter project is on my new high tunnel (greenhouse) High
temperature control by ventilation is critical for good growing. I will
be ventilating by using a rollup side curtain. I plan to automate the
process by using a small 12 volt DC gear motor and wench. I've settled
on my mechanical design and plan to order parts tomorrow.

My query is on control. KISS is the order of the day here. I plan on two
thermostats - Hi and Lo. Also two limit switches - full open and full
closed. The control is simple - if you make Hi; roll up for a few
seconds and go to delay timer. If you make Lo unroll a few seconds and
go to delay timer. Stop on limit switches. Repeat 24X7.

I'm thinking this is PLC territory. I know nothing about them. Is there
an inexpensive simple to program unit that runs on 12 volt DC?
Alternatively, I can see a way to do it with a timer that continuously
does a few seconds on then several minutes off continuously.

Karl

If outdoor temp is higher than your minimum, if the temp ever got high
enough to open the curtain it'd stay open until outdoor temp drops.

No problem.

If outdoor temp is lower than your min but there's enough sun to heat
the space to above max with curtain closed, then the system would cycle,
alternately opening and closing.

I'm not so sure -- Karl's control rule as stated could possibly find a
sweet spot.

If outdoor temp is lower than min and there's not enough sun to reach
max temp, then the curtain would stay closed.

Which is the best you could expect, unless you want an alarm to ring so
that Karl knows he's got to go install heaters.

If you only partially move the curtain and then go to a delay timer for
a while to see if that move drops temp below max, might it take
unacceptably long to fully open on a high temp condition? The time
constant will be quite different on calm days vs windy days.

This is what Karl is describing, and you share your concern with me. I
think it could be alleviated considerably with tapered vents -- when it's
cold and/or windy the vents would stay mostly closed, so make sure that
the vents are narrow there, such that an incremental opening of the
curtain doesn't open the vent up much.

A PID controller with a temperature sensor would provide better
temperature stability, but at the expense of battery life because the
curtain would be making small moves very often.

Possibly. A controller with a bit of built-in hysteresis wouldn't. Or
Karl may find that really small motions don't drain the battery badly
enough for it to be a concern.

I was equating PID controller with the temperature controllers
available on EBay for under $50. I don't know if those have optional
hysteresis or not. I have a Honeywell and an Omega and I don't think
either of them has the option of a deadband.

You'd need curtain position feedback too.

I don't think you do, necessarily, beyond limit switches. The motor/
curtain system will just act like an integrating plant; this means that
Karl really only needs a PD controller, probably, or a P-double D (ick).

Yes, and worst case (calm day) that integrate time could get quite
long so the curtain drive speed would have to be very, very slow or
it'll just limit cycle and you could skip the PID.

Position feedback on the curtain would help if you were really going for
low power and/or precise temperature control, however. So would a
monitor on the outside temperature, for that matter.

In article ,
cavelamb wrote:

Joseph Gwinn wrote:
In article ,
cavelamb wrote:

Joseph Gwinn wrote:
In article ,
cavelamb wrote:

[snip]
I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be
needed.
I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.

The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn

There is an old saying that,
"If engineers built bridges the way programmers write software,
the first wood pecker than comes along could destroy civilization".

Yes, plus the sayings about "If Microsoft built xxx".


And there is some truth in that.

But no, I'd not design an autonomous system that need manual oversight.

IIRC, Karl said his vent was about 6 feet long.

My first fantasy was a fabric tape/shade (wide enough to cover the vent
slot)
that rolls up on rollers at each end. Maybe it has some shaped supports
to keep it snug against the enclosure(?). But there is nothing to jam
into
at the end of the run.

So all I'd be doing is rolling the shade up or down.

Well, the shade may tear. One may decide to simply clean up afterwards
if this happens, but I would think it would prove to be a big nuisance,
enough to justify some limit switches.

Given that shade replacement is manual, manual-reset limit switches (a
pair of normally-closed microswitches in series with the motor power)
may make sense, as reset is far easier and perhaps cheaper than shade
replacement.


The computer can monitor the drum and tell, within reason, where the
opening
is at any time. If we are rolling up on a fairly small shaft, just count
turns. If it's a big drum, maybe glue some magnets around the drum and
count
them with a Hall effect sensor.

You don't see that kind of proactive defense in other mechanical devices.
Printers, Plotters, Flight simulator motion platforms, CARS.

The usual solution is to make sure that the motor will stall without
harm to anything. Also using a pipsqueak motor saves money on the motor
and its power supply. But it takes a lot of engineering to achieve this
kind of balance, and so is worthwhile only for production items, not for
one-off projects.

Industrial gearmotors have *lots* of torque, so unless it doesn't matter
if the motor keeps on running forever, explicit limit switches or some
kind of mechanical torque limiter or mechanical fuse (like a shear bolt)
are necessary.


But you do have to be careful about writing any wood peckers into your
code.

Even with care, one hears the pecking from time to time.

For an extreme example, fly-by-wire bet-your-life avionics code is
developed to the DO-178B standard, which increases the cost per line of
the resulting code by a factor of about ten over the process used to
develop for instance radar signal and data processing code.

The resulting avionics code is very reliable, and yet bugs are still
found from time to time, even in systems with many flight hours to their
names.


Joe Gwinn


Ok, but make the limit switches DPXX types so I can monitor the status
in software. If something did go wrong bad enough to trip the mechanical
limits I want the software to know about it.

That makes sense, although the computer may no longer be sane enough to
care.

It would be double throw (two circuits) double throw (each circuit has a
normally-open contact and a normally-closed contact). One circuit stops
the motor, the other tells the computer why it gets no respect.

Joe Gwinn

In article ,
"Michael A. Terrell" wrote:

Joseph Gwinn wrote:

In article ,
cavelamb wrote:

[snip]

I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent.
But if the device has comfortable "over-run" areas, it might not be
needed.

I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.


Diodes across the limit switch, so it can only run the other
direction. This was common on Sat dish steering motors, and trailer
jacks. You hit the limit, and the switch opens, but the diode will allow
it to be backed off.

That would certainly work for a DC motor. Multiwinding AC motors are a
bit different, but it can be done.

I wasn't intending to design it sight unseen, but wanted to ensure that
the issue was addressed. And that software was properly distrusted.

Joe Gwinn



The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn

In article ,
Tim Wescott wrote:

On Wed, 09 Dec 2009 09:06:23 -0500, Joseph Gwinn wrote:

In article ,
cavelamb wrote:

[snip]

I would like to see limit switches at each end just for safety sake.
That would take up two bits of input per vent. But if the device has
comfortable "over-run" areas, it might not be needed.

I agree that limit switches are needed, but they should physically
interrupt power to the motor, and in no way depend on software.

The problem is that once these limits are hit, the computer can no
longer recover control, and a manual reset is needed.

The usual solution is to have two sets of limit switches, inner and
outer.

The inner limit switches are sensed by the computer, telling it to stop
moving in that direction.

The outer set physically interrupts power to the motor, to prevent
damage should the computer fail to do the right thing.

Joe Gwinn

With a DC system it's easy to set up limit switches that'll prevent a
motor from driving any further into a stop, but will let it drive out.

And even though I write embedded code, too, I still prefer to have
mechanical safety devices -- for when someone else starts maintaining my
bug-free code, of course.

Yep. I would insist, not just prefer, unless it could be shown that
fetching up against a stop was harmless.

I wasn't trying to design it, but wanted to make sure people didn't
trust software too much.

Joe Gwinn

Don Foreman fired this volley in
:

start
if temp_too_high then open_curtain_a_smidge
else if temp_too-low then close_curtain_a_smidge
waitabit
goto start


In which case, no position sensing would be necesary, at all.

If the curtain hits a limit, it just stops at a mechanical limit switch.
If the controller senses that the temperature stays a certain amount past
a warning limit either way, and isn't making an excursion toward the
desired temperature, it signals an alarm saying it can no longer cope.

That's a good idea, Don. Dead-simple, too. No PLC is necessary if the
out-of-control alarms aren't needed: Just a timer and temperature
comparator with a "safe range of temperatures" dead-band. Wait a period
of time, and decide to move the curtain, or not, then do it again, over
and over.

LLoyd

"RogerN" wrote in message
...

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
snip

Roger, a decent PID algorithm accommodates changes in conditions, and
"learns" the lead/lag characteristics of the system. Most of the even
most-basic PID controllers (ready made) have that capability.

LLoyd

It's been a while since I messed with my Basic Stamp but IIRC they used 8
bit integer math. My Basic Stamp 1 had only about 16 bytes ram, I'm not
sure that would do a PID control, maybe. I think the BS2 has about twice
that amount of ram. I'm not to great at working with integer math,
especially 8 bit.

RogerN

I looked at some of the instructions on the Parallax website and it
refreshed my memory. You can address memory as bits, bytes, or words, so 16
bit math should be OK, but on limited words. The specs for the BS2 say 32
bytes ram, 6 for I/O & 26 for variables, I guess you can have up to 13 word
variables.

RogerN