Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading SSI absolute encoder with USB-6008 DAQ

I am trying to use a 10-bit Absolute encoder with an SSI interface hooked up to a USB-6008 DAQ card reading into labview. The encoder we are using is a Baumer BMSK 42L1G05C10/0006B http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=4361214 and datasheet here; http://docs-europe.electrocomponents.com/webdocs/0144/0900766b80144560.pdf

 

My original intention was to use one digital I/O line on the USB-DAQ for the clock out and one for the data signal in - however I have been informed from a controls specialist that the TTL I/O lines on the USB-6008 will not be able to drive an SSI interface and we will need a differential line driver/reciever (e.g. http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=460-679) sitting between the DAQ card and the encoder. Can anyone comment on the ability of the USB-6008 to drive an SSI interface?

 

Additionally would anyone be able to provide an example of a labview VI for a) generating the required clock signal and b) decoding the 10-bit binary word into a decimal which can then be converted to an angle? Apologies for all the links, any help you can provide on this subject will be most appreciated!

 

Many thanks,

Hugh Blakemore

hugh.blakemore@rolls-royce.com

Regards,

Hugh Blakemore
Rolls-Royce Plc
hugh.blakemore@rolls-royce.com
0 Kudos
Message 1 of 49
(12,409 Views)

Hi Hugh,

 

To do SSI properly you'll probably want to consider a board that has clocked digital I/O.  The USB 6008 only has software-timed digital lines.  It might be possible to create some sort of software-timed implementation, but it will be non-deterministic and you won't meet the timing specs from the data sheet you provided (especially given the latency of USB single-point operations):

 

2011-03-25_143029.png

That is, your pulse times will be much larger than the maximums given in the specs page if you are only updating the line based off of software calls.  Whether or not this is a problem I can't say.  I have advised somebody doing this in the past, you can find the thread here.  Their DAQ hardware was capable of clocked digital I/O however which is essential if you want to be able to deterministically sample the data off of a clock signal.

 

 

The data sheet does suggest using a differential line driver and even gives a few specific part suggestions:

 

        2011-03-25_145018.png

 

The benefit of utilizing the differential driver is an improved tolerance to noise.  It might not be necessary for you if you just connect the Data+ line to your DAQ card and leave the Data- line unwired, but I can't say for sure without trying it out.

 

 

Anyway... the major problem with the 6008 for this application is that the digital I/O capabilities are limited to software-timed only.  If you're looking for NI Multifunction DAQ products that support clocked Digital I/O, here are a few options:

 

 

All of the above only support single-ended TTL however.  If you want something from NI with integrated support for differential digital signals your best bet is probably a CompactDAQ based solution such as:

 

  • 9174 (chassis), 9411 (for differential inputs), 9401/9402 (for outputting the clock signal).

 

 

Before looking into alternative hardware, it couldn't hurt to try using the 6008 to implement some sort of software-timed SSI interface to see if it meets your needs (or if it even works at all).  Your code would have to sequentially do the following:

  1. Drive a DO line low (to be used for the "clock")
  2. Drive the "clock" line high
  3. Read from digital input line (connected to Data+)
  4. <repeat until all bits are acquired>

 

The DO ("clock") task should probably include two lines, since the encoder is expecting a differential clock signal.  The 2nd line would always output the inverse of the first one.  I put "clock" in quotes because it's just a software-timed update and isn't really a deterministic clock signal.

 

Once you have the data in software, you'll want to convert the 10 acquired bits into a single 10-bit integer, then multiply by (360.0 / 1024) to get the position in degrees.  LabVIEW for has a boolean array to number function that would be quite useful here.

 

 

Best Regards,

John Passiak
Message 2 of 49
(12,400 Views)

Edit to my previous post:

 

I just realized you are using the BMSK 42L1G05C10/0006B.  The G in the name indicates that your encoder encodes the data using Gray-code.  My previous advice for converting the number to a degree would apply for the Binary-code version.

 

The wikipedia article I linked in this post has a section that describes converting between Gray-code and Binary-code, but I can't say I've implemented this before.

 

 

I guess step 1 should be just to get the data into software, then from there you can work on converting it into position.  Does the encoder have a more thorough manual that describes in more detail how the data can be decoded?

 

 

Best Regards,

John Passiak
0 Kudos
Message 3 of 49
(12,382 Views)

You'll probably find this helpful:

 

Converting Gray Codes to Their Standard Binary Numbers

 

 

Best Regards,

John Passiak
0 Kudos
Message 4 of 49
(12,373 Views)

John,

 

Thanks for your replies. We have got our hands on some diff line drivers and we're using one DO to supply the 'clock' and one DI to read the signal back in. We have managed to build the required 'clock' signal in labview but since we are using sequential DAQ tasks/wait tasks it is some orders of magnitude above the clock timings listed on the datasheet (as you suggested it would be).

 

We have run this clock through the decoder and the output was less than clean, but we are using some pretty old scopes/connectors so it's hard to tell where the error is coming in. We have built the read-in/gray code/decode tasks into the labview .vi but have yet to test the encoder with this.

 

Unfortunately the datasheet linked on the RS website is the most information we have been able to get - although I am trying to contact the manufacturers about the required timings e.t.c.

 

Regards,

Hugh

 

 

 

Regards,

Hugh Blakemore
Rolls-Royce Plc
hugh.blakemore@rolls-royce.com
0 Kudos
Message 5 of 49
(12,346 Views)

Hi Hugh,

 

Feel free to post the VI you have and I'll take a look to see if you might be able to optimize it.

 

Like I mentioned, there's certainly no guarantee that this will work with a software-timed interface since I'm not sure how long the data on the line remains valid after receiving a clock edge.  All I have to go off of is the specs which indicate that there is a maximum time for the clock period which will not be achievable with software-timing.

 

 

Best Regards,

John Passiak
0 Kudos
Message 6 of 49
(12,328 Views)

John,

 

The .vi is attached - it builds the signal sequentially and reads the data input following the rising edge of each of the ten 'clock' pulses. The sequential structure generates a signal of the correct shape, but as you say not of the correct frequency. We will be testing the read-in facility (to see if it is returning any useful data) today.

 

Our ultimate goal is to measure a small rotation (~5 degrees) with accuracy but with a low response required (the rotation will take place over 10s of seconds). The reason we selected an encoder is for the high accuracy - a potentiometer would do the job in terms of response time but we have been unable to find anything with an accuracy ~1 degree (mechanical rotation, that is)

Regards,

Hugh Blakemore
Rolls-Royce Plc
hugh.blakemore@rolls-royce.com
0 Kudos
Message 7 of 49
(12,323 Views)

John,

 

As you indicated, we have had no success using the USB-6008 DAQ card for our encoder. We have managed to borrow a cRIO 9004, and have used this technique to enable microsecond timing on the cRIO. Since we are only running one encoder from the cRIO we aren't concerned about the effect on the CPU.

 

After doing this we have been able to build a timed sequence with a 1MHz clock signal in labview (we have the RealTime module installed) but get an error message when trying to run the .vi - the message states the cRIO 9002/4 can only be used in LabView FPGA Interface Mode, but the online product page says the cRIO 9004 can use RealTime.

 

It has been mentioned that if we cannot use the RealTime module, we may be able to use the FPGA function to build our signal and take advantage of the hardware clock on the cRIO that way. Do you have any thoughts on this?

 

 

Regards,

Hugh Blakemore
Rolls-Royce Plc
hugh.blakemore@rolls-royce.com
0 Kudos
Message 8 of 49
(12,304 Views)

I'm a greenhand to use Labview software Ver 8.6 with hardware USB 6353 DAQ to get absolute encoder SSI signal , the encoder's specification is http://www.avagotech.com/pages/en/motion_control_encoder_products/magnetic_encoders/aeat-6012-a06/, I try to hookup the pin CSn with p0.0 and CLK with p0.1 and DO with PFI 1, but there always erros show in the Labview DAQ windows. I don't know how to get the right way to acquire the data. I ever sort many diz in this forum, but can't find the one I need, thanks a lot!

 

Best regards,

Hanbo

hanbo@dimec.unige.it

0 Kudos
Message 9 of 49
(10,438 Views)

Would you please help me to solve the SSI absolute encoder using USB 6353? I'm waiting for the help, thanks a lot!

BR

 

0 Kudos
Message 10 of 49
(10,428 Views)