I'm running a D4 and don't know if I can make that mod. I ordered a 2nd D4 which should be arriving today, so maybe I'll take it apart and see if that mod can be performed on the D4 as well.

As far as leaking, I don't think that's as much of a concern as the pump not spinning since a leak under pressure is likely to blow up your system anyway since the water would pretty much go everywhere. The problem with a leak not being able to shut down your system would therefore be solved. :)

I run an external radbox (linky) and if i had a leak in there... it wouldn't kill my system with water...
currently my RPM signal from my MCP600 does fluctuate
it runs at 3200+RPM but has been know to drop below 500rpm ... at least on the monitoring side for a moment...
that is enough to sound off alarms in my bios and HW monitor so i have since turned it off :mad:

.NET (VB preferabbly) and PIC ASM/C guy here.

Best to do the dP sensing in a PIC and then convert it to a scaled RPM signal out one of the outputs. a PIC with dual A/Ds isn't hard to come by, etierh. it'd be the sensors, the pic (and you could use one with an internal oscillator, come to think of it) and a transistor to run the signal to the 'tach. Cake if the math isn't too bad, I guess that'd be the only weak thing about the PIC - math speed.

If this is the original flow meter proposal then surely you can get the tach signal out of the meter without a PIC. If it's the dP method, then feeding it back via the tach signal seems a bit round the houses. Surely better to get a A/D via sireal, usb (or even SMBus ;) ). There's a lot more monitoring you can do once you have a multichannel A/D, such as pump power consumption (with a transducer), temp and whatnot.

Hmm.. anyway suppose you are using a conventional flow meter, would flow stop immediately when there is a leak in the loop?

How about some sort of Venturi measurement system?

Utilizing the water's electrical conductivity abilities to shortcut an electronic circuit when the water floods the measurment hose because of lowered flow rate and therefore higher pressure. Instead of using the water to shortcut the circuit a "floating metal ball" of some sort could do the trick :D

It's certainly cheap and safe, and give us both flowrate and safety. But on the other hand cumbersome and demands testing and thinking.

You don't want any kind of electrical current in the water.

Mad / Brian, we would need a desktop / background utility that will monitor rpm signal from flow sensor, by the fan port input, just as current utilities function.

The difference is a conversion display from RPM to L/M or GPH.

I will provide the conversion charts based on trials against an instrument quality flow meter.

Don't think I can get you big $$ for this, although C-Systems parent company, and AVT are good size companies, the retail section just consists of myself (part time) and Julie (sales / shipping - full time).Primary focus of both companies is industrial / OEM, with C-Systems having to maintain a retail section by original sales contract.

Even so, I am an engineer with access to just about everything needed to produce consumer products, and I love to come up with gadgets for you all :)
Many like the idea, so I will continue with development. I should have basic layout and case this weekend.

What does everyone think, wide and short, or taller with small as foot print possible?
I would need to use MAG style magnets, as we require a quad pattern to give standard two pulses per revolution, so will be at least 1.75”x1.75”.

A desktop/background/windows tray util would be pretty easy to write. the I/O wouldn't be that painful either. I like USB for it, because pretty much everything has USB. SMBus (which I've used before) is effective but the programming/API support isn't where it should be.

A util to just write out a few numbers into a simple dialog shouldn't eat much memory either... unless of course it's written in C# or VB.net (hehehehe - I've got 4GB of ram,so a 30MB app to write data to my VFD isn't a big deal).

Well I'm sorted as the Tbalancer software supports up to two flowmeters (configurable for specs of whatever meter). I also remeber that a German soft, WebTemp, supported flowmeters from tach signals.

There wont be any electrical current as long as there is a reasonable flow rate. The coolant usually does not conduct enough electrisity anyway and the system must use some other method in order to switch the computer off (floating ball).

Venturi
http://www.ame.ch/mechanik/venturi.gif

.. and this formula to calculate the velocity of the water:

http://hyperphysics.phy-astr.gsu.edu...s/venturi.html

Sorry if anyone has posted this link before.
http://www.webshop-innovatek.de/0000...3b0dc5e17.html

I'm currently working on a Tbalancer plug-in for LCDC display program.
I have it working in a stand alone app but since LCDC is written in Delphi with Borland’s Memory manager it causes my c++ DLL to crash :mad:
Now I endeavor to write it all in Delphi which I don't know very well at all... :shrug:

I'm wonder if it could enable to take dual display: by lcd (similar to Aerogate 3), besides motherboard util.
Motherboard util (MBMonitor) will take care of any flowless, shutting down to avoid risk and Aerogate3 (or Kingwin) would show us water flow. PIC could handle a programable multiplier to adjust RPM to LPM ratio (or GPH).
For that we would need a T-conection to send rpm data to both, motherboard and rpm monitor (lcd). It is possible by a high impedance entrance circuit...

delphi sucks!

No Sh!t...
but if i want TBalancer plugin to work in LCDC...
i have no other option... :shrug:

Can you get the source to LCDC and rewrite it in a proper language (C++)?

lcdc is a comercial product...
I never thought to ask... but i realy doubt the author will let that happen...

Whilst you're at it, I think it would be decent to add a water temp probe (not too difficult to integrate into the pump housing) - if you're outputting to software its just another number, no? Course, then theres calibration ;)

maybe ask him for his structures?

and, uhm... hmm... why LCDC? why not lcdstudio or something else like that?

I have LCDC software... registered version free with my orbital Matrix MX212 LCD display.
also it is just something of a challange...
I learned pascal 7-8years ago... I'm a programmer..
language should be not important...
it is just a tool
also i never realy considered another program...
lcdstudio.. will look it up...

Version 2.0 should really, really, own. esp. for graphical displays. The whole thing is written in .NET (w00t) with uber easy interfaces to use when you're doing plugins. I've interopped with speedfan (which is written in delphi) using C# before, and it worked fine. But delphi still sucks.

But .NET requires 25mb of runtime (what a waste of hard drive space).

There are already solutions from the automotive field. For instance, LIQUID LEVEL ALARM IC

[rant]
...and is a total nightmare if you're trying to interface it with a device/language that the .NET providers didn't foresee (spent a very miserable month making an already-built .NET system work with RS232 of all things... Problem was the original prototype was built by a hardware engineer who only knew VB - and the "powers that be" decided to just use the prototype as a "real product".)

If you need multi platform graphical support, have a look at wxWidgets. I've built graphical apps that (with an appropriate re-compile) work on Win, Mac, and Linux and are not bloat-ware - and is easily connected with lower level modules.
And if you want fast-built multi-platform apps, there's Java (netbeans looks pretty good). BTW, netbeans and wxWidgets are both free. Beats me why someone would limit themselves with .NET other than "doesn't know any better" - or maybe "wants to get really locked into the wintel world" :)
[/rant]

implementing something like this and having it placed in my resevoir would then have zero impact on flow. to bad my electronics knowledge sux :cry:

I have to preface this with my personal feelings. I really hate defending Microsoft. I prefer Unix. I prefer open source tools. I hate using a proprietary language locked to a single proprietary platform. I even have a license plate in my cube that reads "UNIX" with "Live Free or Die!" as the byline. I used 386BSD, back when it was the first free Unix (not counting Minix). That was BEFORE Linux was even released. I loved my SunOS workstation.

But...

.NET is a nightmare of epic proportions. I know. I've been working on a .NET project for the last 2 years with four other SW engineers (that might tell you the scope of the project). However, given certain limitations, it is better than C++ and MFC.

First, the company isn't interested in portability. I made quite a row over this, but the company just isn't interested. That makes the largest of the .NET problems go away.

Second, the company isn't interested in doing anything exotic with the program, such as interfacing with odd HW, doing anything timing sensitive, or running with a memory budget. In other words, the company is happy with bloatware.

Finally, they wanted something that is low risk. Microsoft has a much better track record than Sun. Sorry, Sun. Microsoft isn't dying like you are. I like Sun. I like Sun much more than Microsoft, but Sun isn't taking marketshare from Microsoft. It's the other way around. So, our customer base in 5 years is likely to be more Microsoft-based than Sun-based.

The benefits of .NET (same as Java) are that it does away with a primary source of software errors: memory management. I dread working on someone else's code that has a memory leak or a use of uninitialized memory. Also, the IDE is fairly nice, even if it wants gobs of memory and occasionally crashes. Gcc crashes occasionally, too.

As long as you exhale, use plenty of lube, relax and smile, using .NET can be OK. Just don't expect it to work well doing anything unexpected. Do things that Microsoft is interested in, the MicrosoftWay(tm), and it works well.

My LCD is a Crystalfontz (4x20- USB) not a MO, but I was looking at the iMon VFD unit as well.

Any hacking efforts from me will be VB as that's my background (well really I'm more of a database developer). I wanted to get some ibutton/1-wire support in there too and that has a .net API now as well.

While we're at it, my other monitoring project was to use a current transducer to measure pump (and possibly PSU) current and have a power consumption display.

I was planning to do this on 1-wire with a DS2450 and have the parts, but also considered using the Velleman K8055 kit which has various I/O options.

Any other recommended I/O solutions?

I've been a programmer for over 30 years, and I'm all for making my job easier, but .NET is just plain a bad idea. I think Microsoft is herding us all to licenced access to the "API" (which they don't want to call it anymore).

First: I'm a wintel guy mostly. When something needs to run on linux, that's fine by me - I know how to do it. but for my workstation I'm quite happy with windows (server 2003 here).

I may be way off base, but when longhorn drops, most everything that you have to do API calls from .NET now will be directly into the framework. I like the framework (and I don't call 25MB a waste) because most everything I need is already there. And that makes my life easy. Interfacing with hardware is somewhat weak now, but there are managed RS232 components for sale, or you can just interop with something else (I use Io32.dll for my VFD software) and be just as dangerous as you were in the unmanaged way of doing things.

Call me lazy, but when I can do things the easy way, I will. I still program in C and ASM on microcontrollers, though :)

Although this is never a holy war I wish to get into, the discussion is still good.

Edit: and that chip is pretty cool. I'll take a look at the sheet in a bit more depth when I'm not at work.

IMO it's especially cool at the price.
Of course, what I want is a pair of something like tyhese that can do a differential level detection - use a very small restriction and the bernoulli effect (and get the sensors at the same height) and you should see, and be able to detect a height differential when coolant is flowing. Yes, there'd be a restriction, but it shouldn't have to be much at all...

Sorry about joining in the religious war over .NET. I just had a bad experience with it. If it does what you want, then it's the tool you need. I'm just going to multiply my rates by at least three if a prospective customer mentions ".NET" and "hardware" or "communication" in the same request.