How to connect digital trigger (DAQmx)

[KNikita]

I would like to be clear: should the trigger channel be signaled or generated in it? That is, connect it to the program as an output (first picture) or as an input (second picture)? Both options don't work for me and I'm trying to figure out what's wrong.
I want a trigger to fire when a button is clicked and run the tasks connected to it.

I asked a similar question a couple of days ago, but decided to reformulate it and make it more specific.

[Kevin_Price]

Sorry, but this is still pretty far from clear.

Neither of the tasks whose screencaps you posted are configured to use a trigger.  I don't really understand what you're asking about, but I can say that neither of those options illustrate triggering.   Have you tried experimenting with the shipping examples like I suggested in the earlier thread?

-Kevin P

[KNikita]

I posted the complete code in another question. Let me explain my main goal - I want two tasks to fire at the same time when a button is clicked. Not quasi-parallel, but parallel. I wanted to do it with a trigger. What I'm trying to write now is test code to understand how the trigger works.
I'm wondering: is it possible to activate a trigger on a button click? So that when the button is clicked, the tasks configured with this trigger will fire. If yes, I should signal or generate on that channel.
Or should I use some other task synchronization methods?

 

 

 

[Kevin_Price]

It seems to me that you've got 2 distinct things to learn about.

1. Starting a task with a digital trigger using DAQmx.  The shipping examples are a good place to get started with this.

2. Basic notions of LabVIEW dataflow, and how you make certain parts of code contingent on things like a user clicking a button.

I'm also getting the sense that the questions you're asking are maybe not the right ones.  You're asking about triggering and button clicks because you think that's your sticking point.  Having been around the forums for a long (long!) time, I've learned that people often get stuck because they went half way down the wrong path and then start asking specific questions about how to continue down that path, thinking *that's* the way to get to their destination.  But sometimes they'd be better off going back to the starting point and taking a different path entirely.

For example: I've been in *numerous* threads that started out with questions about triggering but the *better* approach was to share a sample clock.

So let's back up.  What's your overall app all about?  What are your input and output signals and what do they mean and do out in the physical world?  What are the 2 tasks you want to start in parallel?  Why is it so important for them to be truly parallel and, presumably, synchronized?

Give me a good sense of the big picture -- what the app is all about, what signals you need to generate, what signals you need to capture, and what they all mean to you.  We might end up talking about exactly the things you already asked, but then again we just might find that different questions lead to a better solution.

-Kevin P

[KNikita]

I am writing a program for a physical experiment on light interference. Data from the sensor comes to the analog inputs, and from the output channel I generate a signal for a piezo shifter to change the phase of one of the light rays.
And I want to run these tasks at the same time.
I recently read about software triggers - maybe that's what I need. I want both tasks to run together when running the experiment. I don't have to use a digital trigger.
I found the information, in this case, you need to enter Dev/ai/StartTrigger instead of the source channel (although I saw this only on a couple of sites, there is no such thing in the documentation and on the official labview website) and connect the tasks sequentially. However, here I am also met with an error.

[Kevin_Price]

Two main things.

1. Your trigger source should have a leading '/' character, i.e., "/Dev2/ai/StartTrigger".  I think you must have manually edited the constant b/c the drop-down menu would have gotten it right.

2. This is starting to sound like a feedback control loop application.  If you need to keep continuously adjusting your output in reaction to the sensor values you're reading, then sure enough, this is a feedback control app.

    In such a case, you are indeed at least half way down the wrong path with your pre-defined buffered finite sampling tasks.  And probably the triggering questions too for that matter.

So that leads to a whole other set of considerations.

3. Windows will not give you reliable control loop timing.  It can be good enough for some apps, and definitely not good enough for others.

4. Your output task needs to be software-timed (a.k.a. "on-demand" sampling) by never calling DAQmx Timing to set up a clock and a buffer.  Buffered tasks will necessarily have latency, which control loops don't want.

5. Your input task can potentially still be hw-clocked and buffered, but it should be a continous sampling task and you should read a fixed # of samples each loop to account for your desired control loop rate.

6. So of course, a control loop is going to need, well, a LOOP.  Tasks need to be started before the loop, inside the loop you just read from and write to already-running tasks.

7. If this whole process should only start up in response to a user button click, then you'll have to code up that kind of logic as well.  See the general training resources highlighted at the top of the LabVIEW forum, particularly those under "NI Learning Center".

-Kevin P