h3rk

Thank you, that actually does help a lot. My faith is renewed a bit. Good thing I just finished that binary tree example, otherwise that 'passing into itself recursively' would have gone right by me. Is that in the ReadConfiguration.cs file?

When I spoke of constants, I need to use them as representations of charactaristics of the system that can not be measured easily, but will tune in after many tests. So they are going to be living constants, If this all turns out like I'm seeing in my head.

After this, who's up for re-engineering an engine control unit with the brain?


can you elaborate a bit, I'm not sure I follow.

MP3Car.com

 

h3rk

And that speed thing is an important factor, I'm sure you're aware of (by remembering back to when you were first learning) how unaware I am of how my programming ideas are going to affect speed, or speed and program performance in general.

2k1Toaster

It is found in "FunctionEvaluator.cs". The big ol' function of doom.

And now I see what you mean. You want a varaible to be initialized, and then modified, and saved to non-volatile storage correct? So the next time it starts, it would be the same... Hmmm... I will have to give this thought, but I think it can be done without too much work.

And I am trying to incoorporate what I can to help you out with this as I think this will be invaluable in the future for everyone. Also most of the re-write was inspired by you, so I sort of want it to be used!

As for the constants, I thought I had read somewhere that constants in C# are not really constants as they are in C or C++. I never use them anyways.

__________________

2k1Toaster

The best way is to try and remember how much memory everything takes... When you are initializing variables. For instance, if you initialize a variable to be used in a for loop, inside the loop, that is a lot of wasted time rather than if you were to initialize it outside of the loop and then just set its value different each time. But these things are negligable now. This was more important in the days of the "turbo button".

A good way to see though is make a DateTime object at the beginning of the code. Then when you want to see how long, make a "Console.WriteLine(DateTime.Now.Subtract(oldDateTi me).ToString())" and it will print out the time it took from when the previous DateTime was initialized to "now"

__________________

h3rk

Exactly...It's not likely to be used by many others though, I expect.



I plan to, did you get what I meant about the purist OOP approach, I wish I could show you how this DCS works, next you're in Vegas, let me know if you're interested, I'll show you more of what I'm talking about (it's hard to explain it this way). We're in the middle of an upgrade and now have some really cool new stuff, that is all about what we're doing, only it's highly polished, and I'm the one guy here that's really into it's inner workings.

h3rk

Ok, I'll lay off on trying to re-invent the wheel, that example really did help. That frees me up to spend more time with the side I'm more familiar with anyway: Nuking out this process. And besides, this C# really needs some soak time.

h3rk

I totally thought that <operation type=""> only applied where you used it in the thermometer.xml config file. And was actually going to ask you if it could be used elsewhere, and forgot.

2k1Toaster

if you look at the code, if it finds a function code, it just basically copy/pastes it in place, and uses the same function recursively. It is a very weird programming approach that I rarely ever use, but it seemed the best/easiest. And also if I change it in 1 place, it changes in all places.

__________________

h3rk

Here's a question I posted in a forum that I thought I might get a good answer on, Nothing really so far, but in all I think it has driven me towards hacking an automotive MAF to get flow indication, at least until I can prove (by verifying against measured flow rate) that the temperature based derrivations of flow are close enough. I thought that I'd post it here as well to see if anyone here has any good ideas on the matter:



Here’s a hobby project that I’m working on, and I’m hoping that I can get some help on this forum.
Background:
The project requires an air velocity measurement; sensed in an automotive HVAC system, which by design has no portion long enough to use a differential pressure/pitot tube measurement method. The airflow was originally going to be measured at one speed and interpolated based on fan supply voltage. The system airflow resistance, however, is very dynamic (varies with temperature door position, and mode). Also, some other variables in the control scheme require using an accurate air flow rate to deduce some heat transfer coefficients, used in an overall heat balance control method. Taking all of this into account, I’ve decided measured air velocity is required(fan curves for these blowers are virtually non-existant).
Looking at the normally used anemometers, I have narrowed my choices to turbine, and heated wire/thermistor (or equivalent). I prefer the thermistor solution, as it introduces less flow restriction to the system, has no moving parts that may require periodic replacement/ maintenance.
There are two likely places in the flow-path that this sensor will be placed, either prior to, or after the evaporator. Before the evaporator will provide a more constant air temperature (varies with cabin temperature in recirc mode or with ambient temperature), placement after the evaporator will introduce large, rapid temperature changes as the compressor clutch engages and disengages, but will provide the added functionality of sensing temperature in a location that is not currently measured, and would be a useful parameter to have. I’m not sure if the effect of the evaporator cooling the air during compressor operation will degrade the airflow indication. Will it?

This is a shared project that involves an analog input/digital input and output device, connected via usb to a computer. Control is done with the computer software, which means:

Sensor output has to be 0Vdc-5Vdc.
The output of the anemometer does not need to be calibrated for cross sectional flow area and temperature, this will be done by adjusting constants in the software (part of an overall project directive to allow for use in many types of vehicles). Velocity is all that is required.
Expected air flow rates are somewhat unknown, but the suspected range is 0-500CFM. Cross sectional area range is expected to be 20 insq. to 200 insq.

Questions I do not yet know the answer to:

What exactly is the signal output of the thermal anemometer most proportional to? Mass flow or velocity past the heated sensing thermistor?
Do I need to adjust the output to get velocity, so that it can be used to obtain total airflow as mentioned above?

I’ve seen the circuit referenced at this site:
http://electronicdesign.com/Files/29/1978/Figure_01.gif
http://electronicdesign.com/Articles...ArticleID=1978
-How are R6 and R7 ‘thermally coupled’?
-Is this PIC design overkill, considering the signal can be adjusted in software?
-Would the standard hot-wire method be better in this case? Where can I find an example?

Would ‘hacking’ an automotive MAF found on ebay (as long as it’s not a vortex pulse counter type) yield acceptable results?
What do I need to do to obtain linear output of the device? Noting that automotive MAF sensors, using the same technology have curves similar to this:
http://www.autoshop101.com/forms/h34.pdf

Am I not asking other important questions?
Any help would be much appreciated, I’m sorry for asking such complicated questions about such a simple concept, I just want to be sure I’m doing things right.
How would you do it?

Also with respect to placing the thermistors in a tube? Do they both go in the tube, where only one is exposed (with holes) to direct airflow?

Is there a good schematic for a simple one of these somewhere?



I imagine if it is mass flow, then there would have to be a specific area that the sensor would use. Being that (Bernoulli, I believe is responsible for this):

mass flow = density*Area*Velocity
=> mass flow = kP/kT *Area *Velocity

I suppose I would just have to use a ratio of the two areas, Pressure and Temperature to get what I need then.



Yeah, that would be great if you would. I'm not into reinventing the wheel (though it's usually my first instinct), but the ones that I found online were pretty large, industrial types that priced in the hundreds, which seems a little bit high.



^not exactly what I had in mind, and that 200CFM goes out the window when ratioed out to the cross sectional area I need it for.


Edit: One concern I do have about hacking a automotive MAF sensor (removing it from it's tube and mounting through the wall of the airbox), is that, appearantly many of them after amplifying the bridge output, pass the signal through a voltage to frequency converter prior to sending it to it's parent ECU. I guess that means I'll have to dig around inside to see as I have no O-scope, and then jumper it out. I have whatever shematic I'll need for it, but most of them don't show that level of detail inside sensors.

h3rk

I thought I would put an update up, to show that this project is up and fully alive, it's just waiting for my hardware to come up to par. If you've been poking around in the recent threads, you'll know that I am having a heck of a time getting past the basics with my brain setup. I see that hurdle being cleared in the not-too-distant future. I've pretty much put all of my time into the boring ol' basics lately.

My power transistor is almost here, the testbench airbox, vacuum solenoid block is here, I have enough temperature sensors and relays to get started, I've got a few different servos to test, I have my mini anemometer, an extra blower(for some reason), a new intel computer just for this and a Mass Air Flowmeter from some poor broke down ford which tests great with different airspeeds.

Regarding the heated wire flow meter that I will be using:

I do not intend to require it in my final setup, I intend to use it to verify that my approximations and algorithms (which use only temperature, steady state conditions, and/or timed intervals) will not need airflow measurement, yet will fully control another different setup from scratch. In the event that does not work and one is needed, I will work on a inexpensive, durable solution for adding that as a permament sensor.

My gut tells me that permament airflow sensing is going to be neccessary, but I haven't given up on plans to do without it yet.It sure would make the program smaller and easier though.

Analog out, while eventually neccessary (for variable fan speed), can be simulated in the interim.

I just need to get to where I have some I/O abilities and things will start moving in here again.

Until then....

MastaShake

if you guys need C# help, im your man. lay it on me. or anything.NET related. by the way check out Microsoft Robotics Studio, might find something useful in there :P

over 7 years C# experience

drk

Has there been any progress on this?

I'll be getting a new truck this fall, and it'll be getting the full carputer treatment. I'd love to be able to have an automatic HVAC system controlled by the FB.

I'd be willing to help develop this once I get everything together for the install (which will probably be towards Christmas time). I have some basic coding experience (C++, VBA). Unfortunately, I'm not much use right now as my current vehicle has no PC setup I could test with

__________________
Coming Soon - 05-07 Super Duty Crew Cab PowerStroke 4x4

Planns:
Completely blacked out exterior
Second Skin dampening
MP3car upgraded 7" LCD
2-way Hybrid Audio Legatia or Dynaudio front stage
USD Audio 4 10" fiberglass enclosure
Alpine PDX amps

h3rk

Yep, I'm working on this. But there has been a delay based on Fusion software development. The delay is also related to Analog output availability. If push comes to shove, I will try something else, but I hope analog output is coming down the pike. I want servo too, but I want analog out first.

Oh and my vehicle changed (completely different HVAC setup), so I had to come up with another shell (physical connections, and software methods to make the core of my control scheme perform the same functions IRL).

I should also be getting some really good HVAC info from a recognized OEM expert in the field. I'm even planning to go to one of his seminars later this year (Unfortunately I couldn't make the one that is going on this very moment).

But for right now, I'm beta testing the new MDX software, working with the developer so that it works well enough that I won't need to have my own software written at this point. FusionControlCenter software should be generic and powerful enough once completed and polish to handle this. There are a few functions I hope can be added down the line, like the ability to save variables that were calculated during runtime.

greenman100

The biggest issue is interfacing our board with your truck.

It's like writing a book in english, and trying to get the rest of the world to read it.... you need a translator, and pretty much every car speaks a different language.

Some cars use cables, some servos, some vaccum actuators... and theres many, many combinations. There's absolutely no way to make a one size fits all product.

h3rk

Oh and in corresponding with this expert, I recieved a reply that made me feel that I'm on the right track, citing that TRW uses similar scheme to what I'm doing when designing their control heads.

MP3Car.com