842E-M Encoder

[ksc11]

All,

I've been lurking for quite a long while, and ran into something I could use some help with.

We have an application that previously had an 842E-CM CIP motion absolute encoder on it. The encoder failed and it was replaced with an 842E-M, which is not a motion device. We're able to read values from it, "home" it via message instructions, all is good.

However, the functionality is surprising and making it work in a similar way to the old one without rewriting a lot of the code or at least values isn't obvious to me. The -CM encoder would count up from zero in one direction of rotation, and count in the negative direction for the other direction of rotation. The code would look for the encoder to be in a certain range to verify end of travel.

The -M encoder does not work the same way. It will count up from 0 in one direction, but when it crosses zero going the other way it will jump to the highest count value (resolutions x configured number of revolutions).

The biggest issue I have with this is that it doesn't give a unique value, even incorporating direction of travel. For example, if it was configured for one rotation and 10 counts per revolution, and the encoder is sitting at 5, even knowing which way it is turning (example, in the direction of decrementing) I don't know if a value of 5 means 5 away from 0 as the middle of travel or 5 away from one extreme end of travel. I was definitely expecting this to be signed or at least count up in both directions so that the direction plus whether it was incrementing or decrementing told you where you were.

Has any one worked with these before? I know from a KB article that it is behaving as it is supposed to, and the only thing you can really change is which direction (CW or CCW) counts up vs down. I'm not coming up with an easy solution that doesn't require rewriting a ton of logic. One idea is to set 0 as one end of travel and "home" to the middle of the range (say, 5) and then check a window around 0 and 10 for end of travel.

Next best idea is to set an internal value at the beginning of cycle that says which half of travel it's in and write to that whenever you cross zero (the encoder has a parameter than increments when it changes direction). However under closer check I don't think that will work, as the window for end of travel and home appear the same.

Any help is appreciated.

 

[drbitboy]

How about a non-realistic number of revolutions, say 100, and ten counts per rev? The configured number of revolutions should be set so that it can, and will, never actually reach 500, neither from 499 nor from 501.

Then immediately after you read the input, which will be 0-999, if it is greater than 500, subtract 1000.

Put all that in an AOI or function block, then it will operate essentially the same as it did with the -CM.

You might even be able to configure the number of revolutions and counts per rev to act exactly like the -CM.

 

[_Dock_]

I believe these are rebranded sick encoders so you may have better luck looking through the sick documents. Is it Ethernet? If so you may be able to get more settings using a web browser.

I have used these in the past and my solution to the rollover was to set the “home” as 100 instead of 0. I believe these can be scaled in parameters but I’d have to dig through the manual to say for sure.

 

[_Dock_]

I also remember that there was a period where the velocity feedback for these changes in regards to the engineering units on the same models. This caused headaches obviously for legacy equipment. If you are reading velocity for anything I would double check it to see if it’s what you expect.

 

[ksc11]

Thanks to both of you. This is in line with what we were going to try first, as far as homing to something non-zero. We had a discussion about doing the subtraction to mimic the previous code but had lost track of that somehow.

We are only using 2 revolutions in either direction for this application, so we have plenty of flexibility with resolution to set it wherever is easiest. The -CM encoder was using the .ActualPosition bit which appears to be revolutions, judging by the number it was being scaled by to give inches.

I'll let you know how it goes. There will be some modification required I think but we've got something that appears to be workable.

 

[ksc11]

Quick update to say that this seems to be working well. I was able to home to the midpoint of the upper counts band and then do some simple math to make it work. What I haven't done yet, but I think is the more correct way to go about it, is to pull the max counts and resolution values from the encoder and use them to set the scaling of the signal, so if it's changed we don't accidentally introduce a crash.

Thanks again for the help.