2 proxs on gear to increase resolution

[David Clement]

Hi everyone.
I have a micrologix 1400 HSC reading a prox on a 40PPR large diameter (12") gear. This gear has large trapezoidal teeth. 500 RPM max.

I read pulses for 1 second, multiply x 60, and divide by 40 to get RPM.

133 PPS = 199.5 RPM
134 PPS = 201 RPM
I need more accuracy / stability.

Can I add another prox (staggered on the gear) to increase my resolution?
How would I modify the HSC?
Another solution?

Thanks for any help.
David

 

[Steve Bailey]

In theory yes, but in practice more difficult than you might expect.

First you will have to configure the HSC to interpret the two inputs as A quad B. I don't know the ML1400 product line well enough to know if that's possible.

Second, the mounting of the proxes is critical. Because a quadrature pulse train also tells you the direction of rotation, the leading and trailing edges of the prox signals must arrive in the proper sequence.

 

[PLCDontUQuitOnMe]

If update rate is not a concern, then measuring for a longer time, ie 2 seconds would make it more accurate.

 

[JesperMP]

You are getting quantization errors, because your time and the no of pulses do not correlate.
You are probably seeing something like
133 - 134 - 134 - 133 - 134 - 134 - 133
And that becomes
199.5 RPM - 201 RPM - 201 RPM -199.5 RPM - 201 RPM - 201 RPM - 199.5 RPM

Obviously the RPMs do not actually change like that between 199.5 and 201.
You can increase the time, or increase the no of pulses counted to increase the resolution.
but the smart thing is to measure the actual time from the leading edge of the 1st pulse to the leading edge of the last pulse.
So instead of a fixed time window of 1 sec, you have the real time of 0.989 sec.
Which then gives something like
(133 x 60 / 40 ) / 0.989 = 201.719 RPM

edit: Also notice that by assuming a fixed window of 1 sec, you measurement error is generally biased towards too small values.

edit again: And if that is not enough, double the precision by also measuring time and pulses of the falling edges.
Sum the two RPM values and divide by 2.

 

[JesperMP]

I see that you are using a HSC counter.
I dont know this, but of this does not allow you to see the pulses directly in your PLC program, I suggest to go in the exactly opposite direction.
Dont measure many pulses. Instead measure only 1 pair of impulses, and then measure the time precisely. You can for example attach a half-moon shaped disk to the sprocket for the prox to sense. Then perform the same method of measuring the time of the rising and trailing pulses to accurately calculate the RPM.

edit: And then just get the pulse signal directly into the PLC, without the HSC counter.

 

[Peter Nachtwey]

Why don't people supply necessary information?

Can I add another prox (staggered on the gear) to increase my resolution?

Yes! Right now your pulses should be 360/40=9 degrees apart. A second prox should be staggered 4.5 degrees from the first. You will need to find away to count both proxes.

Another solution?

3 proxes staggered 3 degrees apart.

Provide more information and you will get better answers.
I would use software solution


I would use software because I could get that working in a few minutes.

 

[drbitboy]

1) simply filter the values (new_displayed_value = old_displayed_value * 0.9 + new_calculated_value * 0.1)
1.1) The wobble will drop by an order of magnitude; to do that with a longer time base you would have to count over 10s

2) There is, depending exactly how "[you] read pulses for 1 second," possibly, possibly, some wobble, or even inaccuracy, caused by the timing method; cf this link. E.g. if you are using a TON, then there is could easily a 0.1% error built in. I'm not saying you did it wrong, but if you are asking the question here and don't see the (a) problem, or (b) pros and cons of various solutions, then my money is that you might learn and/or teach a lot in this thread, if you stay with it. Measurement, even of digital processes, is hard.

3) You should use the 10kHz free-running clock counter (S:4) for the time base, if you are not already. For example, S:4/12 has a rising edge every 819.2ms, S:3/13 has a rising edge every 1638.4ms, and S:4/14 has a rising edge every 3267.8 ms. Just like with metric vs. english units, the actual unit of time chosen does not matter to the calculation; we already know that you don't need to update more frequently than 1Hz.

4) A phase-locked loop would be another way to get more resolution without increasing sample time; it might lose accuracy during transients, but probably not by much.

5) Sample the time (S:4 10kHz clock) of every edge in an STI routine, it is a calculation-intensive but otherwise straightforward matter to do a least-squares fit of the pulses vs. time i.e. dCount/dTime; even simpler if you assume the Time-intercept is zero.

6) This question gets asked here. A lot. Do a search.

Except for possibly (1), (4) and (6), I am not saying anything different than earlier responses in this thread.

7) If someone is paying you to solve this, a hardware solution that determines the speed externally and passes a value to the MicroLogix 1400 is probably the most cost-effective solution. I'm not saying this cannot be done in software, rather there is some benefit to not developing a square wheel when someone else is already selling a triangular wheel that has one less bump .

 

[I_Automation]

What I have done for a similar situation as add a sprocket in the shaft with a chain going to a sprocket 1/4 the size. Watch the teeth on the smaller sprocket and you have 4 times the resolution. If you need higher then change the ratio of the 2 sprockets. If the chain is taught there won't be any play or slack in the reading.
Even mounting a finer pitch gear or sprocket to the shaft will work also.
To over-engineer it add a resolver on the shaft and you will precisely know the speed.

 

[Peter Nachtwey]

I need more accuracy / stability.

After all this time we still don't know what this specification must be.

 

[GaryS]

Why not count motor revolutions
1 pulse per motor revolution or even 2 or 4 PPR
to use 2 channels of the HSC they should be 90 deg apart to accurate
what you need to count is more pulses on the same channel even on a 2pole motor it would still only be 3600 per min. The HSC is capable of reading many times that

 

[drbitboy]

Use the Event Input Interrupt (EII) Function File (cf. this link) to execute a Program File on every rising edge of the prox. Have N255 as a 43-element Data File. Store the time (10kHz Free-Running Clock (FRC) count) of each prox edge. This is what the Program file could do:

MOV S:4 N255:41              ### Measure 10kHz FRC count

MOV N255:[N255:40] N255:42   ### Restore count of previous edge of prox for this tooth

MOV N255:41 N255:[N255:40]   ### Store count of current edge of prox for this tooth

ADD N255:40 1 N255:40        ### Increment tooth index

GRT N255:40 39 CLR N255:40   ### Rollover tooth index

LES N255:41 N255:42 BST OTU N255:41 NXB OTL N255:42 BND   ### Handle FRC count rollover.

SUB N255:41 N255:42 F254:0   ### Calculate clock count difference

DIV 600000.0 F254:0 F254:0   ### Convert to RPM in F254:0

 

The interrupts can only occur at the start of a rung (of the continuous task, or any lower-priority task, presumably), or any time during End of Scan (cf. this link). At 500RPM, the number of FRC counts per revolution is 1200 (60*10000/500), so the resolution is about 0.08%, or about half an RPM, per wobble bit in the interrupt timing; at 200RPM it's about 0.03% or a sixth of an RPM. Increasing the size of the data file by a multiple of 40 drops those numbers by that multiple.

 

[David Clement]

If update rate is not a concern, then measuring for a longer time, ie 2 seconds would make it more accurate.

After it is running for a minute I do already average it to get a more stable reading.

I thought about adding another prox to increase the resolution but couldn't figure how to adjust the HSC function file MOD.

Was also looking for other ideas.

Thanks for your help. http://www.plctalk.net/qanda/images/smilies/thumb.gif

David

 

[David Clement]

You are getting quantization errors, because your time and the no of pulses do not correlate.
You are probably seeing something like
133 - 134 - 134 - 133 - 134 - 134 - 133
And that becomes
199.5 RPM - 201 RPM - 201 RPM -199.5 RPM - 201 RPM - 201 RPM - 199.5 RPM

Obviously the RPMs do not actually change like that between 199.5 and 201.
You can increase the time, or increase the no of pulses counted to increase the resolution.
but the smart thing is to measure the actual time from the leading edge of the 1st pulse to the leading edge of the last pulse.
So instead of a fixed time window of 1 sec, you have the real time of 0.989 sec.
Which then gives something like
(133 x 60 / 40 ) / 0.989 = 201.719 RPM

edit: Also notice that by assuming a fixed window of 1 sec, you measurement error is generally biased towards too small values.

edit again: And if that is not enough, double the precision by also measuring time and pulses of the falling edges.
Sum the two RPM values and divide by 2.

Yes. Exactly.
I'm going to digest this and try it.
Thanks JesperMP http://www.plctalk.net/qanda/images/smilies/book.gif

 

[David Clement]

I see that you are using a HSC counter.
I dont know this, but of this does not allow you to see the pulses directly in your PLC program, I suggest to go in the exactly opposite direction.
Dont measure many pulses. Instead measure only 1 pair of impulses, and then measure the time precisely. You can for example attach a half-moon shaped disk to the sprocket for the prox to sense. Then perform the same method of measuring the time of the rising and trailing pulses to accurately calculate the RPM.

edit: And then just get the pulse signal directly into the PLC, without the HSC counter.

How important is attaching this half moon object? I would have to get a mechanic involved and that can be difficult.
Thanks
David

 

[David Clement]

Yes! Right now your pulses should be 360/40=9 degrees apart. A second prox should be staggered 4.5 degrees from the first. You will need to find away to count both proxes.

3 proxes staggered 3 degrees apart.

Provide more information and you will get better answers.
I would use software solution


I would use software because I could get that working in a few minutes.

Thanks for your reply Peter.
David