1769 hsc rate counter

ronny_resistor · May 22, 2021

Here is my hail Mary pass

I have a wheel that produces 33 pulses per revolution. The RPM of that wheel will be anywhere from 25.21 to 62.7 Pulses / Rev / sec. That means it pays out a wire at the outer circumference at 25.21 and as it depletes it goes to 62.7 Pulses per / Rev / Sec. This is at the maximum line speed of 300 Feet / Min.

That being said the line speed can be less than 300' feet so 30' / min is possible thereby reducing my pulses to 2.521 and 6.27 Pulses per second. I have an HSC card and no matter what i throw at it it comes out wrong. I have tried the Subtract the old value from the new value and get 4, 3 ,2 ,5 and averaging those numbers looks like ****. I do suspect that the lower speeds are not perfect as there maybe other factors that are in play here (takeup reel not being perfectly center / round. This may cause the speed to fluctuate. Anyone have any ideas on how to calm the number down ? I just need an average that shows a downward trend the Rate is multiplied into line speed.

The machines diameter is calculated with these numbers.

Regards

Ron

drbitboy · May 22, 2021

Hey @ronny,

I suggest you search this forum for posts about HSCs and frequency measurement.

What is the sample period for those values (4, 3, 2, 5)? I suspect that period is varying with the scan time of the PLC. You will need to sample the counts at a consistent period e.g. 1s or more, using timed interrupts - not TON timers - to get reasonable, less noisy data.

Does the HSC have a frequency measurement option? That might solve the problem.

Alternatively you may be able to have the HSC generate an interrupt at a fixed number of pulses (e.g. 1, or 3, or 33, or some integer set as a multiple of the line speed setpoint) and measure the time between interrupts using GSV WallClockTime to microsecond resolution. That will yield a more stable pulse rate for the diameter calculation (below).

Details

As a Chem Eng, some of the units in that post are, to coin a phrase, ******* (I used asterisks there

).

I think what you are saying is that you have

A wheel (reel) that generates 33pulse/rev(olution)
Wire that pays out from - spools off - that reel
- The amount of wire paid out by one rev varies with the circumference of the outer layer of wire at any given time
At the maximum line (wire payout?) speed of 300ft/s,
- at max circumference you measure 25.21pulse/s (not pulse/Rev/Sec)
- at max circumference you measure 62.7pulse/s (again, not pulse/Rev/Sec)
At a line speed of 30ft/s, or one-tenth the maximum, you see pulse/s rates one-tenth of the maxima
The value you are trying to calculate is the instantaneous diameter, D, of the outer layer of wire, in [ft diameter]
- The sources of the data for that calculation are (presumably)
  - LS - The line speed, presumably either as measured or as a setpoint, ft/min
  - PPR - The number of pulses in one revolution, 33pulse/rev
  - PR - The pulse rate from the 33pulse/rev encoder on the wheel/reel, pulse/s
  - The ratio of [circumference of the outer layer of wire, i.e. the wire paid out in one revolution of the wheel] to the [diameter of the outer layer of wire], more commonly known as π, (ft circum)/(ft diam), also (ft/rev)/(ft diam)
  - SPM - The number of seconds per minute, more commonly known as 60s/min

So the calculation looks summat like this:

Code:

[SIZE=3][SIZE=2][LS ft/min] = [PR pulse/s][/SIZE][/SIZE][SIZE=3][SIZE=2][SIZE=3][SIZE=2] * [SPM s/min][/SIZE][/SIZE] * [(1/PPR) rev/pulse] * [[/SIZE][/SIZE][SIZE=3][SIZE=2][SIZE=3][SIZE=3]π[/SIZE][SIZE=3][SIZE=2](ft/rev)/(ft diam)] * [D (ft diam)][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE]

On the right side, most of those units, specifically pulse, s, rev, and (ft diam), are in both numerator and denominator once, so they cancel out, leaving ft/min, which is consistent with the line speed (LS).

Solving for D is then

Code:

D = (LS * PPR) / (PR * SPM * [SIZE=3]π[/SIZE])

The only variable, and measured, quantities in that calculation are line speed (LS) and pulse rate (PR). You are seeing noise in the pulse rate, so you need a better way to measure it.

ronny_resistor · May 22, 2021

Nope the payoff unit has a Rope brake and this is a strander with Copper wire. we are currently pulling a double wire (normally 19 wire construction) I believe the pull tension as payoff reel can be seen varying in speed, it is cyclic this tells me there is a high spot somewhere. My algorithm works but i thought there would be a better way of doing this. We have tried an STI file where the count circuit has its own scan time between 50 and 500 mseconds. makes no difference. The payoff reel has a 25" diameter that goes down to 10" in diameter. the original pulses went to dedicated circuit board that has now been replaced with a high speed counter card I have done this before with a PLC input and an immediate input instruction placed in several areas of the program with good results but this HSC card I suspect cannot handle the low frequency from the proximity sensors, tomorrow I am going to try a PLC input and call the Input several times in one scan (able to do this in a SLC500 not sure if this Controllogix processor can deal with this.

drbitboy · May 23, 2021

STI ... scan time between 50 to 500 mseconds

yah that would never work: 2.52Hz pulse counts at 50ms would jump between 0 and 1 at 50ms, and between 1 and 2 at 500ms.

The problem with sampling at fixed time intervals is that the increments in the pulse count measurements would always be integers while "fractional" pulses accumulate until a whole pulse is added which makes the per-sample pulse count jump; the result would be similar to the "high spot" conjecture, though opposite in sign.

That's why I suggested measuring the time required to reach a fixed number of pulses; having the pulse generate an interrupt, to run a short program file that only records the pulse and the current μs value from WallClockTime while the main program would detect μs values and make the calculation, should provide better resolution. At 2.5Hz the time base is 400ms or 400,000μs, so in theory the resolution is one part in 400k, but the time sampling of the PLC i.e. how precisely in time it executes the interrupt program file, is probably an order of magnitude or two less than the 1μs WallClockTime. At 62Hz, the time base is 17,000μs, so the interrupt program file execution time precision might still be the limiting factor. Measuring time over multiple pulses increases the time base and therefore the resolution.

Did the successful SLC program use the 10kHz clock?

The μs values are 64-bit integers so calculating differences is messy, but I think Logix 5000 has a special instruction for that.

Logix 5000 has an Immediate Output (IOT) instruction, but I htink inputs happen when they happen, and asynchronously with the program scan.

but this HSC card I suspect cannot handle the low frequency from the proximity sensors

A High-Speed Counter that cannot handle low frequency (low-speed) pulses?

Peter Nachtwey · May 23, 2021

How many times do I have to say this? The the highest PPR encoder your HSC can handle.
Also, the HSC and PID update must be synchronous.
I have said this many times. It seems the forum forgets as soon as the topics go off the front page.

ronny_resistor · May 23, 2021

Ok what about this.. I connected the proximity sensor to an 1769-IQ16 input and ran it at low speeds and the numbers generated are steady.

So worst case scenario 10" drum x 3.14 = 31.4" so each review = 2.61 feet. At 300 feet per minute i would have 115 Revolutions x 33 pulses is 3795 pulses per minute.

Or 63.25 pulses per second can an 1769-IQ card read that read this ??

drbitboy · May 23, 2021

ronny_resistor said:
Or 63.25 pulses per second can an 1769-IQ card read that read this ??

That is ~170ms per pulse or 85ms per rising and falling edge. Probably not a problem, but that assumes a 50% on-off duty cycle from the prox hardware; if that is not the case then, without a pulse stretcher, all bets are orr. Cf. e.g. here.

The issue is how accurately you can timestamp any edge in the PLC. Also, increasing the number of edges per timestamp might improve the situation.

I am still curious why the HSC did not work, as it is able to handle a far higher pulse rate than the -IQ16 or even -IQ16F. Can you publish your code (as a PNG or PDF)?

ronny_resistor · May 23, 2021

Like I said I believe the algorithm of subtracting what came before from the current works, but the issue was the wheel was not constant a low speeds. These pulses will be used for two things one is to calculate diameter for a reduction of brake pressure during the bobbin depletion. The other will be used to compare side A vs side B in RPM if the rpms are drastically different the machine is out of balance and will need to slow down the cabling rpm. The machine is capable of rotating at 350 rpm. Keep in mind it probably weighs in around 2 to 3 to tons empty. Add 18 bobbins of copper each weighing in at 800 pounds. Fun fun and more fun.today we were at 100 rpm.

drbitboy · May 23, 2021

ronny_resistor said:
Like I said I believe the algorithm of subtracting what came before from the current works,

1) How is the pulse rate measured? Because the HSC or the -IQ16 only provide a number of pulses, not the rate. Getting a rate (pulse/s or Hz) requires a time be divided into some number of pulses. What is the time base for calculating the pulse rate? How is the time between, say, the rising edges of some number of pulses measured?

ronny_resistor said:
but the issue was the wheel was not constant a low speeds....

2) What about the wheel was not constant at low speeds? What measurement was made to make that assessment?

drbitboy · May 23, 2021

For the HSC and the slower rates (order 100Hz i.e. <<1MHz) in this thread's application, the Pulse Interval Rate method, which is basically what I have been suggesting, is described here.

ronny_resistor · May 24, 2021

We had a great day. The 590+ drives have an encoder input on C7. I plugged in my ppr 33 and connected the proximity and we got 6 RPM we even measured the frequency at one point and it was around 8 Hz. So this number will be written to the PLC and we will be running the PLC inputs as well. The point is we can now read the RPM without any fancy High speed counter card.

drbitboy · May 24, 2021

ronny_resistor said:
We had a great day. The 590+ drives have an encoder input on C7. I plugged in my ppr 33 and connected the proximity and we got 6 RPM we even measured the frequency at one point and it was around 8 Hz. So this number will be written to the PLC and we will be running the PLC inputs as well. The point is we can now read the RPM without any fancy High speed counter card.

So the 590+ drives have functionality to replace the obsolete dedicated circuit board?

ronny_resistor · May 24, 2021

We are using two brand new 590+ drives version 8 that incorporate two encoder feedbacks. One is used for the physical feedback the other is on C7 and C8 these can use a quadrature A and B signal or anything else. I did not know it existed until today we tried it and it works. Dedicated electronics build in for low frequency counting. We needed two of these circuits and the drives are connected via ethernet / Link modules so we have no problems any more. Also all I had to do was install 33 as the number of pulses per revolution and it works .

drbitboy · May 24, 2021

That was easy; cool beans!

Glad you didn't have to do it in the PLC in the end; it would have been tough to get get a result without jitter.

Thanks for the feedback.

ronny_resistor · Jun 6, 2021

Still working on the pulses

The Issue with the drive is that we are filtering the **** out of the signal. Parker has a summation filter

(Sumof #)/ # = Output. We currently have a value of 30 in there and it takes way to long for an accurate count. The same input on a PLC is calculated as:

Count for 15 seconds the number of high inputs. After 15 seconds push the count into another register and reset count.

Then we multiply by 4 and divide by 33 and we get a decent number (we use real numbers so that the number looks presentable) As we have two sides but only one regulator we add the two RPM's up and divide by 2. This works, on Friday we watched the line run and i get the feeling we will never be running anything faster than 200'/min.

There is a 1769 High speed input card as well as a 1734 high speed input card we may opt to put one of these on the machine if the speed exceeds 200'/Min.

1769 hsc rate counter

ronny_resistor

Member

drbitboy

Lifetime Supporting Member

ronny_resistor

Member

drbitboy

Lifetime Supporting Member

Peter Nachtwey

Member

ronny_resistor

Member

drbitboy

Lifetime Supporting Member

ronny_resistor

Member

drbitboy

Lifetime Supporting Member

drbitboy

Lifetime Supporting Member

ronny_resistor

Member

drbitboy

Lifetime Supporting Member

ronny_resistor

Member

drbitboy

Lifetime Supporting Member

ronny_resistor

Member

Similar Topics