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.

 

Being the weekend, you're not going to get a response on this forum because it's moderated and they don't work until Monday either. A-B does offer weekend and 24/7 support, but it's expensive.

I've seen a problem in greycode conversion in ControlLogix in the past that occurred because of the asynchronous nature of Logix I/O updates.

Greycode decoding depends on a specific input data set. An I/O update can occur *during* the execution of the decoding rung, which can make the decoded value "jump around". This isn't a problem in SLC or PLC5, which only update I/O at the end of logic scan, but it can happen in Logix.

It's very easy to work around; precede your decode rung with a rung to copy the Input data to a temporary holding tag, then decode the value of that tag.

 

If I remember correctly, Flex I/O allows you to set a filter frequency and on time requirements. Maybe check that. But I think you may have an issue with the input being able to resolve the pulse stream and update the processor image table fast enough. Really you should be using the ID2? module for encoders. Especially over controlnet.

Just my .02 cents worth.

David

 

Most likely the count you are seeing is not the actual count because you are on a communication network. The speed of the network might be the problem. To solve it, I would wire the encoder to the main PLc rack and see if the problem rectifies. Just run temporary cable for the encoder, and try it.

Good Luck

 

- Take a close look at the how you've scheduled the ControlNet network (RSNetworx) to make sure the update rate is OK.

- I'm not sure about the one you list, but some input modules have a filter capability, you might want to play with this (disable it?)

I worked on a project that had a 2-bit grey code encoder. This was a jog dial for a servo axis.. So theoretically you knew the jog direction from just the two bits. Problem was if you jogged it too fast you could actually get backwards results. The solution was, we didn't care about the absolute position, just ticks and direction.. So we programmed it to ignore invalid transitions. It's not perfect but it is usable.

My guess is the result changes too quickly. Keep in mind your 10 bit encoder is single-turn; you have 1024 transitions per revolution. That's 2.8 counts per degree. If your IO update time is 50 ms, then 50 ms * 1024 = 51 seconds... You're not doing more than one rotation in 50 seconds? If you are, then it really doesn't look like grey code to the PLC, that means (assuming you are extending the resolution by tracking in the PLC) you'll have some unreliable calculations.

- I hate to sound like an announcer of the obvious, but don't forget if you go over one revolution, you no longer have an absolute position! If this is the case you need PLC logic to make a "real" position based on increment/decrement of the encoder... Hopefully your design has gearing set up to not exceed one rotation.

- I don't know if this will help or not, but make sure you're buffering the inputs before you use the value to calculate your position... In ControlNet/ControlLogix your inputs are updated asynchronous to program scan which means your calculation could be invalid.

If worse comes to worse and you need the speed, you may need to get a high speed counter module. I think you should be able to put the least significant bits into the counter module, the more significant (slower changing) bits into regular inputs and program logic to make it work. (Most high speed counters have a small number of inputs (2 or 4)).

Hope this helps, let me know what happens.

Jim Zupich
[email protected]

 

Are you sure you have the conversion correct? Remember that you have to invert the bits from the encoder. Using that particular arrrangement they don't com into the PLC correctly. Your ones should be zeros, and your zeros should be ones. Do this inversion *BEFORE* you decode the Gray Code to binary.

Of course, there's no guarnatee that you don't have a hardware problem.
--
Michael R. Batchelor - Industrial Informatics, Inc.
Contribute to society: http://www.distributed.net/ogr/

 

One problem is that the inputs are not fast enough. They probably have some sort of RC filter on them. The variations in filtering time from channel to channel mean that not all of your inputs are reading correctly at any given time. Use a faster input module.