Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

cam / crank phase tester

oemcar

Member
gents,
im a newbie to electronics forums, so don't hit me too hard- lol
looking for input on a simpler way to accomplish a project I was commissioned to do at an engine rebuilder.
assign:
develop a tester that can be used while ohc engines are being spun by dc motor to detect correct cam to crank phasing. tester must be programmable by floor personnel and diverse enough to test any version sohc / dohc app.
scope:
initially considered AB's 830 controllers, but they are limited to 4 pulse inputs- I need 5 with 4 cams and a crank sig. also- ab tech wasn't sure the 830 could
compare 5 hi speed pulse inputs in real time.
then considered the freescale etpu stuff- which seemed to be made to order here- but software programming would have taken me some time to learn... even worse- try to bring floor personnel up to speed on. I wanted something menu driven, like the AB, but couldn't locate... so that's the crux of my question-

is there a menus driven pc (preferably RLL programmed) controller that can compare 5 hi speed pulse inputs in real time? 10khz capability?

well, as a fall back due to time constraints- I relegated back to my 'old skool' background- designing at the gate level- using multivibrators as signal conditioners and gates/ decade counters to array the signals to an easily programmable dip switch format.
bottom line is I cant help but think I did this the hard way, guys- what say you??
thanks,
jim
 

Attachments

  • DSCF1347.JPG
    DSCF1347.JPG
    392.4 KB · Views: 284
  • DSCF1350.JPG
    DSCF1350.JPG
    335.8 KB · Views: 289
  • DSCF1348.JPG
    DSCF1348.JPG
    375.3 KB · Views: 256
  • DSCF1346.JPG
    DSCF1346.JPG
    730.6 KB · Views: 255
Engines don't go that fast.... Most never go beyond 6000RPM ... That works out at 200Hz for a cam..

A single pic could read all the data and send it to a PC running excel running 5 graphs... For speeds sake you could use an off the shelf PC datalogger...
 
It has been a loooooong time since I did this. If you have an automotive scope, set it up like watching alternator output but on the crank sensor. Use the spark plug pickup cable on the cam sensors to trigger one at a time. On the spark plug pickup cable hook it up directly to the cam sensor but with a 1 meg potentiometer in series. Slowly turn it up from 1 meg until it starts to trigger. You should be able to see when the cam sensors happen in relation to the crank sensors. Quick and easy but one cam sensor at a time.

Or get an electronics scope with 5 or more traces.
 
Last edited:
It has been a loooooong time since I did this. If you have an automotive scope, set it up like watching alternator output but on the crank sensor. Use the spark plug pickup cable on the cam sensors to trigger one at a time. On the spark plug pickup cable hook it up directly to the cam sensor but with a 1 meg potentiometer in series. Slowly turn it up from 1 meg until it starts to trigger. You should be able to see when the cam sensors happen in relation to the crank sensors. Quick and easy but one cam sensor at a time.

Or get an electronics scope with 5 or more traces.

yep,
would have liked to have an inductive pickup on #1 from running engine- but 2 probs-
1. firing a fresh reman engine would black the exh ports and take the 'newness' out of the crate
2. installing p/i transducer to signal #1 TDC doubled the required time to install cam /crank sensors and was poopoo'ed by manufacturing's motion/time study at that station.

so i had to design in the 180* out possibility at the circuit level
 
Last edited:
A regular programmable controller definitely won't be fast enough to measure these phase differences. You can still use a small PLC as the backbone of the system, but use some external electronics to do the fast phase/timing measurements and then then transfer them to the PLC. This still allows you all the conveniences of the PLC.
 
Engines don't go that fast.... Most never go beyond 6000RPM ... That works out at 200Hz for a cam..
A single pic could read all the data and send it to a PC running excel running 5 graphs... For speeds sake you could use an off the shelf PC datalogger...
rpm


yes, accurate to rpm period specific but,
referencing #1347- the cam reluctors are asymmetrical. signal conditioning job of the cam in monostables is to mark each transition with a .1ms leading edge...
giving me something i can compare the crank reluctor pulse window to. if i leave each pulse as delivered without this mod, unrefined cam pulse will span more than 1 tooth offset, therefore defeating the test.

datalogger suggestion is good stuff-
looked at omega and dataq. 's sites.. receiving / displaying multiple inputs in real time was not a prob... but 2 Q's thereof-

1. said suppliers listed 1 hi speed pulse input on their 8 inp models... assume it could be used for 60 tooth (58-2 for this app) crank sig.
there are dig in's also... perhaps those could be config'ed for cam in's?? not sure of read capability- would have to confer with manufacturer on this.
2. data acquisition is the front half of the equation... simultaneously comparing those indices and providing 'go / no go' determinants in real time is the back half- essentially locating the cam trigger pulse in a numerical crank position is the goal..

thanks for replies, gents-
jim
 
Last edited by a moderator:
Why not add an extra encoder on the crankshaft with a large number of pulses per rev. For example 3600. this would give 0.1 degree resolution. Have a software counter that is zeroed by the TDC sensor on the crankshaft. Then capture the value of the counter when each camshaft sensor is triggered. An alterative to the extra encoder would be a phase locked oscillator running at 3600 times the crankshaft speed. For this method to work the crankshaft speed would need to be very stable. Yet another possibility would be to drive the crankshaft with a large stepper motor (Probably this would have to be via a reduction drive.) and count step pulses.

Les
 
Are you going to try and read both banks at the same time?? The two outputs on the left bank "Should" read exactly the same as the right two... Or is this your goal, to syncronise all four cams? If you need to sync the cams then an XOR gate coupled with a pulse lengthener (555 one shot ) so you only get an output when they are not perfectly aligned...
 
A regular programmable controller definitely won't be fast enough to measure these phase differences. You can still use a small PLC as the backbone of the system, but use some external electronics to do the fast phase/timing measurements and then then transfer them to the PLC. This still allows you all the conveniences of the PLC.

'hybrid' idea might have saved some time-
I drew much the same conclusions as you @ concept phase.


Are you going to try and read both banks at the same time?? The two outputs on the left bank "Should" read exactly the same as the right two... Or is this your goal, to syncronise all four cams? If you need to sync the cams then an XOR gate coupled with a pulse lengthener (555 one shot ) so you only get an output when they are not perfectly aligned...

the goal is to check all four cams to crank position simultaneously.
I originally tried a 555, but the multivibrators worked much better at shortening the input events with configurable r/c network.
you would think the 2 like cams would match, but that would make way too much sense- lol. in this app, they were close, but not close enough to gate together. I also had to keep focus on the goal of flexibility to work on all ohc apps. so that mandated I evaluate each cam individually
 
Last edited:
Why not add an extra encoder on the crankshaft with a large number of pulses per rev. For example 3600. this would give 0.1 degree resolution. Have a software counter that is zeroed by the TDC sensor on the crankshaft. Then capture the value of the counter when each camshaft sensor is triggered. An alterative to the extra encoder would be a phase locked oscillator running at 3600 times the crankshaft speed. For this method to work the crankshaft speed would need to be very stable. Yet another possibility would be to drive the crankshaft with a large stepper motor (Probably this would have to be via a reduction drive.) and count step pulses.

Les

I didn't think of tying into the existing drive-
pretty sure, however, that would have been frowned upon. during testing on the 'mule' in my unheated shop, I noticed slight timing deviations from cold to warm,,, guessing coeff of expansion in alum. so while more resolution may seem like a plus, too much can be detrimental by causing 'false' alarms due to simple thermal exp, and production stack tolerances on machining of engine components.
thanks for replies,
jim
 
I am assuming this unit is to verify the valve timing after replacing the timing chains/belts. As from the picture you are testing double overhead cam V (6, 8, 12) engines I would imagine the unit to have 4 digital displays (One for each camshaft.) The displays would indicate the number of degrees (and tenths) that the camshaft sensors triggered after the sensor on the crankshaft. The person using the unit would just have to check that the readings were correct for that model of engine.

Les.
 
So what happened to the old fashioned and well-proven method of simply making sure all the factory alignment points match the timing marks they are supposed to? o_O

To me, this sounds like an overly complicated way of doing something that should be a normal and critical but well-understood engine building process. :rolleyes:

I'm just asking being that to make precision readings of crank to cam phasing every pickup sensor and its related indexing point on the crankshaft and camshafts will need to be precisely located to do any good and to precisely locate the in reference to the actual crankshaft throws and camshaft lobes requires mechanically indexing them first to make sure they are located properly.
 
I am assuming this unit is to verify the valve timing after replacing the timing chains/belts. As from the picture you are testing double overhead cam V (6, 8, 12) engines I would imagine the unit to have 4 digital displays (One for each camshaft.) The displays would indicate the number of degrees (and tenths) that the camshaft sensors triggered after the sensor on the crankshaft. The person using the unit would just have to check that the readings were correct for that model of engine.

Les.

please understand, les-
these are us production line workers... even tho they are the wheel turners here in the states- their level of discrimination isn't evaluating tenths...
that's not to say they aren't capable, rather theyre limited to their station's time constraints of passage
So what happened to the old fashioned and well-proven method of simply making sure all the factory alignment points match the timing marks they are supposed to? o_O

To me, this sounds like an overly complicated way of doing something that should be a normal and critical but well-understood engine building process. :rolleyes:

I'm just asking being that to make precision readings of crank to cam phasing every pickup sensor and its related indexing point on the crankshaft and camshafts will need to be precisely located to do any good and to precisely locate the in reference to the actual crankshaft throws and camshaft lobes requires mechanically indexing them first to make sure they are located properly.

well now you've stepped in it- lol
the money trail- the impetus of this program was based on the change of financial responsibility after first of this year from manufacturer to rebuilder regarding rework costs when cam/ crank timing caused error codes in the field...
thanks,
jim
ps. but that's ok.. really- situation gives electronic guys like us a chance to shine- since even manufacturer doesn't possess a gauge that fills this bill
 
Last edited:
Unfortunately I am as skilled in applied mechanics as I am in applied electronics and I can assure you that all the precision sensing electronics in the world does no good without first having a precise mechanical reference to work from on each and every application and situation.

As far as I have ever seen it all mechanical manufacturing processes have a +- tolerance as do all other items that get attached to them which means that for electronic sensors to work precisely with any mechanical system they have to first be mechanically dialed into one master reference point before their software or other such control/sensing devices have any relevant accuracy in their signal values on any other component.

The crankshaft position sensor has to be mechanically set to match the TDC of a specific piston before it has any value as an electronic reference just as the camshaft sensors need to first be calibrated to a specific cam lobe or other defined mechanical reference point that is in time with the specific piston being at true TDC or they are just as useless.

Hence the reason of the old fashioned use of dial indicators on pistons to find the true TDC Vs what a crankshaft tick mark or master crankshaft gear tooth on a damper pully says is TDC and then mechanically setting that correctly so that the same can be done next for a cam reference point Vs its timing gear indexing/key/whatever marks say.
 
Unfortunately I am as skilled in applied mechanics as I am in applied electronics and I can assure you that all the precision sensing electronics in the world does no good without first having a precise mechanical reference to work from on each and every application and situation.

As far as I have ever seen it all mechanical manufacturing processes have a +- tolerance as do all other items that get attached to them which means that for electronic sensors to work precisely with any mechanical system they have to first be mechanically dialed into one master reference point before their software or other such control/sensing devices have any relevant accuracy in their signal values on any other component.

I agree-
such +/- targets are what is needed to properly align a gauge such as this..
however, the rebuilder doesn't have access to these datapoints.. as this was my first query concerning this project. as im told, neither does the manufacturer, or which theyre willing to supply. this was a bit of a ruse to me,, however- this project dictates that I must work with what I have. so I derived relationships from a supplied (pic) control group example to base preliminary setpoints with... concluding that if I needed wider, or changed margins of acceptability, they should be accommodated by the tester design subsequent to the factors listed above.
 
Last edited:
The crankshaft position sensor has to be mechanically set to match the TDC of a specific piston before it has any value as an electronic reference just as the camshaft sensors need to first be calibrated to a specific cam lobe or other defined mechanical reference point that is in time with the specific piston being at true TDC or they are just as useless.

I disagree-
piston relationship is arbitrary to this application-
cam(s) to crank timing events are whats relative... although youre assertion is typical in the automotive field in so far as establishing cam / crank events.
 
Hence the reason of the old fashioned use of dial indicators on pistons to find the true TDC Vs what a crankshaft tick mark or master crankshaft gear tooth on a damper pully says is TDC and then mechanically setting that correctly so that the same can be done next for a cam reference point Vs its timing gear indexing/key/whatever marks say.

seems to me youre a gear head too...
my years spent in Detroit as a synchronous belt engineer for Dayco products had me on site at ford EEE in Dearborn and GM V6 powertrain in flint weekly-
rubbed shoulders with the best- which is why I totally understand your call out for standards-
all I can say to this is... its not a perfect world- sometimes money is earned on the fringes
jim
 
Last edited:
I disagree-
piston relationship is arbitrary to this application-
cam(s) to crank timing events are whats relative... although youre assertion is typical in the automotive field in so far as establishing cam / crank events.

You can disagree but the fundamental concept behind all that timing is to make sure the valve open and close at the exact right times in relation to where the piston is in its 720 degree cycle.

I know on a lot of the older engines that a 6 - 10 degrees of cam timing advance (emissions rated cams are typically horribly retarded to keep cylinder pressure and thus NOx production down at the measurable sacrifice in combustion efficiency) makes all the difference in the world for going from meeting emissions standards to picking up a good deal of power and fuel efficiency and that has everything to do with when that air and fuel charge gets let in, lit on fire and then let out again in relation to where that piston is at.

For those who don't follow what we are talking about these guys explain the basics pretty well.

https://www.hotrod.com/how-to/engine/mopp-1211-degreeing-a-camshaft/

So given that I say BS to cam timing in reference to actual piston position and location over the entire cycle not being a critical relationship.

It's the whole concept and basis behind the concept of camshaft Timing! :p


.
 
disposition noted... and now back to the cool stuff-
changed out the 74LS gates for 74AS series and noticed a significant operational advantage!!
shift times are 3x faster,, downside is they take 3x more current in open state.
 
So if piston face position and timing in relation to valve actuation is not key what exactly are you comparing in the timing alignments between crankshaft and camshafts to and for? o_O

I'm curious to know if there is more to an engine's performance than just how the pistons and valves work together in an IC engine being that as I have ever understood it the goal to make them work together the most effectively as possible to achieve the desired end results? :confused:

I'm pretty sure I can't just toss a cam or cams in an engine at various random settings with no accurate alignments to the crankshaft and other key rotating parts and make an engine work.

Or can I and I and millions of other engine builders have been doing a lot of precision measuring fussing over nothing all these years? o_O
 

Latest threads

Back
Top