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