1769-HSC CurrentRate

PLC Pie Guy

Member
Join Date
Jun 2013
Location
Halifax
Posts
1,144
Hey Folks.

A little issue today with a 1769-HSC.

I'm using a 1024 PPR encoder. Connected to a 1769-HSC Card. On my test bench the card is in an L24ER V30.11 and on the machine application its in an L35E V20.18.

My issue is this. My test bench PLC is giving me the I.Ctr0CurrentCount as well as the I.Ctr0CurrentRate and the I.Ctr0PulseInterval. No problems.

The machine application is giving me the current count and the pulse interval but not the current rate, that's the one I need! But the rate is 0. I cant find a difference between the 2 configurations except the PLC itself. I have all the configurations set the exact same. Preset, Hysterisis and Scalar are all set to 1 and the Update Time is set to 1000 ms. Ring Counter Mode, Pulse Internal Direction, and Reset On Rising Z is enabled.

Not sure what I'm missing... What would be the difference between the two PLCs??

Thanks for any advice
 
I should mention that I have no errors and my ModConfig bit IS set, so I'm confident the configuration is good. I'm reading that the Rate count is not supported in an L32 but nothing about the L35 at all.

Thanks
 
PLC Pie Guy said:
I should mention that I have no errors and my ModConfig bit IS set, so I'm confident the configuration is good. I'm reading that the Rate count is not supported in an L32 but nothing about the L35 at all.

Thanks

Where did you read that?...

I'm looking live from my desk onto the network at a 1769-HSC in a 1769-L32E r20.12 chassis on the plant floor. It has a quadrature encoder wired from an SEW Movimot on a machine's main drive conveyor. It's used for track and reject. I have active values on Ctr0CurrentCount, Ctr0PulseInterval and Ctr0CurrentRate (47,400 in my example). I use the CurrentRate value to constantly compare it to a threshold value it should not fall below, else stop and alarm for encoder failure. Also, the module input Ctr0RateValid = 1.

I don't have an L35E to double-check for you but running a slightly older revision 20 firmware in an L32E, and working as you would like, should give you a glimmer of hope for the L35E?

PLC Pie Guy said:
...Reset On Rising Z is enabled

Are you referring to the module properties setting here? If you are, is it not "Preset on Rising Z"? It's "Preset" under my module profile, at least?

Try poking a "1" into the HSC's output image at address: Local:x:O.Ctr0ResetRisingEdgeZ and then reset it to "0" once more.

Then test again and see does Local:x:I.Ctr0CurrentRate come to life?

Regards,
George
 
Thanks For the reply!

"Where did you read that?... " I thought somewhere in the 101 technotes IV looked at today. I can't find it now, I was wrong about that.

As for the "Reset On Rising Z is enabled" Your right. It is Preset On rising edge. Typo on my end. Apologies.

Now for the solution you proposed. I don't understand why... but it worked! I first tried setting Ctrl0RisingEdgeZ to 1 with the Ctr0En set to 0, it didn't work, then I tried while Ctr0En set to 1 and it took off.

Why???

THANK you for the help!!!!
 
I'm realizing now that I have to keep the Local:x:O.Ctr0ResetRisingEdgeZ set to 1 in order to get the rate to keep moving.

On my test bench, It can be a 0 or a 1.....
 
PLC Pie Guy said:
...Now for the solution you proposed. I don't understand why... but it worked! I first tried setting Ctrl0RisingEdgeZ to 1 with the Ctr0En set to 0, it didn't work, then I tried while Ctr0En set to 1 and it took off.

Why???...

...I'm realizing now that I have to keep the Local:x:O.Ctr0ResetRisingEdgeZ set to 1 in order to get the rate to keep moving...

Glad to here it has kick started. Sometimes that is all it needs.

As I'm sure you are aware, the Z output is an index signal that is pulsed once per revolution. Does your encoder have a Z output (it appears to have), and if so, does your application require this signal?

You have "Preset on Rising Z" enabled and you have set a "Preset" of "1". This means that when an index signal is received i.e. a Rising Z signal, the Preset "1" should be written to "Ctr0CurrentCount". This means that the counter is configured to reset to "1" after every revolution. So the counter should only ever count up to how ever many pulses it usually receives for one revolution. Let's say "1024", then "1", then "1024", then "1", and so on. Your counter might be signalling the controller or a HSC output at a particular count like at "1" or "1024". Or, if using HSC outputs, there may be certain ranges configured on the module's "Output Configuration" tab?

When the Rising Edge Z signal is detected, and the Preset loaded to the counter, the input "Ctr0RisingEdgeZ" is also latched ON. However, you must programmatically reset or unlatch this Rising Edge Z signal. Otherwise "Ctr0RisingEdgeZ" will latch the first time and then remain latched ON. While latched, you cannot detect further Rising Edge Z signals and "Ctr0CurrentRate" will freeze at whatever value it was at when the Rising Edge Z signal was triggered. If only starting off for the first time, and the rate is at "0", then it's possible that the first Rising Edge Z pulse will be detected before the rate has been calculated and displayed. So it appears to be frozen at "0".

You have "Update Time" = "1000" ms which is a relatively long time (default = 10 ms), but it depends on the application. This time interval is used to calculate the rate of the pulses. The number of net counts, net change in "Ctr0CurrentCount", during that period is converted into the "Ctr0CurrentRate" value, providing an average pulse rate. You set the "Update Time" to allow enough time to calculate the slowest expected frequency. If that is around 1 second then OK. So, if the Rising Edge Z signal is detected before the 1 second update time elapses, the rate will not have been calculated and will remain at whatever value it was at, until you reset the Rising Edge Z signal.

To reset the latched condition you must transition the output "Ctr0ResetRisingEdgeZ" from "0" to "1" during the scanning of the high speed counter i.e. when "Ctr0.En" = "1" (as you have now realized). Once reset, the rate will begin calculating again, after 1 second update time has passed, and should display a value.

Remember, the reset only works by transitioning from "0" to "1" during scanning after the Rising Edge Z signal has been latched ON. By keeping the output "Ctr0ResetRisingEdgeZ" = "1" permanently, you are not allowing the Rising Edge Z signal to latch the input "Ctr0RisingEdgeZ" again and this is why it is not interfering with the "Ctr0CurrentRate" calculation.

Like I said, you have kick started it. But, again, do you need that Z index signal at all? You are not using it when you set the "Ctr0ResetRisingEdgeZ" output permanently to "1" on the machine application to get "Ctr0CurrentRate" active. If you don't need it then disable "Preset on Rising Z" in the module properties. That is how mine is configured and I have an active "Ctr0CurrentRate" value with the "Ctr0ResetRisingEdgeZ" output set to "0". If you do think you need it, or would prefer to leave the machine as it is, then you will need to add toggle logic to handle the resetting of "Ctr0ResetRisingEdgeZ", else that rate is going to remain static.

I've since found this but it doesn't really explain a whole lot. It just mentions the issue and fix...

33022 - 1769-HSC Current Rate Freezes when configured for Preset on Rising Z
Access Level: TechConnect

PLC Pie Guy said:
...On my test bench, It can be a 0 or a 1...

I would first check if there is any hard-coded logic for the HSC module in the machine controller, and not in the test controller, which may be influencing its configuration. I would also look at the two HSC modules (there are two in play here yes?) and check if they are the same hardware Series (A or B). I would also check the RPI for both modules for any difference. Also check the controller scan times for differences, and so on. Any little difference might tell us something.

Regards,
George
 
Last edited:
Good Morning Geospark.

First. Thank you for the reply. That's more information than I expected. I have been away for a while hence the delay to reply.

First I will answer the question you asked me. "As I'm sure you are aware, the Z output is an index signal that is pulsed once per revolution. Does your encoder have a Z output (it appears to have), and if so, does your application require this signal? "

The answer is that my encoder does not have a Z output signal. I'm planning using it on a production line to give RPM as well as fire line peripherals at position based intervals. The encoder is not an absolute encoder so I'm using a proximity switch mounted on a 1:1 gear with the line positions to reset the HSC count to 0. (Formerly 1, as you pointed out to not be a good idea)This is why I have "Preset On Rising Z" set.
Lets say the encoder counts to 360 pulses on one machine cycle, I will tell Filler A to fire at 150 or a glue gun to fire at 310. I'm doing this by using the configurable outputs on the card itself. Still in the testing phase but this seems to work as desired.

I have tried the method you mention this morning with the UNLATCHING the Ctr0ResetRisingEdgeZ and already, somewhat of an improvement. My rate is still acting a little crazy though, not stable at all and it makes my RPM calculation spit out some random numbers.



What I have is Ctr0CurrentRate MUL by 60. Then I divide that result by 362 which is how many counts I get before the Z pulse happens, this is one full revolution or position of the machine. I am expecting to get the Parts Per Minute of the line from this calculation and sometimes I am. At higher speeds, it seems accurate and fluctuates some. However, when I run at slower speed, the pulse rate is showing sometimes negative values, higher and lower values and almost never seems accurate when comparing to the old method I use of a proximity switch and a timer to RPM equation. I know, the first thought is, what if that calculation isn't accurate. I also compared with a stopwatch and good 'ol manual counting and its good. The average speed I'm looking at is 100 Parts Per Minute. Or, (about) three turns of the encoder. The RPI of the card is defaulted at 20MS.

What can I do to smooth this out? I'm watching the pulse rate go anywhere between -3700 to 1000.

Do I have to spin the encoder faster to give a proper rate

Thanks a billion for the advice on this! The advice is appreciated!
 
I wanted to add something as I am looking at this again briefly this morning. The line in question is running slow. About 11 positions a minute. Meaning my encoder is turning approximately 1 third of this or about 1086 pulses per minute. My rate however from the card was at 0. Never showing more than that unless I speed the line up a bit. To the point where the Ctr0CurrentRate was showing 200. Then it drops back to 0, then up to 300. Jumping randomly and any slower it showed 0.

I tried several things this morning. I disabled the Preset On Rising Z parameter. It made no change to the way the rate was behaving. I also set the counter mode to Linear Counter, again just to try, not expecting it to fix my problem. Then I put everything back the way it was.

I also moved the rung of logic that is unlatching the Ctr0RisingEdgeZ to after I evaluate the rate and move it into an RPM calculation. Again, just to see if it had any effect on my rate.

I even hooked up another encoder this morning at the PLC just to spin it and observe, it showed the very same characteristics. I had to spin it enough to get the rate up to 200 to see anything in the rate value other than 0 with the Counter Update Time set to 10MS...

Now, lastly I changed the Update time in the counter configuration to 100MS from 10MS and it seems, at a very slow speed to be giving me back a slower rate. Also, its slowly changing at a realistic rate rather than jumping up to 400, then 300, then 0 and so on, its looking smoother. I can slowly spin the encoder in my hand and its calculating 2, 3 RPM which seems practical for how slow I'm turning it.

Through all of this I might add, my position is behaving as expected! Counting up to 362 and getting reset by the prox.

I have yet to see it run at any speed with accuracy. Hopefully later today but I'm confident iv got something going on with timing, RPI or something related to how this rate is being calculated. I'm expecting that when I do get to see it run faster, the rate calculation will be giving me a value that is off from the actual of about 7 Machine positions. This was the case yesterday as I fiddled with this Counter Update Time.

I'm really thinking about trying to re-sprocket this to get the encoder running faster even at a slow speed to see if it helps. I see a lot of these applications are using the encoder mounted directly to the motor shaft! Spinning much faster than I'm doing right now.



Ill update again once I can see a speed up, probably in the AM.


Thanks for any interest in this thread.
 
What an unlikely turn of events....

This AM I wanted to put my head in a vise! I was really thinking about re-evaluating my chosen career to become a Walmart Greeter or something simpler. Perhaps the electrical section at the hardware store. You know. No worries kind of work.
That's my endgame though, I cant invoke this plan just yet!!!! This HSC has almost pushed me there but then..........

I went at it again today. I finally had the line to myself, no sanitation going on, no other maintenance happening, no locks on, so at it I go.

The first thing I try is the same thing I have been doing. Wouldn't you know, it was working as expected. The rate was solid and clean.... I changed speeds a bit and then noticed the rate going crazy again. I decided to remove the Z input on the card from my proximity switch. Then, like magic, the rate smoothed out. I put the wire back on the card, right away, the rate wouldn't work anymore. Then I saw it...... The tiny little flickers that were popping up on the Z Input LED. Fast and dim. I could hardly see it without getting really close.

Eureka!! Its a noise issue on the prox. As soon as I went to closely examine the proximity switch I saw the same behavior from it. A tiny flicker on the LED when the drive motor is running but only when the switch is mounted to the metal frame of the line.

So back to basic noise mitigation I go.

First I disconnected the motor leads at the load side of the disconnect and started the drive. Its a PF525, 10 Horse. I noticed that just with the drive running, my switch was flickering, no motor running. So , something on the cable / panel side.

I built this panel and production line so it was easy to narrow down. Some goofball, at some point in the last however many moons, had bypassed the drive's load side reactor with a few Blue Wire Nuts.... Why? I do not know. Even better. I think it was that "It Wasn't Me" guy again. He keeps doing things like this!

I re-connected the reactor and a quick auto tune, I am running with no flickering of any switched or Input LEDs now!

RATE is perfect.

I finally feel like I have an understanding of this card and I know that I don't have to question what I do know. I was really wondering earlier.

Sometimes these things can drive a person crazy!



Just in case anybody is wondering about the motor lead. It is drive cable, shielded, 1000V rated. It is dropped from the ceiling straight to the motor in aluminum rigid conduit. It doesn't get even close to any other wiring and exits the control panel on the opposite side of the control wiring.


Thanks again to Geospark who provided me with a wealth of information and anybody reading this thread.
 
See, I knew I'd figure it all out for you! :p

Well done.

Seeing as you built this MCC yourself - one thing we should always bear in mind is that just because we've moved to fancier and more compact ways of controlling motive power, and further away from standard DOL starters, it's still important to segregate, and where necessary, mechanically screen control sections from power sections. Your example here of the adverse effects of harmonic distortion from an AC drive on nearby control wiring is excellent at demonstrating this.

Remember, the load reactor was fitted to the drive to assist the motor in overcoming things like long motor lead effects, surges, overtemperature and to extend the life of the drive. They are not normally specifically fitted to reduce interference within the MCC. This should be considered and mitigated separately.

Happy counting!
George
 
Happy counting yes.

But now!!! I have to find this noise issue.
I'm not sure where it could be happening. All shielding practices and grounding practices were followed properly. Also this is the only symptom of any noise Iv seen on this line. I am even running an Ethernet encoder on the line as well, its always happy.

Solid ground to the main building from the cabinet as well.
More investigation is required. Also perhaps a new thread. This might not be a place for a noise discussion.

Thanks!
 
Oh MAN!!!

It has stopped working on me. We ran for 2 days with the RATE being solid. The operators were loving the accuracy and everything was going well.
This morning I start adding a bit of configuration for the Outputs based on active ranges. Simply configuring the active ranges with low and high values, all set to count. All working marvelously. But then I realize, that the RATE is stuck at 200. I disable then re-enabled the card. Ctr0EN bit. I cycled the PLC power and even deleted the card from the project and re-created it. With the most basic of set up. As soon as I start the line, the card goes straight to 200 for the rate and stays there, even when stopping. Its completely frozen there. What could I have possibly done to cause this. Tried several different update rates and all the same result.

I had to completely take it out of production and put things back to look at the old encoder... Not good!!!!

I am more than frustrated with this now..

I have disconnected the Z reset just to be absolutely sure it was not caused from a noise issue which started this thread AND IM 100% sure that the pulses are getting read well, my active ranges are spot on and timing on line peripherals is looking perfect.
I'm using the same logic that was running yesterday for the unlatching of the Ctr0RisingEdgeZ bit.

I have even stopped scanning the logic I put in to write to the high and low values for the range0to11[X].low limit and the same for high limit.

I don't know what else to try. Perhaps simply calculating the RPM with a proxy switch would be a better method, use the reset prox or something... I really wanted to get everything from this card. But.....

It doesn't make sense.
 
Last edited:
Is it possible that 1 counter cant be configured to give me a current RATE and fire active ranges. Perhaps I should use 2 counter for this???

No its not possible... This is working absolutely perfect on my test bench right now!
 
Last edited:
So I'm out of time now as the line starts production in a few moments.

As a last ditch...
I just went to my test bench and started a new program. I added a HSC card, left everything default except I did configure the first two active ranges. Also, I did click on preset on rising Z.
I added two rungs to enable the Ctr0.en and to unlatch the Ctr0RisingEdgeReset. Wouldn't you know, the rate works perfectly and the active ranges both work expectedly. All in all, took me maybe 5 minutes at most.

Then I went online with the PLC in question..... saved the program, then I deleted the HSC and I removed all logic or anything that even contains Local.5 in the tag name. (offline of course, then dload) I added only the same rungs used on my test bench to enable and unlatch the appropriate bits..... in the main routine.

Start the line and... Nothing.... The rate jumps up to the value of 133 and stays there. My active range bits are changing as expected. My current count is counting good. Even the pulse interval is returning a changing value. But me RATE is frozen. Also, my Rate Valid Bit is 0.


The test bench is an L24ER 30.11 and the processor in question is an L35E 20.18

I'm thinking perhaps I should try to swap the cards the next time I get a down day to see if it makes any difference. I wonder if there is something wrong with it. That aside from PLC swapping, I don't know what else to do when it works for me on the L24.

Thanks
 
Hey Folks.

Im back at this again!

Some new things learned.

I took the working program from my test bench, I made the module configuration match and downloaded. I'm using an encoder connected locally at the PLC simply because I didn't have code in this project to run my line.. Once online, I spin the encoder to see a rising count, but a frozen at 0 rate.

So, now I try to swap the cards. Still using the test program and encoder, I bring the HSC card from my test bench to the PLC. Once installed and online, I see.... a perfectly changing and updating rate value. Just as Iv always wanted. So now I'm kind of thinking the card is at fault but my mind is telling me, NOT LIKELY! SO I proceed to download the line program back into the PLC. Still encoder in hand, I spin it to see an updating rate.

There, Iv proved that the rate can count on my project. So, still encoder in hand, I program my output configuration. I give it some slow test spins to see that my ranges are active as intended.

Great... Now, still not sure of a culprit yet, I wire my line encoder back up to the card. I start the line, the rate starts to move, then freezes at 280. So.... I put my test program back in, re-wire up the test , in hand encoder and I see that the rate is STILL frozen. On the same encoder and program that worked moments ago...

What changed and what did I do to make it work between the first time It wouldn't work and when I inserted the test bench card. A power cycle... So, a power cycle I do and voila... The encoder in hand is now working and updating the rate.

So, the only difference between my test scenario and the real thing is the Z reset prox. I unhook it, I power cycle, I wire the line encoder back up, I put the original program into the line PLC and then.... Rate works solidly and encoder counts.

Its all on the Z Reset!!!!

As long as its not connected to the HSC card, everything works. If its flagged, downloading or even disabling the Preset On Rising Z parameter will not bring it back.. Only a power cycle will re-enable this rate for some reason.


But now what am I to do... Im getting a perfect rate from the machine but I really need the outputs. To do that, I need to reset my counts every machine cycle.
I have a line of code that says if Local:5:O.CtroEN then turn on Local:5:O.ResetRisingEdgeZ. No conditions, every scan.

Is it normal to use the Preset On Rising Z as I am?
I was thinking of just using a regular input for the proxy and firing the soft preset bit but I'm worried that that would loose accuracy.

Any suggestions or opinions would be appreciated.
 

Similar Topics

Hello all. I am having trouble setting up my HSC to count pulses from a prox switch. I have it wired to the prox and I see the .InputStateA0...
Replies
3
Views
1,353
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...
Replies
14
Views
4,660
Hello all. I have an issue that keeps plaguing me. The system has a 1769-L24ER processor and a 1769 HSC card. I am using CH.0 for tracking...
Replies
0
Views
1,461
Hello, Im trying to use a 1769 HSC card to get the RPM of a single channel encoder at 60ppr. Ive read the other threads of people have similar...
Replies
0
Views
1,677
Flashing Red OK Status indicator : Rockwell Automation Publication 1769-UM006E-EN-P - July 2013 Table 23 - Configuration Error Codes pg 117...
Replies
3
Views
2,158
Back
Top Bottom