cordm

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