SLC 5/03 with 1746-HSCE

[glenncovington]

I have a double end tennoner with a ball screw for opening and closing. On the back of the motor driven by a VFD there is a 100PPR differential encoder connected to a 1746-HSCE Card in a SLC 5/03 Rack. Upon startup of power the card is initialized and activated. The machine goes open to a home prox and then in just until it comes off of the prox. A home position value is inserted into a Float number. Then a target is entered and the machine should close to the position. If the next target is larger it opens beyond target by a little bit and then back closed to target to remove any backlash.

Only the A+ A- B+ B- leads are connected not Z.
I have tried both Encoder X4 and Pulse with the same problem. Moving in I can scale the encoder count an go to any position moving in accurately. If I change direction and open the machine it grows in size by a 1/16" or more. This happens each time it goes out. I have tried everything I can think of, but something is going on when the encoder changes direction. It is mounted firm to the motor. I have checked for backlash in all elements with a dial indicator and found to be less than 0.001".


Attached is my current program if anyone would mind looking at it. The encoder is set up as a ring to rollover at 32767.​

 

[OkiePC]

Is it possible that it is rolling over? This is a linear device, so you don't want the encoder to rollover, unless you are dealing with that correctly before you scale it into the float.

If you are scaling raw counts to a float, that is fine, but if you are using the distance travelled each scan, then converting to a float and summing that with your internally scaled float, then you will have cumulative rounding error.

Other than that, you need to check the signals with an o-scope, make sure you don't have noise on the line, make sure the pulse edges look right in both directions, and that you aren't exceeding the input frequency of the HSCE.

How many RPM does the encoder turn?

 

[JeffKiper]

Are you building this system or is it a new machine?

 

[JeffKiper]

test

 

[glenncovington]

This is a retrofit to an older machine. The input frequency to the card is approx 6khz on each channel at the highest frequency.

I also ran the motor with the encoder off and no stray (noise) signals received.

I am using a routine that takes the difference in counts between scans and performs math functions to create a float value that represents my to count value. There are multiple rollovers because of the length of travel (100"), but there is a routine that captures the fact that the encoder rolled (based on Absolute value of difference) and takes the 32767 ring rollover value into account.

It appears to scale and work fine in one direction from Home (i.e. from fully open to fully closed) but when reversing direction it seems to lose counts. I am going to get the Z channel connected this morning thinking that this might be the problem.

 

[OkiePC]

This is a retrofit to an older machine. The input frequency to the card is approx 6khz on each channel at the highest frequency.

I also ran the motor with the encoder off and no stray (noise) signals received.

I am using a routine that takes the difference in counts between scans and performs math functions to create a float value that represents my to count value. There are multiple rollovers because of the length of travel (100"), but there is a routine that captures the fact that the encoder rolled (based on Absolute value of difference) and takes the 32767 ring rollover value into account.

It appears to scale and work fine in one direction from Home (i.e. from fully open to fully closed) but when reversing direction it seems to lose counts. I am going to get the Z channel connected this morning thinking that this might be the problem.

Okay, now we know you're within the speed spec, and we know the PPR, and we know the length in inches. You need to track total travel in actual counts, no matter how you deal with rollover.

We don't know how many pulses per inch so I don't know how many counts you need to track for your 100" of travel.

Don't scale the counts to float and then sum it. Sum the counts, then scale the grand total to your float.

Don't set the range of the ring counter to a value that is not a multiple of the PPR of either the motor or the ballscrew. It can work, but it won't make life easier for you, since you may need Long integers (unavailable in the 5/03) to track total absolute position in raw counts, you will probably have to double up on your logic. One compute for revolutions, and another for counts within that revolution.

Personally, I doubt the Z pulse has anything to do with the problem, unless you want to use it as a hardware reset, or to add precision to your homing routine.

Now that I am at work, when things slow down, I will try to look at the file you posted.

Paul

 

[OkiePC]

In file 3 rung 13, you are summing an integer with your float. This too will lead to cumulative rounding error. I don't know why you need to use the ABS and have conditional subtracts and adds. You should be able to sum the difference to get the new count, and if it's less than zero, add the range and CTD revs. if it's more than the range subtract the range and CTU revs. Then CPT your float = Scale * (REVS.ACC * range + encoder).

 

[glenncovington]

Well I think I have it working. The ABS value was used to determine rollover of the encoder. I scoped the A and B channels, not pretty but seem to be okay. Then I used the histogram to monitor N7:33 the difference value. On the way in all of the difference values were positive as expected, but on the way out (opening) the values were 99% negative with a few positive value sporatically thrown in.

I ended up taking away the directional determination for the HSCE and used a routine to monitor which direction I was commanding it to go and then did the math accordingly. All seems happy now.

Thanks for the help.

 

[OkiePC]

I ended up taking away the directional determination for the HSCE and used a routine to monitor which direction I was commanding it to go and then did the math accordingly. All seems happy now.

Thanks for the help.

Good that you solved it, but that method of depending on commanded direction to determine polarity of change can be risky. If there's any drift after a command goes away, or if there's backlash or any movement when you're not commanding motion, are you still getting those counts?

Your encoder should be able to count accurately in both directions, and the math and logic should be able to work right independent of the direction commands, so if the problem returns, or is merely lessened, please let us know.

Paul