AutomationDirect PLC, jumping encoder values

I am using an automation direct PLC D0-05 hooked to an encoder to track the movement of an automated cart. The cart picks units off of an assembly line and takes them to one of 5 testing stations by following a track. The cart runs off 24V DC, it has two motors: one to drive and the other to move its conveyor. The encoder is mounted on a pinion gear that runs along a rack on the floor.

Here is the problem: After an operator unloads the unit on the cart and hits the button to send it back to the assembly line the PLC adds an incredibly high number to the current count of the encoder. This happens about 1/4 of the time and it seems that the number being added is 65535 (FFFFFF). We cannot directly confirm this because the DirectSoft4 program only shows the last 4 digits of a double number. It also only reads this the last 4 digits in the program so the cart just goes to a random place while it is trying to find home.

Has anyone else experienced this problem using AD stuff. Could this be some sort of interference (I used shielded cable for the encoder wire into the PLC enclosure, but like I said we determined that it was alway adding FFFFFF). Anyhelp would be great

Cheers,

Brandon

I assume you are using a quadrature encoder setup for two-wway counting. What number should the counter be at when it gets to the unloading station?

The encoder zeroes intelf everytime it reaches the loading station via a proximity switch in the floor that goes to an input on the plc. The plc then determines this to be the 'home' position and loads a value of K4422 into CTA76. The lowest the encoder travels is to a count of 2300 and the highest is to a count of 5900. Home is 4422. The problem most often (99%) of the time while the cart is out at stations above the home position. Meaning - when the encoder tries to count down after counting up to a testing station, the problem will most likely occur.

I recently thought that there was something up with the wiring so i switched the encoder around backwards and left everything the same in the program except which way to drive when it went through its logic. Now the other side of the line has the problem. Note that after switching the encoder around, that the problem from above did not change (it still only happens when counting back down to home) but it just happens at the stations that used to have to count up to get back home.

Quadrature - Yes

My first reply. Finally something I can add to this wonderful knowledgebase.

Had the same thing happen to me in an application on a D0-05DR. I was using a photosensor to preset the quadrature high speed counter. My program worked fine on my desk, however, I was never turning the encoder as the same time as enabling the photosensor. As soon as I tried it on the machine it would mess up approximately 80% of the time. It seems to vary with the speed the encoder was turning. Ironically performing a reset (0) worked flawlessly using the same photosensor.

I wound up by creating a "Band-Aid" solution as the positioning of the process was not overly critical. I knew that my count would never register a value greater than 5 in the HI order bit of the high speed counter. I wound up by doing a compare that if the counter exceeded 5 in the HI order bit and placed it in parallel with the input that the photo sensor was hooked-up to activating the preset. This way the preset would be performed in the next scan if the value was greater than 5. It worked in my application. Hope this helps.

P.S. We were also using a shielded encoder and thought it may be noise as well.