Is it possible to abort pulse width generation during the initial delay?

[mola]

Hi

First of all Im' using a PCI 6602 counter card and is programming it in C#.

I seek to create a single inverted pulse on a counter output. The pulse should be software trigged and occur around 200-300us after the trig and I should be able to abort the pulse generation during the initial delay period. See sketch below:

^       

^-------------------------------------                     ------------------------------       

^                                    |____________|       

|-------------------------------------|---------------------|---------------|-------------       

            InitDelay                  LowTime      HighTime      Idle

My problem is the aborting. How do I abort the generation of the inverted pulse, once the start trigger is fired?

I've tried the following without luck:

1) Controlling abort by setting the duty cycle to 0/1 during the initial delay period. This is not allowed and causes exceptions to be thrown.

2) Controlling abort by using a pause trigger. This is not possible because pause triggers are only applicable in Continuous mode.

- The application is time critical, so I do not have enough time to Stop/Restart the entire Task every time I abort.

- I cannot simply wait to fire the start trigger

Does anyone know how I can get around this problem?

/mola

[Kevin_Price]

The requirements are a little unusual so let me make sure I've got this straight:

1. you say the pulse should be software triggered, so it's a decision at some instant in time, right?

2. initial delay will be 200-300 microsec

3. must be able to abort the pulse before the end of the initial delay (before pulse begins)

4. application is time critical

So it sounds like at instant A your software decides to generate a pulse that is "scheduled" via

the "initial delay" property to happen 200-300 microsec in the future.  Then at instant B which is

less than 200 microsec later, your software *may* decide to abort that pulse.

So it seems something else must happen during that interval that your software needs to detect

and respond to.  Why not wait a little longer before making the pulse/no pulse decision, and

use a correspondingly shorter initial delay?

Also, you're counting on multi-kHz decision making loops here.  Are you on an RT system and

does your app have consistent loop timing rates?  If not, much of this discussion is kinda academic

because a non-RT OS isn't going to support such a fast reaction time reliably.

-Kevin P

[mola]

Hi Kevin P

1-4 are all true. I'm running win7 (non-RT OS), but I'm confident that I will be able to react in time on an abort (I have measured this) and if not 99% successful aborts is better than zero for this application.

Let me explain the details a little further, before I argue why I cannot wait to trig the pulse:

1a) The software arming is fired based on another sampled signal's rising edge:

            ____________________________________________________

_______|                                                                                          |____________________________

1b) Which should generate a pulse like this (this is the signal described in the initial post):

_______________    ____________________________________

                           |_|

            |< delay >|

1c) But if the triggering signal (1a) turns out to be noise (too short), like

           __

______|   |_____________________________________________

I would like to abort the generation of (2b).

So, back to you question regarding waiting to arm.

I do not get an deactive transition to act on in (1a) if the signal is not noise - so where would I fire the pulse? -I could of cause rely on a .NET timer or a Thread.Sleep to generate this decision point, but this is where the non-RT OS becomes a problem - it is simply not accurate enough. 

/mola

[John_P1]

Hi mola,

So the pulse is actually triggered off of a hardware signal.  Have you considered using digital filtering which is built-in to the PFI lines of the 6602 (see user manual)?  Although, my understanding of the application isn't complete enough to say whether or not this would be a viable solution.

Best Regards,

[Kevin_Price]

It seems as though you could solve this with the counter hardware.   Have you looked into

doing digital filtering on the PFI line that you wire the external signal into?   That should let

you set up a filter time that weeds out short (noise) external pulses.  The counter task will

only receive a rising (triggering) edge if the external signal lasts "long enough", and you

can still maintain the original timing by configuring a shorter initial delay for the pulse

generation task.

-Kevin P

[Kevin_Price]

Oops, sorry for being redundant.  That's what can happen when you click to start a reply at lunchtime, then get distracted and finally get back to it at the end of the day without checking whether it was answered in the meantime. 

-Kevin P

[mola]

Hi

Using the filter is not an option, because the application uses the number of samples acquired from 1a) (and the known pulse frequency) to compute the precise time of the transitions, which is stored for later processing. Applying the filter would remove pulses from the pulse-train, and thereby ruining the timing of the recorded data, which is not acceptable. Hope this explanation make sense?

/mola

[Kevin_Price · Accepted solution]

Um, how about parallel-wiring the 1A signal to both an unfiltered PFI line (for the counts/timing you just referred to) and also a filtered PFI line (to reject short pulses and suppress your triggered pulse output)?

-Kevin P

[mola]

Hi

Thank you very much for your time (all of you) - I think this will solve my problem!

/mola