cordm

First search result for "labview loop tunnel mode": Auto-Indexing Tunnels with For Loops and While Loops in LabVIEW In your case:

If the time appears for each channel, then you didn't set the loop tunnel mode to last value.

Use probes to check if there is an error: right click the wire and select "Probe" in the read loop. Do Hi_Rate_Volt and Hi_Rate_Trig use the same channels? You cannot run two tasks at once that use the same channels.

Sorry, I misunderstood. So when the threshold is crossed, the Hi_Rate_Trig task should start, but Hi_Rate_Volt should continue? There are plenty of ways to do that. One is to use a notifier for communicating from one loop to another. The loop that should be triggered waits for a notification, which the slow sampling loop will send when the threshold is crossed. The data and type of the notifier don't matter in this case. The triggered task can run multiple times, which may or may not be desired. A notification can also be send while the trigger task is running and it will then run again after it has finished. R_R_9_MTDS_Split_Rec_retrig_CM.vi

Sure, just wire another button to stop those loops.

That is just the first value of the Y array, not its maximum. I assume you want to start the Hi_Rate_Trig task after reaching the threshold, right? Your VI won't do that, because the case structure executes once at the start when the boolean is still false. Get rid of the local variables and use data flow instead. Some more points: either wire a number of samples to read or a duration to the DAQmx Read VIs. That makes your waveforms the same length which makes postprocessing easier. Check what works with your resampling duration For continuous sampling mode, it is usually not necessary to wire the samples per channel terminal. labels keep the block diagram and front panel readable See if the attached VI does what you want. R_R_9_MTDS_Split_Rec_trig_CM.vi

Use the builtin TDMS logging function and set the samples per file via property node (DAQmx Read class): https://www.ni.com/docs/en-US/bundle/ni-daqmx/page/multiplefiles.html R_R_9_MTDS_2_CM.vi

You are trying to wire an array to the case selector. Extract the maximum value from the Y array using Array Max & Min. You might also want to take the absolute value of the Y array.

There is a list of discord servers on the wiki: https://labviewwiki.org/wiki/LabVIEW_Community_Managed_Discord_Servers

The mutex ensures that no one else can perform a read or write while it is locked. Otherwise you could mismatch requests and replies. [W1,R1], [W2,R2] instead of potential W1, W2, R1, R2 You could have it in a non-reentrant VI, but then you would also restrict parallel operations for completely different ports. In this case, in could be wired direclty to out since there are no modifications to it. The mutex will be locked either way.

Here is the original thread: https://forums.ni.com/t5/Actor-Framework-Discussions/Implementing-the-State-Pattern-in-Actor-Framework/td-p/3409456 The VIP contains a project template. Create a new project from that template and look around. It also contains a PDF with more info.

Is the frame size 16 bytes? In the first you use 14, in the second 16. This is slightly faster: The biggest hurdle is converting the endianness, I do not think you can get much faster with conversion. I tried to be clever using BLAS dcopy for copying out the relevant part, but the conversion kills the performance gain. decode-frame-cm.vi

There is a KB article about this: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7OGSA0&l=en-GB We also had this problem when building a large application. You could see the GDI object counter hit the limit in task manager and soon after LabVIEW would crash. After upgrading to LabVIEW 2020 SP1 it went away, though I have not explicitly heard that this problem was fixed.

Have you seen this thread at the NI forum: https://forums.ni.com/t5/LabVIEW/JSON-difficult-to-parse/td-p/3338777? With the built-in method you would have to write some additional code, but JSONText seems to do that out of the box.

"where" without parameters searches in the PATH (https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/where). That environment variable will not update unless you restart your process. (or you jump through some hoops (https://stackoverflow.com/questions/171588/is-there-a-command-to-refresh-environment-variables-from-the-command-prompt-in-w)) Try querying the registry for environment variables that the installer will create (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment).

Seems spot on. NI has a repository https://github.com/ni/grpc-device that contains a "gRPC server providing remote access to NI device driver APIs". At the moment only the more recent drivers are tested.

You have some serious undefined behaviour in your c code. In create_copy_adress_Uint you dereference an uninitialized pointer, writing in a random location. In get_adress_Uint you return the address of a stack variable that is invalid as soon as the function returns. You are going to experience lots of crashing. Have you looked at the configuratrion options for the call library node? You can just pass parameters by pointer. Passing an array by "array data pointer" will let you manipulate the data as in C (but do not try to free that memory). You do not need to make a copy. Be mindful of the lifetime. That pointer is only valid during the function call and might be invalidated later. So don't keep it around after your function returns. If you also want to resize LabVIEW data structures, there are memory manager functions to do that. Pass the array by handle and use DSSetHandleSIze or NumericArrayResize. Examples for interfacing with DLLs are here: examples\Connectivity\Libraries and Executables\External Code (DLL) Execution.vi