I can't look at your code unless you back-save, preferably to LV 2016 or earlier.
If I understand correctly, I'd configure the analog task for retriggerable finite acquisition and then configure the encoder tasks to use the AI task's sample clock. Then they won't need to be triggered, you just need to start the encoder tasks *before* starting AI.
Else, you'll need to look into "Arm Start" triggering for the encoder tasks, which adds a level of complication you probably don't need.
OK, the first order of business (unfortunately for you) is to Learn LabVIEW. Find someone who knows it pretty well and "apprentice yourself" to her (or him) for a few days -- if you are a Master's Thesis student, and they just changed Measurement Systems on you, you want to get up to speed quickly, and almost nothing beats "one-on-one".
Here are some comments:
thank you for the feedback and critical questions.
We finally solved the problem for our application (see attachment, uploaded it in V2016).
We were not able to fit the analog tasks and the frequency tasks into one case structure. Fortunately we have two NI USB-6363 devices. Therefore I can use one for the analog tasks and the other for the frequency (encoder) tasks. Both devices are running simultaneously.
We do not have any LabVIEW experts in our house. For this reason our VI does not look 'professional' but it is doing what it is supposed to.
If someone has ideas for improvement it would be highly appreciated.
My ideas for improvement would require an awful lot of LabVIEW and DAQmx background knowledge which I can't distill into the time and space I have here.
DAQ Assistants and Express VI's make it easy to get started but then leave you stuck near the starting gate. Regular DAQmx and analysis functions would open up an awful lot of important options, but also require a lot more learning time.
This would *definitely* be possible to do on a single 6363 board, though you'd probably still need separate loops for your AI task and your encoder frequency measurement tasks.
The "solution" you have now has an important flaw you should be aware of. Your various tasks are not sync'ed in time. Hopefully you can still correlate the data during post-processing, but I honestly don't know how timestamping information might get handled by the DAQ Assistants, the blue "dynamic data" wire, and the file writing Express VI. There's a possibility you might be losing any chance of correlating the measurements you took.
My recommendation: carefully consider the data you collect now. Figure out a way to evaluate whether you can accurately *correlate* your measurements in time during a post-processing step.
I understand and appreciate that learning LabVIEW and DAQmx isn't a goal of yours, you just needed to dabble about with hardware long enough to solve a particular problem. The main trouble with such dabbling is when something *actually* works just a little bit different than how you *think* it works, due to lack of expertise in the field. That's why I brought up the business about sync and data correlation. Those are things that can potentially set you up to make wrong interpretations and decisions because you get data that looks believable but which is actually not accurate in a fairly subtle way.
So it's pretty important to set up a controlled experiment that lets you properly evaluate your ability to correlate the data. True sync (at the hardware capture level) is simply not gonna happen with your DAQ Assistants.