h3rk

Thanks a bunch, that worked. I guess I was calling the class.method wrong and not building the instance right.

That definately helped me a little better than the books I'm using, for some reason.

All that and I think I have the timer class down a little better, after seeing how you used it.

I think that flap moving all on it's own is coming sooner than later.

MP3Car.com

 

2k1Toaster

Yeah when I first started I had no idea how to use a class. Still to this day though, I dont understand using classes for things a regular method can do. The only time I use them is for obviously different pages, then custom types (like the Digital Outs, Anal. Ins, and Dig. Ins), and things that are the same that would be good to use on different pages (like a dec to binary string converter type thing).

The 1 class I took in C#, the professor was obsessed with classes. Drove me crazy. Had to make a class just to get/set a variable and add/subtract... Useless. Like Calculator class and then myCalcClass.Subtract(int a, int b)... Why not just a - b. So much simpler. That guy really ****ed me off.

__________________

h3rk

***deletes his new calculator class in shame...***

2k1Toaster

me.Laugh(true);

__________________

h3rk

While working on the heat transfer alg's I had an interesting thought. The OEM's take into account the shell of the car for conduction heat transfer, and the glass area for sun radiated heat transfer to tune their heat balance alg's that determine fan speed and door position. Glass plays a part in both of those factors. both in transparence and in coefficient of heat transfer. One trip to the local tint shop and we screw that all up. With this, we'll be able to tune for it

2k1Toaster

You going to put a photosensor on the inside of the car, and outside and measure the difference to get your tint value? Or just measure from the inside as that is the light coming through?

EDIT: and you sure are up late!

__________________

h3rk

I'm not sure that will allow me to compare apples and apples. There will be some info the user (or me somehow enetering it in table format for each model) gathering cabin volume and glass area. Then I hope by monitoring temperature changes over time, the other coefficients,fan curves, constants, etc. can be determined by analyzing what data can be obtained. Start the car park it in the shade and when coolant temp is right and whatnot, push the 'calibrate' button. After some time it may prompt for another run with different conditions. Once the coefficients are obtained, maybe only slight tuning would be required later, and the car would be ready to tackle dynamic situations like everyday use, using those constants, sunload, and temps to drive the door and the fan automatic-style.

And I might add so are you

Edit: I want to let it be known that I'm not ignoring humidity, but right now I have enough on my plate, that will come with time, it all will.

mustanglou

For what ever it's worth, I have some experience working with models and I have found that the easiest way to play with them is to use excel.

Can you tell me about your solenoid module? Where did you get it?

h3rk

I got it at rockauto.com for $54, it's AC-Delco PN: 15-72182.

I've seen modeling done in excel, and that is the first place I put the alg's to see what they should be, then I put it in the prog to see how it can be implemented.

2k1Toaster

First of the Uber Edition: http://www.mp3car.com/vbulletin/soft...ml#post1144574

If there is a graphic element in your skin that could be made easier let me know. I havent included labels or the equivalent of dead images yet. And I am still building the control options (what to do when clicked).

__________________

h3rk

Ok, update time.
I've come a long way, working on the backside of the skin.
I've continued on what I was doing in the last few threads a bit, and have a very basic control model working (.exe). I've been working on getting the Modernity climate control skin going on the new software.

I've applied thermodynamics theory to Automotive HVAC, and come up with the governing equations for each major aspect of a passenger cabin heat balance. For those of you who have a thermodynamics background, you'll know that there are some design aspects, variables in each equation that aren't known, aren't available in service manuals. I've come up with a series of self tests that will be performed initially and periodically (automatically with the software) using installed sensors (some have to be added for conversion from manual HVAC to automatic, but nothing not found in typical automatic HVAC cars). These self tests will determine the unknowns, and constantly fine tune these constants, accounting for test errors and changes like window tinting, weatherstripping leaks, paint jobs, etc. So far the theory behind these tests is pretty solid and I really think it will work in real life.

From here, I will apply these constants and sensed inputs to a series of functions that will provide top notch automatic control of our HVACs.
I have coming in the mail a complete airbox, fan, evaporator, heater, servo, and actuators for the testing that I will need to do to verify my work. I hate working under the dash!
So if there's something related, that you think should go with HVAC controls, let me know.

Here's an example of the a modeled result of one of the tests:

A 3 dimensional array for the Blend door position as required for controlling the amount of air going through the heater, found at each fan speed.

Hey 2KToaster, I'd really like to have the means to fill up, save to file, modify, and access a multi-dimensional array, or equivalent, through the skin. But at this point, no hurry. If it's on the list, I'd be happy.

h3rk

Well, I'm still at it. The biggest thing I have been working on is coming up with a means to get a reliable blower flow rate. The air box is here, it comes with an evaporator and a blower, so now I have a spare blower (2 actually). I'll be setting this up as a test bench.

The mode doors work almost the same as the picture showed, but there are some things that baffle me a little, meaning, I wouldn't have done it that way. Just by studying the door arrangement and the actuator sequencing chart I made from observing my truck in each mode, I learned a lot; most of which is about how the evaporator air(without heat) is used in heat/defrost, and how little heat flow is used when heat comes out of the panels. I'll elaborate a little on that when I get a little further.

These are going to be part of my new test bench:








One of the directives of this project is to utilize only sensors found in modern automatic control systems. But I'm worried about getting a good flow signal. Currently Mass flow rate will be derived roughly as follows(I'm not going to bore everyone with the little details...too much):
With the evaporator off and at steady state conditions:

Mflow = (Toutlet-Tinlet)c/UA(Tcoolant-((Tinlet+Toutlet)/2))

But UA was originally to be determined similarly. It's to be a compound constant (area and overall heat transfer coeffecient).

When I started I intended to use an anemometer at the recirc to come up with a fan curve and use those values. But then as I got further into things (especially after the box showed up) I noticed that there are several dynamic influences on system resistance. In addition to the effect of changing the mode, the heater door will greatly affect system resistance. And still manufacturers fan curves are no where to be found, and still, I am not some big company with big computational flow dynamics modeling software here.

In fact the goal is to make the software 'system independant'. I don't want to do this just for myself.

I want to do this through a system that can be used for other means as well, and applied to any application. Because of that I've spent a lot of time lately working on programming, and I am by no means a programmer. I'm at chapter 18 now in my C# book, ''enumerating collections" yuck. some really abstract thoughts, but very useful. I've been seeing how to accomplish things as I do the labs. I still think a pure object oriented approach is the way to do the software:

GUI would only talk to a process and processes drive outputs and retrieve inputs, they would be classes in a heirarchical structure so that they would be filled themselves with objects, and the types of objects would dictate what they do, some would take up to 4 inputs and or them, some would add up to 4 inputs etc. Any number of processes would be able to be linked together by the internal objects inputs and outputs. A minimal process would be one that just took an input (GUI event) and delivered and ouput (digital out), 2 objects within a process, processed in the order they are specified. If it were done right it would then seem easy to: fill out the required object's fields(input, output, constants, maybe a simple mathematical expression), put it in the right process and let it do its job.
I imagine there could be a pretty basic configuration utility for a user to build/edit these objects and the processes they are within, and then save them to a database to be loaded each time the software starts.
I know it's hard, I am working on it though, I'm not about to try and steer Nick in yet another direction, I just don't want to end up writing skin code that is cascaded 3/4 of the way across the page. (This is the direction I meant to steer in all actuality)

BTW, anyone else interested in this project? anyone interested in working with me on it? I'm not talking about money and entreprenuership here, as I'm dedicated to using the fusion brain, it's just a really big project, and I've only slowly chipped away on it (nothing else really on my plate).

2k1Toaster

Well if you need help with the code let me know.

__________________

h3rk

I've had a few questions about interfaces, and then later delegates (general stuff, I've seen your help in coders corner) but I think after the 15th or so time through each of those chapters, and examples I've finally got it. But it's a different game entirely, I'm sure, when you're not working someone else's guided example.
I hope to start defining classes in my process/function relational heirarchy as the first step in this, I'll have questions (frustrations) soon.
It figures my getting my feet wet would be something so daunting. How appropriate for me.


With FCC, I'm just worried about working with the kind of complex continuous control methods, using that low(er) language style xml language, and how to accomplish some of this stuff with it. I'm going to try but...for instance, The process is at this point, intended to save dynamically learned constants. How would I do that with Uber xml code? I'm still not sure how to do that one equation up there^ with the skin laguage.

2k1Toaster

It is very easy.

If you want to set a predefined variable, then that goes in all variables (The constants for cabin volume and such). As in C#, there are no such things as "constants", just dont assign the variable anything, just retrieve the value. I never saw the value of constants anyways unless it is a group of like 20 developers piecing code together it is good for debugging...

And the code is run fast, and well actually. I cannot monitor the entire evaluation process code using the TimeSpan value because it is less than the minimum time span to monitor it is that fast...

As for getting functions to wacky-my-xml-code, I am willing to help. It is simple once you get it. Maybe be easier for you to understand from a coding point of view. Basically, it looks at an if node's children. If the child is "parameter1" or "parameter2" it passes it through the same function. and it keeps passing itself in recursively until it gets to something that can be evaluated or retrieved. So nested things are like the inners of a "()" in math.

so "Mflow = ((Toutlet-Tinlet)*c)/(UA*(Tcoolant-((Tinlet+Toutlet)/2)))"



It is not pretty, but it is very powerful.

__________________

MP3Car.com