Leaderboard

The file you get with "Create c. file" is just a function prototype with an empty function. You can of course turn that into a DLL but it won't do anything useful. You can fill in the function with some useful code and then it is a good starting point for your DLL. My usual working method is slightly different. I use the "create c. file" function to create a file containing the matching function prototype, then copy this prototype from that file into the real project C file that I use to implement my DLL. But in most cases I don't even need that intermediate C file as I'm usually able to create the correct function prototype myself.

Just wanted to say thanks. Yesterday I used the built-in Modbus Comm Tester for the first time in an actual project. It worked well and enabled us to validate the Modbus comms to a device that our team hadn’t used before.

Hi everyone, I'm loosing my mind trying to solve an issue about POO, dynamic dispatch and shared reentrancy. An example of my system's architecture is available in the Labview code enclosed. A "Main.vi" runs several parrallel loops (they can be considered as differents processes), each one calling a shared reentrant VI. The loops need to run independently (so I need clones) and shared reentrancy is required by utilization of POO and dynamic dispatch. This subVI contains an uninitialized shift register to have a memory effect between calls of the loop (in the example the subVI is a simple counter). When I run the Main.vi, the first (top yellow) and second (middle yellow) loops don't work properly (counters mix the data). The 2 instances of the shared reentrant subVI are randomly provided to the first or second loop during the execution. I'm surprised of this behavior. Does that mean I can't use any of the NI signal processing VIs (which largely use uninitialized registers) in shared reentrant VIs as soon as several of them are allocated in the same time ? Many thanks for your help, Nicolas Test Shared Reentrancy.zip