Random 200141 error while measuring simple (slow) timeperiods

[cvschinkel]

Hello,

I am measuring the timeperiod between pulses. The period is typically between 0.1 sec and 2 sec. so it shouldn't be too difficult for the pc and the software to keep up. I use a NI PCI 6250 DAQ device.(I also tried swapping this device with a PCI 6024E)  Most of the times there's nothing wrong, but once every now and then the VI fails and gives me an error 200141 (Attachment 2)

The VI is in the attachment. I am using LV 2012 32 bits with NI DAQmx 15.1.1 ; I only recently installed NIDAQmx 15.1.1 because of this error since that tip was given at another topic on this forum.

Thank you in advance for your help.

Christiaan

[GerdW]

Hi cv,

why do you read the counter in a loop running as fast as it can?

What's the purpose if the inner while loop?

When that error only occurs "now and then" then why don't you filter it (or: "handle it") in the loop?

[cvschinkel]

Hi GerdW,

The mainloop is not running as fast as it can, it uses minimally 1 ms. I already tried the program making this 10 ms, but there was no difference.

The inner while loop is to implement a certain dead time.

We detect drops of water with a IR led and a detector, if a drop is between them a timeperiod ends and a new one starts.

Sometimes after a drop a tiny drop comes right after it. We don't want to measure that one, so for that we have the inner while loop to add a dead time.

I don't know how to filter/handle the error. Can you tell me how?

And what does that mean for my measurements?

Kind regards, cv

[GerdW]

Hi cv,

LabVIEW comes with a lot of example VIs, surely there are examples on error handling…

Some logic like this might help:

IF error THEN
  IF error number = 200141 THEN
    clear error
    start measurement again
  ENDIF
ENDIF

[JakeA]

Hi CV,

From what you've described it could be that your sample rate is too high for the system to handle. Have you tried slowing down the execution of the DAQ to see if this eliminated the error? Based on your description of the application I think a lower sample rate would still work well.

Best regards,

[cvschinkel]

The program delays the loop to a minimum of 1 ms waiting time. I have tried changing this to 10 ms, the error still occurred but I have only tried that once, so I don't know how often the error occurs. I can raise this delay even higher, but I cannot go much higher than 50 ms I think, because the time period is at it's minimum about 100 ms. I shall try by raising this delay to 50 ms.

[cvschinkel]

Yesterday I found out some new things. I wanted to test the speed of the system so I used a function generator to simulate the signal. Then I turn up the frequency and I even got to 2 kHz (containing the same error randomly) but the system was not crashing sooner (i.e. to the number of measurements, of course at 2 kHz you have 2000 measurements per second, so if it stops after 1400 measurements it is shutting down faster).

Then I started playing with the knobs of the function generator and I happened to notice that when I tune up the risetime of the pulse the program got more stable. I was able to perform 200K measurements at 2kHz with no problems!

So my theory now is that when the daq is sampling sometimes it samples at the precise moment that the pulse is rising or  falling. That means that the measurement is not 5V or 0V but something in between, a non-TTL signal. If this is the case I think the error that is displayed is incorrect. Now the problem is: I can change the rise/fall time of the function generator  but I can't change the rise/fall time of the sensor. (which isn't actually that high, order of micro seconds). Is there a way to tell labview to ignore the non-TTL signals? Or does anyone have another smart solution?

[GerdW · Accepted solution]

Hi cv,

that's why all (or most) manuals for NI DAQ hardware mentions the "TTL" type of the PFI pins. TTL is more than just some voltage levels, it also defines maximum rise/fall times of pulses!

Instead of telling the DAQ hardware to "ignore" non-TTL compliant pulses you could use a simple (self-made) hardware/pcb to improve the "bad" signals of your sensor to "good" TTL pulses. I usually use a simple 7414-type IC (Schmitt trigger) when I expect "bad" pulses due to noise or long cables…

[cvschinkel]

Hi GerdW,

I think the option with the Schmitt trigger will be the one most elegant. I will try that.

I consider the problem solved. Thank you all for your help.

cv

[cvschinkel]

I mounted the 7414 ic schmitt trigger, the problem seems solved :). thank you all for your help.