delay trigger

[AzimJ]

Hi,

I am trying to program a Labview application.  The application monitors an analog signal.  After the signal reaches a given threshold the VI should send a digital pulse after a user specified delay.  In the attached wire diagram, I simulate the input trigger with the lower loop.  Once the counter of this loop reaches 100 it notifies the main loop with the trigger signal.  The main loop then generates a digital pulse after the given delay (delay in millisecond control).  I think I have the logic right but was wondering if there was a more efficient way to do this.

thanks

Azim 

[tbd]

Hi Azim,

      I'm confused because your post implies monitoring some physical signal, yet there are no references to [reading] hardware in the example - is it the example you want to have be "more efficient" or do you seek the logic to actually read some signal and output a pulse after some delay?  If so, this may be possible without any loops!

What hardware are you using?

If using NI hardware, it probably has counters and they are great for generating easily configurable and precise TTL-level (0 to 5V) pulses.

Here you want to use an analog trigger and I'm not sure whether counters support this type of trigger directly, but I'm pretty sure 

 you could first configuring a dummy Analog Input to use an analog trigger,

then [internally] route the digital AI start signal (generated by hardware when AI starts) to your counter's trigger.

Here's a valuable link. 

BTW: I think your example sends two triggers - one at i = 99, and one at i = 100.

Cheers!

[AzimJ]

Hi tbd

Sorry for the confusion in my post.  I didn't have access to the computer with the hardware when I wrote it so I just created the attached wiring diagram as an example of the type of thing I need to do.  

The hardware I currently have is:

    1.  Intel Core 2Duo CPU 3GHz w/ 2GB RAM

    2. DAQ  NI PCI-6034E connected to a BNC 2110 connector block

The actual application will be continuously acquiring an analog signal  on AI1 in a timed producer loop (PL) with dt=10 . The acquisition is setup as an DAQ-MX task and queued for processing in a consumer loop (CL);  In my example the lower loop was meant to simulate this CL and generate the trigger. In the real application the CL will monitor and perform some calculations on the incoming data and generate a flag once the calculated values match a given criteria (details of the calculation are not important and still need to be decided on).  The lower loop is a simple case of this and just monitors the index until it reaches a certain range (in this case between 99 and 100).  The application then needs to generate a TTL on DO-1 after a delay.  This delay should be a parameter controlled by the user.

I hope my explanation clears things up.  

Thanks again 

Azim

[tbd]

Hi zimR,

      Thanks for the added info.  To address your original question - efficiency - I would try to get away from the 1ms timed loop which is polling for new Notifications.  I'm not sure that a Notifier is best here - especially if it's possible for two triggers to arrive so close together that a new notification has to wait for the end of a pulse-in-process - causing pulses to "stack-up" implying delay problems.  Only you know if this is a reasonable scenario.  If a Notifier is suitable, I'd put it in a regular loop and have it wait indefinately - it will react as soon as it receives a trigger-event. 

Attached VI (in LV 8.5?) shows an alternative method of using the notifier here.

Note.  You could remove the "Triggered" locals completely by wiring the Notification output of the Wait for Notification directly to the terminal and to the AND.

Cheers!

[AzimJ]

Hi tbd

Thanks for the VI.Actually, the program just needs to send a single trigger once the calculated quantities in my consumer loop meet a given criteria. So, in your example when the random number in a specific range (eg 99 or 100).

Your message suggests that there might be another way to proceed without using a notifier. could you explain?  

Also, I notice that in the loop that waits for notification you wired the error terminal of the wait on notifier node to the case structure instead of the notification terminal.  Can you explain why you wired it this way.

Azim

[tbd · Accepted solution]

Hi zimR,

      Thank you for the Kudos!

---

Your message suggests that there might be another way to proceed without using a notifier. could you explain?  

Also, I notice that in the loop that waits for notification you wired the error terminal of the wait on notifier node to the case structure instead of the notification terminal.  Can you explain why you wired it this way.

---

I don't know why, but I thought you might need to re-trigger - in which case the Notifier method seemed to introduce a potential response latency, necessitating a different approach!

In my example the Notifier is being used to:

1) communicate an event (though we don't care what value - True or False - is sent!)

2) terminate the top loop when Notifier is destroyed (in bottom loop)

3) prevent execution of pulse when [top] loop is stopped (by Notifier destroyed)

But since we don't need to re-trigger, the top loop goes away!  So point 2) is moot and point 3) is of questionable value.

The attached example uses the Occurrance to communicate trigger-event instead of a Notifier - see warning-note on diagram!

Cheers!

Message Edited by tbd on 12-12-2008 01:19 PM

[AzimJ]

hi tbd,

Again thanks for your information and help.  I think the occurence model is the right approach for me.

Azim