Experimental Instrumentation

[fredrosse]

You can delete unwanted posts.

[Lopez Mike]

I haven't found a good source for an economical rotary encoder that will stand continuous running. It would seem to me that a ball bearing unit would be necessary. Either digital or analog would do. Just has to run and run and run.

[barts]

I haven't found a good source for an economical rotary encoder that will stand continuous running. It would seem to me that a ball bearing unit would be necessary. Either digital or analog would do. Just has to run and run and run.

Something like

http://www.phidgets.com/products.php?product_id=3530

or better yet

http://www.phidgets.com/products.php?ca ... _id=3532_0

since that one has an index channel... looks like w/ the right board it will plug right into USB port on lap top.

- Bart

[Lopez Mike]

I can hear computers turning off all over the world as this thread leaps off into electronics esoterica.

That first one looks like the way to go. Just a section of pulleys of different sizes depending on the general size of the engine and some plain old radio dial cord or any relatively low stretch cord. I plan on trying to test engines from a Stuart 10 with a stroke of .75" to at least one I can think of that has a stroke measure in feet.

A spring to keep the cord under tension will be needed. Since the sensor will likely be making many revolutions per stoke, a rotary spring might be difficult to work out. Maybe plain old surgical rubber? Screen door spring? This all presupposes two pulleys on the sensor, one for the cord to the crosshead and one to the spring. And I'm probably missing some far more elegant solution.

Maybe no long spring but two cords. One direct to the pulley and one going the other way from the crosshead, thence around a couple of direction reversing blocks and back to the pulley. One small spring as a tensioner at one of the blocks to keep any slack out.

Calibrate the setup by moving the engine from one end of the stroke to the other. These pressure sensors have such a low volume that there will be very little heat transfer from steam or condensed water movement. I'm trying to think of some better way to isolate the sensor than a loop. Maybe a ceramic or high temp plastic tubing coupler.

A true fanatic would build this into the installation and have a small LCD screen showing both diagrams at the engine control position for optimizing the valve gear while under way. Complete with a numerical readout of IHP. I can hear Colin Glencannon rolling in his whisky soaked grave. "Foosh!"

[barts]

A true fanatic would build this into the installation and have a small LCD screen showing both diagrams at the engine control position for optimizing the valve gear while under way. Complete with a numerical readout of IHP. I can hear Colin Glencannon rolling in his whisky soaked grave. "Foosh!"

Well, I don't know if I'd go that far, but a portable setup would be pretty handy. Instead of an index pulse, you could use a piece of reflective tape on the prop shaft or flywheel and a photo transistor, and a rubber wheel on the encoder.... you let it run for a bit and the program will calibrate the encoder's counts per revolution. I'd light an LED when the tape was 'seen', and then rotate the pickup so that the pulse matches either TDC or BDC. A few small pipe tees would permit attaching the pressure sensors to the cylinder drain ports.

Once that's done, a program on the laptop could display indicator diagrams of the engine as it ran, and this setup could easily be attached to almost any engine.

- Bart

[DetroiTug]

For rotary encoders, check out www.usdigital.com, looks much the same as what Bart posted. And of course used units show up on Ebay.

The cable spinning an encoder is not very accurate. For rotation driven from linear movement, have a look at timing belt and pulleys. It needs to be something that stays in synchronization.

It should be noted as well that CPR stands for cycles per revolution. Their are four encoder edges per cycle or in "quadrature", A high and low, B high and low, high and low being 5 or 24 vdc for high signal and 0 vdc for low signal. i.e. 200 CPR encoder is 800 output pulses per revolution. Need to know the voltage too for whatever your supply is going to be, they can be either 24vdc (majority) and 5vdc.

A 5vdc encoder can be connected directly to the DB25 parallel port of a Windows 32 bit PC. Some ports only supply 3.2 volts, so an external power supply (5v wall wort) must be used. A DB25 bi-directional breakout board will work. Then you'd need some sort of software to read and display the input.

-Ron

[Lopez Mike]

I didn't make my 'wonderful' scheme clear.

I wouldn't have the encoder driven by the crank. I would have it rotate one way and then the other driven by the crosshead. Since the encoder is a quadrature type, the data system knows which way it is turning. As I said, you could mechanically position the engine at one end of the stroke and then the other or just have the software figure it out from the direction it is rotating.

No need for an index output from the encoder that way. Just hook it all up so that the encoder is generating enough counts for sufficient resolution and start running it.

[DetroiTug]

"As I said, you could mechanically position the engine at one end of the stroke and then the other or just have the software figure it out from the direction it is rotating."

Yeah, that should work, don't really need much resolution.

-Ron

[Lopez Mike]

Compared to a standard mechanical indicator, this sort of thing will have too much resolution in both linear travel and rapidity of pressure variation.

I don't have an old card handy but I think that resolving the stroke to better than 1% will equal what I was getting. And the linkages and masses involved in a traditional indicator limited the high frequency response a lot. We may need to do some filtering to get rid of small scale pressure wiggles that don't add any information.

I still think that having a real time IHP readout as well as diagrams would be a real coup. Maybe the first time in reciprocating engine history. Add some strain gauges on the prop shaft and a tach input to the system and you have BHP as well. Then subtract one from the other and you have efficiency as well.

Probably run aground while looking at the numbers!

[PeteThePen1]

Just a quick thought on the electronics side.

The Raspberry Pi is a full computer with excellent I/O facilities and about the size of a fag packet, so would be ideal for this sort of application, especially if you want portability. It runs on 5V, so battery power or a solar panel could power it all day.

It runs Linux as its native operating system, and you can get Python for it which is a popular programming language for this kind of task. The latter also supports MySQL which is both tiny and very popular so help is easy to find if you are an old wrinkly like me.

I have been using one for the past two years to monitor our solar thermal panels and heat store with 9 data streams with a Python data collection program I wrote with help from the Raspberry Pi Forum. So if you can get digital sensors for all the measurements you want, then the task of going for real time monitoring is possible for most of us. Analogue sensors could be used, but I gather than involves rather more programming to get the numbers out.

The big issue that I have not solved, is how to do some serious analysis of the numbers generated. This year's file of readings comprises something like 35,000 sets. Even something simple like graphing the points for a week is pushing the average spreadsheet. I suspect that recording a day's steaming would yield the same sort of problem as reading would presumably be taken more often than the 10 minute interval I used.

Much fun to be had on a wet and windy winter's night!

Regards


Pete