PXI 6602 RT missing pulses

[DickBiz]

Based on an external pulse train of 7200 Hz data should be written to a digital port. Writing of data should start from an external trigger pulse. Used two PXI 6602 counters as input and a PXI 6508 as output. Based on the LabVIEW example hardware-timed simultaneously updated i/o using the timed loop (see VI) I can’t get consistent behaviour (see screenshot). PXI controller is a 8176 running on max of 8% total load.

Tried also the method mentioned as Hardware-Timed Counter Tasks (see VI), but get the same inconsistent behaviour and sometimes stopped with a error -209803 (DAQmx Wait for Next Sample Clock detected 3 or more missed sample clocks since the last call to Wait for Next Sample Clock which indicates your program is not keeping up with the sample clock, and data was subsequently lost before it could be read by the application.)

Screenshot signals from bottom to top

D0 7200 hz pulse

D1 synchronisation pulse

D2 output

Analog 2 synchronisation pulse

Analog 1 output (trigger)

New ideas are very welcome!

Regards

Maarten

[ThiCop]

Hello Maarten,

Can you indicate on the picture where the problem is?

Is it the short drop I see on the dimmed signal (at around 75% of the high time)?

I also wanted to ask you where you found these examples?

Was it on the NI website?

Are you in any way limited to this approach or can I provide you with some alternative DAQmx-code that uses anothger structure.

The error you see can be caused by several reasons.

Are you familiar with benchmarking in LV RT?

Is there a specific reason why your using armstart triggers instead of a regular trigger?

One other question.

Am I correct to assume that this is the HW connection?

- PFI39 -> D0 clock

- PFI35 -> D1 arm trigger

- port6/lin0 -> D2 Output

Or is there something else I forgot?

[DickBiz]

Some more explanation about the screenshot. First of all, the scope trigger is on the output signal of the digital port. Input signals are related to that signal. The scope display is set on persist and showing about 100 loops. There are actually 2 problems:

1. There is no fixed time relation between trigger signal (blue) and output (yellow)
2. The output pulse is sometime longer

In my opinion related to the same problem that the VI is missing up to 4 clock pulses.

I’m open for all suggestion to get the Hardware-Timed Simultaneously Updated I/O working other DAQmx code or regular trigger should be ok.

The hardware connections are correct; in the real application I use 32 digital output channels.

I’m not familiar with RT benchmarking, but NI Netherlands did a benchmark back in 2008 for the selected hardware.

[Kevin_Price]

Still not clear on your signal relationships.  Here's what I *think* I understand in relating the screenshot to the code and description so far:

• D0 and D1 are input signals that you want your code to sync to.  D1 is used for the Arm Start trigger and D0 is your sample clock?
• D2 is the digital output pulse you generate.  You have an array of digital states, 1 for each clock on D0.
• Blue & Yellow are analog-related signals.  You're bothered by the timing variability of these signals, but it isn't clear how these signals get generated or how their timing is controlled.  There's no code for it, and you haven't described how the digital timing signals might drive them.

I'm not very experienced with some of the RT timing features you're using so take my comments with a grain of salt.

• It seems doubtful to me that it's hurting you any, but your outer Timed Loop could be a simpler While Loop.  Timed Loops get extra priorty treatment, so I'd get rid of any that aren't really necessary just in case.
• The version that uses an inner Timed Loop driven by the external 7200 Hz pulses generally looks right.  Nothing looks noticeably wrong or sub-optimal.  I would look for a way to log some of the properties available in the Timed Loop to get a more detailed look at iteration-to-iteration timing.  Try it both with and without the call to write your digital bit.
• The version that uses the counter in hw-timed single point mode also looks generally right.
• Offhand, 7200 Hz sounds like you're pushing things a little, but doesn't sound like an unrealistically high speed.  You shouldn't have to be stuck with missing 3 cycles and running at 1/4 that speed.
• Are you characterizing the behavior from the Dev environment, with an active host-side front panel being updated by RT behind-the-scenes?

-Kevin P

[DickBiz]

It seems to be difficult for a non native speaker to be really clear. About the picture, I'm showing only 3 signals, only from the scope side it is named analog. D0 = clock = PFI 39 D1 = analog 2 = PFI 35 = armstart trigger D2 = analog 1 = output = port 6/line 0 This week I'm abroad so I can't try anything. The real application uses 4 timed loops based on the machine control software design concept from the NI website. I've used also the While loop to see if that made live better, but it didn't. Just before I went abroad I run a test with the real time execution toolkit with one of the examples. I noticed two things: if it runs ok the digital write is even spaced. During the intervals the processor/RT OS is just waiting. In one occasion (I run only 5 loops) you can see a delayed write, causing the output pulse take longer. The 7200 Hz is about the maximum rate, but lower rates like 5000 Hz are showing the same inconsistent results. I've run tests in both environments, development with active frontpanel and as stand-alone RT version, same results. Regards, Maarten

[ThiCop]

Hello Maarten,

One thing I would like you to try is to use these VI's in a parallel loop:

https://www.ni.com/docs/en-US/bundle/lvrt-api-ref/page/targets/ni/rt/vi-lib/utility/rt-get-cpu-loads...

I just want to verify that the lateness/discrepancy is not caused by your CPU being overloaded.

Also I would like to ask you if it's possible to make a simple schematic of how the signals should behave and what should cause waht effect.

This way we can test alternative architectures and see if we can fix the problem you're encountering.

[DickBiz]

I’ve changed one of the VI adding CPU load measurement and logging. Running this VI shows not much CPU load as mention before.

Attached a log file running the VI until it stops with an error (see screenshot). The log file contains the elapsed time with the percentage of CPU values. External clock is 6000 Hz. Changed the external clock from 2000 Hz till 15000 Hz, no much difference in CPU load, but showing the same results ending in the -209803 error.

Regards,

Maarten

[DickBiz]

Please find attached a simple schematic of the signals with some explanations.

Kind Regards.

Maarten

[ThiCop]

Hello DickBiz,

My apologies for the late response. I was Out Of Office the last two days.

Tomorrow morning I'm back at the office and I'll look into the other troubleshooting steps/approaches we can take.

I'll call you tomorrow after I have had the time to further investigate this issue.

[ThiCop]

Hello Dickbiz,

I tried to call you this morning, but I couldn't reach you on the phone so I'll continue over here.

After doing some further research I have found the following things.

In the code you sent I see that you use very specific Hardware-Timed IO functionality for implementing your application.

However, if I look at the specs of your cards 6602 (https://www.ni.com/en-us/support/model.pxi-6602.html) and 6508 (https://www.ni.com/en-us/shop/model/pxi-6508.html), then I see that Hardware Timed DIO does not seem to be supported.

However, your code seems to be based on a Hardware-timed approach, but the cards do not support this.

Did someone tell you that this should be possible?

In this case a software timed approach would be more logical.

Somewher earlier on in this thread you also mentioned that benchmarks were done related this set-up.

Can you give some more information about these benchmarks?

To get back to the code you're using:

Only approach 5 form your tutorial would be a valid approach.

Also very important is that with software timed IO the issues you're encountering will most likely be related to software jitter and not purely to CPU usage.

I made a small example of the principle you could use to tackle this issue in a software timed way.

Are the steps I take here understandable for you

The attached Code is provided As Is.  It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments.  You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense

PS: I heard from one of my colleagues that you tried to call me back during my lunch break. Unfortunately I was outside of the office when you called.