# Motion high speed DAQ

J

#### Jeremy Pollard

Good morning all - looking for some guidance.

A customer of mine has the requirement of logging data from a multi-line encoder at a rate of 3 meg samples/second 16 bit analog data triggered.

Cust needs a complete turnkey solution, and has a need for 20 a year or so...

This is outside my realm of expertise so looking for some guidance for him.

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

M

#### Michael Griffin

1) Is this a production line tester, a lab bench tester, or a hand held field diagnostics device? There is a BIG difference in how to approach each of these. The hand held is a custom electronics job. The others might be done with PCs and data acquisition boards.

2) Is there a very low target price? Is the customer looking for something cheap and nasty, or do they think they need something fairly sophisticated? If it's the cheap and nasty option, what are they willing to compromise on, and by how much?

3) Log data at 3 Msps. How much data though? How many samples per test, and how many tests per day? Is this data stored forever, or is it discarded after each test? Is just a digest of the test logged? 3 Msps at a continuous rate is over 500 GB per day of data if it is continuous, non-stop logging.

4) What is a multi-line encoder? Are you talking about an absolute encoder, incremental, multi-turn, or something else? What is the interface?

5) The acquisition is triggered by an analogue signal. What does this signal look like? Voltage? Bandwidth? Signal conditioning?

6) How much phase error between the trigger and the data can be tolerated? Nano-seconds? Milli-seconds? Do you need pre-trigger? Post-trigger?

7) Is this just acquiring the data, or does the system need to analyse it? Is a data display needed?

8) Does the test system need to integrate with other equipment?

9) If this involves a PC based test system, then having tens of systems means that it will be important to think about having the software design avoid using licensed libraries or other software components which require per unit run-time software royalties. It's not just the cost, it's also the licensing bookeeping involved.

If the details are customer confidential and you would rather talk about it off line, let me know.

R

#### Robert Scott

Exactly what do you mean by a "multi-line encoder"? Do you mean "lines" as on an optical disk as in a quadrature incremental encoder? Or do you mean multiple signal lines, as in an absolute encoder? In either case, what is the use of a 16-bit analog input? These encoders are inherently digital devices. Unless you mean that the encoder should furnish trigger pulses for taking analog data from some other source. Please be more specific.

Robert Scott
Real-Time Specialties
Embedded Systems Consulting

C

#### Curt Wuollet

You will probably be looking for a solutions vendor rather than just a card vendor. Triggered at 3msps you will probably need fairly sophisticated hardware. I'm thinking of one but I can't remember the name. They had fast stuff but their solution was proprietary and I wasn't interested. Google high speed DAQ and Linux and they'll pop up.

Regards

cww

J

#### Jeremy Pollard

> 1) Is this a production line tester, a lab bench tester, or a hand
held field diagnostics device? There is a BIG difference in how to
approach each of these. The hand held is a custom electronics job.
The others might be done with PCs and data acquisition boards. <

PRODUCTION LINE TESTER

> 2) Is there a very low target price? Is the customer looking for
something cheap and nasty, or do they think they need something
fairly sophisticated? If it's the cheap and nasty option, what are
they willing to compromise on, and by how much? <

TARGET PRICE FROM MY UNDERSTANDING IS > THAN 30k

> 3) Log data at 3 Msps. How much data though? How many samples per
test, and how many tests per day? Is this data stored forever, or is
it discarded after each test? Is just a digest of the test logged? 3
Msps at a continuous rate is over 500 GB per day of data if it is
continuous, non-stop logging. <

UNSURE

> 4) What is a multi-line encoder? Are you talking about an absolute
encoder, incremental, multi-turn, or something else? What is the
interface? <

ANALOG INCREMENTAL?? THE WAVEFORM IS SINUSOIDAL AND THE VOLTAGE VALUE OF THE TWO SIGNALS (SEE PREVIOUS POST) ARE COMPARED FOR PHASE... NOT SURE WHY I USED THE MUTI-LINE THINGY... SORRY.

> 5) The acquisition is triggered by an analogue signal. What does this
signal look like? Voltage? Bandwidth? Signal conditioning? <

TRIGGER IS DIGITAL, AND THE OUTPUT IS ANALOG AS SUCH...

> 6) How much phase error between the trigger and the data can be
tolerated? Nano-seconds? Milli-seconds? Do you need pre-trigger?
Post-trigger? <

UNSURE

> 7) Is this just acquiring the data, or does the system need to analyse
it? Is a data display needed? <

UNSURE

> 8) Does the test system need to integrate with other equipment? <

UNSURE

> 9) If this involves a PC based test system, then having tens of
systems means that it will be important to think about having the
software design avoid using licensed libraries or other software
components which require per unit run-time software royalties. It's
not just the cost, it's also the licensing bookeeping involved. <

TRUE ENUFF... THX.

> If the details are customer confidential and you would rather talk
about it off line, let me know. <

I AM TRYING TO HELP THIS GUY FIND POSSIBLE VENDORS THAT HE CAN GO TO... AND NOT TRYING TO FIND THE SOLUTION FOR HIM. AS YOU CAN TELL MY KNOWLEDGE OF
THE APPLICATION IS LIMITED... AND I HAVE ONLY HAD ONE CUP OF JAVA!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

J

#### Jeremy Pollard

Thx Curt - will research.

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

J

#### Jeremy Pollard

Thx Robert...

The encoder signals are incremental, 1V peak to peak sinusoid. There are two simultaneous inputs that need to be evaluated in relation to each other, and to other external events.

There is a trigger. We just collect the data and then transfer the whole block for offline analysis. The complicating factor is that the time
relationship between the two encoder input is super critical, the whole purpose of the analysis is to quantify phasing error between the two pulse
trains.

Data that is logged is a 16 bit analog value - not sure how that gets there...

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

C

#### Curt Wuollet

There are other ways to handle the phase data that
aren't anywhere near as difficult as acquiring data at that speed and maintaining timing integrity, Most reasonably priced DAQ cards will multiplex a single A/D across several channels. This causes skew and that is bad news for what you want to do, especially if it is not consistent, Although it would require some (small) custom hardware, I would use a one bit A/D for the phase data. That is, I would use very fast analog comparators to capture the zero crossings and then use digital counters to measure the phase relationships. Much, much easier and probably much less uncertainty and scatter. The software would become almost trivial and you would be logging much less data. But, what do I know? :^)

Regards

cww

M

#### Michael Griffin

Let's see if I have this straight. We have the following:

Criteria:
- Two analogue sinusoidal input signals with 1V pk to pk. Let's call these 'A' and 'B'. The fact that the signals come from something described as "encoders" sounds to be irrelevant. We are just dealing with two sine waves.
- A trigger from a separate signal. Let's call this 'C'. This is sometimes described as "digital" and sometimes as "analogue".
- A and B require resolution of 16 bits.
- The sampling rate was described as 3 Msps.
- Data acquisition is controlled by the trigger.
- Size of acquisition is at present unknown, so buffer size is unknown.
- Analysis algorithms are undefined, other than we are interested in the phase relationships between A and B. This could be a knotty problem (or not), depending on the details.
- This is a production line tester.
- Interfacing requirements to other equipment is unknown. It is reasonable to assume that some sort of handshake with a PLC would be required. This is fairly simple, so we can just assume that something is required.

If I have the above correct, I think I can draw the following conclusions (in no particular order):

1) The likely solution would be based on a PC based test system using high speed data acquisition boards.

2) The analysis algorithms have to be properly defined by someone who understands digital signal processing. The advanced math can make your head ache, but some amazing things can be done with these techniques.

3) Doing digital signal analysis on large amounts of data can be very demanding on hardware. The amount of data to be analysed sounds like a critical parameter in knowing the difficulty of the problem.

4) The high sampling rate (3 Msps) combined with measuring the phase relationship between A and B will require using a simultaneous sampling (SS) DAQ board. These have independent D/A converters on each channel. A conventional DAQ board (even high speed ones) would not be suitable as they have one D/A converter which is multiplexed between input channels, which introduces a phase error between signals.

5) Simultaneous sampling boards in the mega-hertz range are less common than conventional DAQ boards. A quick look at some specs on the internet shows a few prospects for 12 or 14 bit resolution, but nothing for 16 bit (I didn't check the more obscure vendors though). Given that getting 16 bits of accuracy out of a complete system is very difficult, this requirement is something you might want to discuss further with your customer (I admit I don't know how critical this spec is to the application). Boards range in price between $1500 to$6000 (depending upon speed, resolution, and the name on the box they come in).

6) Hardware triggering is a pretty standard feature for these sorts of boards. Provided the details of the triggering are not too exotic, this shouldn't be a problem. For example, on a 4 channel SS board, you might have 4 input BNC connectors with a 5th connector for the trigger input.

7) Signal conditioning will depend upon some factors that are not clear from your description. If these "encoders" are the product being tested, then you will need some sort of isolation and protection for the board inputs. If they are part of the instrumentation, then somewhat less protection may be required. In either case, some anti-aliasing filtering may be required.

Equipment Concepts:
a) A PC will contain a DAQ board, and will analyse and store the data. Analysis algorithms are undefined at this time.

b) A high speed simultaneous sampling board will acquire the data.

c) Signal conditioning of some sort is required for the analogue signals.

d) Digital I/O may be required for additional test control, or for handshaking to related equipment. This could be located on the DAQ board, or in an additional digital I/O board.

e) One or more power supplies may be required to power auxiliary test equipment and the "encoders".

f) All of the above would fit into an industrial PC enclosure (e.g. Rittal, Hammond), along with various other auxiliary components.

g) Software could be written in 'C', Python, or a combination of the two, or some other language. There would be screens to display the test results, enter parameters, conduct set-up and calibration, and perform equipment diagnostics. Libraries should be selected to avoid recurring run-time costs. All libraries should be in source code form only (except for board drivers).

h) Given that this is a production tester, fixturing, guarding, etc. would be required.

i) I would expect that adequately documenting a system like this would require an operations and maintenance manual of minimum of 100 pages.

j) The \$30,000 target cost you mention sounds quite realistic, depending upon just what else goes into one of these things. This however doesn't include one time engineering costs.

I hope that the above sheds some light on your problem. I have designed and programmed systems similar to the above, although the sampling rate is higher than I have worked with in the past. If I understand your description, then the concept sounds quite feasible although the potential problems are of course always in the details.

The big issues I see are the analysis algorithms and the amount of data to be analysed. I don't want to harp on those issues too much though. I just want to point out that those will be criteria that have a very significant effect on the design.

I don't know if your customer is someone who intends to use this equipment themselves, or whether they intend to sell it to other people (this sounds likely from the description). If they are looking for someone else to build it for them though, then there are a few other issues I would like to mention. My experience with companies which specialise in custom (one off) test equipment has been that they might understand the DAQ hardware and software fairly well, but they are fairly weak on the mechanical part of it and their electrical workmanship is often not very good.

Your customer might be better off getting the actual building of it done by a conventional small machine builder who does good quality work. They still have to find someone who can actually design and write software for something like this though, and this person would have to be available to help troubleshoot commissioning problems in subsequent builds.

I guess I should also mention that your customer should make sure that they actually get ownership of the design, including all copyrights, source code, drawings, bills of material, etc. Third party libraries (excluding basic board drivers) should have licenses allowing re-distribution and the creation of derivative works.

If you would like to discuss this further, let me know.

M

#### Michael Griffin

The frequencies of the two signals would need to be exactly the same or you would get a different answer depending upon when you took a reading. We don't know if the frequencies are the same. I was under the impression that there were at least two independent signal sources.

G

#### Gilles Allard

That's not necessarily true. Some DAQ boards have a "Sample and Hold" front-end for that purpose. A S&H will hold the analog signals stable while the ADC is busy converting other channels. Phase error is non-existent. The S&H eliminates the need for a converter per channel. The con side is that a faster converter is required. However, for Jeremy's application, I agree that a converter per
channel may be the appropriate solution.

Gilles

C

#### Curt Wuollet

Well, if the frequencies aren't at least harmonically related, the term phase has no meaning. If you are doing waveform analysis you may need all that data. If they are sine waves, the zero crossings and perhaps instantaneous polarity pretty much convey the story. Or am I suffering from fft disease?

Regards

cww

M

#### Michael Griffin

In reply to Gilles Allard: None of the high speed boards that I looked at had sample-hold circuits built in. Sample-hold circuits are usually implemented as external modules that have to be controlled via a signal from the DAQ board.

I haven't seen an off the shelf multi-channel sample-hold module that is fast enough for this application. The ones I have seen seem to be intended for medium speed applications (100 - 200 ksps per channel or less). They are probably best for when you have a large number of channels that you have to sample together, but at a not very demanding per channel acquisition rate.

If you need high accuracy, high speed, and only a couple of channels, then simultaneous sampling boards are a much better choice. In fact, for the sampling rate specified, you would find it difficult to find a board that wasn't a simultaneous sampling board.

If you don't need high speed, then a high speed multiplexed board can sometimes be used instead of a sample-hold circuit. The board can sometimes sample all the channels in close sequence, wait, and repeat (this is sometimes called "burst mode"). The sampling is not actually simultaneous, but if the overall cyclic sample rate is low enough, the channel to channel delay may be small enough to not matter in that application. This technique wouldn't work in the application we have been discussing though, as the specified cyclic rate is too high.

M

#### Michael Griffin

In reply to Curt Wuollet: I'm not saying you are wrong, I am just pointing out that your suggestion requires certain assumptions. We don't really know what the actual application is.

I suspect the "encoder" description was just intended as an analogy. If so, then the "comparing the signals for phase" might also just be an analogy and over simplification. I have limited my assumptions to there being two or more signals to be sampled at 3 Msps and 16 bit resolution and then compared to each other using post processing.

And yes, I wouldn't be at all surprised if there were some FFTs involved in this. I have done some test systems where you inject a sine wave into something and then compare several signals coming back out to each other. Time domain comparison of the signals is very difficult if you have a lot of noise or distortion.

If the application were actually a couple of nice clean sine waves from encoders (or other similar transducers) which were locked together at the same speed, then your suggestion would be a good one. The whole measurement hardware system could be done as a custom board controlled by a microprocessor, possibly with an RS-232 link to the PC to output the results. Given that there are tens of systems potentially involved, it would be worthwhile getting the PC boards made to do this. Of course this is the sort of innovative solution that you can only come up with if you understand the application in detail.

I can think of a few applications where you have to compare two sine waves. In some, a data acquisition board with post-processing is the way to do it, in others some custom external electronics with real-time processing is the way to do it. But in this case, why does someone need 16 bit voltage resolution if all they are interested in is phase?

J

#### Jeremy Pollard

To all that replied - Thank you. I have assembled the responses and sent it off to my buddy who is struggling with this application.

When he determines the avenue which he will travel on I will report back on the whole application...

Help and guidance is really appreciated... thank you!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com