PLC?

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

Reply to
cavelamb
Loading thread data ...

Don Foreman fired this volley in news: snipped-for-privacy@4ax.com:

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

Reply to
Lloyd E. Sponenburgh

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

Reply to
cavelamb
[snip]

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

Reply to
Joseph Gwinn

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

Pete Keillor

Reply to
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.

:)

Reply to
cavelamb

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.

Reply to
Tim Wescott

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

Reply to
Tim Wescott

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

Reply to
Don Foreman

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.

Yes, because the servo has internal position sensing feedback.

Reply to
Don Foreman

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

regards Mark Rand RTFM

Reply to
Mark Rand

Don Foreman fired this volley in news: snipped-for-privacy@4ax.com:

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

Reply to
Lloyd E. Sponenburgh

No problem.

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

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.

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.

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 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.

Reply to
Tim Wescott

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.

Reply to
Tim Wescott

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

Reply to
Tim Wescott

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

Reply to
cavelamb

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.

Reply to
Michael A. Terrell

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.

Reply to
Tim Wescott

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

Reply to
Don Foreman

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.

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.

Reply to
Don Foreman

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.