PLC?

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

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

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.

:)

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.

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

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

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.

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

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.

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.

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.

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.

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.

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

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.

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