SSI ABS Encoder

PCW wrote: What does hm2_7i80.0.ssi.00.zencoder.rawcounts
show?

it shows from 0-4096
But when I restart linux cnc, the values (3072 to 4096 ) is negative numbers from -1024 ->-1

annhandt09 wrote: The values return from 0x0000000->0x0000ffff for 0->4096

This is starting to look like it's my fault, then.

However I am fairly sure that the encoder wrapping logic works properly, as it is used extensively by things like the smart-serial MPG counters.

Is the returned position continuous at least? If it is then the conventional axis home offsets will mask the issue.

can you see the video?



thank you very much

annhandt09 wrote: But when I restart linux cnc, the values (3072 to 4096 ) is negative numbers from -1024 ->-1

I think what is happening is that the initial change from the initialisation value of zero and the first real data is looking like an encoder wrap. But if the M flag is set then it shouldn't even be running the wrap code.

andypugh wrote:

annhandt09 wrote: But when I restart linux cnc, the values (3072 to 4096 ) is negative numbers from -1024 ->-1

I think what is happening is that the initial change from the initialisation value of zero and the first real data is looking like an encoder wrap. But if the M flag is set then it shouldn't even be running the wrap code.

i only reboot my LinuxCNC. The power of the encoder is still ON

And I think I see the problem.

github.com/LinuxCNC/linuxcnc/blob/master...2/abs_encoder.c#L258

The check will fail for a "me" as the check list does not contain "m".
Which means that you can't use the "%12me" specifier (that would raise an error) and "%12em" will simply not parse the m.

Are you running LinuxCNC 2.8 or are you running master from buildbot? I can get a fix in to the master .debs pretty quickly.

If you are building from source then that would be even better, as you can test the fix before I make it...

annhandt09 wrote: i only reboot my LinuxCNC. The power of the encoder is still ON

Yes, but when you reboot LinuxCNC the internal "last position" is zero, and the wrap-detection kicks in.

This isn't typically wrong as-such, though it really should be returning -2048 for 2048 and 2047 for 2047

I think that you should see the same behaviour if the encoder is also powered down?

andypugh wrote:

annhandt09 wrote: i only reboot my LinuxCNC. The power of the encoder is still ON

Yes, but when you reboot LinuxCNC the internal "last position" is zero, and the wrap-detection kicks in.

This isn't typically wrong as-such, though it really should be returning -2048 for 2048 and 2047 for 2047

I think that you should see the same behaviour if the encoder is also powered down?

i tried to turn off the power of encoder when the linuxcnc work. When i turn on the power then the data is correct.

I am using the brand s_kins ( github.com/LinuxCNC/linuxcnc/tree/dgarr/s_kins )

Sorry for my English. I am learning English.

If you are building from source, can you try editing abs_encoder.c, so that line 258 is

And then see if "%12me" fixes the problem?

andypugh wrote: If you are building from source, can you try editing abs_encoder.c, so that line 258 is

Code:

else if (strchr("bBuUsSeEfFpPgGhHlLmM", *format)){

And then see if "%12me" fixes the problem?

i tried this. The encoder data returned : 0->2047 - 2047 -2046 ...->-1 for 0->4096 datas
Is it correct?