PXI 6602 RT missing pulses

[ThiCop]

Hello Dickbiz,

I had indeed forgotten one thing in the example.

I have made a small adjustment to it.

Please do keep in mind that this is not a final solution and you should also double-check if it behaves correctly when you have a roll-over of your counter value.

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

Regarding the other card (6133) we discussed on the phone.

There is an example (Help > Find Examples) you should take a look at:

- Write Dig Chan-Ext Clk (Write Dig Chan-Ext Clk) Also note that this example uses a Digital Waveform to write to the Digital Output.

In your case you should better use an array in which you add the "wait time" before the actual Digital data. With "wait time" I actually mean that you can adapt your original Digital Pattern (array of booleans) so that it first sends out False Boolean values.

- To this piece of code you should also add a DAQmx trigger that gets triggered by a Digital Edge on the "trigger PFI line"

- Also you should select the right PFI line as the clock source/external sample clock.

[ThiCop]

Hello Dickbiz,

I think I have made a mistake in my previous posts.

After some wondering about how it could work I started to dig a bit deeper

I have been looking back at the code in your original post and doing some further research about the PXI-6602 you're using.

Apparently for this counter card does have the ability to do Hardware Timed Single Point IO and the original code was correct.

Based on you explanation it seems likes method 1 (Hardware timed simutaneously updated io using timed loops) was working the best.

When looking deeper into this code (now with more complete understanding about the specific counter features) I had the following remarks:

- It would indeed be a good idea to remove the for loop from around the inside Timed Loop

- Personally I would also use a normal while loop instead of Timed Loop for the outer loop.

- Did you already log somewhere how many iterations are missed when it is ok and when it is not?
This can be done by looking at the Output Node inside the inner Timed Loop (the one with the "Write Digital Bool" function inside) 

- The cause for this inconsistetn behavior is most likely some kind of jitter in the Timed Loop.

- Can you change the settings in the Inner Timed Loop? (https://www.ni.com/docs/en-US/bundle/labview/page/configuring-timed-loops-and-timed-loops-with-frame...)

The things I would like you to change are

a) the priorities (make it higher than any other Timed Loop in your whole application)

b) the deadline (can you change it to 1 so that if you don't execute the code within 1 tick, then you'll get a "Finished Late[i-1= true" )
If this is one is not set like this, then the defined "Actions on Late Iterations" will never be triggered.

PS: Again my apologies for missing this specific concept for the 6602. I should have seen this faster. 

[DickBiz]

Hi Thierry,

Sorry to inform you but the second version does not work either. Running with a clock of 6000 Hz and the trigger at 50 Hz the first counter tasks reads 4115 and the second in the timed loop 41947 using highlighted execution. It execute the timed loop only once. Changed the trigger to Armstart trigger.

Kind Regards,

Maarten

[DickBiz]

Hi Thierry,

The VI with method 1 (Hardware timed simultaneously updated io using timed loops) is the original method I used in my application. It is working the best because it doesn't give any errors when it is missing pulses. The timed loop can never be aware of a missed tick, and therefor will not give any late finish. Using the other method with wait for next sample clock will give an error about missing clock pulses.

I've tried all your suggestions, removing the for-loop, change the priority of the outer timed loop (running now on 1us), change the outer timed loop for a while loop, deadline set to 1 the inconsistent behaviour will not change.

Back to square one.

Kind Regards,

Marten

[ThiCop]

Hello Maarten,

How do you test the Real-Time VI/application in both cases?

Is the Front Panel of this RT VI open when you deploy and run it (or in other words are you using "Interactive Mode")?

Using Highlight Execution can be used for debugging purposes, but this will not allow you to preserve the correct Timing Characteristics.

The reason is that everything will be executed at a "slower rate" when Using Execution Highlighting.

It is possible to do lateness checking in your application.

I think you might have misunderstood me. I wanted you to:

- Replace the outer timed loop by a while loop: Ok

- Remove the for-loop, because it only executes once : Ok

- Change the priority of the Inner Timed Loop : Not ok
Please also make sure that Ticks is Selected for the Inner Timed Loop

- Change deadline to 1 of the Inner Timed Loop.

Can you also send me the adapted VI where you have implemented these changes so that I can check if my explanation was understandable?

Please also let me know If you're looking at the RT VI's Front Panel while it's executing? 

[DickBiz]

Thierry,

Attached the VI, scope screenshot and VI screenshot with error -201027. The Boolean array is 111100000..

Regards,

Maarten

[DickBiz]

Thierry,

Another run with different error same VI as above. Boolean array 0111000000..

Both errrors ocure independent of boolean array settings.

Attached the scope screenshot and the VI screenshot after error occurs. The scope picture looks more complicated because 2 anomalies occur: late start of the output pulse secondly pulse is longer.

Regards,

Maarten

[ThiCop]

Hello Maarten,

As promised on the phone I would look into the triggering issue you encounter on the 6133.

It is indeed not possible to directly use a start trigger for triggering hardware Timed DO.

However, there exist work-arounds for this that use correlated DIO.

I have made a simple illustration to explain the concept.

Basically you will use an analog input task as a dummy task:

- You will define the triggering (Digital Start) for this dummy task.

- You will also define the External clock (one of the PFI lines) as source for the dummy task.

- In the DO part you will use this special "AI sample clock" as source for the DO task.

I have included an example that illustrates this concept for a non-retriggerable Finite DO task.

[Kevin_Price]

As I said before, I'm not particularly knowledgeable about the behavior of Read or Wait functions during HW-Timed-Single-Pt mode, nor whether RT makes a difference as well.  But just to give you another angle of attack, here are some questions & thoughts that occur to me when looking at your code:

1. Have you tried setting "WaitForNextSampClkWaitMode" to "Polling"?  That'll burn more (maybe too much more?) CPU, but maybe your speed is being limited by your system's interrupt scheduling?

2. Is your counter task counting any actual edges or are you only using the counter task to try to establish hardware-based timing?   If you aren't counting anything real, I would recommend that you configure the task to count edges of your internal

20 MHz clock.  Inside your main loop, preserve the value you read from the counter and send it off to an RTFIFO.  This could provide you with some precise timing information to use when troubleshooting.

3. Since you started your DO task before the inner loop, I'd set the auto-start input to "False".  I kinda suspect that the "True" gets ignored on a task that's already in the run state, but it won't be hard to experiment just in case.

-Kevin P

[ThiCop]

Hello Maarten,

I thought we discussed on the phone to do these tests with the "Hardware timed simutaneously updated io using timed loops.vi 57 KB " VI that contained the adjustments?

Can you do the tests with that specific VI (so that I can see how it behaves with the scope triggered on the trigger pulse)?