FlowSoft - The Scoop on the PTS-DM with FlowSoft

[bruce]

As the first of the PTS DM Ships

[1960FL]

OK here goes,

I am starting to get my notes together to improve FlowSoft to support European values (Metric) so I need some input here.

What are you guys doing?

Rick

[UKDoug]

Rick,

We are pretty odd in the uk. The most common bench over here is superflow which is why I guess we are all used to seeing flow figures in cfm and inches o2.

However all of our linear measurement is done in mm so trying to do valve lifts in a fraction of an inch is a bit of a struggle!

[86rocco1]

Not that it makes any difference to me whatsoever but I think if you're going to go metric, go with the standard metric units. IOW, pressure in kiloPascals, flow in Litres/second, velocity in metres/second.

I've not yet seen Flowsoft so I'm not sure what's in there but if there are any calculations for weather related corrections, I'd very much like to see temperature in degrees Celsius and atmospheric pressure in either kiloPascals or millibars (hPa). I'd personally find using inches of mercury for atmospheric pressure very annoying as my digital barometer reads in millibars and all of the local weather stations report MSLP in millibars or kPa.

[1960FL]

[slracer]

Rick, I'm not going to be a part of this, but reading your second post:

"FYI each output will be set separately so if you wanted to look at CFM at 71.1 CM depression etc"

makes me think that it would be easiest to just do a conversion of the current version answers to metric. That way, only one version of FlowSoft is needed and everyone can choose the output they want to see.

Software control can be a major headache! As a Project Manager for a 5 year, $3 Million software development program for the military, I can attest to that! Keep it as simple as possible and eliminate as many opportunities for errors as possible. JMO, Doug

[1960FL]

Doug,

Thanks for the insight, but I beg to differ with you being part of this, I still plan to add support for Pitot Tube. I just need to look over the math. Then you will be the Guinea Pig

The reasons for this are simple and self serving, I want to be able to build a Pitot flow element to use on the different carburetors we use, then be able to record flow through the motor and manifold pressure against RPM on the Dyno.

Rick[/color]

[slracer]

Rick, I have no problem with the pitot part, it's the Metric part I have a problem with being a part of. We were working with the Germans (Messerschmitt, B..., B...) and couldn't make our numbers match by about 10%. After the proverbial light bulb flashed, I asked how many lbs in a tonne. The answer was 1000 kg or 2204 lbs. OOPS! About 10%! Yeah I can visualize lbs/sq ft, but newtons/sq m ???

I'll get the bench retuned for the Guinea Pig job!

Doug

[larrycavan]

If the data is just a .csv file, as long as the end user realizes CFM is CFM and FPS is FPS, then all the conversions can take place in Excel. If, Then statements can manipulate which formulas get applied to the data based on some other selected option, eg. a simpl yes/no check box for Metric Units.

My understanding may be incorrect. Please enlighten me if I'm not getting the drift here.

I thought the whole concept was toward a database driven application. That's not what I see here. Maybe this is just the Beta version to get things rocking and rolling or something....

If Excel is going to be the power source for the data analysis, then ultimately wouldn't MSCOMM be the way to go to communicate with the serial port?

Seemingly that would contain everything to a single application. It's the thing that held me up from advancing FPexcel with the FP1. My objective had always been to arrive at a unified application that handled the hardware commands, monitoring and data crunching.

To me, it's a little cumbersome having to flip out of Excel to an executable serial application to send commands to the hardware.

MSCOMM can be used within the data analysis application [Microsoft Flavored Of Course] and eliminate the need to have more than one application to contend with for the end user....

Now there's nothing faulty in function about having one app talke to the hardware and another app handle the data analysis. It's not not a tidy arrangement...

Anyway, something to ponder I suppose.

And please don't take this as faulting your efforts. It's just that I've been down a similar road and early on realized there was a cleaner way to go. Circumstances outside of my control prevented that from happening. No matter though. Things still work very well.



Larry C



Edited By larrycavan on 1235963740

[1960FL]

[gtpumps]

[MrHijet]

What I have read in books and professional articles, in Germany (and I assume also in the rest of Europe) we use the metric format (mm) for all measurings and (still) CFM for the output.

I think they still use CFM the the air measuring, as it is much easier to compare with US based measurements.

Cheers,

Daniel

[Tony]

Many countries still used mixed units in rather strange ways.
Vehicle wheel rim diameters and rim widths are still in inches in every country around the world. But tire widths are in mm.

So you get a 205/60/16 radial tire, where the 205 is mm, but the 16 is inches. It's a crazy world we live in.

[Erik]

Some things is to be what they are
I live in a metric world but some things I just do the american way. Mesuring flow is one of them and a nother is mesuring the valve size for japan motorcycles they are mesured in mm in USA.
Why in Sweden we are 9mil persons and USA are more than 250mil

[larrycavan]

Hi Rick,

I spoke to Bruce the other day about your goals. I'm considering modifying FPexcel to work with your .csv files as imports. I just need some time to get something together. After March 27th I should have more time available to do something.

I'll holler to you then.

Larry