HSCE Freeze Display

[roxusa]

I have a HSCE reading 2048 PPR on one section of a machine= one revolution of machine=66"
I have a prox switch on the other sections 0 mark trying to freeze display to determine offset.
my frozen display is varying per each revolution and I believe it is a scan time issue.
I am using a 1747-L532 with a 1747 sn, I have tried bringing the prox back to the SLC on an input to bypass the RIO but got the same thing.

Does anyone have any Ideas. When the system was originally changed to the SLC to replace relay control no one anticipated adding what they are looking for now. Digital Registration along with being able to see if product is slipping between section.
It is a rather long program and if I am reading the processor scan time correctly it is varying 200-300ms

 

[dmargineau]

A 300 ms scan time is quite unacceptable for any application; a 200-300 ms variation is outrageous; what is the average scantime?

You will probably need to update the platform to CompactLogix; I don't see any way to 'squeeze' registration quality with hundreds of milliseconds of processor scantimes...

 

[roxusa]

I could be reading the processor status under scan times wrong.
Under "Current[x 10ms]S:3{low Byte}= It is changing 2 or 3

 

[dmargineau]

I could be reading the processor status under scan times wrong.
Under "Current[x 10ms]S:3{low Byte}= It is changing 2 or 3

That is 20-30 ms -quite a difference...; what is the average scantime?

 

[roxusa]

Average is always a 2

 

[roxusa]

I should not that in freezing the value of the input of hsce I am varying up to 100 pulses
mostly around 50 up and down

 

[dmargineau]

Are you Online? 2ms average for a 20-30 current doesn't quite make sense.

What is the Maximum scantime?

What is the average RPM of the shaft the encoder you are reading with the HSCE module is connected to?

 

[roxusa]

The average has a 2 in it but would that be 20 [x 10ms]

 

[dmargineau]

Are you sure? What CPU are we talking about, SLC 5/01, 5/02, 5/03, 5/04, 5/05?

Only the Current scantime (S:3 Low Byte) and the Watchdog (S:3 High Byte) have a x10 multiplier; Maximum and Average should be x1.

 

[roxusa]

I have a 1747-L532 Maximum-Average-Current & Watchdog all have a [x 10ms] next to them under "scan times" under Processor status. I am on line and rpm of encoder is only 126 at the moment which is = to 7560 boxes per hour

 

[dmargineau]

Okay, so let's presume the average scantime is 20 ms.

126 RPM = 2.1 RPS = 0.0021 RPS^-3

In 20 ms your shaft travels 0.042 rotations (roughly 0.01 degrees) which corresponds to 0.063" in machine linear travel (about 1.6 mm or 1/16")

1/16" would be the average 'error' of the nominal performance related to the scantime only; what is to be expected from the system?

A generic CompactLogix system could reduce this 'error' by one order of power (ten times more accurate).

I think 20 ms of average scan is quite acceptable for a SLC system; you might be able to reduce a few milliseconds if you programatically 'extreme' optimize the application, however, I think you are pushing the current system's limits.

 

[roxusa]

I get 1.97--- pulse per 1/16" and my pulses are varying up to 100 over 6-7 rotations
sometimes I get several in a row that are right on or 1 pulse off then it will walk up and down 20-40 pulses either direction. From what you say most of this would not be scan time. I am currently running it on the RIO with a baud of 19.2 this could add to the delay ?
also as long as the reaction time of the prox was consistent it should be ok. Anything else I'm missing.

 

[dmargineau]

Well, the scans are variable; a scan of 30 ms will increase the 'average error' by 50%.

Then every linkage which is not perfect (couplings, transmissions, belts, etc.) will also introduce errors.

Definitely move your flag proximity switch on a Local Input module; RIO will induce variable lag.

Also, make sure you examine the flag input prior to the HSCE 'snapshot' (above scanned routine or ladder logic rung) thus avoiding 'missed scans".

Again, if you determine that all the mechanical components are not inducing any additional, variable lag and the system is not performing as it should, maybe it is time to update. It is a high speed application running on a thirty years old platform.

 

[roxusa]

Thanks for all the input. I will do some tests over the weekend reverting back to an input not on RIO and also see if I am getting backlash on any of the mechanical side.