Absolute Encoder

Hi Guys,
I am on a new equipment installation and we are using an Allen Bradley 845G Absolute 10 bit Gray Code encoder connected to a 1794-IV16 24VDC Sourcing Flex I/O Input Module talking thru ControlNet to a ControlLogix PLC. The problem I am having is that my encoder counts are jumping all over the place. I have the correct Gray code to Binary conversion logic, I have tried a new cable, a new encoder and checked the wiring several times. I have isolated the encoder from possible noise by taking it off the machine and turning it by hand. Still have the same problem. The encoder is turning at a slow speed so speed is not an issue. The encoder is used to time when several pieces are to perform their tasks in relation to our conveyor. Does anyone have any ideas on what might be wrong. Being the weekend I cannot contact Tech Support and we really need to have this fixed by Monday. Thanks in advance for any help.

Afraid I haven't played with those type of encoders before..... With that said, I have a couple of questions...
1. Do the encoder counts jump around when just sitting there, or is the problem with inconsistent readings when it is moving?
2. Are the readings consistently wrong? I mean, when you move the encoder 1 revolution do the readings change appropriately with some erroneous values, or is it that every time you move it 1 turn you get some miscellaneous wrong value? Or some combination of both?

The encoder counts stay steady when sitting there. The readings are consistantly wrong. They may start out counting right then get to 400 or some number and jump back to 100 then back to 400. This in turn causes my machine to send out double triggers if programmed to use this range.

What's the exact part # of the encoder you are using?

I believe this is the right number as I left my drawings at the plant. 845G-F3G8HC1024R

Looks like the right encoder. I don't mean to sound smart but you do know this is a single turn encoder right?

- Have you tried measuring voltage at the different input points on the card?

- Are the 24V commons the same on both the encoder and the card?

If the above is correct then either;

YOur wiring is wrong
You have a bad encoder
You have a bad input card (unlikely)
Your grey code conversion is wrong.

I know you've stated that you checked all of these but there is nothing else to go wrong.

Sorry I couldn't be more help

By single turn you mean that the count rolls over to zero everytime, right? If thats the case then yes because we are only measuring one flight at a time. I've tried a new encoder and a new cable and double checked the Gray code conversion so the only thing left is the module. So i'm gonna try checking each input in the morning and if I have a bad one change it to another input and see if this fixes the problem. I will check the things you suggested also. Thanks for the input.I will let you know what I find in the morning.

I hoped you would find this forum, Double L, because I saw (and replied to) your post of the same question over on the Control.Com forum. This Forum is a much higher traffic system than that one, and because it doesn't rely on a moderator (except when folks get out of line!) the answers, information, and opinions come faster. Even, as you've seen, on the weekends ! (or, in my case, while I'm sitting at the airport in Spokane.)

I've seen the sort of behavior you are describing in graycode conversion before, and it's unique to ControlLogix.

Traditional PLC's update their I/O only during "housekeeping" time between logic scans. ControlLogix I/O connections update asynchronously to logic solving, so it's possible for the input data from your encoder to change {i]during[/i] the decoding rung !

Fortunately it's very easy to work around. Simply use a MOV instruction on a rung before your decoding logic to move the 1794-IV16 module input data into a "holding register" tag. The data will arrive intact from the 1794-IV16 over ControlNet and cannot change during the decoding rung.

I can't say for certain that this is the problem you are encountering, but I had a customer a few months ago with a 1756 input module and identical symptoms and that simple workaround solved his problem.

I have no doubt that Ken is right. I couldn't understand what could possibly be the problem if everything had been checked but this makes perfect sense.

The way that CLX handles processing its program has a lot of advantages but there are a few things that you have to keep in the back of your mind while programing.

Thanks guys,
I had just come to that conclusion this afternoon that there had to be a an issue with the Control Logix but I didn't know where to start looking. I was going to ask Allen Bradely this question in the morning. After looking at this thing all day and even trying a new module I was at my wits end. I really appreciate your timely response and I will become a regular here and hopefully pass on some info to help someone else out in the future.

Thanks,

DoubleL

Given that the encoder seems to be responding across its full swipe, my bet is that your Gray Code decoder has a bug or two in it. I've tried to do it with XOR blocks, but it's a royal pain in the ***. I just program the individual rungs with the XOR logic and it works quite well.

I got burned by this exact same problem during my learning curve from SLC to Control Logix.....

You want to make sure you use a 'Synchronus Copy File' instruction. (CPS for short). As Ken indicated, if you are doing logic on the input word the data will be changing asynchronously. Perform a CPS at the start of a rung and move the data to a buffered register, then perform your decode logic on the buffered data.

Note: just doing a normal copy or normal move won't work if you are working with a 32 bit integer due to 'big end/little end' update issues.

Inquiring minds want to know.

Greg Gauper said:

Note: just doing a normal copy or normal move won't work if you are working with a 32 bit integer due to 'big end/little end' update issues.

Click to expand...

How were you able to do synchronous reads or writes? There must have been away do synchronize the data. One can't read the data twice because it could update frequently while moving. This might work if the two reads happen faster than the Control Logix updates register.

We have had to add an extra synchronization register in both the input and output registers. Only when the two are equal are the input registers considered to be valid and the output registers can be written.

Peter,

In my case I was doing simple digital limit switching.

I had a problem with 'bad data' in which I checked for a number change that exceeded the actual speed of my axis. I concluded that the data was bad because I was evaluating the low byte while the high byte was changing (or vice-versa). I was using a regular copy instruction with no luck.

My understanding of the CPS instruction is that it copies all of the data at that instant and therefore can't get interrupted by other events. Worst case is that my data was one scan old (i.e. I just begin to copy the data an instant before the input data updates, therefore the new data is ignored for one more scan), but that was okay in my application. Once I used the CPS instruction my 'bad data' problem went away.

This was an open loop digital limit switch routine and not a closed loop motion controller. I was running a 5msec task. I was using an SSI absolute encoder read thru a third party SSI-to-Controlnet module (the only way I could get SSI data into my Control Logix PLC at the time). Since this was the only device on my network, I 'brute forced' the data to update as fast as possible (set the RPI to 2msec).

And you are correct, this approach cannot be used for closed loop motion control due to the asynchronous update nature of the input data.

I didn't know about the CPS command.

Was the CPS command added in a recent release?

Thanks

Maybe you would be interested in this:

Butterworth Hi Pass Filter and Design.