Connect an absolute SSI encoder to a DAQ card

[Liran]

Hello John,

As a follow-up i would like to know if i can do the same thing with my PXIe-6361 (on the same encoder) using C language.

Outputing the signals is not a problem writing to port0 (DAQmxWriteDigitalU8), but i dont understand how can you read using one of the PFI (which is not Hardware-Timed) , this means that you can't read as fast as 500 ns.(Correct me if i am wrong about this)

In conclusion , my question is how can i read and write at the same time as fast as stated before.

Liran

[John_P1]

Hi Liran,

I added some clarifications to my previous statement (in bold😞

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.

I think you're gotten this far already--let me know if otherwise.  The goal of implementing the above is to be able to generate a clock and chip select signal to use to interact with the SSI encoder.

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).

This part is not necessary on your 6361.  The digital output subsystem on X Series can use its own dedicated internally derived clock instead, so if you just set the DO rate to 2 MHz you don't have to specify another clock source.

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.

This is where my statement might have been a little ambiguous.  The PFI line is used to route timing and triggering signals--in this case, the PFI line will be used as the sample clock source for a digital input task on port 0.  You are using 2 port 0 lines for generating the CSn and CLK lines, which still leaves 6 available for sampling the encoder output (you could read from 6 encoders all controlled by the same CLK and CSN signals if you wanted to).

So, the sampling of the actual signal is still done on port 0, but the generated clock has to be routed back in through a PFI line since there is no internal route for port 0 to be used as the sample clock for another task.

Best Regards,

[Liran]

Hello John,

Did you mean that i should use a different function instead of  DAQmxWriteDigitalU8 ?

I ask this because this function uses the whole port 0 , meanning it sends 0 to lines p0.2 - p0.7.

Liran

[John_P1]

Hi Liran,

The write still requires a U8 datatype, but the lines which are not included in the task are masked out so they wont be affected by your output task.  You can use these lines for a digital input task.

So for example, your output task could use "Dev1/port0/line0:1", and your input task could be "Dev1/port0/line2:7".  The two tasks would run independently and would not affect eachother since the unused lines are masked out when you read/write data.

Best Regards,

[FilipxSikora]

Hello everybody,

I'm also trying to connect on SSI device, but I have little problem with sync (I suppose). SSI is a bit different, it doesn't use CSn signal, it's just Clock and Data (this one). Device is connected through 2 IC LTC485, one "translates" simple clock signal what I'm generating on P0.0, second translates data from SSI to Logic Low and Logic High and then I'm reading it on P0.1. Device is Absolute Encoder with 12 bit precision, that means, I suppose, 12 data bits (Datasheet of encoder). I'm using LabWindows/CVI and PCIe-6351.

What I have done so far :

-I have P0.0 for generating clock signal, it is 28 samples pattern clocked at 200kHz with sample clock, and it looks like this - 1 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, I checked the signal on oscilloscope and it looked just fine, frequency was exactly 100kHz, monoflop time was over 20 micro seconds.

-From P0.0 leads signal to transmitting IC and then to encoder, I also physically wire this signal to PFI8.

-On P0.1 I'm reading signal returned from encoder, it also uses sample clock, but as timing source i used PFI8, so it should match the CLK signal. Then I have registered EveryNSamplesEvent, as number to samples to read, I have selected 12, because of 12 data bits, but I'm not sure if is this right.

-In EveryNSamplesEvent, i use DAQmxReadDigitalU8, I read 12 samples and calculate decimal number. From image of SSI I'm suspecting MSB on first position and LSB on last position, but maybe I got it wrong. ipow(x,y) is function for integer based Power(x^y).

result = 0;
result += ipow(gData[0],11);
result += ipow(gData[1],10);
result += ipow(gData[2],9);
result += ipow(gData[3],8);
result += ipow(gData[4],7);
result += ipow(gData[5],6);
result += ipow(gData[6],5);
result += ipow(gData[7],4);
result += ipow(gData[8],3);
result += ipow(gData[9],2);
result += ipow(gData[10],1);
result += ipow(gData[11],0);

 I hope this description is enough, if it is not, just tell me, I can clarify or add aditional info.

Now what's wrong:

I'm able to get back data from encoder, but they are evidentely wrong. For instance, if I start my tasks(P0.0 for clock and P0.1 for data input) I get an number from encoder (let's say 2500 for instance), then I stop my tasks and start them again, without even touching the encoder, now it's saying 450 for example. Another thing is that output curve should be linear for one revolution (0-4096), but it is not even close to that, this is what my output curve looks like for 1 revolution (taken when reving was made by my hand, in cca 2 sec interval, that means nothing really accurate, but still should be +/- linear 😞 

This is everything what I think is relevant right now, if you need any more description, just ask.

Thank anybody who could help me.

[John_P1]

The digital input task is going to take a sample for each edge--if you count them you actually have 13 per 12-bit encoder "sample".  Change the number of samples to 13 and discard the first sample, the remaining 12 bits should be your data.  Also, if you're not already it looks like you should be sampling the digital input on the falling edge of the clock to allow for enough time for the data line to update.

If you give precise numbers for consecutive "samples" when not moving the encoder (e.g. you mentioned 2500 -> 450) I wouldn't be surprised to find that the numbers share the same bit pattern (but shifted).  Although, from the graph it doesn't look like the value is ever getting up to 2500 (the MSB appears to always be 0) so I assume the numbers you gave were just a hypothetical example (or maybe the graph just didn't have enough of a time window to flip the MSB, but given the 2nd MSB flips twice it doesn't seem likely).

Best Regards,

[FilipxSikora]

Thank you John for reply.

Anyway I changed number of samples on digital input to 13 and sample off first bit. Now I'm able to get to the max (4096) but it still behaves very odd. I've made sample curve again (same conditions as before - 1 revolution with my hand in cca 2 sec interval). Also it still doesn't keep it's position (983 -> 1415 -> 2755 (this time these are real numbers what I get in ON-OFF cycle)) without moving with shaft. I also slightly changed output pattern, now it has 30 samples like this - 1 1 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 so it matches 13 falling edges per cycle.

To answer and clarify your questions : 

-My digital output task is configured on risig edge

-My digital input task is configured on falling edge

I've also made oscilloscope pictures of clock and data signal, don't know if that could help, but maybe it can, this is from yesterday, when sampling 12 bits and using 28 samples pattern mentioned in my

first post :

And this one is with "improvements" mentioned in this post : 

//Edit: I also take picture of signal, when I get indicated position 4089 (that was as much as I was posible to get to the max value of 4096 with my hand) and I think that the signal is a bit "messed up" (probably reversed, it should be from MSB to LSB, but it seems LSB to MSB for me(but I may be wrong)) : 

I appreciate you help John, thank you.

Filip Sikora

[FilipxSikora]

Update : It's working well right now. I've made two stupid mistakes, first I didn't realize that output of the encoder was in gray's code, not in binary code and second, I've shifted + and - wires on Clock and Data signals 😕 I'm really sorry for wasting your time.

Filip Sikora

[gbob]

hi

im using a ni pxi 6361

the clk is connected to the counter output and the data to the digital input, i cant get it to work .

can someone plz upload a working example how to make it work even if u are using other way to connect it.

i need the example in C not in LABVIEW

thx

gilad

[yf49782341]

Hi, I need your help I have a SSI transducer(MTS),it is 24 binary,differential signal (CLK+、CLK-、DATA+、DATA-),I use CO to generate clock signal,and DI to get the DATA signal,but now I have the question below: how can I connect the wire bentween the SSI and NI-USB-6343. I think the point is the differential signal