Encoder dropping pulses on 1756-HSC

[KevinO]

Hello. So we have a machine with a carriage run by a VFD driven motor. I have noticed that for some reason it periodically loses 720 pulses and then regains them shortly after, see picture. There is no pattern to it that I can find and it sometimes takes 1 second to regain the pulses and other times can be upwards of 30 seconds. It occurs at different points in the carriage's travel.

We are using a 1756-HSC with a Turck Ri-QR24 contacless encoder at 4000ppr. Voltage is good, shield is intact on the cable, encoder ring runs true to the motor shaft.

This is causing a significant difference in where the PLC thinks the carriage is at in it's travel. Any ideas?

Thanks in advance.

 

[sparkie]

The first thing we always check is to make sure the encoder isn't slipping mechanically. This has been the most common cause of missing pulses we have found.

The easiest next step if you aren't using a scope or encoder simulator is to replace the encoder with a known good one.

Then on to the cable. If the cable is old, try to just drape a cable over to the cabinet and wire it up to see if it fixes the issue if you have a spare. This often only takes a few minutes and can eliminate a bad cable.

Finally the input as these tends to go out the least.

It just needs to be broken down into a series of steps.

Remember, if you don't have the equipment available and have to try and eliminate parts one at a time, you need to put the machine back to the way it was before each step, or you aren't really eliminating anything.

 

[Steve Bailey]

If you are using an incremental encoder, the problem looks like it is somewhere in the PLC. Is the screenshot showing the raw count from the HSC or is it a calculated position. If the latter, double check your scaling equation at the point where you see the problem. There could be an overflow for the range of raw count values where you see the upset. Also check to make sure nothing in your logic is writing to the raw count value or to any of the control bits associated with the HSC module.

 

[KevinO]

Thanks guys. Yes, we have ensured it's not slipping, this is a new encoder, I have run a cable direct to the HSC to eliminate noise, and double checked all the connections.

Yes, this is an incremental encoder and yes, that is the raw data in the picture. I have the preset on the encoder set to 500500 and it only drops to 472200 at full travel, so I know it's not due to rollover. All the plc does is take the difference between a fixed value and the raw encoder pulses, then multiplies that by a calibrated constant to give us travel distance in inches.

The weird thing is that the loss of pulses is exactly 720 every time and doesn't fluctuate even 1 pulse, ever. That's another reason why I'm confident it's not mechanical. I will check with an oscilloscope and try another different encoder.

Thanks again

 

[JRoss]

Can you give us more information about how you have the HSC card set up? Screen shots or the actual program file would be useful. The card has a lot of options, maybe there's something there.

 

[daba]

That graph indicates to me that the HSC is giving you false information - there is no way an encoder will give you a "burst" of pulses to make the raw count drop by exactly 720, followed by another "burst" of the same number to make it recover to the true value.

Try another channel on the HSC and see if it does the same there...

 

[robertmee]

Are you sure you don't mistakenly have the z channel from the encoder wired to an A or B channel? How is the encoder wired?

 

[BlueAltezza]

That graph indicates to me that the HSC is giving you false information - there is no way an encoder will give you a "burst" of pulses to make the raw count drop by exactly 720, followed by another "burst" of the same number to make it recover to the true value.

Try another channel on the HSC and see if it does the same there...

This was my initial thought - I've never seen an encoder make up pulses.

KevinO: If you actually lose a fixed amount of pulses randomly then I'd think there is something mechanically wrong with the drive mechanism. Something like the motor experiencing a sudden increase in load, belt slipping, or a blip on the incoming speed reference to the drive.

If the pulses are 720 too low from expected but then go 720 over expected after a time period to "even" out I'd lean towards the PLC/Card being suspect. Have you altered the card configuration - RPI, Filters?