Thread: Beginning of an Automatic Climate Control System, all juiced up on Fusion

wow, just found this thread again and had lots to read!

I think it is a very safe bet to say that you have the most involved car install that we have so far. Or will have. Definately take pictures!

What is it that your software is trying to do?

And the debugger came later.

I think the first thing I did if I can remember (I cant believe it has been almost a year since I started working on this software ) was create the global lists, to support the outputs and inputs. Then got the GUI to control what should happen, and then translated the should happen to is happening through the USB code.

Debugger was added after it was communicating with me using breakpoints and manually entering a byte stream to send off, or manually reading the binary stream being returned to verify what was happening. Then I made it easier to manipulate through the debugger.

Speaking of software, I need to get back to work!

This thread looks promising, I read through the first page but im getting abit confused... your changing a manual dial type a/c to a fully automated climate control, like sense the temp and adjust accordingly? These vacuum servos are to physically turn the a/c dials?

I'm using this software as a 'testbench' for the maze of algorithms I'm going to need to make this work. Then I thought, maybe a standalone AC application might be the ticket, depending on how successful it goes;

Here's the basic psuedocode outline I have so far:

//open form
//read inputs (which I'm going to enter as text for now)
//update outputs (again more checkboxes and textboxes for now)
//read user inputs
//determine process type (can be Manual/Auto/Startup-Hot/Startup-Cold) from inputs

the process type will determine the manner in which it steps through the methods, there will have to be many more used in auto.

I wanted to call Auto/Manual 'Modes' but mode is already taken by 'where the air comes out' so I'll call them process types.

The one thing I'm running into is time:

It's going to take time for the servo to move to it's desired position. It's going to take time for temperature to react. So I'm using a 'step' button to run on a new set of (textbox) inputs. I'm going to have to graduate from that soon, to see how stable the algorithms are. I'm going to have to build simulator methods to react to outputs for the time being. But, at that point I'm going to need to slow the loop speed down to fusion levels.

I'm concerned however (cuz I'm new at this) that I might miss a user input at these slower speeds. I'm going to need to build buttons and methods that fix that I guess. Since the real application wont have textboxes for 'non-tuning' stuff, like actually controlling HVAC.

I also found a really cool article on coding PIDs, but I can't use it for my temperature door since I can only send 0,2.5,5 volts to it. but maybe for the blower.

PID

The reason why I asked about debugger, was it's been a useful tool as I rebuild, each step of the way.

Originally Posted by 2k1Toaster

I think it is a very safe bet to say that you have the most involved car install that we have so far. Or will have. Definately take pictures!

Yikes pics?!? That means I'm going to have to revise my duct tape method of touchscreen mounting. I hate working with plastic and glass(I suck, I've ruined two bezels already), I wish turbocad was available for a hire job, but I know he's swamped with a million projects too.

Seriously, I'll take pics, for sure when it gets to that point.


This has been my dream for years now, back when you guys first started I had that 'inventor's envy', I was going to build what mastero didn't, a fully automatic solution for HVAC something that would work with various types of configurations, something that would work in a new mercedes as well as an old musclecar. It would have drive circuits for vacuum, servo, stepper, etc. and a modern control panel with buttons and display so that it could be used without a carpc but still provide auto climate control to cars previously without it. You can say I had delu$ion$ of grandure. I dug in and started learning ASM and C for MPLAB, but I lost steam, it was really hard, and I'm not quite an engineer. But I'm back in it, and I'm going to do the best I can with your product. Once I'm done with my application (or while) I'll add more functionality to the software (or skin) so that people with different types can use it. It will have the aforementioned calibration utility so that it will provide precise control independant of application. And the delusions have subsided.

Originally Posted by BiGGy

This thread looks promising, I read through the first page but im getting abit confused... your changing a manual dial type a/c to a fully automated climate control, like sense the temp and adjust accordingly? These vacuum servos are to physically turn the a/c dials?

Those dials I hope to put on the shelf and never see again, one day.

The vacuum solenoids are to operate the vent doors, every one of them except the temperature blend door on my vehicle are controlled with vacuum actuators. I'm bypassing the dials and controlling them directly.

Ok, I see. I plan on doing this with my digital hvac climate control, its all buttons with one digital temp dial and a small lcd. I would think mine would be an easier project as no servos or solenoids are needed, do you agree?

diamante right, hmmm... if I recall your application uses a power transistor to drive the fan, and servomotors with position feedback on most doors. If you tie digital outs to the buttons on the controller, you should be fine. You still have a dial for temperature control, so that is where you might get into some stickyness. A lot of the module's operation needs to know what temperature you want, it's used for more than just driving that particular door, so you can't just bypass the module and drive the servo directly with analog out. And I don't know if that servo needs a pwm signal or not.
That pot is like 180-4820 ohms, so maybe a motor driven pot could be put in its place. But because of our output limitations that's gonna get tricky. and you'll have to use an AIN to tell the software what temperature youve selected. Yep, another circuit that drives a motorized pot using a (DOUT for UP and another for DOWN), a shunt or some way to see what the pots at (AIN). and you'll be set....maybe. Keep in mind analog input voltage requirements.

getting info back to the software, like current fan speed, may prove the hardest part.

I had to show someone, I'm pretty happy. Being a novice programmer, I duelled with this a little but I finally have a little program that simulates one slice of time, taking in inputs from the textboxes, and provides a driving variable that will eventually influence voltage to the servo. It wont take much to make a user configurable option to send an error signal directly, or use it for PWM etc.
Both the effect of a deltaT across the car and sunload work as expected, but I still have to figure out how to determine the magnatude of their influence.
Interior temperature reads higher than setpoint because this is only one slice of time, they will converge with time, and constant heat losses.



Soon I will be working in the time domain where the door will move on it's own. Once I figure that out (timer methods, arrays, etc) I'll put some simulators in there to help tune it.
Plans include:
-ambient simulator that uses a min and max limits with a random direction function

-using Upper and Lower temperature(eventually weighted by mode) as additional feedbback to the door drive signal, maybe replacing interior in some aspects.

-reaction simulator for interior temperature as door position changes and upper and lower vent temps change.

I still haven't got to blower and mode sections yet.

But I'm happy for now. This was a big step for me, even though appearantly I don't understand classes and overloading.(I tried to put tempDrive in it's own class, and VS ridiculed me)

When you put it in a class, you have to create an instance of it.

public class Blah {

public Blah() {
return;
}

public bool BlahThing(bool input) {
return input;
}
}

then in the main section you need:

Blah myBlah = new Blah();
bool returnValue = myBlah.BlahThing(true);

Originally Posted by h3rk

diamante right, hmmm... if I recall your application uses a power transistor to drive the fan, and servomotors with position feedback on most doors. If you tie digital outs to the buttons on the controller, you should be fine. You still have a dial for temperature control, so that is where you might get into some stickyness. A lot of the module's operation needs to know what temperature you want, it's used for more than just driving that particular door, so you can't just bypass the module and drive the servo directly with analog out. And I don't know if that servo needs a pwm signal or not.
That pot is like 180-4820 ohms, so maybe a motor driven pot could be put in its place. But because of our output limitations that's gonna get tricky. and you'll have to use an AIN to tell the software what temperature youve selected. Yep, another circuit that drives a motorized pot using a (DOUT for UP and another for DOWN), a shunt or some way to see what the pots at (AIN). and you'll be set....maybe. Keep in mind analog input voltage requirements.

getting info back to the software, like current fan speed, may prove the hardest part.

Ok, that kinda made sense. Thanks