Home control

> > > If you were defrosting by a heater something like a heatsink or > > > radiator that was being refrigerated to cool it, but was operating =

=A0in

> > open air and not in a closed cabinet, it would be slightly more > > > beneficial from a power saving viewpoint to let the defrost heater's > > > heat dissipate first before re-starting the compressor. > > > Given that our natural gas is 80% cheaper than electricity, and going > > lower. =A0I might replumb the fridge with (gas) hot water pipes, with > > electromechanical water valves. =A0Can i use plastic sprinkler valves > > for warm water? =A0I can install the valves at the outlet, so they won'=
t
> be too hot anyway. > > =A0 =A0Items made with the gray plastic for sprinklers isn't certified fo=
r
indoor use. =A0It is low pressure & low temperature rated and easy to > break.

Added CAE, where some embedded designer are. We started with defrosting the fridge, perhaps controlling the microwave, and piping hot water through the fridge into the toilet. This way, we can defrost the fridge everytime we flush the toilet. However, in case we don't flush the toilet often enough, we need a PIC to monitor the toilet as well.

We are going to need defrost cycle counters, duration timers, target temperature, pipe temperature and toilet counters. So, first thing is to build the counters. I've decided to build with 42 LEDs and 4 595 shift registers. See:

http://173.224.223.62/pic32

Reply to
linnix
Loading thread data ...

=A0in

s

n't

for

This should do it:

while(1) // loop forever { temp_fridge =3D read_temp(0); // Fridge temperature temp_exch_beg =3D read_temp(1); // Temp. at beginning of exchanger temp_exch_end =3D read_temp(2); // Temp. at end of exchanger temp_room =3D read_temp(3); // room temp.

if(temp_fridge < temp_target) { compressor(TRUE); sleep(TIME_COMPRESSOR); compressor(FALSE);

temp_delta =3D read_temp(2) - read_temp(1);

// push latest value on data stack push_comp_temp(temp_delta);

// if heat exchanger temp. delta is decreased, time to defrost differential_temp();

if(defrost(TRUE)) { heater(TRUE); sleep(TIME_HEATER); heater(FALSE); } }

led_display(temp_fridge); sleep(TIME_IDLE); }

Reply to
linnix

BEGIN_ATOMIC_OPERATION

END_ATOMIC_OPERATION

(using "temp" in an identifier raises ideas of "temporary")

I assume you really mean: if (temp_fridge > temp_target) // fridge too warm; cool it

Do you really want to run the compressor open loop like this? Granted, you want it to stay ON for some minimum amount of time lest you end up forcing it to turnon and off to quickly. But, you probably also want it to stay *off* for some minimum time once turned off. Your alorithm (above) could see it turned back on AS SOON AS it is turned off!

WTF? Where's it going? Why do you need it?

Is this computing something? Preumably, it is impacting the return value of the defrost() invocation which follows.

See compressor comments, above.

Note that this could just sit and oscillate -- heater warming up the fridge causing compressor to turn on to cool it down, etc. If that *can't* happen, how does your code make that apparent?

IMO, a better approach would be to have "handlers" for the compressor and heater that embody the rules appropriate for their indiviual operation (ie., a compressor shouldn't be restarted within N seconds of having been stopped a compressor should run for at least M seconds once started, etc.).

THen, have a supervisory task that decides what it would *like* to see happen. It can have history so it knows not to get into an oscillatory mode, etc. It conveys its *requests* to the handlers. And, then watches the actions of the handlers in making up its mind what it

*should* do (i.e., if the compressor didn't turn on when requested, then any part of your control algorithm that is predicated on the assumption that it is "running" is inapplicable. It's only running when the handler *says* it is running. Your control task has to cooperate with its "subservients" else it makes silly control decisions.
Reply to
Don Y

we

is

=A0 =A0 // Fridge temperature

beginning of exchanger

end of exchanger

=A0 =A0 // room temp.

l it

Yes, it does. In fact, the TIME_IDLE is several times more than TIME_COMPRESSOR here. We know that the compressor is main function of the fridge, so we need to keep it going often. Yes, we still need to work out the timing parameters.

after a TIME_IDLE. Even if not, it's no worst than a dumb open loop fridge (most existing fridge).

ad_temp(1);

ck

Here, we want to push the compressor efficiency onto a data stack. Namely, how much temperature change did we get for a certain run time.

is decreased, time to defrost

Yes, computing the slope of the temperature curve. In other words, how well is the compressor working.

Turn on defrost, if compressor efficiency is getting low.

R);

Yes, details, details that we still need to work. This is just a starting point for the high level design (i.e brain storming). Thanks for your comments anyway.

Reply to
linnix

Why isn;t the compressor being driven directly by the temperature? I.e., a control loop that ensures the temperature reaches its setpoint temperature.

if (fridge > target) { compressor(ON); sleep(MIN_COMPRESSOR_ON_TIME) while (fridge > target) { // twiddle thumbs } compressor(OFF)

// check to see if defrost needed

This is still suboptimal as you want to also enforce MIN_COMPRESSOR_OFF_TIME, etc.

(Multitasking makes things like this just *so* much cleaner!)

I think existing refrigerators use closed loop temperature controls. To verify this, time how long the compressor

*tends* to run. Then, open the door *wide* and see how long it runs (and *if* it ever shuts off!)

Fine. But where's the *consumer*? After of iterations of this loop, that stack is going to overflow.

defrost

Where is that result? Who uses it?

OK, presumably determined by the "differential_temp()" invocation. And, presumably that is also consuming the push_comp_temp()? None of this is clear from your code (why cant you just pass the "temp_delta" directly to differential_temp()?

Reply to
Don Y

arm; cool it

f

With ice buildup on the heat exchanger, it will be wasting energy to run the compressor. Some most fridge have a timer based defroster to halt the compressor and heat up the pipes to defrost it.

Surprisingly, no. The OP of this thread has a timer based control, and so does my five years old fridge (broken and stored for two years).

read_temp(1);

stack

Yes, that's why we need a big data stack, as much as 32K bytes. The time constants are relatively long; so a few K should be enough.

lta is decreased, time to defrost

The following function, deciding whether to defrost or not.

Yes, will be there when we are ready to post the result. We are still working on tests and evaluations.

We are still debating whether we should do it with a low end PIC, or high end PIC32 just in case we need it.

Reply to
linnix

--
You're doing nothing of the sort; you're trolling and posting
nonsense.
 Click to see the full signature
Reply to
John Fields

I always hear that, when people running out of reasoning to argue.

That part is just a joke. I guess you can't take a joke.

Yes, that why we should start with PIC32 and not PIC12 based PICAXE. So, you agree that PICAXE is useless here, right? Why bother with low end chip and end up with problems later on.

Reply to
linnix

--
Well, when reason fails and all you post is nonsense, like 14 LEDs,
PCBs with connections that go nowhere, and a slew of pushbuttons for
 Click to see the full signature
Reply to
John Fields

ill

The connections go to the back of the CPU board

http://173.224.223.62/pic32/cpu.jpg

There are additional headers on the PIC32 CPU board for buttons.

Reply to
linnix

e:

still

Got some rare pinned themisters. Newer one are usualy smd. Cleared out their inventory; oh well, only 20; wish they had more.

This 10K themister has good response at room temperature. I tie it to

+5V via a 10K resister and took some readings between 60F and 70F (normal operating range of furnance). Outside ranges are probably not accurated, but don't care for now. Here is my calibration table.

// maximum value is 1023 int tval[30] =3D {950, 940, 930, 920, 910, 900, 890, 880, 870, 860, //

50s 850, 840, 828, 812, 805, 790, 775, 760, 750, 740, // 60s 730, 720, 710, 700, 690, 680, 670, 660, 650, 640 // 70s };

Each room controller (PIC32MX) needs to measure and report it's temperature and forward commands to hit the fan. Plan A is using USB WiFi. Got it enumerated and initialized, but don't know what to do next, i.e. channels, WEP and setups. So, plan B is using USB Bluetooth. Hopefully, i can setup and pair the USB/BT on another PC and move it to the PIC. Still waiting for my after chrismas gift to arrive ...

For the fridge, pobably need a different themisters and/or circuit. This one does not seem to work too well at low temperature

Reply to
linnix

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