Absolute Encoder Questions / SSI via 5i25

Hi

I am about to update my machine to AC Servos.

The drives I use are able to put out a SSI-Simulation on their Encoder out pins. 12 Bit Rotation, 12 Bit Turns, 25th bit always zero, 200kHz or 1.5MHz, +/-Clock +/- Data.

Even 200kHz gives ~4000 Updates per second (if I am not wrong), what should be fair enough...

For I am using absolute Encoders on all Axes, this would be my ultimate solution. I read that the 5i25 is able to read SSI encoders, but I cant find how?

Questions are:

1. Can I use the SSI Simulation on my drives encoder out to be read by 7i77 or some other card?
2. If yes, can EMC work with TWO absolute drives on one Axes? I have two Motors on Y-axe. Am I just to connect the Position Pin to the SSI readout?

best regards,
Julian

andypugh wrote:

juwi wrote:

1. Can I use the SSI Simulation on my drives encoder out to be read by 7i77 or some other card?

There is currently no LinuxCNC support for the Mesa SSI receiver.
It looks like it would be relatively easy to add a driver as it appears to be a fairly simple interface.
It would probably only need a few modifications to the resolver.c driver, as the behaviour is fairly similar.
I could do that, but it would be hard without hardware to test with.

Give me your address. Do you have a 24V Power supply? Ill Send you a drive + Motor, no absolute Encoder Motor (these Motors are way to heavy) but with resolver, which is single turn Absolute and after being referenced Multi turn.
If you have 110V you need a three phase supply, but It even maybe that you only need to power the 24V to check the SSI Out.

ACK?

You would need a firmware for the 5i25 with SSI compiled in, that would probably need to come from Mesa.

2. If yes, can EMC work with TWO absolute drives on one Axes? I have two Motors on Y-axe.

You would probably want to use Gantrykins for this, but it might be possible to use two PID controllers in HAL operating from the same command signal. Each would have its own feedback and tuning.

I am an expierienced C Programmer. Show me the way?

best regards,
Julian

PS: This is really fast support

A couple of things

There is no current support for SSI but as Andy says its very similar to the
resolver interface

A 7I77 does not provide any RS-422 outputs except the one I/O expansion port. This could be used for testing the SSI interface but its just one channel you may need a 7I74, 7I85 or or similar daughtercard for
multiple SSI channels (or 7I44.7I47 if 50 pin FPGA cards are used)


200 KHz is pretty slow since the CPU will have to spin its wheels waiting for the return data 1.5 MHz is better as thats only about 17 uSec

andypugh wrote:

[...]
In that case, it probably makes sense for you to write the SSI driver.
Have a look at this file:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...fb2e7d795a53d1b702f3
And compare the resolver and SSI register layouts in the attached Mesa regmap file:

I think that it would mainly be a case of changing the word "resolver" to "ssi-encoder" in the pin names.

File Attachment:

File Name: regmap.txt
File Size:62 KB

C-Code is fine, not really read now, but looks understandable. What I am missing looking @ the remap file is the position register of the SSI. Resolver has velocity and position, SSI not?
Am I overlooking sth?

best regads,
Julian

PCW wrote:

A couple of things

There is no current support for SSI but as Andy says its very similar to the
resolver interface

I see , but cannot find the position register?

PCW wrote:

A 7I77 does not provide any RS-422 outputs except the one I/O expansion port. This could be used for testing the SSI interface but its just one channel you may need a 7I74, 7I85 or or similar daughtercard for
multiple SSI channels (or 7I44.7I47 if 50 pin FPGA cards are used)

Ok, do you know if the 7I74 is available from your german distributor?


PCW wrote:

200 KHz is pretty slow since the CPU will have to spin its wheels waiting for the return data 1.5 MHz is better as thats only about 17 uSec

The doc from the drives say 13us in 200kHz and 3us in 1.5MHz, which seems to be realistic from my understanding?

best regards,
Julian

There is no position register as such but there is a data register, it represents the data shifted out of the SSI encoder. Its right justified so a proper driver must mask the data appropriately. Note that some SSI encoders are gray code so if this needs to be supported. the translation would need to be in the driver.


Those timing numbers must be another parameter,
transfer time for 25 bits at 200 KHz is 125 usec (5 uSec x 25 bit times)
transfer time for 25 bits at 1.5 MHz is 16.6 usec (.666 uSec x 25 bit times)

Using a triggered read would be a bit difficult with the current TRAM structure as the all-reads then all-writes sequence is rather strongly baked-in.
I get the impression that there is an option to trigger continuously instead?

There is that but that would add a lot of jitter

probably best structure would be:

issue (write) read requests for slow devices

do normal reads (this allows wait time to overlap this I/O time)

do slow device reads

do writes

lacking this timing optimization the start read would
just need to be buried in the driver