hall effect sensor on helical gear?

ep71

does anybody know if you can use a hall effect sensor to measure rpm on a helically cut gear?
also how would i go about wiring it up to display in labview?
all help appreciated

steifanc

if you have a good hall effect sensor you can use it for plusing .
a TTL suported sensor is the one to go for,
as for labview , it really depends on the daq you use and the function of the daq , all can be used for rpm but in the basic daqs 6008/9 there is no hardware timer and the rpm must be calculated using your comps clockspeed , on daqs with hardware supported timers pwm can be mesured .
all the multi function daqs will except a high speed bit train in a TTL format . so depends on your daq ,and expected rpm speed

DublinDilbert

steifanc wrote: »

if you have a good hall effect sensor you can use it for plusing .
a TTL suported sensor is the one to go for,
as for labview , it really depends on the daq you use and the function of the daq , all can be used for rpm but in the basic daqs 6008/9 there is no hardware timer and the rpm must be calculated using your comps clockspeed , on daqs with hardware supported timers pwm can be mesured .
all the multi function daqs will except a high speed bit train in a TTL format . so depends on your daq ,and expected rpm speed

There is a counter module in the 6008/9 units if i'm not mistaken! Just pipe the TTL pulses into this. If you read out the value from the counter (and clear it) each second, it should be very easy to calculate RPM.

I would guess you'd calculate RPM like this:-
RPM = 60 x OneSecCountVal / NumTeeth

steifanc

there is a counter on the 6008/9 but its an event counter not a timed counter and it only counts falling edges , so for measuring rpm if the precision of the rpm isn't critical you would be OK .
i remember doing a project before using a 6008 , and if i had to do it again i wouldn't use the 6008 but the mitsi alpha plc , its the same money but far more functions, and is compatible with labview ,
the 6008/9 can only measure voltage or a digital h/L signal, the alpha plc is far more versatile

DublinDilbert

steifanc wrote: »

there is a counter on the 6008/9 but its an event counter not a timed counter and it only counts falling edges , so for measuring rpm if the precision of the rpm isn't critical you would be OK .
i remember doing a project before using a 6008 , and if i had to do it again i wouldn't use the 6008 but the mitsi alpha plc , its the same money but far more functions, and is compatible with labview ,
the 6008/9 can only measure voltage or a digital h/L signal, the alpha plc is far more versatile

Yea but your PC knows how long a second is as it has an RTC. So if you clear the counter, wait a second, then read it, you'll have one seconds worth of pulses. Your not looking for this to be super accurate anyway. This also has the effect of filtering/averaging over one second, so can be quite handy too.

steifanc

DublinDilbert wrote: »

Yea but your PC knows how long a second is as it has an RTC. So if you clear the counter, wait a second, then read it, you'll have one seconds worth of pulses. Your not looking for this to be super accurate anyway. This also has the effect of filtering/averaging over one second, so can be quite handy too.

OK so here goes ,
the point I'm making is that if you use a 6008/9 to measure rpm its not going to be accurate , i would thing that if you were using a milling machine to drill a specific piece of steel your rpm is critical or you will melt your bits , position automation systems , rpm crucial to the process , robotics !! and the list goes on and on ,
so why isn't the rtc on the computer accurate ?

"The timer-counter is programmed by the BIOS to generate an interrupt every 54.936 milliseconds, or about 18.206 times per second. Another BIOS routine counts the interrupt requests and generates a time-of-day clock that can be read or set by other software programs. For example, Windows uses the information from the software clock when it date and time stamps files.

The software clock is useful, but it has several limitations. First, the software clock is a poor timekeeper. Its accuracy is limited by the stability of the interrupt requests. Any change in the interrupt request rate causes the clock to gain or lose time. If you leave your computer turned on for long periods, the software clock might be off by large amounts, perhaps a minute or more for every day that the computer was left turned on. It's also possible for an ill-behaved software program to use the timer-counter for another purpose and change its interrupt rate. This could cause the clock to rapidly gain or lose time.

Another problem with the software clock is that it cannot display all possible time-of-day values. The resolution of the clock is limited to the interval between interrupts, or about 55 milliseconds as stated earlier. Only times that are even multiples of this interval can be displayed. For example, 00:00:01.00 could never be displayed by the software clock. The closest possible values it can display are 00:00:00.98 and 00:00:01.04.

The single biggest limitation of the software clock, however, is that when the computer is turned off the clock stops running. On the original IBM-PC, this meant that you manually had to set the clock each time you turned the computer on. You could purchase an optional battery-backed clock for the PC, but there were several different standards, and not all of them worked with all software packages. This problem was addressed with the introduction of the IBM-AT in 1984, which included a battery-backed hardware clock as standard equipment. An AT-compatible hardware clock is included with every 'WinTel' computer produced today.

The hardware clock is based on the Motorola 146818 Real Time Clock Chip, or a functionally equivalent device. The clock is supported by the BIOS, and BIOS services are available that let software programs read and set the clock.

The hardware clock is a CMOS device that consumes very little power. When the computer is turned off, it runs on batteries. When the computer is turned back on, the software clock starts running again and sets itself (within 1 second) to the hardware clock. Although the two clocks are synchronized at start-up, they may run at very different rates and will probably gain or lose time relative to each other while the computer is running.

The hardware clock is updated once per second and cannot display fractions of a second. For this reason, it cannot be read or set within better than a second. The accuracy of the hardware clock is determined by the quality of its timebase oscillator (typically a 32.768 kHz crystal). These crystals are economical, costing less than $1 in single quantities. However, they offer only marginal timekeeping performance. They are sensitive to temperature and other factors and are often not calibrated at the factory. Even under the best conditions, these oscillators are not likely to be stable to better than 1 part per million (about 0.1 seconds per day). In actual operation, most hardware clocks seem to gain or lose time at a rate of about 1 to 15 seconds per day, with 5 or 6 seconds per day being typical. Although the hardware clock usually outperforms the software clock by a considerable amount, its performance often pales in comparison to even a low-cost wristwatch."

http://www.beaglesoft.com/mainfaqclock.htm


so its best to use a daq with a onboard clock , national instruments them selves recommend the PXI-7833R card used with FPGA hardware.
really it comes down to your alp plication ,if you can use a daq to count timed events it makes life so much easier ,as far as i can remember ni have got a taco subvi on the web of everyone to use, unless your a development engineer ,lets try not invent the wheel ,
also , using software timing, lets not forgert about Latency

DublinDilbert

What is your definition of accurate? When i said it wasn't accurate it will probably be within 5% of the actual value, which isn't bad. How accurate does the measurement need to be?

steifanc

yet again it falls back to your application, accurate to me would be .001%
if you worked with a tolerance of 5% at a RPM of 5000 you could be +- 250RPM which is quite substantial.
if you were talking in terms of a motor getting position using a 2inch pulley traveling a 5000rpm with a tolerance of 5% you can either overshoot or under shoot your mark by 42 feet .
at .001% your hitting your mark with in .25mm being quite exceptable
relative to time of course

DublinDilbert

steifanc wrote: »

yet again it falls back to your application, accurate to me would be .001%
if you worked with a tolerance of 5% at a RPM of 5000 you could be +- 250RPM which is quite substantial.
if you were talking in terms of a motor getting position using a 2inch pulley traveling a 5000rpm with a tolerance of 5% you can either overshoot or under shoot your mark by 42 feet .
at .001% your hitting your mark with in .25mm being quite exceptable
relative to time of course

Measuring RPM is very different from measuring position. You can't really use RPM measure to give you position. You'll need an encoder of some sort. One hall sensors will not create an encoder, you'll need quadrature signals, which can count up and down.

What exactly are you trying to measure/control?

steifanc

DublinDilbert wrote: »

Measuring RPM is very different from measuring position. You can't really use RPM measure to give you position. You'll need an encoder of some sort. One hall sensors will not create an encoder, you'll need quadrature signals, which can count up and down.

What exactly are you trying to measure/control?

I'm not trying to measure or control any thing , i do enough of it all day in work !!
ep71 was asking about a hall sensor ,rpm , 6008 and labview,
the only point i was making was the 6008 has no rtc ,and isn't great for measuring rpm , there is an event counter but it dosnt measure period ,u could use code as you have said , but for a high rpm you get all sorts of problems
Following the USB-6008 specifications, the pulse needs to have a minimum lenght of 100ns (both in high and low state).

As a counter is using edges to count the pulses (for USB-6008 only the falling edge) the edges need to comply with the TTL specifications which means that the rise and fall time of the pulse needs to be within the 50ns range.
If not you will have to add some additional electronics to reshape the pulses.

as for position that was a loose example, rpm is part of a calculation for position .

DublinDilbert

steifanc wrote: »

I'm not trying to measure or control any thing , i do enough of it all day in work !!
ep71 was asking about a hall sensor ,rpm , 6008 and labview,
the only point i was making was the 6008 has no rtc ,and isn't great for measuring rpm , there is an event counter but it dosnt measure period ,u could use code as you have said , but for a high rpm you get all sorts of problems
Following the USB-6008 specifications, the pulse needs to have a minimum lenght of 100ns (both in high and low state).

As a counter is using edges to count the pulses (for USB-6008 only the falling edge) the edges need to comply with the TTL specifications which means that the rise and fall time of the pulse needs to be within the 50ns range.
If not you will have to add some additional electronics to reshape the pulses.

as for position that was a loose example, rpm is part of a calculation for position .

Sorry just realised that you weren't the OP. A schmitt Trigger should clean up the output from the hall sensor nicely. If the OP is only working on a college project this should work fine. Just highlight the potential errors in the report. It would also be good to do some tests with a signal generator and see how accurate the system is, it might be pretty good.

Velocity feedback is only used as a secondary input to a position control system, but isn't the primary measurement input. Its used to slow the system down as it approaches the set point, hence doesn't need to be that accurate.

ep71

hi guys, sorry i didnt get back sooner, yes its a college project, making up a vibration rig using two camshafts with offset weights to generate a rotationg unbalance, i now have what i think is a hall effect sensor that i salvaged from a crank and trigger wheel arrangement on a petrol engine, a 6008 with labview. having a bit of bother getting any signal out of it at all at the moment!!!

DublinDilbert

ep71 wrote: »

hi guys, sorry i didnt get back sooner, yes its a college project, making up a vibration rig using two camshafts with offset weights to generate a rotationg unbalance, i now have what i think is a hall effect sensor that i salvaged from a crank and trigger wheel arrangement on a petrol engine, a 6008 with labview. having a bit of bother getting any signal out of it at all at the moment!!!

how many wires are on the sensor? There must be 3 wires, 5V GND and signal output. If there is only 2 wires you have a passive pick up coil.

Check you have a signal coming from the signal output with a scope before connecting it up to the 6008

ep71

looking at it there is 3 wires but when i pull the insulation back it appears that there are 2 wires going to the sensor ans the third is wrapped around the others like the shrouding on a coaxial cable, i have checked the output across the two wires with a scope and i get a wave output when i move a metallic object past the front of the sensor

DublinDilbert

ep71 wrote: »

looking at it there is 3 wires but when i pull the insulation back it appears that there are 2 wires going to the sensor ans the third is wrapped around the others like the shrouding on a coaxial cable, i have checked the output across the two wires with a scope and i get a wave output when i move a metallic object past the front of the sensor

Is the 3rd wire that's providing the "shield" actually connected to the sensor?

What sort of waveform do you see? sine wave? square wave?

ep71

no its not, its only connected to where the bolt holds the sensor to the engine. i thought it was an earth but when i removed the insulation it just shields the other 2 wires. the signal on the scope looked like a sine wave but it was only achieved by me moving a metal object past the sensor irregularly, i didnt have it pointing at the gear i want to measure at the time

DublinDilbert

Yea doesn't sound like a hall effect device, its just a pick up coil.

I think you should be able to run it into a schimtt trigger to generate a square wave output. But there might be some messing around.

ep71

would i be better off to just use a regular optical encoder?

steifanc

as dilbert said schmitt could be the man , there are also signal conditioners , filters and a/d converters that come with the signal express for labview , you should have this is u have a 6008

DublinDilbert

ep71 wrote: »

would i be better off to just use a regular optical encoder?

Yea optical encoder will do the job nicely and will typically have a 0->5V square wave output. Most will have 2 outputs, so you can tell the direction, but you'll only need to wire one up if your only interested in speed.