Connect an absolute SSI encoder to a DAQ card

[Yaxis]

Hello, everyone

I am trying to connect four encoders to DAQ card. Two of them are quadrature encoders and the rest two are absolute encoders. I guess that connecting the two quadrature encoders to the two timers/counters on the card. But what about the absolute SSI encoders? Anybody can give a hint? Thanks a lot.

By the way I am using PCI-6251 and xPC Target.

Pengfei

[John_P1]

Hi Pengfei,

How many bits on your SSI encoders do you plan on using?  Do your measurements need to be hardware timed?

If so, you would need to connect the outputs of the SSI encoders to port 0.  The digital inputs on port 0 can be sampled based off a clock signal.  However, there are only 8 lines on port 0 on the 6251 so that would only give you 4 bits per SSI encoder.

You can use the other digital lines for software-timed Digital Inputs.  If software timing is acceptable, then you can connect the SSI outputs to any of the digital lines (other than the ones being used for the quadrature encoders obviously).

Best Regards,

[Yaxis]

Thank you very much for your prompt reply.

The SSI interface data is shown in the picture.I think that it does require to be hardware timed. Because xPC Target doesn't support many NI DAQ cards, any solution for the lack of bits?

[John_P1]

Oh silly me, it's a serial interface, ignore what I said earlier about using parallel lines.

If the clock on your two encoders can be shared then you can acquire from each encoder on one of the port 0 lines.  Do you have a method to generate the appropriate CLK and CSn signal?  Since both of your counters are already being used, you'll probably have to generate the CSn and CLK signals using a DO task.

Best Regards,

[Yaxis]

Thank you, John. This is exactly what I want to know, what is the best way to generate CSn and CLK signals. I can get another PCI-6251 if it is necessary. Then is it possible to use the counter to generate CSn and CLK signals and also translate the DO signal?

[Robert.L]

Hi Pengfei

Using a second card with available counters would give you the ability for faster clk speeds as digital IO tasks are slower than the counters.

An example of how to set up a continuous pulse train can be found in the NI example finder

Hardware Input and Output>>DAQmx>>Counter Measurements>>Generating Digital Pulses>> Gen Dig Pulse Train-Continuous – Dig start. Would be a good place to start looking other examples in this folder show different ways of setting up a continuous pulse train.

[John_P1]

How fast do you need the clock to be?  The digital I/O lines can be updated at up to 10 MHz on your 6251.  At this rate it would only take a few microseconds to clock out each sample from your encoder.  If this is suitable then you wouldn't need another board.  If you're looking at purchasing another board, X series would be better since it has 4 counters instead of the two on your M Series.  The X Series counters also have more functionality.

In any regard, I think the 6251 that you currently have will do the job just fine.  Do you have a link to the datasheet, the screenshot is quite small and hard to read.  I'm assuming the set-up and hold times are in the ns range and won't be a problem, but I just want to double-check.  If you want to use the DO of the 6251 let me know and we can help you build the appropriate waveform.

Best Regards,

[Yaxis]

That's fantastic, John. You can find the encoder manual through this link:

http://www.austriamicrosystems.com/eng/Products/Magnetic-Encoders/Rotary-Encoders/AS5045

We are using the card to do hardware in the loop testing. I can see that your PCIe cards also have 4 counters, but they are not supported by xPC Target component in MATLAB, so I can't use them. Any other suggestion on the card selection?

Please do not generate the waveform in Labview, because I am not using it. Just let me if the card is appropriate for the application, and if possible, let me know how to generate CSn and CLK signals and also translate DO signal into angle position.

I really apreciate your help. Thank you so much.

Pengfei

[John_P1 · Accepted solution]

Hi Pengfei,

If you're not using our driver then I'm not sure if all of this is supported, but here is how I would do this using DAQmx ...

According to the timing characteristics defined on page 10 of your specs page, 500 ns is the minimum period for almost all relevant parameters:

    Semi period of the CLK line

    Time between CSn and first clock edge

    Pulse width of CSn

So, it makes sense to clock your DO out at 2 MHz.  You would need to output the following two waveforms, each cycle would clock out 18 bits of data (12-bits for the encoder, and  6 status bits).  The total cycle ends up being 38 samples long, and would take 19 microseconds to execute (if updating at 2 MHz).

CSn   1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

CLK   1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1         

The actual binary data to write to the card would depend on what lines you are using.  For example, if you use p0.0 for CSn, and p0.1 for CLK, the array that you would need to write would be the following:

3 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2

The bits of the U8 numbers would correspond to the 8 lines on the port.

You'll need a sample clock source for your DO task.  I suggest using Freq Out on the 6251.  In DAQmx, it's programmed in the same manner as a counter output.  You would set this up as a continuous counter output running at 2 MHz.  Specify on your DO task to use "/Dev1/FrequencyOutput" as the sample clock source (not necessarily Dev1, but whatever your device name is).

You would physically wire the CLK signal from port 0 back into one of the PFI lines, and use it to sample a DI task so you can read back your data.  You can sample off of the falling edge of CLK to allow 500 ns for the value to settle (the maximum time from your spec sheet is 394 ns).  The only downside to this is that you are not sampling the parity bit, but it doesn't sound like that's an issue unless you were planning on using it.

Once you get the bits, you would need to translate that into an actual position.  When you call DAQmx Read, you will have an array of values.  The first value of every cycle is a throwaway (look at the timing diagram to see why).  The next 12 elements of any cycle would be the 12 data bits, the next 5 are status bits.  Like I mentioned earlier, the parity bit would not be sampled due to the decision to sample off of the falling clock edge (again, you can refer to the timing diagram to see why this is the case).

You'll want to convert the 12 data bits from the array into a single 12-bit integer, then multiply by (360.0 / 4096) to get the position in degrees.  I'm not sure what development environment you are using, but this type of data manipulation should be achievable.  LabVIEW for example has a boolean array to number function that would be quite useful here.

I hope that helps!

Best Regards,

[Yaxis]

John,

This is perfect. Thank you so much.

I'll try this and let you know the outcomes.

Thank you again.

Pengfei