Impact Testing-Time Delay Between Channels?

[Dave_Jr]

Hello,

I think I am having some issues with channel synchronization between my first and second module.

We are performing impact testing on a shock absorber and recording the displacement with a laser (-10V to 10V output) wired into a NI-9237 AI module, and an interface loadcell that is wired into a NI-9237 Bridge module. 

In the program we set a "top of stroke" trigger point which is acquired from resting the impact sled onto of the rod and recording the voltage. Looking at the results, it looks like the force data is lagging behind the position data.

It has also been found that the time difference between the two channels increases when the impact velocity is increased.

We are sampling at 50,000 samples/sec with the onboard clock. I have attached a VI, If anyone has any suggestions I would love to hear them!

[GerdW]

Hi Dave,

at first you should cleanup that VI to follow StyleGuide, like left-to-right wiring. Then you should reduce the amount of Rube-Goldbergs…

You put two channels from very different type of AI modules into just one DAQmx task: the NI9205 uses a MUX, the NI9237 instead uses  SAR for ADC process. (This forces your samplerate of 50kS/s instead of the requested 30kS/s!) As both modules work very differently syncing them by your approach will not work very well…

Does your cDAQ allows you to use the NI9237 clock to act as external clock source for your NI9205 module? This would allow for best syncing…

[mcduff]

---

@GerdW wrote:

You put two channels from very different type of AI modules into just one DAQmx task: the NI9205 uses a MUX, the NI9237 instead uses  SAR for ADC process. (This forces your samplerate of 50kS/s instead of the requested 30kS/s!) As both modules work very differently syncing them by your approach will not work very well…

---

I have not used these modules personally, nor looked at the VI in question, but combining channels in a single task is called Channel Expansion which should handle all of the synchronization details. If the modules can be combined together then DSA and SAR delays should be handled automatically. But @GerdW is correct, sample rates will be coerced to allowed values.

mcduff

[GerdW]

Hi mcduff,

thanks for correction - learned something new (to me)…

Maybe this article will be interesting to the OP.

[mcduff]

---

@GerdW wrote:

Hi mcduff,

thanks for correction - learned something new (to me)…

Maybe this article will be interesting to the OP.

---

That link is nice; I remember it well. But since then I have switched to channel expansion (when possible) and it makes life easier. Only one task is needed, don't need to add anything special, just treat like a normal task, etc.

Below is a screen shot of a program I am working on; two SAR devices (allowed SR up to 1 MSa), two DSA devices (up to 50kSa and 51.2kSa). Interestingly the sample rate is coerced to the 9234 device, max rate of 51.2kSa/s, not the smallest value.

mcduff

[Dave_Jr]

Mcduff & Gerdw,

Apologies for the layout mess. I tried to simply the program to make it easier to look at. The full program is organized much better. Either way both VI's yield the same results.

Do you think I should try and split up the tasks?

I tried using the Bridge module sample clock and it looks the same.

[Dave_Jr]

Mcduff,

Alright, sorry I typed up my last response before I saw this one, So if using channel expansion with only one task is ok, what could cause the time delay I am seeing?

-Dave

[mcduff]

---

@Dave_Jr wrote:

Mcduff,

Alright, sorry I typed up my last response before I saw this one, So if using channel expansion with only one task is ok, what could cause the time delay I am seeing?

-Dave

---

I'm sorry I don't have time now to look at the VI in depth due to meetings this afternoon. A quick look at possible areas to examine:

1. You have filters; filters make delays.
2. Can't say I understand the delay between force and displacement as I don't exactly understand the experiment. Just guessing here. Think of an object on a table that you push to move. The force to move it has to exceed the force of static friction, until the force exceeds that friction, the object does not move. So your force will increase, to a point, without any displacement.

mcduff

[Dave_Jr]

Mcduff,

No worries, I appreciate the feedback!

Alright I will try to remove all the filters and just look at the force and displacement data.

Some background Info on the test:

We are dropping 100lbs from about a foot high onto the shock absorber. The static friction from the seal pack and piston head is very negligible compared to the impact force on the shock from the falling mass. Like you said If this was the case I would expect to see the force rise to a point and then see the displacement take off. However I am seeing the opposite, the mass is falling through about .09" of displacement before the force starts to rise. The shock does contain oil that is metered off as it goes through stroke, and it should produce a reaction force throughout the full 1" of stroke.

Now there can be a small amount of "Dead zone" or free travel if the shock is not filled fully. However this unit has been checked and has a "Dead Zone" less than .01".

[Kevin_Price · Accepted solution]

Ok, after a quick little dusting off of my freshman physics, it seems that after a 1 foot drop, your weight should be travelling at about 100 in/sec (rough order of magnitude here, not super precise).  So the ~0.1 inch delay corresponds to about 1 msec.

The specs for your 9237 show a digital filter delay of about 0.8 msec at 50 kHz sampling.   (Note: this is after taking care to realize that the device can only sample at integer divisors of 50 kHz.   When you ask for 30k, you *get* 50k.   So 50k is what I used in the filter time calc.) 

Whuddya know, right in the same ballpark, eh?  (There's an analog anti-aliasing filter stage as well, which adds just a bit more delay that will correspond very roughly to 1/sample rate.)

So what this says to me is that for some reason, "channel expansion" is maybe *not* automatically compensating for the delay.  Maybe mcduff has some further thoughts -- I know from past discussions he has *FAR* more experience and knowledge about channel expansion than I.

Until then, I dug around in the DAQmx Channel property node and found properties related to the filter delay (AI->General->Filter).  Perhaps you can try explicitly enabling the removal of delay?

This *might* in turn mean that you need to do this after adding the 9237 channel(s) to your task but before the others.

-Kevin P