200019 error with external clock (6123)

[ms2222]

Hello,

so i am having a problem with the 200019 error which is plaguing me for a few months. For people who dont know what error this is. (http://digital.ni.com/public.nsf/allkb/1275F44215D5C13F862579AE006CA222)

First of all:

It is a tyre testing machine using a rotary encoder in the tyre axis which is used as an external clock. There are analog signals to be measured (voltages -> forces) while the tyre is running. I have an SCB-68A connector block where all the analog signals are connected to, plus the trigger signals from the encoder (Z and A) which go on PFI lines. This block is connected to a PXI 6123 card with a 8820 PXI board. On the PXI the DAQ software is running which is then communicating to the machine PC to send/reveive data and inputs. The machine is in China, so i only have remote possibilities, anything hardware related is a bit complicated to test, because i have to communicate that to the people on site.

The encoder has 1000 increments per revolution which we use as external clock.

The Z pulse is used for triggering the measurement, so that the orientation is always the same.

There are two possible modes:

- static mode for "static" tyre (= not running at the drum) used for calibration and so on which uses the internal clock and no trigger (no error here).

- single sample mode is the standard which is used during automated tests. 9000 samples are used, so 9 full rotations of the tyre. This is with external clock and start trigger. This mode causes the error 200019. 

At random times during automated tests, the VI attached produces this error which then halts the test and so on. Playing with the sample rate didnt do much. I know that using an external clock, the rate mainly influences the buffer size, but either large or small rate do not really help. Also sometimes one day it kinda works, but the next day it does not. The maximum expected Hz with the lowest tyre diameter which running at 400kmh is 84kHz, but realisitcally most tests go to a max of 180kmh and a realistic rate is around 20kHz which is way below the official hardware acquisition rate of max 500kHz. I played with clock ranges from these 20kHz to as low as 500Hz hoping to influence the buffer and other parameters, but nothing really helps. Also it is important to mention, that the error does not occur at highest speed, but is rather random. Often it happens at 80kmh which is generally the lowest speed used in these tests.

I know that noise is often supposed to be the reason for this error, but we currently have another machine which is similar, but I can never produce this error there, even if i try the hardest. So its hard for me to reproduce it where I am currently.

Digital filtering is not available on a 6123 card, so that drops out of the possibilites aswell. (btw where can i find a list of cards which DO support it, because in the product descriptions of several cards, I coudl not find it.)

I have attached the VI (2011) for the DAQ. It is more or less a copy paste of an older version of the predecessor of this machine. When you try to open it, just ignore all missing items, they are not important for this problem (just serial communication with a device). The main part happens in the top loop.

I really need some solution or atleast ideas what more I can try, preferably a software solution, I would be very grateful. I am really running out of ideas with this problem............

[Kevin_Price]

I'm afraid your software options are limited considering that your DAQ board doesn't support filtering on the digital input timing signals.

It seems likely to be a noise issue, where at unpredictable moments, noise is high enough to register as a new sample clock edge.  The description for that error makes it sound like it'll get thrown whenever that noise glitch happens while the task is in the midst of a particular cycle of sampling.

One thought for possibly reducing how often the error comes up is to set the AI task's convert clock to operate faster.  The default behavior on most if not all multifunction boards is to spread the actual multiplexed ADC conversions across the entire sample interval.  Because of this, a noise glitch will almost always coincide with being in the midst of a cycle of sampling.  An alternative is to speed up the convert clock.  Understand that you're reducing your settling time between channels, which could have some side effects of crosstalk or ghosting.  Here's a snippet of a couple DAQmx property node calls you can put in your AI config chain:

That spurred me to take another look at your code.  I see that the sample rate wired to the DAQmx task config is a user input item.   Even though your actual sampling uses an external clock signal, the value you feed to DAQmx to define sample rate still matters.  It's used to choose the convert clock rate, buffer size, and reported time interval on waveform reads.

There's a possibility that at least some of your -200019 errors are due to underestimating the sample rate input and not due to noise at all.  Suppose you estimated the rate to be 20kHz and entered that into the gui input.  During config, DAQmx would choose a convert rate that would spread the conversions across (almost) the entire 50 microsec sample interval, taking into account the # of channels in your task.   Let's pretend you had 4 channels.  DAQmx might place the convert clock at the 10,20,30, and 40 microsec mark within the sample interval.  (Detailed timing rules for a particular board can be found, I'm just giving you the general idea.)   Now suppose that you spin up faster than expected and the external clock goes to 30 kHz.  Your task is still trying to place the convert clock at the 10,20,30,40 microsec marks, but then a new (non-noisy) sample clock comes in too early at 33.333 microsec.  I *think* that'd produce your -200019 error.

Oh, hey, just remembered something else.  You *can* accomplish something much like digital input filtering by using one of your counters.  The counter acts as an intermediary between the incoming encoder clock and your AI acquisition task.  The counter is configured to generate a single pulse and to be retriggerable, using the encoder signal as the trigger.  The total pulse duration pretty much sets the frequency threshold for filtering because any extra triggers arriving in the midst of the previous pulse (whether due to noise or just unexpectedly high encoder speed) are simply ignored.   Your AI task would then need to use the counter's pulse output as its sample clock.

Here's a link to a prior discussion and below is a snippet to illustrate.

-Kevin P

[ms2222]

Thank you for your reply, I have some questions to it.

Just some words I like to use:

- fast trigger = the trigger which is the root of the problem and has 1000 samples per tyre revolution

- slow / zero trigger = trigger which is used as digital edge to start measuring, so that the orientation of the measurement is always the same (1 sample per revolution)

I could calculate the high time depending on the tyre speed, however there is 1 problem. The test machine also performs a test where the tyre leaves the drum at lets say 180kmh, rotates freely and then takes measurements at like 160kmh, 140kmh, 120kmh and so on which means that this high time would vary during a measurement of the 9 tyre rotations (measurement typically starts at around +3kmh and end at -3kmh, so in the case of 160kmh, start at 163kmh, stop at 157kmh). Its a test for measuring tyre unblanace. What do you think about this case, would it work here?

And i am not quite sure at which point in my program would I insert all this. Do I put the stuff you showed infront of my "clock rate" for the AI channels? The AI chain would be unchanged from what I see at the moment except the timing node?  I imagine I can still use the slow trigger for the start of the AI measurement, right? A small sketch would be very appreciated.

EDIT: After I read your ideas I also thought about the following : Can't I use the counter Input of the same PFI line (PFI0) and use it for triggering its AI channels. I read somewhere that counter inputs are used differently within the hardware than the "normal" trigger source. So I am not sure, if the noise translates to the counter inputs instead of trigger inputs. However i have no real idea on how i would go about that practically.

[Kevin_Price]

1. note that the 'rate' input to "DAQmx Timing.vi" needs to be wired with an appropriate value for the test run, according to the earlier comments I made.

2. The key to the approach I described is that the total counter pulse duration should be slightly shorter than the shortest possible tire encoder interval (i.e., highest speed).  This allows the counter to be retriggered and ready just before the next legitimate encoder edge comes in.   Any noise glitches occurring in the midst of the counter's pulse will be ignored by the counter task, cause no output pulse, thus no AI samples.

   For a variable speed test, you'll need to configure for the highest possible speed.  As the actual speed decreases, your noise immunity will cover a smaller fraction of the interval between encoder edges.   But you'll still have *some*..

3. All the counter config would occur outside the main loop so you can feed the OutputTerminal property directly into the AI task's call to "DAQmx Timing.vi".  Note again that you'll need to wire in an estimated max sample rate.   I'd recommend *not* using the 1st snippet at first, wait and see what you get from the counter-based filter alone.

4. For the sake of clarity when talking about data acq here, it'll help to make careful distinction between "triggers" and "clocks".  The once-per-rev pulse acts as a start trigger for the AI task, making sure the acquisition starts at the same physical rotation angle each trial.  The 1000 cycle per rev encoder channel acts as a clock for the AI task, making sure that one sample is taken for each encoder cycle, or 1000 samples per rev.

     The counter-based-filter mod I'm recommending simply puts a little "filtering" on the clock signal.  The encoder "clock" is brought into the counter task and the counter pulse output is fed to the AI task as its now-filtered clock.

5.  The task sequencing I did in the snippet to make sure AI starts before the counter pulse task is probably not necessary in your application.  You can go ahead and start the counter pulse task before entering the main loop.  

-Kevin P

[mhakkine]

Hello. I have Exactly same kind of problem mentioned here. Difference is that wheel is rotating at speed 60 rpm or 120 rpm. Encoder has 10240 ppr. I dod try to implement this counter solution without success. Does somebody have example code? I didn't quite understand how this is implemented to analog input and why timing task needs to started separately.

[Kevin_Price]

Can you give a little more detail - what do you need to happen, what's happening instead, what have you tried so far? 

It'll also help if you can post code.  I for one am still on LV2013, so if you're on a newer version I'd appreciate if you could "Save For Previous Version..." to LV2013 or earlier.

The essential idea here is to use the encoder edges as an external sample clock for an AI task.  This help correlate samples to rotational position directly via hardware timing.   The problem *appeared* to be that the encoder signals may have been noisy and needed some digital filtering to suppress short glitches.   Some boards support such filtering directly in hardware, but the original poster didn't have such a board.  The retriggerable pulse was meant as a workaround that can accomplish a similar effect.

-Kevin P

[mhakkine]

HI, and sorry about the delay...

I have sync pulse (1 pulse per round connected to PFI0 (pin1) and clock pulse to PFI1 (pin2). Both signals come from encoder. SIgnal is so noisy that extra triggers and clock signals appear. I have tried also to use capasitors to filter the signal but without any breakthru. No there seems to be this sw way left.

Unclear is that should I use more digital port with this solution. Attached is my code.