Re: [CAD_CAM_EDM_DRO] Re: Position counter stop updating....Still there....

Babar wrote:

> although the stg2diag shows big errornous values
> following is the respone of stg2diag utility:
>
> [root@localhost bin]# stg2diag
> Servo To Go Board IO address = 0x200
> +1.000 +1.000 -2.000
> +1.000 +1.000 -65538.000
> +1.000 +1.000 -2.000
> +1.000 +1.000 -65538.000
> +1.000 +1.000 -2.000
> +65537.000 +65537.000 -65538.000
> +1.000 +1.000 -2.000
> +65537.000 +65537.000 -65538.000
> +1.000 +1.000 -2.000
> +65537.000 +65537.000 -258.000

Bingo! This is the same horrible behavior seen with the STG-I
card! This is not encoder noise, this is noise on the digital position
reading coming OUT of the 7166 encoder chips. NIST put in a filtering
routine to throw away any samples that were too far away from the last
sample. but, notice, these jumping values are almost always jumping ONE BIT
in the middle-most-significant byte! The first bit of that middle byte is changing
from sample to sample, causing a jump of 65536 counts in the total position
value. Since the STG-II is a significant rework of the STG card, I suspect this
is an inherent defect in the 7166 chip, at least in the mode that STG and EMC
use it.

Are these lines sequential samples recorded to memory, or does the computer only
print out a position reading whenever it detects a change from the previous one?
In other words, do these wildly jumping reading pour out of the computer, or do
they come out every now and then?

I noteced the problem was most severe in the STG-I when the encoder position moved
acrosss the boundary from 0 to -1, ie. when all 24 bits changed value at once. This
could be expected to cause noise in the system.

I don't know what to tell you about this, but from previous info you've supplied, it
is a problem of noise getting into the STG card, and upsetting its logic. If you have those
cable shields connected to terminals on your STG breakout board, try grounding them to
the computer's CASE, instead. You don't want to force interference currents through the
board's logic, or through the logic's ground traces.

But, this info you provide here makes it look very clear it is NOT, specifically, noisy
encoder signals causing false counts in the encoder counters.

Jon